Order of the Bath

When editing WordPress pages or posts there are a number of buttons in the editor to make things a bit easier; Things like Bold, Italic, Blockquote etc. There are in fact a lot more built into the editor than are actually shown in the menu bars. I rather like having superscripts and subscripts come out properly so I have allowed for it in my themes; things like 2^nd and H₂O. To make these easy to edit I have crested this little WordPress plugin – RJP-Superscript. Just add it to wp-content/plugins on your site and activate it and new buttons Sup and Sub will be enabled in both the Text and Visual editor (in the Visual editor, click the “Toolbar Toggle” on the end of the first line to reveal the second line of buttons). It can’t do magic though—if your theme doesn’t style super and subscripts then nothing will happen in the finished post.

I am getting occasional (3-4 a month) errors in a log file on the various WordPress installations that I support. The full text is

[25-Sep-2011 09:02:01] PHP Fatal error: Call to undefined function get_header() in /home/<ACCOUNT>/public_html/wp-content/themes/<THEME NAME>/index.php on line 1

Doing the natural thing I Googled for a reason but didn’t find much that was informative. Most of the cases reported were where the user had stupidly inadvertently overwritten the root index.php with the one from their theme of the day. The best I found was ardemis who is one step ahead of me.

As he implies, at important step is to stop the message reaching the user’s browser because it reveals rather too much about your web server. This is done by including the call

ini_set('display_errors', 0);

before the get_header();. This makes the message ONLY appear in the log file, which incidentally, can be found in the theme directory. He then goes on to describe a more sophisticated approach which you can read there if it suits your site. But why are they occurring? Is it search engine spiders or hackers probing the depths of your site.

As I mentioned in the previous post, there can be a problems inserting foreign text into WordPress. I have done it in the past with simple accents for French and German with no problem and for some special characters I used the &#….; codes but when it came to pasting in a chunk of Arabic it didn’t work at all, just displaying a bunch of question marks. I suspect that there would be a similar problem with Hebrew, Chinese, Japanese, Cyrillic and any other non-western scripts. I had a search around and the first suggestion I came across was Obsessed with the Press which suggested commenting out the lines for DB_CHARSET and DB_COLLATE in wp-config.php. This appeared to work (on a test site) but looking at older posts I could see that some characters in there were now corrupt, displaying a white question mark in a black diamond. In the comments on the same page there was a suggestion to not do that but just change DB_COLLATE to the value ‘utf8_general_ci’. This didn’t really work either. There were suggestions on other pages to set it to ‘utf8_unicode_ci’ and various other things, so it was time to do some more serious investigation.

It looks like the problem is not really the fault of WordPress at all but the MySQL installed on some sites (including mine). Deep in the MySQL is a configuration parameter for the default character collation and it is often set as supplied to ‘latin1_swedish_ci’—Why? Because MySQL was originally Swedish! If it was just taken out of the box and installed then that will be the default you get for most of your tables because DB_COLLATE in WordPress is set to null and so takes the default. In practice you will find some tables are different, perhaps because they discovered it was important.

So, what does that mean for fixing the problem? DO THIS AT YOUR OWN RISK—I AM NOT AN EXPERT.

First—the second suggestion above was correct—change the DB_COLLATE line to read

define('DB_COLLATE', 'utf8_general_ci');

If you are setting up WordPress for the first time, this may be sufficient because it will use this value, but if you are hacking an old installation then you will need to correct it a bit. You need to go into phpMyAdmin and change some of the collations on your tables. The important one, which fixed my problems, is table wp_posts, field name post_content, but if you are planning to use unicode in post titles, comments and other places then you may need to do more of them. I am planning to be a bit cautious about changing too many in case it breaks something else.

Customising a WordPress installation is relatively straight forward—you pick a theme and then tweak it to your satisfaction—you can make that as easy or hard as you like depending on your skills and requirements and it is all fairly well documented. It uses a theme system so that any templates that you place in the theme directory override the default ones, This blog, for instance, has modified versions of the index, page and single templates which determine the content and appearance of the post stream, pages and single posts respectively.

Customising the feed contents and appearance is not so easy. The system includes three hooks which allow additional content to be included—In the case of RSS2 feed they are rss2_ns in the RSS header, rss2_head in the channel content and rss2_item in each item section. These are what podcast plugins use to add in the iTunes XML stuff that they need.

There is, however, no mechanism to remove or modify the existing standard content. What it needs is the ability to override the templates with ones of your own. The relevant template here is wp-includes/feed-rss2.php and it is loaded from the function do_feed_rss2 in wp-includes/functions.php. That default routine looks like this

function do_feed_rss2( $for_comments ) {
	if ($for_comments)
		load_template( ABSPATH . WPINC . '/feed-rss2-comments.php');
	else
		load_template( ABSPATH . WPINC . '/rss2-atom.php' );
}

What is needed is this which can be put in your theme’s functions.php

