Module Multisite

[Guy Verville]

Yes, it look good, Adrian. I will keep my choice to PW to present to the client ;-)

[adrian]

2 minutes ago, Guy Verville said:

Yes, it look god, Adrian. I will keep my choice to PW to present to the client ;-)

Good to hear!!

[Soma]

Wanted to mention that there's a new dev version https://github.com/somatonic/Multisite/tree/dev2 that we are testing and using right now.

It was tested and works with multilanguage and PW3 various features.

[Guy Verville]

Thank you Soma, I will download it. Meanwhile, one question remains, but perhaps it has been answered elsewhere. We will have dev, staging and productions sites. How can we manage a GIT flow around the fact that those sites won't have the same adress? It's easy to keep separate databases and not having the same content, but at some point, we will have to fill the official content in staging, so every "root" addresses will have to be changed. No big deal because it's only 10 subdomains.

dev, staging, prod, naming examples:

dev:

• dev.organization.local
• north.dev.organization.local
• south.dev.organization.local

staging:

• staging.organization.local
• north.staging.organization.local
• south.staging.organization.local

etc.

That's what a mapping table would be interesting. The name of the "roots" wouldn't change in the tree, but the URL would be easily changed.

[Soma]

39 minutes ago, Guy Verville said:

Thank you Soma, I will download it. Meanwhile, one question remains, but perhaps it has been answered elsewhere. We will have dev, staging and productions sites. How can we manage a GIT flow around the fact that those sites won't have the same adress? It's easy to keep separate databases and not having the same content, but at some point, we will have to fill the official content in staging, so every "root" addresses will have to be changed. No big deal because it's only 10 subdomains.

dev, staging, prod, naming examples:

dev:

• dev.organization.local
• north.dev.organization.local
• south.dev.organization.local

staging:

• staging.organization.local
• north.staging.organization.local
• south.staging.organization.local

etc.

That's what a mapping table would be interesting. The name of the "roots" wouldn't change in the tree, but the URL would be easily changed.

That's why the settings are in config.php https://github.com/somatonic/Multisite/tree/dev2#add-multisitedomains

You'd have a config already for both so it's just a matter of having different domain and the root in PW stays the same.

[Guy Verville]

I should have explore this before asking. Thanks again. This is really great.

[renobird]

Hi Soma, all...

I'm hoping to use this module to add another domain to a existing site that is very large, so I can't move the primary domain to a child of the "Home" page.

It's currently setup like this:

Home (Primary Domain)
-- Academics
---- School A
---- School B
---- School C (Needs to be sub-domain)

Is anyone using a setup like this — where the home page is still the main domain as usual, and the subdomain is a nested page?

[MadeMyDay]

Hey Reno,

first, you don't need to have the main domain as a child of the root document. Second, it should be possible to have the subdomain folder somewhere in the tree. Afair the module matches the page name and then rewrites from there, so it shouldn't matter where it is nested in the tree. But Soma surely knows better ;-)

From one of my sites:

 

[renobird]

Hey Marc,

Thank for the quick reply and screenshots. Other than nesting the subdomains, that's the setup I need.
I'll hang tight to see if Soma (or anyone else) chimes in with a gotcha.
Hopefully it will work, because it would make incorporating this existing domain a breeze.

 

[MadeMyDay]

Well, just saw this: https://github.com/somatonic/Multisite/tree/dev2#troubleshooting

My screenshot refers to an older version of multisite (2-3 years maybe?!), but it works... so better wait for Soma. ;-)

[renobird]

That's exactly the bit that got me concerned.

[Soma]

No, the new versions does only support to have all domains in the root.

[Soma]

1 hour ago, MadeMyDay said:

Hey Reno,

first, you don't need to have the main domain as a child of the root document. Second, it should be possible to have the subdomain folder somewhere in the tree. Afair the module matches the page name and then rewrites from there, so it shouldn't matter where it is nested in the tree. But Soma surely knows better ;-)

From one of my sites:

 

I think that should still work. A domain as root (just no config for it) and other domains on the parent root. But then links won't get parsed correctly, as it doesn't "know" the main domain.

[renobird]

Thanks Soma,

I'll take a closer look at the code, I may be able to modify the module to suit my specific needs. Thanks for the quick reply.

[renobird]

Soma,

Just reporting back that the dev version works well for my setup. I did make a small modification so that it just bypasses all the hooks in the ready() function if $config->MultisiteDomains doesn't have a setting for the active http_host. 

[Soma]

