I can’t remember if I upgraded WordPress or the Recent Posts plugin or both, but I’m guessing it was an upgrade to the Recent Post plugin that caused the problem. The new version requires a “Post-Plugin library” (written by the same guy).

I found the link on my WordPress Admin Plugins page in the description of the Recent Posts plugin as part of a message telling me the plugin:

Requires the latest version of the Post-Plugin Library to be installed

Oops. Apparently I didn’t have any version of the Post-Plugin library and:

The Post-Plugin Library does nothing by itself but must be installed to provide shared code for the Similar Posts, Recent Posts, Random Posts> [sic], and Recent Comments plugins.

Anyway, that meant manually creating the accounts, setting up the mail accounts and subdomains in them, extracting the root folders (public_html, mail etc) individually and manually importing the SQL backup. Everything was relatively painless (if dull) however Fantastico wouldn’t recognise my WordPress installations (I had two). To persuade Fantastico that there really were a couple of WordPress blogs I had to do two things:

1. Extract the \.fantasticodata\WordPress files from the zip (in this case it was called nerd.steveferson.com| ) and upload it to the same location in the FTP server. Of course that bar | made Windows barf, so you’d need to rename it (e.g. using an underscore instead) and replace the bar after uploading it via the FTP client (FileZilla didn’t seem to have a problem doing this).
2. I think this is might be because the blog’s in the root of a subdomain, but I also had to upload a file called installed_in_root.php from \.fantasticodata to that location on the server.

Once I did this, Fantastico picked up the blog and allowed me to upgrade WordPress to 2.5.1 – no hassle.

When I logged into the backend of the new subdomain there were no images – including no buttons on the rich-text editor (TinyMCE) and no WordPress logo on the login screen.  I later noticed there were also background images missing on the public part of the new blog.  When I right clicked “View background image” on the missing image, it took me to an HTTP 403 (Forbidden) meaning there was a permissions problem. The strange thing was the problem didn’t occur in the nerd. backend.

And the solution…? In this instance it was because I’d enabled hotlink protection in my server to stop other people using images stored at steveferson.com on their sites, because this eats up precious bandwidth.  When I created this new subdomain, I had forgotten about the hotlink protection and so hadn’t added it to the list of sites allowed to link to images at SteveFerson.com.  When I added it everything went back to working as expected.

The server reported an error with the following URL:

http://www.blog-domain.com/b2evo-path/xmlsrv/xmlrpc.php

403 Forbidden

Thinking it might be a problem with b2evolution, I tried with a WordPress blog. A different message appeared, both on this blog and another:

The server has reported that the following URL could bot be found

http://nerd.steveferson.com/xmlrpc.php

please ensure that you have specified a valid and reachable URL

I discovered help was at hand after searching for help with the WordPress problem. According to posters at the Windows Live forum, some hosts block access to any files called xmlrpc.php because of a security vulnerability in an early version of WordPress. This same problem (and same solution) seemed to apply to b2evolution too (though I don’t understand why there are 2 different error messages). To get round this you need to add the following to a .htaccess file in the same directory as your xmlrpc.php file (or create a .htaccess file containing this if you don’t already have one):

<Files xmlrpc.php>
SecFilterInheritance Off
</Files>

Simple really, no? Enjoy!

<title>[Post/Page name - ] Blog name</title>

On installing 2.4, however, I noticed that the default title is just the post/page name if it exists and the blog name if it doesn’t (i.e. for the posts list). This was based on a function call to a function called request_title. Google didn’t tell me much about this function (not the 2.x version anyway) so I went hunting and found the function in the file: \inc\_core\_template.funcs.php

It’s one of the new 2.x style functions that takes a single associative array as its parameter instead of taking a list of parameters in a specific order. From the definition the parameters it can take are:

• auto_pilot – default: ‘none’. If this is set to ‘seo_title’ (which it is in any skins that don’t override the default _html_header.inc.php) default values override some of the parameters (see below).
• title_before – default: ”.
• title_after – default: ”.
• title_none – default: ”.
• title_single_disp – default: true.
• title_single_before – default: ‘#’.
• title_single_after – default: ‘#’.
• title_page_disp – default: true.
• title_page_before – default: ‘#’.
• title_page_after – default: ‘#’.
• glue – default: ‘ – ‘.
• format – default: ‘htmlbody’.
• arcdir_text – default: T_(‘Archive directory’).
• catdir_text – default: T_(‘Category directory’)

The ‘autopilot’ parameter is set to ‘seo_default’ by the default _html_header.inc.php file (which is used by any skin that doesn’t supply its own _html_header.inc.php file). This has the effect of overriding the values of the following parameters:

• format = ‘htmlhead’
• title_after = $params['glue'].$Blog->get(‘name’)
• title_single_after = ”
• title_page_after = ”
• title_none = $Blog->dget(‘name’,'htmlhead’)

It looks to me like to truly customise the HTML title tag value you need to delete the line:

'auto_pilot' => 'seo_title',

from the _html_header.inc.php or create a copy of this file in your specific skin’s directory and delete that line from the copy (if you put this file in your skin’s own directory, your skin should use this ‘custom’ version instead of the backup in the ‘skins’ directory). I took the latter option and created a copy of \skins\_html_header.inc.php in the subdirectory for my skin. To get the effect described above (i.e. <title>[Page/post name - ]Blog name</title>), I amended the PHP code between the title tags to the following:

request_title( array(
'format' => 'htmlhead',
'title_after' => ' - ' . $Blog->dget('name','htmlhead'),
'title_none' => $Blog->dget('name','htmlhead'),
) );

I also added two more elements to the array to change the headings when looking at the archives and categories from “Archive directory” and “Category directory” to “Archives” and “Categories”. This was fairly simple – just adding:


'arcdir_text' => T_('Archives'),
'catdir_text' => T_('List of Categories'),


It seems to work pretty well. I copied a default skin (the asevo one) to a directory called proto, installed the copied skin and began changing it. I decided I wanted to keep the 3-column layout from my old 1.10 skin and luckily there is already a default container called Sidebar and another called Sidebar 2. The problem was my skin didn’t use Sidebar 2.

It was easily fixed, I created a new <div> and used the same skin_container function which the skin used to call the Sidebar widget. I just replaced skin_container( NT_(‘Sidebar’) with skin_container( NT_(‘Sidebar 2′) and it fitted in. Despite the fact the skin now used Sidebar 2, the admin interface kept telling me it didn’t. The container in the admin site said Sidebar 2 [NOT INCLUDED IN SELECTED SKIN!] and every time I tried to add a new widget I got a message saying “WARNING: you are adding to a container that does not seem to be part of the current skin” (I Googled the former error message and, to my shock, got zero results. Hopefully this post will fix that).

Solution

It still worked ok, but I don’t like things that are out of place. To solve this, it turns out all you have to do is go to Global Settings -> Skins install panel and there’s an icon beside each skin to “Reload containers”. Do that and it’ll pick up your call to Sidebar 2 and rid you of that irksome error message.

I noticed a file called error_log (no extension) in the wp-admin directory and had a look. Apparently some database tables (‘wp_term_taxonomy’ and ‘.wp_terms’) were missing. After reading this support thread I investigated the possibility that my database was out of date. I followed MichaelH’s suggestion of navigating to /wp-admin/upgrade.php, which informed me that my database was up to date. I didn’t believe this to be true though; certainly not after learning that tables were missing. At a hunch, I guessed that when I’d been upgrading through Fantastico, I must have run out of space (a semi-regular occurrence) so the database upgrade was probably left half finished. Assuming that WordPress would determine whether or not I needed to upgrade based on a single configuration or database field I soon found the wp_option.db_version field, which was set 6124.

The Solution

As I suspected, 6124 is the db_version value for WordPress 2.3. I changed this field’s value back from 6124 to 5183 (the db_version value in WordPress 2.2) and hit the upgrade.php page again. This time it told me to upgrade, I did, and the categories are back.  Adding new categories still caused 403 and 404 errors, but that was because I’d deleted the .htaccess file created previously when trying to fix the first problem! Recreate that and we’re cooking with gas again.

Initially I thought this was because there had been a problem writing some of the files so I downloaded a clean copy of wordpress and uploaded the files manually over FTP. This didn’t help. Having eliminated browser problems by testing in IE as well as FireFox, I noticed that the page seemed to be loading fine and these 404s were appearing after the page loaded. Guessing Javascript I disabled this feature and tried again. It worked!

It was about this time that I stumbled across some information in the WordPress support forums pointing to a AJAX issue. It seems to be something to do with displaying the dynamic information like notices from WordPress (and incoming links?) and, more specifically, with the Content-type HTTP header being returned having a newly-added character encoding field.

Anyway, for the important bit, here’s the fix:

1. FTP to your wp-admin directory
2. If there is a .htaccess file there, append the following lines. If there is no .htaccess file, create a file called .htaccess and put these lines in it.
<IfModule mod_security.c>
SecFilterInheritance Off
</IfModule>
3. Save the file in your wp-admin directory and the rule you’ve just added will be applied to all files in that directory (and thus in your admin interface). Done!

Why does the fix have anything to do with Apache’s security? As it turns out the errors were actually 403 (forbidden) errors caused by a badly-configured mod-security module.   mod_security didn’t like WordPress sending character encoding in the Content-type header. Unfortunately I didn’t have custom 403 pages set up, so I only got the 404s telling me that the 403 page the server was looking for couldn’t be found! That’ll teach me to be half-assed with my error pages (maybe).

Then it came: my Eureka moment. After some messing about I noticed it didn’t happen on the “General Options” page (options-general.php), only on the “Writing Options” page (options-writing.php). I then tried updating the settings without changing any of them and … it worked!! Crazy!

It didn’t take long from then to figure out that the problem wasn’t with the WordPress setup, but with one of the URLs I was trying to get it to ping. Apparently WordPress doesn’t like Pinging the services at NorthernIrishBlogs.com, BritishBlogs.co.uk or IrishBlogs.ie

WordPress doesn’t seem to want to work with any URI that has a “.” in it, so that rules out any that point to files (with extensions) rather than directories (in fact, I just tried to save this post after inserting an example URL and was given a similar 404. I then went into panic when I hit ‘back’ on the browser to see an empty text area where my post used to be! Thank goodness for auto save). Presumably WP is trying to pingback the URL because it was in my post, and is having problems but I don’t know, but it doesn’t seem to have a problem with normal URLs, extension or not. Bizarre!

To be continued…