Tag: wordpress

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