Jump to content

Multisite


apeisa

Recommended Posts

Hi, 

I'm having some issues with the subdomain, the homepage of the subdomain is working but the sub pages are throwing a 404 page. I've made sure to point the domains at the same file area. I've included my config code and a screenshot of the file tree.

$config->MultisiteDomains = array(
    "codeweavers.io" => array( // domain name is used to map to root page
            "root" => "cw-home", // page name for the root page
            "http404" => 27
    ),
    "blog.codeweavers.io" => array(
            "root" => "blog",
            "http404" => 27
    )
);

I don't know if I've set something up wrong or have missed a step, but any help would be appreciated. 

Lucy

Screenshot 2019-10-22 at 09.50.49.png

Link to comment
Share on other sites

$config->httpHosts = array('codeweavers.io', 'blog.codeweavers.io');

Have you set this?

And one other thing that might be a good idea to make it more bulletproof.

Change the root names from cw-home and blog to something like lkajsd and oiquwe to avoid any future conflicts with page names. I learned this lesson some time ago.

Link to comment
Share on other sites

  • 11 months later...

Hi guys,

I'm involved in a project with two main domains, each split into subdirectories representing countries. And finally there will be also a multi-langual function.
So this is the structure:

mydomain_first.global (in english, for neutral visitors)
mydomain_first.global/at/
mydomain_first.global/bg/
mydomain_first.global/ch-de/
mydomain_first.global/ch-fr/
mydomain_first.global/ch-it/
mydomain_first.global/de/

mydomain_second.global (in english, for neutral visitors)
mydomain_second.global/at/
mydomain_second.global/bg/
mydomain_second.global/ch-de/
mydomain_second.global/ch-fr/
mydomain_second.global/ch-it/
mydomain_second.global/de/

Every visitor will be redirected by geolocation to the country of interest.

