Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

We have ten blogs running on a little EC2 instances, we want to see if all the blogs can share the same wordpress php code so

  1. When I update the Wordpress, all the blogs get updated
  2. Save memory in Apache/mod_php as no duplicated scripts or bytecode in the cache (in case of APC).

We cant use MU as we need all the blogs in a separate DB, so when later when we need to move them it would be much more easier.

Anyone have tried this before?

share|improve this question
1  
"instances" or "instance"? –  SickHippie Jul 5 '12 at 21:38
add comment

2 Answers 2

up vote 11 down vote accepted
+50

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.

share|improve this answer
    
Very informative, thanks. –  Yoga Jul 6 '12 at 2:55
    
curious if anyone has the rules needed to do this with nginx and if so, could they share them, or point to an article. I'm wanting to do this as I am using apc, fastcgi, memcache and would love to save on the ram for all the files I have to cache. wpmu is not an option as they are sep client sites on same server with diff users –  shawn Aug 4 '13 at 1:23
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.