gornycreative Posted December 4, 2022 Share Posted December 4, 2022 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. 1 Link to comment Share on other sites More sharing options...
bernhard Posted December 4, 2022 Share Posted December 4, 2022 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: That's the reason why I'm using that syntax all over ? Link to comment Share on other sites More sharing options...
gornycreative Posted December 4, 2022 Author Share Posted December 4, 2022 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. 1 Link to comment Share on other sites More sharing options...
bernhard Posted December 4, 2022 Share Posted December 4, 2022 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 More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now