The goal is, to manage all these domains in one PW installation. For now there is a PW installation with the multisite module (https://github.com/somatonic/Multisite/). 

Аll discussion here are about other domains and subdomains. In our case, we're dealing with subdirectories (a good explanation can be found here: https://neilpatel.com/blog/international-seo/). Sub-directory is a combination of ISO 2-digit country plus 2-digits language codes.

The main reason for managing all this in one PW installation is to keep the later support on a low level. 
Is PW capable to manage this structure?

Link to comment
Share on other sites

  • 11 months later...
On 10/11/2020 at 10:03 PM, neophron said:

So this is the structure:

mydomain_first.global (in english, for neutral visitors)
mydomain_first.global/at/
mydomain_first.global/bg/
mydomain_first.global/ch-de/
mydomain_first.global/ch-fr/
mydomain_first.global/ch-it/
mydomain_first.global/de/

mydomain_second.global (in english, for neutral visitors)
mydomain_second.global/at/
mydomain_second.global/bg/
mydomain_second.global/ch-de/
mydomain_second.global/ch-fr/
mydomain_second.global/ch-it/
mydomain_second.global/de/

Every visitor will be redirected by geolocation to the country of interest.

Hi neophron,

sorry for the year-late answer. I think the first part of your structure, up to the "... will be redirected" (more on that in a bit), is managable in ProcessWire. I have a(n old) MultiSite setup that basically is the same. I have not bothered about the language at all in the $config->MultiSite, and have the what you call subdirectories, managed with the MultiLanguage set up, where I can define the "slots" for the language on the root (pid=1) page. this results in

mydomain.global/  => / is the "name/slot" of the default language (en)
mydomain.global/de/ => /de/ s the "name/slot" of the first language (de)
mydomain.global/it/ => /it/  the "name/slot" of the 2nd language (it)

and so on.

In the $config->MultiSite:

$config->MultisiteDomains = array(
    "mydomain.global" => array( // domain name is used to map to root page
      "root" => "mydomain.global", // page name for the root page
      "http404" => 27
    ),
   "mydomain_second.global" => array( // domain name is used to map to root page
      "root" => "mydomain_second.global", // page name for the root page
      "http404" => 27
    ),

This works fine. What I haven't tried yet, is to redirect in one of those domains directly to a translation. I could do this with a .htaccess rewrite or maybe with a session->redirect() in ProcessWire, but with the inherited set up that "/" is the default language, AND a redirect from "/" -> "/de/" for example, it is difficult to switch back to the default language on that site.

I wonder if

"mydomain.global" => array(
      "root" => "mydomain.global/de/",
      "http404" => 27
    ),

would work, though.
EDIT:
nope. this does not work, I just tested it

  • Thanks 1
Link to comment
Share on other sites

18 hours ago, Webrocker said:

Hi neophron,

sorry for the year-late answer. I think the first part of your structure, up to the "... will be redirected" (more on that in a bit), is managable in ProcessWire. I have a(n old) MultiSite setup that basically is the same. I have not bothered about the language at all in the $config->MultiSite, and have the what you call subdirectories, managed with the MultiLanguage set up, where I can define the "slots" for the language on the root (pid=1) page. this results in

mydomain.global/  => / is the "name/slot" of the default language (en)
mydomain.global/de/ => /de/ s the "name/slot" of the first language (de)
mydomain.global/it/ => /it/  the "name/slot" of the 2nd language (it)

and so on.

In the $config->MultiSite:

$config->MultisiteDomains = array(
    "mydomain.global" => array( // domain name is used to map to root page
      "root" => "mydomain.global", // page name for the root page
      "http404" => 27
    ),
   "mydomain_second.global" => array( // domain name is used to map to root page
      "root" => "mydomain_second.global", // page name for the root page
      "http404" => 27
    ),

This works fine. What I haven't tried yet, is to redirect in one of those domains directly to a translation. I could do this with a .htaccess rewrite or maybe with a session->redirect() in ProcessWire, but with the inherited set up that "/" is the default language, AND a redirect from "/" -> "/de/" for example, it is difficult to switch back to the default language on that site.

I wonder if

"mydomain.global" => array(
      "root" => "mydomain.global/de/",
      "http404" => 27
    ),

would work, though.
EDIT:
nope. this does not work, I just tested it

Thanks for this solution. 

  • Like 1
Link to comment
Share on other sites

  • 2 months later...

Is anyone else having issues with the @Soma version of this module (or the original for that matter) on the latest ProcessWire build? (3.0.189).

I had a ProccessWire install that was working fine with the original module on 3.0.146, but on upgrading it broke.

I've tried downgrading to 3.0.184 and upgraded to the more recent multisite module, but multisite still seems broken.

The home URL works, and menu links for sub-pages are generated, but clicking on any of them returns the 404 page, and entering any domain other than the 'main' domain goes to the home page of the main domain.

 

 

 

Link to comment
Share on other sites

6 hours ago, Kiwi Chris said:

Is anyone else having issues with the @Soma version of this module (or the original for that matter) on the latest ProcessWire build? (3.0.189).

I had a ProccessWire install that was working fine with the original module on 3.0.146, but on upgrading it broke.

I've tried downgrading to 3.0.184 and upgraded to the more recent multisite module, but multisite still seems broken.

The home URL works, and menu links for sub-pages are generated, but clicking on any of them returns the 404 page, and entering any domain other than the 'main' domain goes to the home page of the main domain.

 

 

 

hi,

I have no problems with a 3.0.185 currently, but wait with the update after reading this ?

Link to comment
Share on other sites

I resolved the problem in a bit of an odd way. The 'deprectated' version of the module that I was using mostly worked, except links to site admin somehow ended up broken.

Soma's module didn't work at all. I was able to patch together some bits from the newer module to ignore admin urls, and that got the older module working again fine on my site(s).

It got it working for 3.0.184 but I can confirm it broke again with 3.0.189.

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...
16 hours ago, eydun said:

Has anyone gotten this module working with international domain names, e.g. containing umlauts?

 

 

I can only say, that a domain with an »Umlaut« causes trouble, especially the emails with this domain name. A few years ago, I had to build a website with a domain with an »ü«. I remember how suddenly part of the email was converted into an »xn--«
Since then, when a client want's a fancy Umlaut domain, I'm sending him some informations about alls pro and cons and usually they agree, that it's better without.

Check this:

https://bambule.de/umlaut-domains-ja-oder-nein-unsere-empfehlung/

https://webhoster.de/oe-ae-ue-¬-sind-umlaute-in-der-domain-sinnvoll/

Link to comment
Share on other sites

Just now, eydun said:

Thanks for the reply. I agree, I would never purchase a domain with foreign characters. But a client of mine has already done just that, so therefore I need it for multisite.

 

What about purchasing the same domain name with ue, oe or ae?

Link to comment
Share on other sites

50 minutes ago, eydun said:

Thanks for the reply. I agree, I would never purchase a domain with foreign characters. But a client of mine has already done just that, so therefore I need it for multisite.

Always purchase those Umlaut-domains but although get those ae, oe, ue domains... you can always redirect in any direction.
I maintain restaurants-neumünster.de while everything works from restaurants-neumuenster.de - better to have those domains than be sorry.

Even get those misspelled-domains. Depends on the domain base but... think about it.

 

Link to comment
Share on other sites

  • 6 months later...

In case anyone else finds it helpful, I've been having major issues with both the original deprecated and later version of the module described in this thread not working properly with the latest builds of ProcessWire (>=3.0.200) and it seems like this module hasn't had much love in a long time, but after poking around on Github, I found a fork by @kixe that works for me.

https://github.com/kixe/Multisite/blob/master/Multisite.module

  • Like 1
Link to comment
Share on other sites

  • 1 month later...

@kixe Your fork of the module doesn't allow issue reports on Github, so I'll mention it here.

There is a hook into AdminRestrictBranch module if present to automatically restrict the page tree to the root of the domain in multisite mode.

						if ($this->wire('modules')->isInstalled('AdminRestrictBranch')) {
								if (method_exists('AdminRestrictBranch', '___getBranchRootParentId')) {
										$this->addHookAfter('AdminRestrictBranch::getBranchRootParentId', function ($e) {
												$e->return = $this->rootPageID;
										});
								} else
										$this->warning('AdminRestrictBranch::getBranchRootParentId() is not hookable');
						}

Where this has an issue is that if a user is only supposed to have access to page tree belonging to domain A as defined in AdminRestrictBranch, and then logs in to domain B, the branch restriction defined in their user profile or role is overridden by the hook in multisite. This means if any user knows other domains under the same installation of ProcessWire using Multisite, they can log in and access the page tree of those domains, even if AdminRestrictBranch is configured to otherwise prevent them from accessing them.

A quick fix is to comment out the hook code.

A better fix would be to check whether a user or role already has branch restrictions in place defined by AdminRestrictBranch, and if so, defer to those restrictions, but if not, provide default behaviour as exists of restricting to the root of the domain.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...