http://youlookfab.com/welookfab/topic/your-favourite-80%E2%80%99s-music-bands

The “%E2” in this URL is an encoded version of the apostrophe in “80′s”. I investigated a little using Firebug and web-sniffer.net, and discovered that this URL does indeed cause a 302 redirect. But why?

bb_repermalink() is the problem

The answer is in a bbPress function that runs for most forum pages: bb_repermalink(). (you can find this function in “functions.bb-core.php” in the “/bb-includes” folder of the bbPress distribution) I couldn’t find any documentation or discussion on this function, but it appears to check  the permalink and do a redirect if it finds an error. It turns out that the “correct” permalink (i.e. the one based on the post slug in the database) encodes special characters with lowercase hex (i.e. “%e2″ instead of “%E2″ using our example above). When bb_repermalink() compares the URL we typed into the address bar (with uppercase hex characters) to the “correct” one (with lowercase hex characters), it finds a discrepancy that it thinks is an error in the URL. So it redirects to the “correct” URL.

A plugin workaround

Fortunately there are some well-placed hooks in bb_repermalink(), so I was able to create a plugin that detected uppercase hex in the URL and then adjust the “correct” permalink accordingly. The code for this plugin is at the end of this post.

Why the Google crawl error?

One question still remains: why did this 302 redirect cause an error in the Google crawler? I can’t say for sure, but my theory is as follows…

1. The crawler converts hex to uppercase before crawling the URL. So even though my sitemap specifies the URL with lowercase hex, Google’s crawler converts this to uppercase.
2. Then when the crawler visits this URL, bbPress detects the uppercase discrepancy and issues a 302 redirect to the lowercase URL.
3. Google’s crawler takes the new lowercase URL, AGAIN converts the hex to uppercase and then re-crawls the URL.
4. This of course leads to an infinite loop as the crawler repeatedly converts to uppercase and bb_repermalink() repeatedly redirects back to the lowercase URL.

The crawler probably detects that it is getting the same URL back repeatedly, and interprets this as an error.

Again, I can’t be certain that this is what’s happening, but its a theory. If you know more than me about this issue, I would love to hear about it in the comments.

Here is the code for the plugin that will force bbPress to accommodate uppercase hex in encoded URLs without issuing a 302 redirect.

function _permalink_fix( $permalink, $location )
{
$matches = array();
/* are there any URL encoded hex characters with uppercase in the request URI? */
if (preg_match( '#\%([0-9][A-F]|[A-F][0-9]|[A-F][A-F])#', $_SERVER['REQUEST_URI'], $matches ))
{
/* replace ALL URL encoded HEX parameters with uppercase versions */
$patterns = array(
'#\%([0-9])([a-f])#e',
'#\%([a-f])([0-9])#e',
'#\%([a-f][a-f])#e' );
$replacements = array(
'"%" . $1 . strtoupper("$2")',
'"%" . strtoupper("$1") . $2',
'"%" . strtoupper("$1")' );
$permalink = preg_replace( $patterns, $replacements, $permalink );
}
return $permalink;
}
add_filter('bb_repermalink_result', '_permalink_fix', 10, 2);

But what if your WordPress installation can’t send email? This is the case with my development server, so recently when I lost the password I had to do a manual reset in the WordPress database using phpMyAdmin. Here are the steps:

1. Start phpMyAdmin
2. Select your WordPress database in the sidebar on the left
3. Select the “wp-users” table in the sidebar on the left
4. Select the “Browse” tab at the top of the page
5. Click the pencil icon to edit the admin entry
6. Enter a new password in the “Value” field (don’t press “Go” yet)
7. Set the “Function” field to “MD5″
8. Press the “Go” button

Done. Step 7 is the tricky one. MD5 is the password encryption that WordPress uses in order to prevent people from seeing the passwords if they somehow gain access to your database.

Well, something worked. Our traffic returned to pre-plunge levels a few days ago. Courtesy of Google Webmaster Tools, here is a chart of our traffic from Google over the period.

Export your production database. There are many ways to do this, but the most common is probably the tool “phpMyAdmin”. Most hosting services provide access to phpMyAdmin, and it is also part of the WampServer installation that I use on my local webserver. Since WordPress and bbPress have so much in common, I thought it would be wise to follow the WordPress steps for creating a database backup using phpMyAdmin. In particular, steps 1 through 7 worked just fine.

Step 8 is where I had my first problem. Our bbPress database is too big to be saved to a file, and would get cut off after the first 256 posts. For some reason you can get the full database contents by unchecking “Save as File” in the phpMyAdmin “Export” form. The contents are then displayed in a text area.

Copy it into a text file. I got the idea of pasting the contents of the textarea into a text file from Rex. Since it is a text area with over 10MB of text, it is a little unwieldy, but usable nonetheless.

