Unfortunately, and much to my surprise, the custom code did not work flawlessly the first time and I was left staring at errors like:

“Fatal error: Call to undefined function test(); in wp-content/plugins/php-code-widget /execphp.php(37): eval()’d code on line 1″.

Unfortunately, as this error shows up in the dashboard where I would normally edit the widgets content, this is not as straight forward to fix as one would hope. So… after diving into the database and some trial and error I found that the widgets reside in the wp_options table, as this table is quite large, and contains more than just widget information, I had to narrow down what I was looking for. I ended up with this query:

mysql> select option_name from wp_options where option_name like 'widget_%'; +------------------------+ | option_name | +------------------------+ | widget_akismet | | widget_archives | | widget_calendar | | widget_categories | | widget_execphp | | widget_meta | | widget_pages | | widget_recent_comments | | widget_recent_entries | | widget_rss | | widget_tag_cloud | | widget_text | +------------------------+

In this case, it is content in the php-code-widget that is causing our errors, as there is no widget_php-code-widget, it seems that the widget_execphp is the next closest thing. So let’s inspect the widget_execphp entry.

mysql> select * from wp_options where option_name='widget_execphp'; +-----------+---------+----------------+-----------------------------------------------------------------------------------+----------+ | option_id | blog_id | option_name | option_value | autoload | +-----------+---------+----------------+-----------------------------------------------------------------------------------+----------+ | 347 | 0 | widget_execphp | a:1:{i:291302011;a:2:{s:5:"title";s:4:"Test";s:4:"text";s:16:"<?php test();?>";}} | yes | +-----------+---------+----------------+-----------------------------------------------------------------------------------+----------+

Bingo… here we can see the code that was entered into the widget. In this case the test() function does not exist.

The first, and arguably the simplest option is to simply delete the entry, we delete it using the option_id value we obtained above. The option_id value is also used later in the article, in the event you chose to update the entry as opposed to removing it.
mysql> delete from wp_options where option_id=347; Query OK, 1 row affected (0.29 sec)

At this point you can simply go back into the dashboard and recreate your widget, more careful not to include non existent functions this time. But that would be too easy, a more interesting alternative is to modify the existing entry.

mysql> update wp_options set option_value = "a:1:{i:291302011;a:2:{s:5:\"title\";s:4:\"Test\";s:4:\"text\";s:20:\"<?php new_test(); ?>\";}}" where option_id=347; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0

Let’s look at this more closely, the above query updates option_value to:

a:1:{i:291302011;a:2:{s:5:”title”;s:4:”Test”;s:4:”text”;s:20:”<?php new_test(); ?>”;}}

If you notice, two things have changed from the previous option_value value.

The first change is to the string length variable, represented by s, which precedes the string. In our example s:16 becomes s:20. More simply put <?php test(); ?> (16 characters in length) becomes <?php new_test(); ?> (20 characters in length).

The necessary changes is to the string itself, and probably the reason you are getting the undesirable behavior in the first place, is left up to the reader. It is my hope that this sets you in the right direction.

Whatever the cause, the following article will describe in detail how you can easily manipulate your wordpress database to move the misplaced comments you have to the post they belong under.

This article will accomplish this by using the command line mysql utility. Depending on where you have your wordpress blog hosted, you may not have access to the database at all, or if you do you may have to access it using a tool such as phpmyadmin.

But before I get started, here is a list of what you will need to complete this process:
* mysql username
* mysql password
* mysql wordpress database name

First you’ll need to connect to mysql and select your database
$ mysql -u wordpress -p Enter Password: ******** mysql> use my-wordpress-database; Database changed mysql>

Now, there are two tables that are of primary interest, wp_posts and wp_comments.
Let’s start with wp_posts, the columns of interest are ID and post_title.
mysql>select ID, post_title from wp_posts; +----+------------------------------------------------+ | ID | post_title | +----+------------------------------------------------+ | 4 | Bob Dylan | | 6 | Johnny Cash | +----+------------------------------------------------+

Now let’s look at the comments that have been left, they reside in the wp-comments table.
Here, the columns of interest are comment_ID, comment_post_ID, and comment_content.
mysql>select comment_ID, comment_post_ID, comment_content from wp_comments; +------------+-----------------+-------------------------------------------+ | comment_ID | comment_post_ID | comment_content | +------------+-----------------+-------------------------------------------+ | 1 | 4 | I really like Bob Dylan, nice article | | 2 | 4 | Johnny Cash is the best | | 3 | 6 | Johnny Cash the man in black | +------------+-----------------+-------------------------------------------+

Note, in wp_comments, comment_post_ID ties in to wp_posts ID. So that means there are two comments for the Bob Dylan post, and one comment for the Johnny Cash post.

But wait…

