Jump to content

Multisite support


gornycreative
 Share

Recommended Posts

Hi @bernhard:

I tried to use this in a multisite environment, but /site/ is hardcoded in a few places rather than use of the $this->wire->config->paths->site value.

In particular the StylesArray.php class where paths get passed to LESS methods,

Also the excludeDefaults paths in LiveReload.php

In the main RockFrontend.module there is hardcoding in the renderMatrix method - I haven't used it yet, but I noticed it going through.

A way to reproduce might be an installation where you rename the /site/ folder to something else - as in multisite the different site folders are generally called something like 'site-domain' or something similar.

I guess I am the only one who still has some multisite installations, but for some projects it make maintenance simpler and more consistent.

 

 

  • Like 1
Link to comment
Share on other sites

Hey @gornycreative thx for that find.

I don't really like the word "hardcoded" here, because RockFrontend is actually using smart paths where /site/... is not really a hardcoded path and would also work on installations in a subfolder like /foo/site/...

But obviously I did not think of multisite environments 🙂 

Maybe it would be enough to do a str_replace in the path here? https://github.com/baumrock/RockFrontend/blob/825caa131e7bca6e988f34e0bbb6d4cd17e33e15/RockFrontend.module.php#L690

Above that line you could add this:

      $path = str_replace(
        $this->wire->config->paths->root."site/",
        $this->wire->config->paths->site,
        $path
      );

Maybe that already works?

Having to replace all occurrences of /site with $config->paths->site would also be an option, but I'm not sure if I like that. What is really nice with using /site/templates/... paths is that the IDE gives you hints of the available files and folders:

JCjv41b.png

That's the reason why I'm using that syntax all over 🙂 

Link to comment
Share on other sites

You don't have to support multisite with your tools - it just will make sense to mention that in your feature set.

If a person installed multisite according to the tutorials/instructions provided on the PW site:

https://processwire.com/docs/more/multi-site-support/

Under option #1 they typically will have a directory structure where their main website install is under /site/ and subsequent sites start in tmp/site and then are moved under /site-1/ /site-2/ or something similar.

For example, a person installs a new /site-3/ and decides they want to try your front-end plugin. They add your module to /site-3/ and want to install a new uikit profile there.

They might be shocked and upset to find their /site/ folders and files were modified. I'm guessing you'd hear about it.

  • Like 1
Link to comment
Share on other sites

20 minutes ago, gornycreative said:

They might be shocked and upset to find their /site/ folders and files were modified. I'm guessing you'd hear about it.

I've had a look into the module's settings and both fields that download to or modify the /site folder clearly state that 🙂 So if one is using the module on a multisite installation that does not use the /site folder he/she should be clear about what RockFrontend will do and if that is a good idea for his/her installation.

But I'll add a note in the readme.

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
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...