• CTRL-A to select all in the text area, then wait a minute for this to register.
• CTRL-C to copy all that text, then wait another minute or so.
• CTRL-V in a text editor to paste all the text into the file.

So far, so good. Unfortunately, things didn’t go as well when I used phpMyAdmin on the local server to Import the file. There were several odd syntax errors. After some experimentation I started to suspect the text encoding of the file was off. I had been using Notepad++ (a great free editor). To cut a long story short, I switched to trusty Notepad and when saving the file I specified “UTF encoding” in the Notepad “File Save As” dialog box.

Import the text file into your local database. With the database backed up in a UTF-8 encoded text file, the next step is to fire up phpMyAdmin on the local server, load the bbPress database and go to the “Import” form. Since we have a large database, I needed to take a few extra steps to ensure that phpMyAdmin loaded the file. These are the same steps that you need to take before importing a large WordPress blog, namely, setting the following variables in your “php.ini” file:

upload_max_filesize = 20M
post_max_size = 20M
max_execution_time = 200
max_input_time = 200

Voila. The database contents were imported without any problems.

One small note: If your database had allready been configured by the bbPress install, then you need to go into phpMyAdmin on your local server and delete the existing tables to make way for the tables that will be restored from your backup. Please, please be careful. It would be all too easy to get confused and delete the tables in the wrong phpMyAdmin window, that is, the one on your production database. Bye bye forum.

The YLF forum is currently based on bbPress 0.8.3 (great forum system, more on that in future posts). I was setting up a development server to test some new features and hit a strange error. For the record, my server is using WampServer 2.0c on a Vista SP1 PC. WampServer is great if you have a LAMP (Linux OS, Apache webserver, MySQL database, and PHP) production server and want an equivalent setup on your local Windows PC.

During the bbPress install, which is normally just as simple as the WordPress install, I got the following database warnings:

Warning: mysql_get_server_info() [function.mysql-get-server-info]: Access denied for user ‘ODBC’@'localhost’ (using password: NO) in C:\xampp\htdocs\bbpress\bb-includes\db-mysqli.php on line 80

Warning: mysql_get_server_info() [function.mysql-get-server-info]: A link to the server could not be established in C:\xampplite\htdocs\bbpress\bb-includes\db-mysqli.php on line 80

Who exactly is “ODBC”, and why is he trying to access my database without a password? After much futzing with the database settings and the BBPress config, I starting looking around the web for a solution. Fortunately, it wasn’t long before I found one. No explanation for why it works, but it does.

In the file “bbincludes/db-mysqli.php”, change…

if ( !empty($this->charset) && version_compare( mysql_get_server_info(), '4.1.0', '>=') )
$this->query( "SET NAMES '$this->charset'" );

to…

if ( !empty($this->charset) && version_compare( mysqli_get_server_info( $this->$dbhname ), '4.1.0', '>=' ) )
$this->query( "SET NAMES '$this->charset'" );

Now, this does involve modifying a file in the bbPress distribution, which I would normally avoid. But in this case I just want the development server up and running asap, so I will live with the hack.

The procedure is simple:

1. Export: Go to the admin pages of your current blog. Inside the “Manage” menu, press “Export”. You will specify a destination folder and the file will be saved there.
2. Import: Go to the admin pages of your new blog. Inside the “Manage” menu, press “Import”. Pick the file you saved in step 1 and the contents will be imported into the new blog.

Easy. Unless, that is, your blog contents happen to be larger than 2MB. In this case you need to do some extra work. If you have access to your php.ini file you can just set the following variables:
upload_max_filesize = 20M
post_max_size = 20M
max_execution_time = 200
max_input_time = 200


I found that the first two variables above were already in my php.ini file, but were set to 2MB and 8MB respectively. I had to add the second two variables. If you don’t have direct access to php.ini, then you need to set these variables in your .htaccess file, which lives in the root of your website. This blog entry shows how.

You then need to restart the php server for these settings to take effect. That is easy on my local staging server, but I’m actually not sure how I would do it on our production server that is hosted by MediaTemple.

Once you are done with the import, it is probably a good idea to set the four variables above back to their default values.

Since the plunge I have…

1. Installed the All in One SEO Pack plugin. Google’s content analysis tool (part of Google Webmaster Tools, or GWT) told me that I have duplicate title tags. This plugin ensures that each page has its own unique title tag.
2. Removed the meta description from the header. GWT content analysis also told me that I have duplicate meta descriptions. Some research on the web revealed the consensus that no meta description is better than duplicating the same meta description across all the pages.
3. Resubmitted the sitemap. I also installed the latest version of the Google XML sitemaps plugin.

One thing I noticed in GWT was that our incoming external links had dropped very low. the reason? Our home page was not the list. I checked that our site was indexed and it was. Recently the external link stats returned to normal and our home page is back in the list.

We are also getting quite a few web crawl errors that don’t make sense. Perhaps our server was down while the Google crawler was doing its thing, but I don’t see that in the server logs.