The second comment, with comment_ID 2 looks like it is supposed to be a comment for the Johnny Cash post. Let’s see how we can move it.
mysql> update wp_comments set comment_post_ID=6 where comment_ID=2; Query OK, 1 row affected (0.02 sec) Rows matched: 1 Changed: 1 Warnings: 0
and verify that it was moved
mysql>select comment_ID, comment_post_ID, comment_content from wp_comments; +------------+-----------------+-------------------------------------------+ | comment_ID | comment_post_ID | comment_content | +------------+-----------------+-------------------------------------------+ | 1 | 4 | I really like Bob Dylan, nice article | | 2 | 6 | Johnny Cash is the best | | 3 | 6 | Johnny Cash the man in black | +------------+-----------------+-------------------------------------------+

Good, the comment was successfully moved, but there is still a problem.
mysql> select comment_count from wp_posts where ID=6; +---------------+ | comment_count | +---------------+ | 1 | +---------------+
There are supposed to be two comments, so let’s update the comment_count for both the post that the comment was moved from, and where it was moved to.
mysql> update wp_posts set comment_count=2 where ID=6; mysql> select comment_count from wp_posts where ID=4; +---------------+ | comment_count | +---------------+ | 2 | +---------------+ mysql> update wp_posts set comment_count=1 where ID=4; mysql> select post_title, comment_count from wp_posts where ID in (4,6); +------------------------------+---------------+ | post_title | comment_count | +------------------------------+---------------+ | Bob Dylan | 1 | | Johnny Cash | 2 | +------------------------------+---------------+
And that’s it. Now your comments are moved and all of the counters have been updated to reflect the moved comments.

There are many reasons why you may need to put a redirect on your blog, perhaps one of the most common is when content changes or is moved; maybe you’re migrating an existing web page or blog into wordpress.

So let’s look at the migration scenario, we have a number of files which we want to move into wordpress posts and pages and since we are the authority on the modern stone age family, countless Bedrock fans link to us. Since we would like to maintain the integrity of these links, we look to htaccess and mod_rewrite to rewrite incoming requests for the old content hierarchy to our wordpress hierarchy.

Before we go futher, here is a look at the default wordpress .htaccess file, this file should reside in the wordpress root directory.
# BEGIN WordPress <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule> # END WordPress

Now, let’s consider the files (links) which we wish to maintain. Some are static html and others dynamic php which take arguments to determine the content.
/about.html /bedrock.html /bio.php?character=fred /bio.php?character=wilma /bio.php?character=pebbles /bio.php?character=dino

No problem, let’s knock about.html first, the mod_rewrite rule should look like this
RewriteRule ^about\.html$ /about [R=301,L]

This rule is fairly straight forward, but requires some knowledge of regular expressions, let’s break it down. RewriteRule is the configuration directive. ^about\.html$ is where it starts to look confusing.

The ^ indicates the beginning of the request, without this a request for whatabout.html or nothingabout.html would match the same as a request for about.html would.

Much like ^ does for the beginning of the request, $marks the end of the request. Without $ requests such as about.html.backup would match the same as about.html.

Finally, . is a special character in regular expressions which means match any character, so we escape it with a backslash to represent a literal period. Without escaping it, you would match requests such as aboutahtml.

Returning to our rewrite rule, /about is what we are rewriting about.html with.

[R=301,L] are the flags you’re passing the rewrite rule. R means redirect and 301 is a redirect code for permanent redirect, which is perfect in our scenario. L means this is the last rule, if we match, apply the rewrite and stop evaluating rules.

Now, let’s address /bio.php?character=fred, while you might logically try
# This does not work RewriteRule ^bio.php\?character=fred$ /fred [R=301,L]

It does not work and can lead to hours of frustration, the mod_rewrite rule should look like this
# Working Rewrite RewriteCond %{query_string} ^character=fred$ RewriteRule ^bio\.php$ /fred? [R=301,L]

We’ve introduced a new configuration directive, RewriteCond. As the name suggests, this directive allows you to pass conditions on which to assess the rewrite rule. In our scenario we want to assess RewriteRule if the query string, represented by %{query_string} is character=fred.

The RewriteRule should look familiar, as RewriteCond is already handling the arguments for the php script the only real difference is the trailing ? on the rewrite, without the trailing ?, when /bio.php?character=fred is requested, you would end up with /fred?character=fred after the rewrite. While this may be desirable in some scenarios, this is not what we want.

With these two scenarios addressed, we can complete our modification to .htaccess, after you’ve added the rewrite rules, your .htaccess should resemble the below.
# BEGIN WordPress <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteRule ^about.html$ /about [R=301,L] RewriteRule ^bedrock.html$ /bedrock [R=301,L] RewriteCond %{query_string} ^character=fred$ RewriteRule ^bio\.php$ /fred? [R=301,L] RewriteCond %{query_string} ^character=wilma$ RewriteRule ^bio\.php$ /wilma? [R=301,L] RewriteCond %{query_string} ^character=pebbles$ RewriteRule ^bio\.php$ /pebbles? [R=301,L] RewriteCond %{query_string} ^character=dino$ RewriteRule ^bio\.php$ /dino? [R=301,L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule> # END WordPress