In previous versions of WordPress, if you enabled the Visual Editor via your User Profile page, that’s pretty much what you were forced to use. There was no way to leave it enabled and then just choose your preference locally from the Write/Edit post screen, so every time you updated your post, the editor would switch back to visual mode – even if you repeatedly click the HTML editing-mode button. Older versions of WordPress were like this for quite awhile, and during that time many WP peeps just decided to disable the Visual Editor to avoid the headache and constant switching.

Above is a screenshot of the User Profile page of version 2.3.3. At some point, it switched from “disabled” to “enabled”, as shown below for WordPress version 3.1.2:

Fast-forward to WordPress 3, and welcome the new streamlined Linking Tool that only works in visual-editing mode. It’s an awesome tool that makes internal linking almost fun, but unfortunately it is not available with the HTML editor. So all of those seasoned WP users who’ve been conditioned to disable the Visual Editor during setup are now completely missing out on the awesomeness of the new Link Tool.

I don’t know when it happened (which version), but somewhere along the way, WordPress started remembering your editing preferences right there in the Write/Edit post screen, so it’s no longer necessary to “Disable the Visual Editor” next time you’re setting up a site. Sure you can still disable it if you want to, but why? Leaving it enabled gives you the option to choose which editor to use while actually writing your post. This gives you access to WordPress’ new Link Tool without sacrificing your ability to compose in HTML mode.

Then again, I may be totally wrong and everyone already knows about this. I hope that’s the case, because the new Link tool is super useful and worth a quick jump into the Visual Editor.

© 2011 Digging into WordPress | Permalink | 16 comments | Add to del.icio.us | Post tags: Admin, editing, editor

Then, to complicate matters, WordPress’ auto-save functionality seems to have a mind of its own, at times interfering in the revisioning process even when post-revisioning has been disabled. Taken together, these post-revisioning and auto-save features have been known to confuse and frustrate WordPress users.

In this article, I explain how to take full control of WordPress’ version-revision and auto-save functionality. We’ll explore how these features work, why they don’t, when they clash, and how to stop the madness once and for all.

WordPress AutoSave Feature

WordPress implemented the AutoSave feature in version 2.1. Its function is to periodically (every 60 seconds by default) and automatically save your post while you work. Aside from the occasional hiccup, AutoSave works great and is a genuine benefit to most WordPress users. Unlike version revisioning, AutoSave does not create a new database entry for every save. Instead, a single database entry is created for each post and is updated with each AutoSave cycle. AutoSave isn’t perfect, however, and many folks find the time interval between saves either too brief or too long. Fortunately, WordPress makes it easy to modify the autosave interval with a simple configuration trick:

define('AUTOSAVE_INTERVAL', 300); // in seconds

Simply specify your desired autosave interval (in seconds) and add to your wp-config.php file to enjoy immediate results.

If you are one of the rare individuals who prefers to write without the autosave feature, here is an easy way to turn it off:

function disable_autosave() {
	wp_deregister_script('autosave');
}
add_action('wp_print_scripts','disable_autosave');

Just add that slice of code to your theme’s functions.php and say goodbye to Autosave!

WordPress Post Revisioning Feature

WordPress implemented Post Revisioning (aka Version Revisioning) in version 2.6. Its function is to record changes made to your documents by storing unique revisions in the database. While this feature may benefit a few users, it is widely understood that most WordPress users have no need for this level of functionality. In my humble opinion, the revisioning “feature” is overkill and completely excessive. It should have been left out of the core (i.e., released as a plugin) or there should be an Admin option to completely disable it. Post revisioning creates extraneous database content and, in my experience, functions inconsistently and unpredictably. Fortunately, there is an easy way to disable it by adding the following line to your wp-config.php file:

define('WP_POST_REVISIONS',false);

Or, if you prefer to keep the versioning functionality but limit the number of allowed revisions, add the following line to your wp-config.php file:

define('WP_POST_REVISIONS',3);

There is even a way to clean up your database by deleting all post-revision data. Andrei Neculau shows us how via this handy little SQL command:

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';

