Now that I’m well-settled in the YTEC office with everything set-up and running, I hope to make some actual progress on this project next time that I’m here.

This is how the pagination for page one of my home looks now:

For page six you can see more of what the plugin can do:

And finally…

Do I have twenty pages of posts already?

At some time, I had already installed (but not activated) the Live Comment Preview plugin, but that’s client-side only. I removed it because I want the comment to show as it would after being piped through all the hooks and filters that comments normally get piped through. Enter the AJAX Comment Preview plugin:

Other preview plugins don’t know what sort of changes WordPress will make to a visitor’s comment, but this plugin uses AJAX and other buzzwords to send each previewed comment through WordPress’ inner voodoo.

The result? With the click of a button, your site’s visitors can preview their comments exactly as they will appear when they submit them for realies.

You just gotta love their phrasing. Enjoy the new preview feature.

cat upgrade-wordpress.sh 
#!/bin/bash
 
svn_repo_url=file:///var/svn/blog.omega-research.org/vendor/wordpress/
last_version=$1
new_version=$2
 
tmp_dir=`mktemp -d`
cd $tmp_dir
 
for version in $*; do
    echo "Downloading and extracting WordPress version $version..."
 
    if [ -z `svn ls $svn_repo_url|grep $version` ]; then
        branch=`echo $version |sed -e 's/\.[0-9]\+$//'`
        archive_file="wordpress-$version.tar.gz"
        md5_file="wordpress-$version.md5"
 
        wget "http://wordpress.org/$md5_file"
        wget "http://wordpress.org/$archive_file"
 
        if [ `md5sum $archive_file |cut -f 1 -d ' '` != `cat $md5_file` ]; then
            echo "MD5 sum did not match!" >&2
            exit 1
        fi
 
        tar --extract --ungzip --transform "s/^wordpress/$version/" --file $archive_file
        svn_load_dirs.pl $svn_repo_url -t $version current $version
    fi
done
 
cd -
svn merge "$svn_repo_url$last_version" "$svn_repo_url$new_version" .

I’m actually planning to make both scripts a little bit more generic (in the sense that svn_repo_url becomes an external param) and to track future changes to them using GitHub’s Gist. (How ironic is that, tracking an script for Subversion using Git?)

The transformation: wordpress-full-atom-feed.xsl

<?xml version="1.0" encoding="UTF-8"?>
 
<xsl:transform version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:atom="http://www.w3.org/2005/Atom"
xmlns:thr="http://purl.org/syndication/thread/1.0"
xmlns="http://www.w3.org/2005/Atom">
 
<xsl:param name="base_url" select="atom:feed/atom:link[@rel='self']/@href" />
 
 
<xsl:template match="/">
  <xsl:apply-templates select="node()" />
</xsl:template>
 
<xsl:template match="*">
  <xsl:element name="{name(.)}">
    <xsl:apply-templates select="node()" />
  </xsl:element>
</xsl:template>
 
<xsl:template match="@*|node()">
  <xsl:copy-of select="." />
</xsl:template>
 
<xsl:template match="atom:feed">
  <feed>
    <xsl:apply-templates select="@*|node()" />
 
    <xsl:call-template name="process_feed_page">
      <xsl:with-param name="page" select="number('2')" />
    </xsl:call-template>
  </feed>
</xsl:template>
 
<xsl:template name="process_feed_page">
  <xsl:param name="page" />
 
  <xsl:variable name="page_doc" select="document(concat($base_url, '?paged=', $page))" />
 
  <xsl:if test="$page_doc/atom:feed/atom:entry">
    <xsl:apply-templates select="$page_doc/atom:feed/atom:entry" />
  
    <xsl:call-template name="process_feed_page">
      <xsl:with-param name="page" select="$page + 1" />
    </xsl:call-template>
  </xsl:if>
</xsl:template>
 
</xsl:transform>

The transformation works by processing the atom:feed element. Before closing that, the process_feed_page template is called. This template tries to open the next page and process all atom:entry elements in there. Then it tries to recurse to the next page.

The next page’s URL can be guessed because this is the normal feed URL with ?paged=[pagenum] appended to it. The feed URL can be found because WordPress adds it to the feed:

<link rel="self" type="application/atom+xml" href="http://blog.bigsmoke.us/author/halfgaar/feed/atom" />

