Smokes your problems, coughs fresh air.

Tag: WordPress (Page 3 of 3)

Untangling WordPress’ core files from your local customizations

Since version 2.6, WordPress can be installed in its own directory, separate from your customizations and everthing. Needless to say, this makes upgrading a whole lot easier.

If, in the pre-2.6 days, you wanted to fetch your WordPress updates through SVN, the docs would advice you to do an svn checkout from the official WP SVN repo in your working dir and then do an svn update whenever you want to update WordPress. This works because svn update leaves local modifcations alone. However, this means that you’ll be unable to commit your local changes (configuration, themes, plugins, etc.) if you choose this route.

I used my own subversion repository for my blogs and thus had to upgrade the old fashioned way with each release (although I prefer diff/patch over rm/cp). (I could have used vendor branches, but, clearly, I hadn’t thought about that at the time.) This was pretty much a royal pain in the ass, so I was glad when I could move WordPress into a separate directory with its 2.6 release.

This process consisted of removing everything except wp-content/, wp-config.php, .htaccess. (I also kept robots.txt, favicon.ico and some other personal files.) Then, I added the current WordPress release as an svn:external.

svn propset svn:externals 'wp-factory http://svn.automattic.com/wordpress/tags/2.6.1' .

.htaccess changes

In the WordPress codex, it is then suggested to copy index.php to the root dir and to change it to require wp-factory/wp-blog-header.php instead of ./wp-blog-header.php. I preferred adding some mod_rewrite voodoo of my own to .htaccess, so I did:

<IfModule mod_rewrite.c>
# This way I don't need directory indices
RewriteRule ^$ /wp-factory/index.php [L]
 
# This way WordPress can manage its own block without doing any harm
RewriteRule ^index.php /wp-factory/index.php [L]
 
# Allow easier access to /wp-factory/wp-admin/
RewriteRule ^wp-admin http://%{HTTP_HOST}/wp-factory/wp-admin/ [L,R=301]
</IfModule>

The middle rule performs most of the magic. It redirects all the requests to /index.php to the factory default index.php. This means that I can let WordPress pretend that index.php does live in the root, so I don’t have to modify the rewrite rules that are managed by WordPress itself:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress 

wp-config.php changes

In Giving WordPress Its Own Directory in the WordPress Codex, it is suggested to change the “siteurl” and “home” options through the administration panel. In my case they would have to be changed to “http://blog.bigsmoke.us/wp-factory/” and http://blog.bigsmoke.us“. I couldn’t do this because I override these with WP_SITEURL and WP_HOME in my wp-config.php. This is because I configured WordPress to support a development environment separate from the live production environment.

Ignoring the customizations for my development environment, these are the relevant settings in wp-config.php:

define('WP_HOME', 'http://blog.bigsmoke.us');
define('WP_SITEURL', WP_HOME . '/wp-factory');
 
define('WP_CONTENT_DIR', dirname(__FILE__) . '/wp-content');
define('WP_CONTENT_URL', WP_HOME . '/wp-content');

BTW: I really like it how WordPress disables the form controls for siteurl and home when you override these settings in wp-config.php. Kudos for that, devs!

Next time: git

In the end, this is all quite a bit of pain to compensate for what is essentially a version management problem. That’s why, on my newer projects, I’m now using git which makes forking and tracking an upstream repo absolutely trivial. 🙂

A few references

New theme

After upgrading to WordPress 2.5.x, I had to fall back on a stock theme because my old customization of the Sandbox theme no longer worked with the upgrade. But, then, it was time to redo my theme anyway. So here you’re looking at the first version of my new theme. I might have let it stabilize some more before putting it on-line, but who cares? My reader maybe? Let’s just hope he or she doesn’t use IE. 😉

Screencap of my new WP theme Screencap of my new WP theme Screencap of my new WP theme Screencap of my new WP theme Screencap of my new WP theme

Vertical navigation

Ever since the first time that I saw a blog which featured vertical navigation instead of the typical columns, I’ve wanted to implement this for myself. Well, finally…

