Archive for the ‘Scripts FAQ’ Category

How to Delete Existing WordPress Post Revisions Stored/Saved

How to Delete Existing WordPress Post Revisions Stored/Saved

For users who had disabled or turned off post revisions tracking or versions history feature in WordPress (added since WordPress 2.6), it is also made sense to delete and remove all existing stored post revisions and changes made on pages stored in the database in order to reduce the wp_posts table size, especially when there is already tons of revisions or changes been kept.

To delete and remove all existing post revisions entries and rows from WordPress database Posts table, simply login to MySQL command-line interface, phpMyAdmin, SQLyog or other MySQL GUI tools. Select the appropriate WordPress database (if you have more than one databases on the same server), and then issue the following command (it’s also recommended to backup the database before performing the deletion SQL statements):

DELETE FROM wp_posts WHERE post_type = "revision";

Once all post revisions related records is purged, all revision histories is deleted, and users no longer able to check the changes by phase or compare differences between versions. Thus, deletion may also been used by administrator to ensure privacy or stop authors or writers in the blog from knowing their posts have been edited.

Disable and Turn Off Post Revisions Tracking in WordPress 2.6 or Above

Disable and Turn Off Post Revisions Tracking in WordPress 2.6 or Above

Another new feature in WordPress blog publishing system added since WordPress version 2.6 is post revisions tracking similar to version control system, which provides Wiki-like style tracking of edits been made onto the posts or pages. Post revisions tracking allows bloggers and authors to view who, on when, made what changes to any post or page, with ability to compare for differences between each saved versions, or revert back to older version.

WordPress Revision Versions Differences Comparison

Each version of post revisions is stored in WordPress database in wp_posts table. Over time, the database may grows bigger and becomes bloated especially when user prefer to click on “Save” button while writing a post or page (contrary to popular belief, auto-save feature in WordPress does not actually trigger or create a new revision version, unless specifically configure). Increasing size of database will surely putting more strains to busy web server, and may slow down post retrieval and web page serving. Beside, WordPress database backups will take longer time and bigger bandwidth to be downloaded.

For WordPress 2.6 or newer version users who feel that post revisions feature is not useful and suffice with AutoSave feature built-in in WordPress editor, post revisions tracking and keeping feature can be disabled and turned off.

WordPress provides constant WP_POST_REVISIONS that can be used in wp-config.php configuration file or plugin to set the status state for post revisions feature. To turn off and disable automatic post revisions all versions saving feature in WordPress 2.6 or later version, simply add the following line of code to wp-config.php file located in the root or home directory of WordPress blog.

define(’WP_POST_REVISIONS’, false);

Once set, WordPress does not attempt to save or store any revisions, except the one AutoSave per post.

How to Change the Frequency or Interval WordPress Auto Saves An Editing Post or Page

How to Change the Frequency or Interval WordPress Auto Saves An Editing Post or Page

WordPress developers add AutoSave feature into the popular blog publishing system since the release of WordPress 2.1, and it has became the permanent fixture in all future generation of WordPress, including WordPress 2.5 and WordPress 2.6 branches. By default, WordPress AutoSave will automatically save and store the unsaved and in-editing draft or published post/page every 60 seconds.

To change the frequency or the duration interval of which WordPress will auto-save the data and content in the HTML or Visual Editor, use the AUTOSAVE_INTERVAL constant to configure and set a new value for the interval duration. The constant can be added in the wp-config.php WordPress configuration file, which located in the root directory of the blog.

The syntax to be added to the wp-config.php to modify or change the AutoSave interval in WordPress:

define(’AUTOSAVE_INTERVAL’, 300);

Code in line above will instruct WordPress to auto-save a post or page every 300 seconds (or 5 minutes). If you want to specify a different time interval between auto-saved copy, just change the time value accordingly (in seconds).

How to Move WordPress Blog to New Domain or Location

How to Move WordPress Blog to New Domain or Location

For blogger who self-hosts the WordPress blog publishing system on a web hosting server with own registered domain name, sometimes, you may decide to reorganize the blog link URL to make it tidier or to reflect new focus or theme of the blog. If you decide to change the URL or link location of your WordPress blog due to changing of domain name (such as from to or the blog to another directory location (such as from to, there are some steps that should be done to ensure the proper migration and no breaking links.

The tricky part when moving WordPress blog to another location is that WordPress is using absolute path in URL link instead of relative path in URL link location when stores some parameters in database. Within blog posts’ contents itself, users may also use the old URLs when creating reference backlinks. All these values in the database will need to be changed when WordPress is moved. The following guide will show you which database fields that has references or values related to blog’s URLs that you want to modify. Note that this guide is not about how to move WordPress blog from one server or host to another new hosting service.

Once the blog has been moved (all files copy over in case of moving location or server or new domain name properly propagated across Internet for new domain name), the first thing to change is to tell WordPress the new blog location (wp-config.php should be no changes, and .htaccess file should be also no changes. If for some reason mod_rewrite rules for friendly URLs no longer works, you can always regenerate the .htaccess file via WP Administration’s Update Permalinks page). This value can be changed via WordPress Options page, but if you no longer able to access to old blog URL, you have to modify the value via MySQL database.

Note: The guide uses SQL statements based on MySQL replace() function to modify the database. To run SQL queries, login to MySQL database that houses WordPress tables via phpMyAdmin or login to the DB server and run MySQL client as root.

To update WordPress options with the new blog location, use the following SQL command:

UPDATE wp_options SET option_value = replace(option_value, '', '') WHERE option_name = 'home' OR option_name = 'siteurl';

After that you will need to fix URLs of the WordPress posts and pages, which translated from post slug, and stored in database wp_posts table as guid field. The URL values in this field are stored as absolute URLs instead of relative URLs, so it needs to be changed with the following SQL query:

UPDATE wp_posts SET guid = replace(guid, '','');

If you have linked internally within blog posts or pages with absolute URLs, these links will point to wrong locations after you move the blog location. Use the following SQL commands to fix all internal links to own blog in all WordPress posts and pages:

UPDATE wp_posts SET post_content = replace(post_content, '', '');

Browse through WordPress blog to check if everything is okay. You also need to re-login to WP Administration as authentication cookie has now became invalid due to different domain.