For very old WordPress versions this doesn’t work, because the paged parameter isn’t supported there. Also, older versions might require you to supply the $base_url param to the XSLT processor, because the rel='self' link is incorrectly set to the URL of the default feed within all other feeds (such as the author feed or the tag feed).

Invocation

Invocation is simple. I use libxslt‘s xsltproc:

xsltproc wordpress-full-atom-feed.xsl http://blog.bigsmoke.us/author/halfgaar/feed/atom

That’s it. You end up with a full feed as if there never was any pagination to begin with; it almost looks as if WordPress does support the nopaging option for feeds.

Dan Peverill’s GeSHI plugin sucks for two reasons:

1. It’s no longer being maintained. It doesn’t even seem to justify a page on Dan’s website anymore (for which reason I’m not going to give him any link-juice).
2. It breaks HTML. With the plugin enabled I can no longer use the <code> tag to mark in-line elements as being code. Frankly, this is annoying and I find myself typing <tt> often when I mean <code>.

A search for WordPress plugins tagged GeSHi reveals a number of results: Sniplets, CodeColorer, Developer Formatter, and WP-SynHighlight. WP-Syntax is a plugin that is missing from the tag search.

Sniplets seems much too generic to my taste. I just want a GeSHi highlighter, period.

CodeColorer says it does what I want, but if I ever want to use the TinyMCE editor again, I won’t be able to with this plugin. Shouldn’t be too much of a problem, but still…

Developer Formatter is very thoroughly written and even sports a TinyMCE plug-in for copying/pasting the code. It is pretty big, though, and, as a rule, I tend to avoid plug-ins that complicate the database schema. I also don’t really see how these extra tables are an advantage feature-wise.

WP-SynHighlight uses a custom BBCode-style tag, [codesyntax] I like this (if you’re going to use pointy brackets, at least keep out of the HTML namespace), though I don’t like the attempt at a generic name; what’s wrong with calling the tag [geshi]? Seriously… I’m sure I’m going to forget this name billions of times if I’ll use this plug-in.

WP-Syntax uses the <pre> tag with a few custom attributes. This at least is better than the officially inline <code> tag that my current plugin uses, because most of the time that I’d use a <pre> tag I really do want syntax highlighting. Just wondering: will it also allow my to use it normally for that other rare occasion? Sadly, the plugin will doubtlessly wreak havoc with the visual (TinyMCE) editor.

So, which plugin will I choose? I am somehow inclined to want a plugin that can play nice with the visual editor because I keep telling myself how much nicer it would be to switch to the visual editor for all my posting. (That this will be difficult because I disabled WP’s ‘wpautop‘ filter to rid myself of its eagerness is a story for some later time.) This requirement rules out CodeColorer and WP-Syntax.

That leaves Developer Formatter and WP-SynHighlight. Both seem to fit my purpose. Developer Formatter sports a nice TinyMCE plugin for inserting code, but I don’t think that switching to TinyMCE will suddenly and unexpectedly make me afraid of typing. Besides, I really don’t want the extra tables in my database without a very good reason, so, for now, I will try WP-SynHighlight.

First, I tried if pagination works for feeds. Appending “/page/2” (as is used an non-feed lists) to a feed URL gives a 404 so I was kind of stuck there. Four days ago, after Googling for some time, unable to find a solution anywhere, I asked on the forum. Still no answer today so I tried to find out which parameters WordPress accepts in the QUERY_STRING. The WordPress Codex does explain how queries are handled but not which parameters are accepted.

Digging into wp-includes/query.php, with much trial and error, I found out that I can append ?paged=2 to the URL to get the next page. At least I got that sorted then. There are a number of much more promising parameters supported by get_posts(), but these don’t seem to be parsed by parse_query(). Next time, I’d like to find out how how to use two of these: nopaging and posts_per_page.

Wiebe could complete his list by merging together all the pages of the feed, but I’d much prefer to find a relatively painless method to produce a feed with an unlimited number of posts.

Notes

• http://codex.wordpress.org/Query_Overview
• http://codex.wordpress.org/Function_Reference/WP_Query
• http://codex.wordpress.org/Template_Tags/query_posts

So I was happy. And I’m still happy. Yet, this time, it does take getting used to it. That’s a bit sad. Probably, it’ll be for all the better, with more space for more (plug-in) features and everything. Still… I will miss the old interface.

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

• Editing wp-config.php in the WordPress Codex
• Giving WordPress its Own Directory While Leaving Your Blog in the Root Directory in the WordPress Codex
• Vendor branches in the Subversion Redbook