Site-wide elements use the complete width of the page. The page content is centered in the middle at 87.5%. The identity stuff in the header and the navigation in the footer sits against a back blackground while the content area has the proven black on white for easy reading. I hope that the strong color-contrast as well as the clear difference in with between site-wide elements and page content makes it easy to keep focused on either reading or navigating without distractions.

… and a talkative footer

With this theme, I didn’t want another footer which consist of the odd logo and some loose copyright statements. I wanted a footer which you can actually read, even understand. And who cares if it takes up a little space? It’s at the bottom of the page.

Related posts

I’ve written an (unpublished, unpolished) plug-in which can generate a list of posts that are chronologically related. Traditionally, most blogs have a next/previous post link at the top and bottom of each post. This works very well if you limit your blog to one subject (which is really a very good idea anyway), but if, like mine, your blog is a little bit messy, you could say that someone who stumbled here searching for an article about Subversion is not necessarily interested in the next post if this is a photo of my baby niece.

Hence the chronologically related posts plugin. With this plugin I can say wether I want a link to the first, previous and next post in the blog, within the same category, or matching a given number of tags. (The tag matching isn’t implemented yet, though. Also, matching on meta fields would be a kick-ass ass way to support explicit sequences.)

I put the list generated by this plug-in on top of a blue background besides the various context links of the post.

Issues left

I hope to have the first major revision of my theme ready soon. Here’s a list of some issues that I might address:

  • The CSS renders a bit psychedelically in MSIE 6 (only version I tested) at the moment. Sigh… Let’s just hope that IE 7 will give better results. Then I’ll gladly drop the IE 6 support.
  • When viewing a category, the tag cloud in the navigation panel at the bottom only shows tags for that category. This has to do with the use with me calling the st_tag_cloud() from within the category template.
  • Some of the elements that I just showed to you don’t really look that good and most elements that I didn’t can be said to be … hideously ugly. 😕 Some highlights: the header (should really be a few cool images), the comment form, and the Next/Previous Page links.

Comment!

I’d almost forget all about the clean, new look of the comment list. And, if you register a Gravatar, your comments will be accompanied by your avatar. Try it. Please!

Separate development/production environments for WordPress

When you’re out Googling on how to maintain a separate development environment for a WordPress installation, you will only stumble across information about how to install all kinds of WAMPP packages. Well, I don’t care about WAMP (or WAMPP). I want to be able to edit my theme, change my plugins, mess with my database locally and then deploy my changes when they’re ready and well-tested (as if I ever…)

Rails was the obvious inspiration for how to do this properly. In Rails, the whole development and deployment process is very intuitive and powerful. In WordPress documentation I never even see the awareness of the need for this separation. They usually tell you to download stuff, upload it and muck about with it on the life production server. But, I’m not the mucking-about-in-live-configurations type. I’m the I-fucked-this-up-so-often-I-want-a-staging-area type. This post is about how I managed to fulfill this wish with WordPress.

Changing the environment

The first thing I had to do was to find some way to decide which environment to go into. For some reason I decided to use Apache’s mod_rewrite to set an environment variable based on the HTTP Host header. This is in fact very illogical, but we’ll get to that later.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} =bsblog [OR]
RewriteCond %{HTTP_HOST} =bsblog.molensteen
RewriteRule . - [env=WP_ENV:development]
RewriteCond %{HTTP_HOST} =blog.bigsmoke.us
RewriteRule . - [env=WP_ENV:production]
</IfModule>
 
# Keep out of WP's own block of rewrite rules below
# BEGIN WordPress 

. - looks like a needle because it’s voodoo. The dot says I match anything and the dash says I change nothing of what I match. I do set an environment variable to whether I want to be in development or in production.

So I now have an Apache environment variable available for querying from within PHP (as if PHP doesn’t have a $_SERVER['HTTP_HOST'] variable:-? ) and I can make use of that in my wp-config.php.