function custom_feed_rss2( $for_comments ) {
	if ( $for_comments ) {
		if ( file_exists(STYLESHEETPATH . '/feed-rss2-comments.php'))
			load_template( STYLESHEETPATH . '/feed-rss2-comments.php' );
		else
			load_template( ABSPATH . WPINC . '/feed-rss2-comments.php' );
	}
	else {
		if ( file_exists(STYLESHEETPATH . '/feed-rss2.php'))
			load_template( STYLESHEETPATH . '/feed-rss2.php' );
		else
			load_template( ABSPATH . WPINC . '/feed-rss2.php' );
	}
}

Then replacing the default routine with the new one using

remove_action('do_feed_rss2', 'do_feed_rss2');
add_action('do_feed_rss2', 'custom_feed_rss2');

then the copies of the templates in your theme directory will be picked up if they exist and defaults used if not. Similar things can be done for the rdf, rss and atom feeds but I don’t use them; note: however, that if you have removed things because you don’t want them revealed to the world then you need to do it on all available formats because they are all available whether you advertise them or not.

What do I use it for? well I want to put the event date into some posts rather than the posting date and also I have a need to suppress comment feeds altogether on one site.

I have finally figured out why the RSS feed on this blog had died. I had been assuming that it was due to an illegal character in one of the post headings because that is what broke it last time; XML is very fussy about character set.

Today I had a look at the source of the XML that wouldn’t display and spotted that there were two blank lines on the front. Removing those (by hand) fixed it, I said XML was fussy!

Now where were they coming from. A search on Google for “wordpress xml blank lines” came up with a few suggestions and it looks like it is a common problem but everyone has to figure it out for themselves; there is no FAQ. The prime suggestion was blank lines on the end of the wp-config.php file but that wasn’t the case for me. The next was in functions.php in the theme; BINGO. I am always very verbal when writing code and put in lots of comments and white space. Normally that doesn’t matter but functions.php is loaded for every action (even for the admin panels) and PHP is a strange beast—everything that is not with us is against us; i.e. everything that is not a PHP statement is directly output to the stream so blank lines before the first < ?php and after the last ?> is output and you cannot separate the functions outside of the PHP structure either. Once I had fixed that then it was all ok.

I still can’t figure out the source of the two blank lines that cause the Comment feed to fail! [Update: that is fixed too. Same problem, just that I hadn’t properly cleared the browser cache.]

As I mentioned earlier, I upgraded the version of WordPress used on this blog last night. I did the Church website some time ago and it was easy but this one was much more complicated. The difference is that this one accepts comments and the commenting system in WordPress was completely revamped for version 2.7.

This is a screen shot from my development system using the Default theme.

Here I have set the Discussion Settings to say

Break comments into pages with 10 comments per page and the last page displayed by default. Comments should be displayed with the older comments at the top of each page.

As you can see from the first line there are 11 comments on this post and below is a link back to the earlier ones and the 11’th one in full. It looks ok but, as I will demonstrate in a minute, they have hidden the underlying problem.

I happen to think that comments need to be numbered. It is my choice but I consider it necessary both as a visual clue so that readers can tell immediately which posts are the most recent and what order to read them, and also so that the discussion can refer to earlier points unambiguously. The generated HTML for the clip above (edited and wrapped) is as follows

	<h3 id="comments">11 Responses to &#8220;Wordpress 2.7&#8221;</h3>

	<div class="navigation">
		<div class="alignleft"><a
                href="http:// … /wordpress-27/comment-page-1/#comments"
                >&laquo; Older Comments</a></div>
		<div class="alignright"></div>
	</div>

	<ol class="commentlist">
			<li class="comment byuser comment-author-sandpit bypostauthor even
                        thread-even depth-1" id="comment-24">

Here you will see the initial heading, the “Older Comments” link and, below that, <ol class="commentlist">. They are using an ordered list which should have item numbers for every <li> that follows, but they do not appear. They are being suppressed by the CSS style sheet using .commentlist li {list-style: none;}. Now if you want comments numbers, as I do, the instinct is to remove this suppression but that is not good enough (disregarding the work to get the layout to look right) because this comment will be numbered 1. because that is what <ol> does, not 11. as it should be. Every page will be numbered 1. to 10. Worse still, if I had set it to display newer comments at the top, they would be numbered in the wrong order.

The solution is to use a fantastic little plugin Greg’s Threaded Comment Numbering which solves this and other even deeper problems.

This is not really a complaint but it is a job half done. They have brought a lot of interesting controls forward into the admin interface for the average user to be able to control commenting, but the back-end code to handle them properly is not there. You can switch the feature on but you need a lot more skill to get it to work. I saw a comment from an experienced developer on the forums saying that WordPress is moving so that functional customising is moving away from themes, which are relatively straight forward to hack, to plugins and widgets which are more difficult and best left to the experts. If that is the case then they need to consolidate so that features such as this are either fully built into the base-code or left to plugin developers but not half-and-half.