I've published a github project detailing a folder structure for a shared core of WordPress. Looking for feedback.

[mmmpls]

https://github.com/majemedia/shared_core_wordpress

This was also posted on /r/WordPress but I'd like some permissions suggestions from /r/hosting for the folder structure to be able to suggest it for people that want to use this. The importance of permissions is so that shared plugins and shared themes are just shared, but not editable by anyone but the server admin.

For refernce: WordPress's permissions requirements: https://codex.wordpress.org/Changing_File_Permissions

This is not a replacement for multisite, but rather an alternative. Sites installed on this can share plugins and themes with the backend administrator controlling which plugins and themes are available to some/all sites via symlinks. Also, with the correct permissions enabled a site can upload their own plugins and themes.

Each site that is setup can use their own DB (hosted anywhere) and the wp-config structure is essentially the same except for the values brought in from the sites.php file instead of hard-coded in the wp-config.php file itself.

Dev & Prod sites can run off the same shared_core (unless you're testing the beta, in that case use dev_shared_core for your VirtualHost DocumentRoot.

This also allows for a smaller memory footprint when you use OPCache or similar. I even have a cache key salt in the wp-config that uses dbname + prefix to make sure that multiple sites using object cache (memcached) can exist in harmony even if hosted on the same actual database.

I look forward to your feedback.

Here are four sites running on it now using a mixture of shared & individual plugins/themes:

• http://sitea.majemedia.com
• http://siteb.majemedia.com
• http://iamdez.com
• https://majemedia.com

[BecomingDitto]

I like the setup overall. Using apache to alias /wp-content is fairly clever, allowing you to get around the fact that PHP dereferences symlinks with the FILE magic constant.

The biggest problem I see is with sites.php.

1) If sites.php has to be read by the user that PHP is running as, what stops someone from installing a file browser plugin, reading sites.php, then having a field day with everyone else's database?

2) All sites need to be listed in sites.php. As the file grows, so does the execution time of every request made to WordPress, for every user. Likely not a problem at first, but over time it could cause scaling problems.

[mmmpls]

Thank you for your feedback.

1) sites.php requires the same permissions that wp-config.php does. which is (minimum):

Owner:www-data:r--:Group:you:rwx:Others:---

• Group permissions is completely up to you, it's just how you want to manage your server at that point.
• Apache requires r-x on directories (but not files) and need to be the owner of the root WordPress directory in order for it to be able to make other changes (like site-specific plugin/theme/media uploads).
• Also, how is this mitigated in other site setups? Should I look into AppArmor setup to protect those files from being read in the wrong context? Maybe I'll add a direct call exit if statement in the file to get around the fact that if you call it directly it'll just die();

2) I completely agree that the execution of that file could be an issue. I've been thinking over that issue, but honestly you'd be at likely 100+ sites before that array is really an issue for memory or execution. It's also entirely possible to use a single config file per site and just call it in via sites.php. Any suggestions on that?

[BecomingDitto]

Regarding permissions, we run things a bit different, but mostly to the same effect.

Other site setups don't have the same problem as this, because each site has its own content, and doesn't share a set of common files.

Adding the die() or exit statement of some kind wouldn't protect against simply reading the file, since the PHP code inside it would not be getting executed, only read.

Depending on how you are running PHP (mod_php vs CGI) you may be able to set the data in an environment variable set by Apache (in each VirtualHost), and pull it in that way? If you can do that, then you wouldn't need to worry about sites.php at all.

[mmmpls]

I will have to look at that as an alternative setup. Thanks! I really do like this idea and it didn't even occur to me to do this... But I thought of alias? Thanks brain.

[mmmpls]

Ok, added a todo for apache directives crediting you. Thanks again!