Category: Blogging

Solved: WP Recent Posts: “Post-Plugin Library missing”

Some of you may have noticed the above message appearing where my recent posts should have been for the last week or two.  It turns out the “Post-Plugin Library missing” message can be fixed by downloading the latest copy of the Post-Plugin Library (shocking, I know).

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

Continue reading “Solved: WP Recent Posts: “Post-Plugin Library missing””

WordPress / Fantastico Server Move

I recently moved this site to a new host because of ongoing problems with my previous hosts. Thanks to some intermittent database errors I’d decided it would be prudent to do my first backup in some time at the start of last week. By the end of that week they’d deleted my account, so I suppose I should be grateful their database server was so f**ked. Nevertheless, the move caused a few issues when my new hosts told me the complete backup I uploaded to them was corrupt. I can only assume (because some backups were corrupt and others weren’t) that it was due either to encrypting the archives using AES in Winzip or decrypting them in 7zip.

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.

Solved: WordPress Admin Images Missing

I upgraded this blog to WordPress 2.5 today, and installed a new copy of WordPress on a subdomain too. Both these actions were carried out using cPanel & Fantastico.

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.

Solved: Blog XMLRPC 403 Error

I was getting the above error message when I recently tried to set up and try out Windows Live Writer to let me publish to a blog from my desktop without logging into the Admin section of the site. I was felled at the first hurdle when, after entering my b2evolution blog’s details, I was presented with a message informing me that:

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:

Continue reading “Solved: Blog XMLRPC 403 Error”

Solved: Override Default HTML Title in b2Evolution 2.x

I’d set up my 1.x installation of b2Evolution to use a custom HTML title in the format:

<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

Continue reading “Solved: Override Default HTML Title in b2Evolution 2.x”

Solved: b2Evolution – Sidebar 2 [NOT INCLUDED IN SELECTED SKIN!]

I’ve just upgraded another blog from b2Evolution 1.10 to 2.4, which means reworking the skin I developed to work with the new “Skins 2.0” framework. It also means that instead of hacking html into my _main.php file, I’m going to use the customisable ‘widgets’ to create my sidebars. This is in the Blog Settings -> Widgets panel.

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.

Solved: Comments Disappeared / Error after WordPress Upgrade

I’ve just upgraded a WordPress blog to the latest version 2.3.2 and when I went to write a new post I realised all my categories had disappeared. They were still in the database but the list to the right of where you type your posts was empty. As well as this, I noticed that adding new comments was giving a 404 error in the middle of the page. This second issue was reminiscent of another one I had (and solved) upgrading to 2.2 – the errors were actually 403 errors, but redirecting to 404 error pages because there was no 403 error page defined (i.e. the 404 was happening when the server looked for the 403 page).

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.

Solved: Dashboard 404s After WordPress 2.2 Upgrade

Immediately after I upgraded (using Fantastico) from WordPress 2.1.x to 2.2.1 I noticed the Dashboard in the admin was giving me problems. I was getting 404 pages displaying in the middle of the page (even though the source code was fine and there actually aren’t any iframes there). I’ll get to the solution in a minute (so read on) but first I want to tell my story (just because I can).

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.

Continue reading “Solved: Dashboard 404s After WordPress 2.2 Upgrade”

WordPress: Problems Updating Settings

I’ve just spent the guts of an hour fannying about no various websites trying to figure out why I was getting an HTTP 404 (File not found) error when trying to update the settings on WordPress to make it ping different services. I hunted through the file being called, ie options.php, to no avail. I Googled the problem and found this. The guy who zipped a new options.php file had taken it offline (more 404!!) and the other solution posted there didn’t work. Still a 404. Then I read it might be something to do with Apache and mod_security, so spent a minute or two pondering contacting my web hosts.

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…