Thanks for reporting. I think it's kind of a mess  The newest dev2 version doesn't have hooks (ready()) as to let the internal url for a page untouched. Therefor the replacing href urls on the render output and adding a request logic to redirect to the multisite url was necessary. Unfortunately this leads to problems to the setup you have. It currently assuming the multi domains are setup all in the root. I'm not seeing through all this as it gets kinda complex and not sure how the login can be changed to achieve what setup you have.

[renobird]

I looked at Dev2 for a bit, but Dev seems to work with just the simple mod. Thanks for your work on this.

[renobird]

Soma,

One thing I'm still fiddling with is RTE links. Right now on this test site, there are only a few links in the RTE that link to pages, and almost all of them work fine because they are on the same branch as the subdomain. There will be times that I need users to be able to link to pages up in the main domain (So, other pages underneath the home page). How do you handle that? Did you have a create a custom version of ProcessPageEditLink, or are you using some textformatter magic on RTE fields?

[renobird]

Quote

Therefor the replacing href urls on the render output and adding a request logic to redirect to the multisite url was necessary. Unfortunately this leads to problems to the setup you have. It currently assuming the multi domains are setup all in the root. I'm not seeing through all this as it gets kinda complex and not sure how the login can be changed to achieve what setup you have.

I see now in taking a closer look at Dev2. This all does get complex really quick.

[renobird]

What I decided to do was leave the RTE fields alone. By default that allows subdomains to link to any page in the tree. In our case, this is doesn't present any permissions issues since we don't have editors who need to be "jailed" to their subdomain. I decided to use a textformatter to rewrite the links on output. It's pasted below in the event anyone else needs something similar.
 

<?php

class TextformatterMultisiteLinks extends Textformatter {

    public static function getModuleInfo() {
        return array(
            'title' => 'Multisite Link Formatter', 
            'version' => 100, 
            'summary' => "Converts links in RTE fields for multisite setups.", 
            'author' => 'Tom Reno (Renobird)',
            'requires' => "Multisite"
        ); 
    }

    public function format(&$str) {

        if (wire("config")->MultisiteDomains && wire("config")->httpHosts){
            
            $rootSite = wire("config")->httpHosts[0]; // make sure primary domain is first in config.php
        
            $document = new DOMDocument();
            $document->loadHTML($str);
            $xpath = new DOMXpath($document);
            
            foreach ($xpath->query('//a[@href]') as $a) {
                
                $href = $a->getAttribute('href');

                // Check $href against our domain roots. Rewrite accordingly.
                foreach (wire("config")->MultisiteDomains as $key => $domain) { 
                    $domainPageName = $domain['root'];
                    if (strpos($href, $domainPageName) !== false) {
                        $url = str_replace($domainPageName, "http://$key", $href);
                        $a->setAttribute('href', $url);
                        break 2; // this link was rewritten, so move on to the next.
                    }
                }

                // append full URL if not viewing the $rootSite 
                if ($_SERVER['HTTP_HOST'] != $rootSite){
                    if ((substr($href, 0, 1) == '/')) { 
                        $a->setAttribute('href', "http://$rootSite" . $href);
                    }
                }
            }

            $str = $document->saveHTML();

        }
    }
}

 

[renobird]

A few more things (in case you are wondering):

• Soma's Dev2 branch will probably be sufficient for most setups where you don't have "/" as the primary domain. 
• Modifying all hrefs on page::render is problematic for the setup I have. Ultimately I need to keep the rewrites specific to RTE fields — hence the textformatter.

[diogo]

I'm having a problem  with bootstraping PW in a install with multisite active, as anyone tried that before? As soon as I include the index, I get redirected to another page and the script doesn't run. I also tested accessing it through a subdomain that is not configured in the module, but the result is the same. Is there a way to bypass the module for a specific domain?

[Soma]

@diogo No never experienced that. I can bootstrap normally. What version are you using?

[diogo]

Hi @Soma sorry for the late answer. The version is 006, but I don't think multisite is the problem. Just installed a new multisite locally and I don't get the same problem. I'll dig a bit more and see what really happening.

[diogo]

Turns out that the problem is multisite. I removed emptied the $config->MultisiteDomains array, and the script was called normally and I was able to bootstrap PW. It's really strange, and I don't have a clue what is causing this behaviour in that particular environment (as I said, in a new local install, all worked perfectly) but for now I solved it by bypassing the $config->MultisiteDomains for that particular domain.

if($_SERVER['SERVER_NAME'] == "alt.domain.com") {
  $config->MultisiteDomains = array();
} else {
  $config->MultisiteDomains = array(
    "domain1.com" => array(
      "root" => "www.domain1.com",
      "http404" => 27
    ),
    "domain2.com" => array(
      "root" => "www.domain2.com",
      "http404" => 5332
    )
  );
}