While upgrading some outdated sites to the latest version of WordPress (currently 2.3.3), I ran across this error:
WordPress database error: [Table 'DB_NAME.wp_terms' doesn't exist]

When I ignored the error and continued to the admin panel, I noticed that there were no categories listed, and all the posts were set to the “uncategorized” category (though even this was not listed on the Manage -> Categories page).

The reason for this error is that WP 2.3.x does not use the wp_categories table; it uses wp_terms and wp_terms_taxonomy instead. The upgrade script is supposed to move the data from the former to the latter, but something was preventing it from doing so successfully.

A search of the WordPress codex revealed some important reminders, but no help:

• Always back up your database before attempting an upgrade
• Always disable all plugins before attempting an upgrade
• Always revert to the default “Kubrick” theme before attempting an upgrade (because many themes now contain custom functions that can interfere with the upgrade process)

Fortunately, I’d done backups, as I always do. However, I must admit to being somewhat spoiled with WordPress upgrades, as this is the first significant difficulty I’ve ever encountered with an upgrade (other than incompatible template tags and plugins). This is a chilling reminder that, no matter how well things have gone in the past, doing a backup is NOT optional; it’s essential.

After trying everything I could think of, I recalled a forum post that suggested commenting out (or deleting) these two lines in the wp-config.php file:
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', 'utf8');

You can comment them out by preceding them with two forward slashes:
//define('DB_CHARSET', 'utf8');
//define('DB_COLLATE', 'utf8');

Certain earlier versions of WP shipped with these lines, though you may not have them at all.

I restored my database from the backup, used PHPMyAdmin to deactivate all the plugins and to set the theme to ‘default’, and ran the upgrade script again (by visiting mysite.tld/wp-admin).

This did it, and I was able to re-activate my plugins and theme. Problem solved.

Share This

WordPress 2.3 quietly introduced a powerful new feature that had previously only been available using plugins: tagging.

There are several ways to list your tags:

• Before or after each post, so people can click a tag to see other posts you’ve tagged the same way
• In a tag cloud in your sidebar
• On a tag archive page

I’ve found that tag archive pages are indexed very well by search engines, so I highly recommend using tags. But how should you use them, and how should they relate to WordPress categories?

As Lorelle said several years ago, tags are like a blog’s index, and categories are like the table of contents. Tags are great for SEO, but you don’t want to list a zillion of them in your sidebar; you want a concise list of categories.

It’s fine to have a zillion tags, but they’re better listed in a tag cloud or on an archive page. With that in mind, let’s look at how tags can become a part of your blog.

Listing the Tags for Each Post

Most WordPress themes have a post metadata section either before or after the body of the post, which includes the date, author, and comment link. This is a great place to display the tags for that post.

In this section, you can add
<?php the_tags('Tags: ', ', ', ' | '); ?>
to display a comma-separated list of the post’s tags, followed by a | mark. The parameters for this function are, respectively, what goes before the tags, what separates the tags, and what goes after the tags. Full documentation for this template tag (WP Codex)

Since tags are likely to make the post metadata section take up more than one line, make sure your theme still looks good if this section is several lines long; for example, some themes don’t leave enough linespacing because the theme author assumes it’ll only be one line long.

Since this tag applies to a specific post, it must be in the loop, not in the sidebar, header, or footer.

Listing Tags in a Sidebar Cloud

A tag cloud is a great way to visualize the topics you blog about, because the size of each tag is proportional to the number of times you’ve used it. This may not be immediately obvious on a new blog, but if you have 1,000 posts, and 800 of them are about horses and only 100 are about fish, the “horse” tag will be much bigger than the “fish” tag (assuming you’ve tagged your posts).

Here’s the function to display the tag cloud:
<?php wp_tag_cloud(''); ?>

You can put this tag in the sidebar or footer of your site, but don’t put it in the loop.

You can customize the minimum and maximum size of the items in the tag cloud, as well as how many to display and how to sort them. Full documentation for this template tag (WP Codex)

Displaying Tags on a Tag Archive Page

If you have tons of tags and you want to display them all in one place, but not on the main page of your blog, you can create a tag archive page. Here’s how.

1. Make a copy of your single.php or index.php template, and name it something like “tag-archive.php”
2. At the top of your tag archive template, insert this:<?php
/*
Template Name: Tag Archive
*/
?>
3. Replace everything from
   <?php if (have_posts()) : ?>
   to
   <?php endif; ?>
   (aka The Loop) with the <?php wp_tag_cloud(); ?> function. You can download a Kubrick-compatible tag archive template here.
4. Upload the new template file tag-archive.php to your theme folder.
5. Create a new page and call it something like “Tag Archives”. Under Page Template in the sidebar, select the new template you created. Leave the body of the page blank, and publish it.
6. Make sure you link to the new page in your navbar or sidebar so people can find the tag archive page

Converting Categories to Tags

WordPress 2.3+ also has a category-to-tag converter, which you can use for categories that don’t have very many posts in them. To use it, go to Manage -> Import, and select Categories to Tags Converter.

The converter lists all of your categories and the number of posts in each. Select the categories you want to convert using the checkboxes, and hit Convert. This will add the tags and delete the categories you select, so be selective and don’t eliminate all of your categories.

Importing Plugin Tags to WordPress Tags

If you’ve been using a tagging plugin like Ultimate Tag Warrior or Bunny’s Technorati Tags, you can convert your tags to WordPress native tags (since they’re stored in a different place in the database). The converters (including the aforementioned category-to-tag converter) are listed in the WordPress admin panel under Manage -> Import.

Share This

One of the questions we get most often is how to enable WordPress to edit theme files using the built-in theme editor. By default, when you upload a theme, the files aren’t writable from the WordPress interface. This is based on the sensible assumption that, generally speaking, visitors to your website shouldn’t be able to edit the files on it. If you’re the administrator of your WordPress site, though, it’s very useful to use the built-in theme editor.

To make your theme files writable, you need to set the permissions on the theme files so WordPress can edit them. This process is also known as CHMOD, short for CHange MODe, which is a UNIX/Linux command (which you probably don’t need to worry about).

To change the permissions of the files on your site, the way you’d open a folder on your computer, you need an FTP application, which is a separate program that connects to the web server to let you upload, download, move, or rename files.

You can download an FTP program such as the following:
Smart FTP
CuteFTP
FireFTP (a Firefox extension, which may be the easiest if you use the Firefox browser; will not work if you don’t)

After installing one of these programs or another FTP application (there are tons available for free), login to your site via FTP. You’ll need three pieces of information:
FTP server - probably ftp.yourdomainname.com
Username - probably the same as your account webhosting account username
Password -probably the same as your account webhosting account password

Note that the username and password will not ordinarily be the same as your WordPress username and password.

Your files are probably within a folder called public_html, httpdocs, html or something along those lines. From there, the themes will be in /wp-content/themes/, and each theme is in its own folder.

Navigate to the folder containing your theme. Then, highlight all of the files in this folder and right-click on them. There should be an option on the FTP program’s right-click (context) menu called “CHMOD” or “Permissions.”

The permissions settings specify what can be done with a file, and by whom. They’re represented by numbers or checkboxes that give read/write/execute permissions for each file to various groups, e.g. website visitors, you (the FTP user), or the server administrator.

If the files are set to 000, only the server administrator will be able to access them. By default, most files uploaded via FTP are set to 755 or something similar, which means that WordPress can run because anyone can “execute” the file (that is, access the script). However, since WordPress is not considered a user, it’s a member of the “public” group, so by default it can’t write to files.

If you set the theme files to 777 (so everyone has “write” permissions as well as read and execute permissions), that will let you edit your theme from within WordPress. If your FTP program uses checkboxes instead of numbers for file permissions, just check all of them. If you change themes later, just re-do this for the new theme’s files. You could do this for all your files without any problem, but it would take a while, and it’s not really necessary.

Note that if you make an edit to a file that introduces an error that takes down your site, you might need to upload a fresh copy of the theme via FTP, so it’s best not to edit PHP portions of your theme unless you have a backup of the theme file or are comfortable editing PHP. The functions.php file should not be edited from within WordPress, as an error can take down the WP admin panel as well as the public site, and you’d need to fix the error via FTP.

This procedure will work for plugins as well using the built-in plugin editor, but editing plugins is much more likely to crash WordPress, so we do not recommend using the plugin editor. Most plugins have an options page now, and don’t require any editing. if you need to edit a file, use a text editor on your computer and upload the changed file via FTP. If you get an error, simply delete the file, fix the error, and upload it again.

To summarize:

1. Download and install an FTP application
2. Login to your site via FTP
3. Navigate to the theme folder
4. Select all the files, and right-click on them, and select “Permissions” or “CHMOD”
5. Check all of the boxes or set the permissions to 777
6. Visit Presentation -> Theme Editor in WordPress to edit your theme files

Share This

MySQL 4.1 has a bug that prevents WordPress 2.1 from displaying accented characters correctly. Instead, they appear as ? marks.

To fix this, open /wp-includes/wp-db.php
and look for this line:
$this->dbh = @mysql_connect($dbhost, $dbuser, $dbpassword);
(it’s around line 52).

Immediately after that line, add:
mysql_query("SET NAMES 'utf8'");

Save and re-upload the file, and you should see accented characters as usual.

Via

If you are a WebbleYou customer and require accented character support, please contact us and we will be happy to make the necessary changes. No alterations to the database are necessary.

Share This

UPDATE: There is now a plugin that imports from New Blogger to WordPress.

At the moment, the built-in Blogger-to-WordPress script that ships with WP2.x is broken for users who have switched to Blogger Beta (now known as “the new Blogger,” as it is no longer in beta.

The workaround is grossly esoteric, but still doable. If you want to move from new Blogger to WordPress but don’t want to tackle this procedure, you can order hosting with WebbleYou and we’ll do the import as part of our free setup process. We are also available to do upgrades for non-WebbleYou customers; contact us for a quote.

• In the Formatting tab, set Timestamp Format to mm/dd/yyyy hh:mm:ss AM/PM (the first choice in the dropdown menu). Save Settings.
• In the Comments tab, set the Comments Timestamp Format just like you did in the previous step. Save Settings.
• In the Archives tab, set the frequency to ‘monthly’. Save Settings.
• Go to your Template. Backup your existing template (fortunately, this is easy with Blogger Beta - it’s a one-click .xml download)
• Click Revert to Classic Template at the bottom of the screen.
• Replace your existing template with this very long line (copy and paste, don’t break it into lines): <blogger><wordpresspost><$BlogItemDateTime$>|||<$BlogItemAuthorNickname$>|||<$BlogItemBody$>|||<$BlogItemNumber$>|||<$BlogItemSubject$><blogItemCommentsEnabled><blogItemComments><wordpresscomment><$BlogCommentDateTime$>|||<$BlogCommentAuthor$>|||<$BlogCommentBody$></blogItemComments></blogItemCommentsEnabled></blogger> Save Template Changes.
• Visit your site’s archive pages, and save each of them. The format is like this:
  http://mysubdomain.blogspot.com/2006_09_01_archive.html
  You will need to do this for each month you have archives - twelve times for every year you’ve been blogging. Ick.
• Rename each of the files so it ends in _wordpress.php, like this:
  http://mysubdomain.blogspot.com/2006_09_01_wordpress.php
• Now for the import. Here we have problems, because a) The manual export only works with WP1.5.x, and the automatic import only works with WP2.x. Hence, the uber-kludge that follows.
• Login to your site via FTP, and create a directory called “old” in your main folder.
• Upload WP1.5.2 (get it here) into the “old” folder
• Create a new database in your host’s control panel
• Set up WP1.5.2 in the “old” folder, the normal way, using the new database (NOT your original WP database).
• Upload the Blogger export files into this same folder
• Upload this importer file into the /old/wp-admin/ folder via FTP, and change the extension to .php
• Visit yoursite.com/old/wp-admin/import-blogger.php, and run the importer.
• Upload the current version of WP2.x to your site, overwriting the WP1.5.2 files.
• Visit yoursite.com/old/wp-admin, and click the links to upgrade this installation to the current version
• Export the 2nd database (”old”) using PHPMyAdmin
• Open the database export file in a text editor such as TextPad
• Delete everything from the dump file, including the headers, except the following sections:
  • wp_comments
  • wp_post2cat
  • wp_posts
  • wp_categories
  • wp_postmeta

  Delete the “CREATE TABLE” sections even for these three tables; save only the lines that start with INSERT INTO, and only those that are in these three tables.

• Go in PHPMyAdmin to your original WordPress database. If there’s already stuff in it, back it up just in case.
• Copy everything left in your text editor (the 2nd DB’s dump) and paste it into the MySQL query box in PHPMyAdmin (or import the file using the import feature)
• WGET the images from Blogger to your server. Hotlinking them from Blogger will not work - once they are viewed in an external page a few times, they will start to be blocked.
• Move the images to a convenient location (such as /wp-content) on your server, preserving the numeric folder paths.
• Dump the DB, and do a find-and-replace on all the image URLs, so the images are being served by your server.
• That’s it!

I’m sure I’ve left something out, so leave a comment or contact us if you have any questions.

WebbleYou is the only hosting company that will perform this procedure for free for all new customers. You can order hosting here if you are interested.

Share This

If you’ve been using Blogger and are moving to WordPress, you might notice that your Blogger-hosted images don’t show up consistently in your WordPress posts, even if you used absolute URLs for the images.

This is because Blogger prevents hotlinking after a few page loads - you may see the images initially, but they will be blocked after a few views.

Getting the images to your new server is not easy, because there is no simple list of the images that you can view and download from.

However, if you have shell access, you can get the images by using the Linux wget command as follows:
wget -e robots=off -E -H -p -Dphotos1.blogger.com,myblogspotblog.blogspot.com --random-wait -r -l inf http://myblogspotblog.blogspot.com

where myblogspotblog is the subdomain you used on Blogger, and photos1 is the blogger subdomain that hosts your images (this may be photos2 or something else for your account).

Run this command, then login to your site via FTP. Move the images to the /wp-content folder, perhaps within a subfolder such as /wp-content/blogger. Check a few URLs to make sure the images were moved as intended.

Next, you’ll need to update your image links to point to the new file locations. The easiest way to do this is to backup your MySQL database, save a copy, and do a find-and-replace in a text editor. TextPad is an excellent editor to use. Drop your database tables, import the modified SQL file, and you’re done.

There is also an easier-but-less-robust plugin that will move images from Blogger to your WordPress site. It does not remove images that are embedded but not linked.

Note: Most hosts will not do this for you. WebbleYou will - just ask when you sign up.

Share This

You can use your own link engine to hide outgoing links such as affiliate links. For example, if you wanted to direct visitors to Amazon when they visit yourblog.com/go/books, you could take the following steps:

1. Login to your site via FTP, and create a folder called go in your webroot (e.g. /www or /public_html or /httpdocs folder).
2. Create a file containing lines like this:
   Redirect /go/keyword http://www.destination-url.com/affiliate-code
   Name this file .htaccess (note the leading period) and upload it to the new go directory. Note: Windows will not let you name a file .htaccess on your PC. Give it another name and rename it to .htaccess after uploading.
3. Now we have to make WordPress ignore the “go” folder, or else it will redirect users into a WordPress error page. Open your main .htaccess file (the one in your webroot directory) and look for this line:
   # END WordPress
   Add this line after it:
   RewriteRule ^go/.*$ - [PT]
4. Add more outgoing link keywords and URLs by editing the .htaccess file in your /go directory whenever you want.

Share This

While exporting several clients’ posts from Blogger recently (using Skeltoac’s script that also exports comments), I have encountered this error:

001: Broken pipes

For some reason, Blogger does not like the template code required by the script.

Here’s a workaround:

1. Choose one of the default templates

2. Insert the WordPress export code at the bottom of the template

3. Republish

4. Copy the files from your server to your computer

5. Edit each of the files, removing everything from <html> to </html>

6. Save and upload each of the files, then run the import script

If this doesn’t work for you, but you find something that does, please leave a comment.

Share This

Kubrickr is a free web utility that lets you make a banner for your Kubric-themed blog. All you have to do is enter a keyword (Flickr tag), select a photo from Flickr, and crop and choose the area you want to use as your banner image.

If you use the default WordPress template, this is a great way to get started with personalizing your blog. You get a JPG file that you can download and copy into your Kubrick-based theme’s images directory. There’s no code editing, and the only software you need is an FTP client.

Kubrickr was created by Owen Winkler.

Share This

One of the greatest strengths of WordPress is the amazing user community, which has created tons of plugins to extend the functionality of an already great blogging tool.

Plugins that change the appearance of your blog need to be activated in two ways:
1. By clicking “activate” in the admin panel
2. By adding the necessary code to your template

Unfortunately, if you deactivate a plugin without removing its code from your template, you’ll get a PHP error, which can break the page’s layout or worse.

To prevent a deactivated plugin from crashing your site, or even creating a visual blight, simply wrap all the plugin-related code in the if(function_exists()) function, like this:
<?php if(function_exists(get_recent_posts)) { _e('<h2>Recent Posts</h2>');} ?>
<?php if(function_exists(get_recent_posts)) { get_recent_posts(10); } ?>

The first line creates a sidebar heading for “Recent Posts,” which you obviously wouldn’t want to display if you weren’t going to list the recent posts. The second line calls the get_recent_posts plugin, and saves your site from deadly page errors should you happen to deactivate the plugin.

If you wrap all of your plugin calls in this manner, you won’t have to edit your template when you activate or deactivate a plugin.

Share This