WordPress, Disable and Delete Post Revisions

Post revisions are one of the more useless features of WordPress that do little but add bloat to the database.

At first they were kind of cool, but then what do you do with them?

You’re not running a wiki. Right?

Here is how to get rid of them once and for all.

Edit wp-config.php, add this line in to disable the post revisions feature.

define('WP_POST_REVISIONS', false);

You will also need to clean the database of all the previous entries under the wp_posts and wp_postmeta tables.

use database_name;
DELETE a,b,c FROM wp_posts a LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id) LEFT JOIN wp_postmeta c ON (a.ID = c.post_id) WHERE a.post_type = 'revision';

Congratulations, you are done! Enjoy your now much smaller database.

Another Day, Another WordPress Hack.

It could have been worse.

A few weeks ago we were hit with an SMF v1.1.3 exploit just a few days after the release of v1.1.4. The intruder inserted a slew of hidden spam links into the main ‘index.php’ file.

It took me a day or two to detect the modifications. And in this short time period forums.devside.net, which has been online since 2003, with a healthy Pagerank, had all it’s pages dropped from Google [with the exception of profiles and archives].

It’s a good thing I keep the forums on their own sub-domain, which Google treats more like a separate domain than anything else. A SE problem with the sub does not affect the main domain.

As a counter-measure to these “exploit app weakness, get shell, d/l script, profit” type of attacks, I have disabled most of the shell related PHP functions on the server.

And so I thought my problems where solved…

This time it’s my fault. I was running WordPress v2.2.2, with v2.2.3 having been released about a month ago. I’ve been checking the WP dashboard, but I must have missed it, or forgotten about it.

This time the intruder exploited one of many WP weaknesses, and inserted some type of a hidden “-1″ post that was nothing more than an attachment to this particular shell-script, executed with URL ‘/blog/?poncheg’…

WordPress Hack 1

WordPress Hack 2 - - [08/Oct/2007:07:10:20 -0400] "GET /wp-includes/js/tinymce/wp-mce-help.php HTTP/1.0" 404 520 "-" "-" - - [08/Oct/2007:07:10:25 -0400] "GET / HTTP/1.0" 200 12071 "-" "-" - - [08/Oct/2007:07:10:35 -0400] "GET /blog/wp-includes/js/tinymce/wp-mce-help.php HTTP/1.0" 200 7665 "-" "-" - - [08/Oct/2007:07:11:01 -0400] "POST /blog/xmlrpc.php HTTP/1.0" 200 4327 "-" "Opera" - - [08/Oct/2007:07:11:49 -0400] "POST /blog/wp-admin/options.php HTTP/1.0" 200 1647 "http://www.devside.net/blog/wp-admin/options.php" "Opera" - - [08/Oct/2007:07:11:56 -0400] "POST /blog/wp-admin/options.php HTTP/1.0" 302 904 "http://www.devside.net/blog/wp-admin/options.php" "Opera" - - [08/Oct/2007:07:11:59 -0400] "POST /blog/wp-admin/upload.php?style=inline&tab=upload&post_id=-1 HTTP/1.0" 200 1554 "http://www.devside.net/
blog/upload.php?style=inline&tab=upload&post_id=-1" "Opera" - - [08/Oct/2007:07:12:14 -0400] "POST /blog/wp-admin/upload.php?style=inline&tab=upload&post_id=-1 HTTP/1.0" 302 509 "http://www.devside.net/b
log/upload.php?style=inline&tab=upload&post_id=-1" "Opera" - - [08/Oct/2007:07:12:25 -0400] "POST /blog/wp-admin/options.php HTTP/1.0" 200 1629 "http://www.devside.net/blog/wp-admin/options.php" "Opera" - - [08/Oct/2007:07:12:30 -0400] "POST /blog/wp-admin/options.php HTTP/1.0" 302 904 "http://www.devside.net/blog/wp-admin/options.php" "Opera" - - [08/Oct/2007:07:12:33 -0400] "GET /blog/wp-admin/upgrade.php?step=1 HTTP/1.0" 200 1446 "-" "-"
... - - [08/Oct/2007:07:12:48 -0400] "GET /blog/?poncheg HTTP/1.0" 200 4789 "-" "Opera/9.22 (Windows NT 5.1; U; ru)"
JSC "VimpelCom" WLAN1 Moscow

Host name of is vps206.fastvps.ru

Luckily, in addition to the disabled PHP functions, I also had all my file/dir permissions under WP locked down, so it does not look like anything was modified. I still recreated the entire WP directory, just for safety sakes, and had to manually go into the database and delete the hidden attachment/post.

It’s not a matter of if you are going to get hacked, it’s a matter of when. So keep those web apps patched!

WordPress Blog Update

Having some free time on my hands, I have taken the liberty of upgrading our WordPress version from 2.0 to v2.1.

It was a rather simple procedure — since our blog is very standard [non-modified]…

  • Backup wp db, as a precaution.
  • Backup wp dir, as a precaution.
  • Unpack new wp version dir.
  • Copy over files wp-config.php and .htaccess
  • Run upgrade.php

With other setups, you would also want to copy over dir wordpress/wp-content, as it can contain themes, plugins, and images linked to from blog posts.

The major changes with our new setup are…

  • The use of the default WP theme, as it’s a bit cleaner.
  • The use of the Akismet spam plugin, hence allowing all visitors to post comments.
  • The use of the wp-cache plugin for faster load times.
  • The use of the Social Bookmarks plugin to allow interested readers to bookmark/submit an article to the various social sites.
  • The use of the Category Tagging plugin. [It’s the only one in its category that I could get to work]
  • The use of the Add-Meta-Tags plugin to improve Blog SEO.

The installation of the wp-cache plugin required permissions and ownership change for the wordpresswp-content dir…

  • ‘chown root:apache wp-content’ to give ownership to the Web-Server
  • ‘chmod 775 wp-content’ to give write permissions to the Web-Server

The Category Tagging plugin was a bit harder to setup, as it required the manual editing of a theme template and css file.

The other plugins installed automatic.

Previous posts: upgrading WordPress.

Upgrading WordPress, the Simple Way

I’m not sure why some instructions make simple task difficult, but here is how I upgrade WordPress…

Backup current ‘wordpress’ directory and database.

  1. cp -a wordpress/* /usr/local/bk/wordpress/
  2. mysqldump --user=root --password=XXX wordpress > /usr/local/bk/wordpress/wordpress.sql

Download and extract latest version of WordPress.
This will unpack a directory called ‘wordpress’ so be careful where you do this and how.

  1. wget http://wordpress.org/latest.tar.gz
  2. tar -xzf latest.tar.gz

Copy the newer wordpress files over the current base. This will not overwrite files ‘.htaccess’ or ‘wp-config.php’, or anything else that was placed or generated after the initial install.

cp -r --reply=yes wordpress/* /path/to/current/wordpress/dir/

Run upgrade script.