Multiple configurations in one file

I love configuration files that share the program’s language; wp-config.php being simple PHP code is what make this whole thing so easy:

<?php
 
if ( getenv('WP_ENV') == 'production' ) {
  // ** MySQL settings ** //
  define('DB_NAME', 'blog');             // The name of the database
  define('DB_USER', 'wordpress');        // Your MySQL username
  define('DB_PASSWORD', '[my password]'); // ...and password
  define('DB_HOST', 'bigsmoke.db');        // 99% chance you won't need to change this value
  define('WP_SITEURL', 'http://blog.bigsmoke.us');
}
elseif ( getenv('WP_ENV') == 'development' ) {
  // ** MySQL settings ** //
  define('DB_NAME', 'bsblog');          // The name of the database
  define('DB_USER', 'root');            // Your MySQL username
  define('DB_PASSWORD', '[my password]'); // ...and password
  define('DB_HOST', '127.0.0.1');       // 99% chance you won't need to change this value
  define('WP_SITEURL', 'http://bsblog');
  //define('WP_DEBUG', true);
}
 
define('WP_HOME', WP_SITEURL);
 
// You can have multiple installations in one database if you give each a unique prefix
$table_prefix  = 'wp_';   // Only numbers, letters, and underscores please!
 
// The rest of the stuff in this config file just isn't interesting
?>

There’s a few things to note here. You have to use getenv() or $_SERVER instead of $_ENV because variables set by Apache end up in the former two. Another thing to note is that I should have just checked $_SERVER['HTTP_HOST'] instead of resorting to mod_rewrite voodoo. For the rest it’s all very straight-forward: I make some database settings depend on which environment I’m in and I set the URL accordingly.

Development URLs

I had some trouble putting the pieces back together when newer WordPress versions started doing automatic redirects for URL that didn’t match siteurl in the wp_options. This change meant that when going to http://bsblog/ (the development URL for this weblog) for example, I’d inevitably end up at http://blog.bigsmoke.us/.

Links had always been constructed according to this setting, so I had already been planning a plug-in to transform production URLs to development URLs. But, I learned (a little late) that this is completely unnecessary since wp-config.php supports the configuration of a base URL. I had wrongly assumed that settings that weren’t in the sample config file, simply didn’t exist.

Thus, after adding WP_SITEURL and WP_SITEHOME to wp-config.php, everything was working.

Ideas to further enhance your configuration

  • Don’t limit yourself to one development environment if you have more than one development server.
  • Automate your deployment process. I use rsync for this.
  • Write a script to clone your production database to your development database. There’s no substitute for actual data.

Upgraded WordPress from 2.1 to 2.3.1

I’m now on WordPress 2.3.1. It was about time too; I was still on 2.1.

Importing the tags from Ultimate Tag Warrior worked fine. Before upgrading and importing, I quickly patched my local version of WP with a little help from Subversion:

$ svn diff http://svn.automattic.com/wordpress/tags/2.1/ http://svn.automattic.com/wordpress/tags/2.3.1/ > wp.diff
$ blog.bigsmoke.us
$ patch --remove-empty-files -p0 < ../wp.diff
$ svn revert wp-config.php
$ svn add `svn status|grep '^?'|sed -e 's/\?//'`
$ svn rm `svn status|grep '^!'|sed -e 's/!//'`

Then, after a few changes to my template files to play nice with WP’s new built-in tagging system, everything was running again.

Allowing dots in WordPress post slugs

I was once again annoyed by the fact that WordPress doesn’t allow dots in post slugs. Luckily, this time I hadn’t published the post with a botched URL yet. (I don’t like changing permalinks because they’re meant to be permanent; cool URLs don’t change.) A quick googling pointed me to a post in the WordPress support forum with a reference to the Periods in Titles WordPress plugin.

The plugin works great and allowed me to post http:///2007/05/30/jeroen-dekker.com with dots and without problems.

Newer posts »

© 2024 BigSmoke

Theme by Anders NorenUp ↑