Recent WordPress versions have supposedly enabled the ability to separate the core WordPress files from the site-specific files, but I found it hard to find clear information on how to do it. Here’s the method I ended up using.

For some reason this has been touted as the “Clean Subversion Repositories” feature. They really mean “Clean Subversion Working Copy”, but in fact Subversion doesn’t really care about other files in its working copies. The feature is mostly useful for people who don’t have command-line Subversion access in their blog file systems. With the core files separated, you can upgrade simply by deleting and copying in a single directory. This is a big improvement to the previous version, which require a tricky piecemeal copy.

The problem is that there’s no definitive documentation on how to enable it. It’s annoying that the WordPress team list this as a new feature, and then leave it up to the users to figure out how to make it work. You could look at the Trac ticket for this feature for more information. That’s what I did; if you want to enable it too, you could do worse than start with my method.

Do this at your own risk, of course. It’s worked for me on the one site I’ve tried it on, but I haven’t yet been brave enough to do this on Semicolon yet.

To have your blog at http://example.com/semicolon, with the content and config files in /home/web/semicolon/. and the core files in /home/web/semicolon/wordpress/, here’s what I would do.

1. Install WordPress in /home/web/semicolon/wordpress/
2. Copy index.php from /home/web/semicolon/wordpress/ to /home/web/semicolon/
3. Edit your new index.php. Replace the line
require('./wp-blog-header.php');
with
require('wordpress/wp-blog-header.php');
4. In WordPress, go to Settings and set your Blog address (URL) to http://example.com/semicolon

Make sure everything works OK. Next comes the scary bit.

5. Move (don’t copy) wp-config.php and wp-content from /home/web/semicolon/wordpress/ to /home/web/semicolon/
6. Edit your new wp-config.php. Add the following lines just before the line that says “/* That’s all, stop editing! Happy blogging. */”

define( 'WP_CONTENT_DIR', dirname(__FILE__) . '/wp-content' );
define( 'WP_CONTENT_URL', 'http://' . $_SERVER['HTTP_HOST'] . dirname($_SERVER['SCRIPT_NAME']) . '/wp-content');

That’s all! Test. Enjoy. Now your own files and content are in /home/web/semicolon/wp-content/ and /home/web/semicolon/wp-config.php. All system files are in /home/web/semicolon/wordpress/, which can safely be deleted and replaced by an upgrade any time.

Now apparently there may still be some problems with plugins and with file uploads. This may explain the complicated instructions in the WordPress Codex, which involve editing the .htaccess file. Yikes. A feature that requires you to edit .htaccess is an unfinished feature. My method is more like the other Codex method described in Editing the config file, except it’s more generic. I haven’t found any problems yet with my approach — but that doesn’t mean you won’t. Break a leg.

Tags: WordPress