Talk In Code

Wordpress has a neat little feature that allows you to write a post and then schedule it to display at some point in the future. This seems good, but it invariably doesn’t work on some server platforms and rather than publishing a post Wordpress just counts the amount of time passed since it was supposed to go live. The basic solution to this is to go into the post and click on publish, which can be a pain if you are taking a couple of days off from blogging and want to leave it running.

The problem lies with the functions that convert a scheduled post into a live post which are kept in the file wp-cron.php in the root Wordpress directory. For some reason the Wordpress developers decided to call the scheduling functions using the fsockopen() function available in PHP. This essentially opens a browser session to the wp-cron.php file, just as you would if you browsed to the location using your web browser.

What seems to be happening is that the browser request is getting blocked due to a permissions problem, which leads to Wordpress simply not running the cron functions. However, even when the wp-cron.php file is loaded manually using your web browser there are two if statements at the top of the file that tend to stop things from working.

After much tinkering and research I have found the following solution.

Open the file wp-cron.php (situated in the main Wordpress folder) and comment out lines 6 to 10.

Change this:

<?php
ignore_user_abort(true);
define('DOING_CRON', TRUE);
require_once('./wp-config.php');
 
if ( $_GET['check'] != wp_hash(’187425′) )
  exit;
 
if ( get_option(’doing_cron’) > time() )
  exit;
 
update_option(’doing_cron’, time() + 30);

To this:

<?php
ignore_user_abort(true);
define('DOING_CRON', TRUE);
require_once('./wp-config.php');
 
/*if ( $_GET['check'] != wp_hash(’187425′) )
  exit;
 
if ( get_option(’doing_cron’) > time() )
  exit;*/
 
update_option(’doing_cron’, time() + 30);

Next, open the index.php file in your Wordpress folder and change it from this:

<?php
/* Short and sweet */
define('WP_USE_THEMES', true);
require('./wp-blog-header.php');
?>

To this:

<?php
/* Short and sweet */
define('WP_USE_THEMES', true);
require('./wp-cron.php');
require('./wp-blog-header.php');
?>

This adds a the wp-cron.php file every time the blog is looked at and because we have removed the if statements at the top of the file the cron functions are always run.

This might cause a small issue on very busy blogs as it can make your pages load slightly slower than normal. So if you have a lot of traffic you might want to just save your posts in draft form and publish them manually each morning.

Of course to run the cron functions on Wordpress (modified or not) you need to actually look at the front page of the blog. If you are refreshing the administration section then nothing will happen.

A good security tip when installing your Wordpress blog is to change the database table prefix, the idea is that this will hide the tables from any hackers looking to compromise your blog. This can be done in the wp-config.php file and the variable $table_prefix. Changing this value from the default wp_ to, for example, blog_ will change the table wp_posts to blog_posts, making it more difficult for hackers to find it. Using blog_ is only an example, you should treat the prefix like a password, include letters and numbers to make it more difficult to find.

But what happens if you have installed your system and want to change the prefix? Well you need to change the $table_prefix variable in your wp-config.php file and alter the tables in your Wordpress database. Which one you do first is up to you, but you should go them both as fast as you can. Here are some MySQL statements that should help you to do this.

ALTER TABLE wp_comments RENAME TO blog_comments;
ALTER TABLE wp_links RENAME TO blog_links;
ALTER TABLE wp_options RENAME TO blog_options;
ALTER TABLE wp_postmeta RENAME TO blog_postmeta;
ALTER TABLE wp_posts RENAME TO blog_posts;
ALTER TABLE wp_term_relationships RENAME TO blog_term_relationships;
ALTER TABLE wp_term_taxonomy RENAME TO blog_term_taxonomy;
ALTER TABLE wp_terms RENAME TO blog_terms;
ALTER TABLE wp_usermeta RENAME TO blog_usermeta;
ALTER TABLE wp_users RENAME TO blog_users;

This just renames the default tables so that they have the new prefix, just do a find/replace on the text ‘blog_’ to be something unique. Note that this doesn’t include any tables created for any plugins that you have, so you will have to add SQL statements for each of these tables.

This allows the front page of your blog to function properly, but when you try to log in to the admin section you will see the following error.

You do not have sufficient permissions to access this page.

This occurs because of some user settings that are created when the database is created and when new users are added still reference tables with the old prefix. The tables wp_usermeta and wp_options need to be changed as they both reference tables by name and will not produce the desired results if you change the table prefix.

To change the wp_usermeta (or blog_usermeta if you used the above SQL statements) table use the following SQL query.
UPDATE blog_usermeta SET meta_key = REPLACE(meta_key,'wp_','blog_');
This will change values contained in the meta_key column. The values that are changed look something like wp_capabilities, wp_autosave_draft_ids and wp_user_level, although wp_autosave_draft_ids won’t be there unless you have saved drafts of posts while editing them.

To change the wp_options table (again, this would be blog_options) use the following SQL query.
UPDATE blog_options SET option_name = 'blog_user_roles' WHERE option_name = 'wp_user_roles' AND blog_id =0;

You should now be able to access your admin system.

This post applies to Wordpress version 2.3.3.