Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Multiple Domain Names pointing to same GS installation
#1
What I am trying to achieve is that the same GetSimple content is served for different domain names that I own.
I.e., after entering the site, the client should keep seeing the domain name (s)he entered the site with
- in the browser URL line
- in the status line, etc., for all links, image tags, etc. that the user hovers over

Unfortunately, the GetSimple settings contain a simple domain.name/GS-contents-path/... URI to define the subdirectory in which GS and its contents reside, so it forces the domain.name for all further clicks.

The paths should be the same (as is the content), but the domain shouldn't revert to the one defined in the GS settings.

(It is not a big deal to define a server proxy, even from a different host/domain that one also owns, to point to the various pages, and the paths to all the pages of the basic GS installation work correctly, with the original domain name, but the domain name doesn't stick).

I am not really knowledgeable about rewrite rules and barely have a nodding knowledge of simple .htaccess files.
There seems to have been a 2011 plugin from dominioit (and even a demo site http://site2.dominion-it.co.za , which is still running), which seemed to manage multiple domains from the same GS installation (don't know if that also meant, shared content), but it is no longer available in GS extend (if it ever wasSad ).

Any suggestions or references to existing solutions (plugins, rewrite rules) in this forum or elsewhere (in that case, my apology for not finding the stuff myself)?
Is there a way to grab the referring domain name and force it in all references?
I already use get_site_url() in a component to prefix all internal links. Maybe it is just possible to patch the domain name before returning it from such a component.
Ideally, all relative links (e.g., in <img src=...> <a href=...>, some metatags) could be prefixed in a similar way.
But there may be smarter solutions.
Reply
#2
would relative url hack not suffice?
NEW: SA Admin Toolbar Plugin | View All My Plugins
- Shawn A aka Tablatronix
Reply
#3
(2017-07-01, 02:21:24)shawn_a Wrote: would relative url hack not suffice?

What do you mean with relative url hack?  Is there any relative url support in GS 3.3.13 or is that for GS 3.4? 
The purpose is to have the same multilingual i18n site, where visitors from another country (and the corresponding language), don't ever get to see the base country's domain (not in the url line, not in the status line, and preferably not in img, metatags for those who would inspect the html source in their browser's dev mode).

I want to avoid maintaining separate sites (my pre-GS situation). Tests for language/vistor_country can easily be built into the common contents/components.

Thanks for your response.
Reply
#4
Sounds like you need relative urls AND rewrite rules.
hmm, cant think of anything but custom rules and custom code
NEW: SA Admin Toolbar Plugin | View All My Plugins
- Shawn A aka Tablatronix
Reply
#5
(2017-07-01, 03:33:25)shawn_a Wrote: Sounds like you need relative urls AND rewrite rules.
hmm, cant think of anything but custom rules and custom code

The admin settings page has a field for the http(s?) path to the GS root folder.
I suspect this path is used all over the place for admin pages, but also for pages that normal visitors see.
Would it be feasible to 
-use some place for the domain, e.g., $domain or (% domain %) or %domain% and get that expanded wherever needed into the right domain string, and 
-have a way for such a variable to be set to the actual domain that shows in the url line (either automatically, or by the theme/plugin/... dev)?

OTOH, currently, some of the hard links in the visitor pages are still generated by my own components/templates (because I have only recently been facing the multiple domain requirement), but that, at least, is easily fixable.

(I hope such an idea wouldn't open a security can of worms)

Also, I am still puzzled by the question as to what are the obstacles to relative links in web pages? Is it the links popup in CKEditor? Are there some versions of GS building blocks in the pipeline that would facilitate the use of relative links?

I remain grateful for your supportive answers and for the excellent GS CMS.
Reply
#6
(2017-07-01, 02:05:18)vanfruniken Wrote: What I am trying to achieve is that the same GetSimple content is served for different domain names that I own.

I assume, all of your domains are on the same server?

Then make as much GS installations as you own domain names. In one of these installations (let's call it "main installation") you'll edit the content. In all the other installations you change the GSDATAPAGESPATH in the file /admin/inc/common.php so that it points to the GSDATAPAGESPATH of the "main installation".

Look at line 116 of common.php:

change
PHP Code:
define('GSDATAPAGESPATH'GSROOTPATH'data/pages/'); 
to
PHP Code:
define('GSDATAPAGESPATH''/server/path/to/this/installation/data/pages/'); 

That's all.

Alex
Reply
#7
(2017-07-01, 22:42:09)Alexander_ Wrote:
(2017-07-01, 02:05:18)vanfruniken Wrote: What I am trying to achieve is that the same GetSimple content is served for different domain names that I own.

I assume, all of your domains are on the same server?

Then make as much GS installations as you own domain names. In one of these installations (let's call it "main installation") you'll edit the content. In all the other installations you change the GSDATAPAGESPATH in the file /admin/inc/common.php so that it points to the GSDATAPAGESPATH of the "main installation".

Look at line 116 of common.php:

change
PHP Code:
define('GSDATAPAGESPATH'GSROOTPATH'data/pages/'); 
to
PHP Code:
define('GSDATAPAGESPATH''/server/path/to/this/installation/data/pages/'); 

That's all.

Alex

Thank you so much for your suggestion. Currently not all domains are on the same server, but if the idea works, I can make it so.
All it takes, then, if I understand you correctly, is that the GS installations have access to the same file space.
Reply
#8
This wont work because the pages cache is still loaded from data/other
NEW: SA Admin Toolbar Plugin | View All My Plugins
- Shawn A aka Tablatronix
Reply
#9
(2017-07-02, 03:41:42)shawn_a Wrote: This wont work because the pages cache is still loaded from data/other

So what about changing these two lines into
PHP Code:
define('GSDATAPAGESPATH''/server/path/to/this/installation/data/pages/');
define('GSDATAOTHERPATH''/server/path/to/this/installation/data/other/'); 

I tried it out and it works on my server. Is there a malfunction I don't see?

Alex
Reply
#10
Should be okay, ill try to think of cons.
NEW: SA Admin Toolbar Plugin | View All My Plugins
- Shawn A aka Tablatronix
Reply
#11
Thanks @Alexander, but I don't think your solution preserves the domain in the url line.
Update on what I did:
(Problem: allowing multiple sites to access the same GS hosting, preserving the referring site's domain name in the url line)
It turns out that GetSimple 3.3.13 does seem to accept relative links of the form ./slug or slug (assuming permalink expansion %slug% without %parent(s)%)
This also makes it possible to move a site to another location by just copying the entire site, (and editing the website url in the settings).
I have a proxy redirect from another hosting (where I can't introduce my own url rewrites). It points to a subdirectory in the main site, with prefix /GS/.
I wrote a component which patches urls so they become relative (mySiteUrl) and which contains a kludge that removes the /GS prefix when necessary.
The trouble with relative addresses is that CKEditor doesn't even see them (and it always reverts to an absolute address when switching from html source view to WYSIWYG mode), so they must be inserted using the html source view.
Anyway, I can make relative links work for me (both for slugs and data/uploads/ paths as for "img src=") and I can make links relative using my component (EXCEPT when I include the component using dynpages in a html source construct like <a href="{%mysiteurl%}slug">linktext</a> -- that doesn't seem to expand the prefix **reliably**: it must have something to do with execution order of the GS engine)

It further turns out that some plugins generate absolute addresses (taken from the path in the settings), such as the i18n nav menu by mvlcek. Luckily for this case a custom component can provided to implement the menu link rendering (which I did to convert his absolute links to relative). But for other plugins, such as the i18n searchform there is no custom rendering option, so that won't work.
Sorry to say, but this reliance of GS on absolute addresses with a prefix as defined in the settings, is rather frustrating. I hope GS 3.4 will address this concern.  (I know there is a thread on that topic, but I wonder if there is already a final solution that could be applied to 3.3.13 e.g., by patching gsconfig.php)

Am I making things too complicated? Any suggestions?
Reply
#12
Your supposed to make the settings url relative...
What is the difficulty your having? this is explained all over forums.

Remove type url from input or manually edit website.xml

The plugins there is no way around that, but there is solutions to all this in 3.4 already.
NEW: SA Admin Toolbar Plugin | View All My Plugins
- Shawn A aka Tablatronix
Reply




Users browsing this thread: 1 Guest(s)
Free HDTV Channels Residential Solar Panels