How to share WordPress core library

2 comments

1. Assuming all the installs are on the same instance and thus can have the same files shared between them, then the main thing you need to do is to have all the custom content stuff live outside of the main WordPress folders.

   So first, you’re going to want a fresh copy of WordPress somewhere, untouched (and untouchable, the whole point is to have a single copy, right?).

   Next, you’ll use hard-links or sym-links to mirror those files elsewhere. Normally in unix-like environments, you use ln -s to do symlinking. How to do this specifically is left to the reader, but essentially if you have your WordPress in /example/wp, you would do something like ln -s /example/wp /home/username/public_html/wp or something like that. If sym-links cause issues, switch to hard-links instead.

   Now, the main two things that live inside the main WordPress folder, but which are custom and not part of “core” are your wp-config.php file, and the entire wp-content folder. So, we need to get these outside of the main /wp folder for each site. Both of these are possible.

   The wp-config.php file is easy, because WordPress also checks a directory up from itself by default. If your wp folder is at /home/username/public_html/wp, then WP will check for /home/username/public_html/wp/wp-config.php, but failing that it will look for /home/username/public_html/wp-config.php as well. So just make your wp-config.php files in the directory above.

   For the wp-content folder, you can reposition it outside the main wp directory by adding code to your wp-config.php file like the following:

    define( 'WP_CONTENT_DIR', '/home/username/public_html/custom-content' );
    define( 'WP_CONTENT_URL', 'http://example.com/custom-content');
   

   And then WordPress will expect the content and everything in it to live there instead. The wp-content folder inside the /wp directory will be ignored completely, so you’ll have to make this folder and put your themes/plugins/uploads in there.

   The last step is to use .htaccess (or some other config files if you’re not using Apache) see the /wp folder as visible from the root, as if it was there. This isn’t tricky, it just requires a bit of thought. See, the normal WordPress .htaccess rules (for non-default permalinks) essentially tell Apache to redirect all requests to the main WordPress index.php file if the request isn’t referencing a file that actually does exist. This allows uploaded pictures and such to work directly, outside of WP.

   Here’s an example ruleset you could use in the /home/username/public_html/.htaccess to mimic this, but also account for the /wp directory.

   Options -Indexes
   RewriteEngine on
   RewriteCond %{HTTP_HOST} ^(www.)?example.com$
   RewriteCond %{REQUEST_URI} !^/wp/
   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteCond %{REQUEST_FILENAME} !-d
   RewriteRule ^(.*)$ /wp/$1
   RewriteCond %{HTTP_HOST} ^(www.)?example.com$
   RewriteRule ^(/)?$ wp/index.php [L]
   

   Essentially, these rules say two things.

   First: If the requested URL doesn’t have /wp/ in it and it’s not an existing file or directory, then change the URL using an internal rewrite to have /wp/ in front of it. This has the effect of remapping all URLs from http://example.com/whatever to http://example.com/wp/whatever. Basically, it makes it work as if /wp/ was actually in the root of the site.

   The second rule changes requests for the root url (just the /) to the /wp/index.php file. This may not be strictly needed, but it works for me.

   This allows the /wp directory to remain “pure”, as it were, and thus you can use symlinks or hardlinks to keep the one-true-WP-install somewhere else, untouched by site-specific stuff.

   Note that many badly written plugins (and even a few themes) may make the assumption that they are in the main wp-content folder. Anything doing something stupid like include '../../../wp-load.php'; or similar will be broken by this approach. This error is on the part of the plugin/theme. No plugin/theme should ever include wp-load.

   Log in to Reply

2. There’s a couple things that don’t make sense in your basic premise. First off, if you have ten blogs in separate instances, then they can’t share the same codebase – ten EC2 instances = ten servers, therefore ten sets of files necessary. Second, you will inevitably have duplicated scripts for the same reason. Can you cross-talk between instances? I don’t think so, but even if you have two sites trying to run from the same codebase, there will be a wp-config.php conflict with database settings at a minimum.

   I’m not really sure multisite isn’t the way to go here. While all the blogs do exist in the same DB, they all have a blog-specific table prefix, making DB backups easier (one DB vs ten) and still allowing for portability (see here for more info). It’s a bit tedious to move one blog out of a multisite, it’s no more tedious than moving a single site to another domain.

   It sounds like what you’re wanting is to have ten different WP environments but only the complete codebase for one of them, and that is the heart of WPMS – one codebase, several sites. So, your requirement of ‘same codebase but not multisite’ is mutually exclusive, which is why it’s been 4 days and no one has answered this. It sounds like you need to rethink your requirements a bit.

   Now, alternately, if you just want to make sure WP is updated globally, maybe consider hooking your core WordPress installs into SVN. You can do the same for individual plugins, as long as they’re in the repository. This way you could simply run a shell script to hit the instances and svn up across all ten at once. However, this seems like a lot of work just to avoid a multisite installation.

   Log in to Reply