That magical query will nuke all post-revisions and associated meta-data from the database.

AutoSave + Versioning = Chaos?

So far, everything presented in this article is fairly straightforward. At this point, I would like to discuss a persistent post-reversioning issue that continues to rear its ugly head even when post revisioning is disabled via the previously prescribed method. Apparently, there is no way to disable WordPress’ post-revisioning functionality. It continues to work behind the scenes even after setting the WP_POST_REVISIONS variable to false in the configuration file.

Why do I say this? Because I have experienced the following series of events with several different WordPress installations:

1. Install WordPress
2. Disable Post-Revisioning
3. Write a post, save it, edit it
4. Notice a message that says something like this:

There is an autosave of this page that is more recent than the version below.

I can see how the timestamp on an autosave may conflict with the actual post during post editing, but when the database is examined after receiving this message, multiple post revisions are usually found. Apparently, WordPress is still saving post revisions behind the scenes even when revisioning has been disabled. With revisioning disabled, an option to compare reversions will never be shown explicitly, but the comparative functionality continues to operate. Further, there is no way to examine a list of the unintended post revisions. They exist in the database, but not in the Admin area. Thus, to see and compare these revisions, you need to do it manually. Here is a recipe for doing so:

• Log into a database interface like phpMyAdmin
• Run the following SQL query:

SELECT * FROM `wp_posts` WHERE post_type = "revision"

If this query returns results, WordPress has been saving revisions without your consent. To delete these revisions and all of their post data, see the method prescribed above. To see and compare different revisions in the WordPress Admin before taking action, continue with the following steps (screenshot provided for clarity):

Post ID columns as seen via phpMyAdmin

• Determine the original post ID for each set of revisions
• Determine the revision post ID of each individual revision
• For each set of revisions that you would like to compare, enter the following URL in your browser’s address bar:

http://domain.tld/wp-admin/revision.php?action=diff&right=X&left=Y

Edit the domain to match your own, and then replace “X” and “Y” with the revision post IDs of any two revisions you would like to compare (order does not seem to matter).

Repeat these steps to compare as many revisions as is necessary. To view an individual revision, edit the following code with the ID of the desired revision and enter it into your browser’s address bar:

http://domain.tld/wp-admin/revision.php?revision=N

Once you have evaluated your autosaved revisions, they may be safely deleted, either all at once via the SQL query provided above, or else individually by simply clicking the delete button (the red “x” in phpMyAdmin) next to each revision in the wp_posts table.

Share your experience

I’m curious to know what other WordPress users think of the post-revisioning and auto-save features. Do you use them, and if so, how are they beneficial? Have you ever experienced unexpected or unexplainable behavior while writing a post while using post-revisioning functionality? It would also be interesting to find out how many people think the post-revisioning feature should have been included in the WordPress core.

© 2009 Digging into WordPress | Permalink | 14 comments | Add to del.icio.us | Post tags: database, editing, optimization, performance, tips

When you have the visual editor turned off, this is the file responsible for created the buttons above the write panel. You know, the buttons like b for strong tags, i for em tags, b-quote for blockquote tags, etc. Personally I much prefer this to the Visual Editor, as I can see exactly what tags are being applied to my content.

But those default buttons are often not quite enough. I like to have a few more buttons easily available to me, like ones for h3-h5 tags, one that will wrap text in both code and pre tags, and one for a float-clearing div.

But remember in WordPress 2.8, this quicktags.js file is now compressed so it cannot be easily altered to include these new buttons like it used to. Thankfully they left a non-compressed version of the file in there as well, called quicktags.dev.js. To use this instead, just rename the quicktags.js file something like quicktags.ORIG.js and rename quicktags.dev.js into quicktags.js.

To add a new h3 button, add a block of code like this, amongst all the other similar code blocks:

edButtons[edButtons.length] =
new edButton('ed_h3'
,'h3'
,'<h3>'
,'</h3>'
,'h3'
);

Force refresh your Edit Post page and you should see the new button!

© 2009 Digging into WordPress | Permalink | 20 comments | Add to del.icio.us | Post tags: button, editing, tags