Module Multisite

[LucyFoster94]

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

[wbmnfktr]

$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.

[LucyFoster94]

Hi, 

Yes, I've set the httpHosts (I forgot to add that line in).

I have changed the names of the pages to random letters and it now working! Thank you! 

[neophron]

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?

[Webrocker]

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

[neophron]

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. 

[Kiwi Chris]

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.

 

 

 

[Webrocker]

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 ?

[Kiwi Chris]

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.

[eydun]

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

 

 

[neophron]

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/

[eydun]

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.

 

[neophron]

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?

[eydun]

Yeah, that might be the best (and only) solution.

 

[wbmnfktr]

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.

 

[Kiwi Chris]

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

[Kiwi Chris]

@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.

[neophron]

Hi,

years ago I build a website with about 12 subdomains. It’s representing an association with 12 local groups. There are 12 users, each user has access to only one subdomain. The current cms is Contao (a german cms), some of you probably heard about or worked with.

The problem now is a human one. Many users are uploading a lot of sh*t, such as a ton of almost the same gallery images, that are too big or too small. You can’t educate them by setting limitations like in the fields with PW. I found also whole html tables with inline styles, that were copied from somewhere and pasted into the editor.   

So I’m wondering, if this would be a good strategy, to install PW with the multisite plugin and to rebuild the old website with all subdomains. Which problems could I face with 12 subdomains and 12 users, that should have access only to their subdomain pages?

Does anybody of you guys has some experience of this kind?

[Markus Thomas]

On 2/4/2023 at 6:37 PM, neophron said:

Which problems could I face with 12 subdomains and 12 users, that should have access only to their subdomain pages?

The only problem i see is, you have to do some workarounds that each user only see his own subdomain. Otherwise all users see all sites in the adminarea.

A hook in ready.php could look like this:

$this->addHookAfter('ProcessPageList::find', function ($event) {
    $event->return->each(function ($p) use ($event) {
        if (!$p->editable() && !$p->addable()) $event->return->remove($p);
        else if ($p->template == 'subdomain-home' && !$this->user->hasRole("superuser") && !$this->user->hasRole(strtolower(str_replace(' ', '-', $p->title)))) $event->return->remove($p); // title from homepage and userrole have the same name
    });
});