WordPress Tip: Careful with that Autosave, Eugene
After upgrading WordPress from version 2.0.5 to 2.3.3, I did some experimenting with the “post autosave” feature. The autosave feature uses some crafty ajax to automagically save your post every 2 minutes (120 seconds by default). Below the post-editing field, you will notice a line of text that displays the time of the most recent autosave, similar to the following:
Surely, this relatively new feature provides an added layer of protection against lost work, but all is not perfect (yet) in the world of automatically saved content.
Several months ago, I lost several hours of work because the autosave feature completely failed to work, despite the periodically reassuring “Saved at..” message. After working for several hours with a false sense of security, WordPress choked and my post had vanished. In shock, I scoured the database for any trace of my recent efforts, but to no avail. The entire post had disappeared into the void. Utterly devastated and disillusioned, I decided to investigate the so-called “autosave” feature, learn what had happened, and take steps to avoid such travesty in the future. Here is a summary of my investigation..
A few notes on the WordPress Autosave feature
The reason autosave failed — Although autosave seemed to be working as expected, all data was lost after I had clicked the “Save” button and received an unexpected server error. Apparently, either my server or WordPress (or both?) doesn’t respond well to various types of character combinations (e.g., the term “
.htaccess”), and will reject any post input containing “invalid” content.
So, without realizing that I had included some forbidden character string, I habitually hit the save button, only to trigger an error and get redirected to a server-error page. Oops, but not a big deal, right? After all, “WordPress Autosave has my back.” Or so I thought. Upon returning to the admin screen, I found no trace of my post. A thorough examination of the database confirmed that autosave had saved absolutely nothing: I lost three-plus hours of diligent work — poof! — just like that.
Moral of the drama: Don’t rely on WordPress Autosave if the possibility exists that your content will trigger an error when saving or publishing your post. I can’t say that autosave will always fail in such cases, but I can say that it is definitely possible. Moving on..
How do you know if autosave actually worked? — If autosave managed to do its job and save your post content, WordPress will display a link to a draft of your saved post. I have seen this link in either of two places, depending on your user status:
- as an individual link located above the post-editing panel, or
- mixed in with other posts listed within the post management panel
If you think that you may have lost some content, and don’t see a draft version of your autosaved post in either of these locations, an autosave failure is highly probable. You may have better luck than I did, however, by searching through your associated WordPress database for the missing content. If you did lose work, believe me, I feel your pain.
Implement a backup strategy — As nice as the concept of “autosave” sounds, don’t rely on it to save your work. Think of it as an added layer of protection against boo-boos, but treat it as nothing more than a bonus feature that may or may not work as intended. Seriously, losing three hours of meticulously crafted material is a total drag. Since then, I have adopted a new strategy for backing up my posts while working on them:
- Work for few minutes or type a few paragraphs
Ctrl-Vinto a blank
- Work for few minutes or type a few paragraphs
Ctrl-Vto replace previous
- Wash, rinse, repeat..
I have been doing this for several months now, and the practice has become almost second-nature. It takes only a few extra keystrokes and a few microseconds, but the habit has already saved my rear on several occasions. Then, as an added bonus, when I am finished writing the post, I also copy & paste the date, title, keywords, description, excerpt, and tags to the text file, save it as the name and date, and zip the monthly collection of posts into a nice archive directory. Paranoid and tedious? Perhaps. Time-saving and reassuring? Definitely.
How to change the time-interval for WordPress Autosave
While experimenting with the autosave feature for this post, I discovered how easy it is to change the default autosave time interval. In WordPress 2.3 (and probably 2.2 and 2.1), open the
wp-includes/script-loader.php and edit the instance of
120 (seconds) to something more appropriate. Don’t get too crazy though, or you might get a nasty email from your host. Here is how the interval-setting code appears on line #43:
'autosaveInterval' => apply_filters('autosave_interval', '120'),
Other stupid Autosave tricks..
While tinkering, I also learned that it is just as easy to customize the default messages displayed throughout the autosave process. While saving your draft, WordPress displays the text, “Saving Draft…”. Then, in between saves, the text “Saved at 2:34:02”, as displayed in the previous screenshot. To change either of these default messages, open the same file as before (
wp-includes/script-loader.php), and edit the following lines to suit your needs:
// line #45 >> 'saveText' => __('Saved at %time%.'), // line #47 >> 'savingText' => __('Saving Draft...')
Other interesting autosave quirks
Also during the investigation, I happened to stumble upon an interesting discovery concerning a common technique for displaying a blog’s annual archives. WordPress provides the following built-in methods of querying and displaying daily and monthly archive listings:
<?php wp_get_archives('type=postbypost'); ?> <?php wp_get_archives('type=monthly&show_post_count=1'); ?>
However, earlier versions of WordPress did not provide similar functionality for the presentation of yearly archives. To accommodate this missing feature, many WordPress users and theme developers have employed the following, highly prevalent method:
<ul id="archives"> <?php $years = $wpdb->get_col("SELECT DISTINCT YEAR(post_date) FROM $wpdb->posts ORDER BY post_date DESC"); foreach($years as $year) : ?> <li><a href="<?php echo get_year_link($year); ?>"><?php echo $year; ?></a></li> <?php endforeach; ?> </ul>
Fair enough, that trick definitely does the job, however, drafts and autosaved posts produce some unexpected results. Specifically, post drafts are stored along with published posts in the
wp_posts database table. Thus, the above query returns a “year” for all post drafts and displays their values in the annual archive list. Any post draft that happens to be a working “autosave” draft will return a zero (i.e., “
0”) for the above yearly archive query (see screenshot).
In other words, drafts are saved with a
post_date of zero. Also, any posts that are deliberately saved as “draft” (i.e, any post that is not published) will also display a zero if the previous database query is used. Fortunately, there are at least THREE easy ways to prevent meaningless zeros from populating your annual archive list:
1) Re-save the draft(s) with an explicit time stamp (hint: pick a year that already exists in the annual archives).
2) For users of WP versions less than 2.3, tweak the database query to ignore posts with “draft” status:
<ul id="archives"> <?php $years = $wpdb->get_col("SELECT DISTINCT YEAR(post_date) FROM $wpdb->posts WHERE post_status = 'publish' ORDER BY post_date DESC"); foreach($years as $year) : ?> <li><a href="<?php echo get_year_link($year); ?> "><?php echo $year; ?></a></li> <?php endforeach; ?> </ul>
3) Even better, for WordPress 2.3 and beyond, simply replace the direct database call with the new “built-in” hotness:
<ul> <?php wp_get_archives('type=yearly&show_post_count=1'); ?> </ul>
This third method includes several useful parameters, including the ability to display the post count next to each year.
That’s it for this post! See you next time with another fun-filled and educational adventure into WordPress land!
at version 2.5 at WP is the autodraft-function new and the time-interval is 60s in standard. You can define a konstant in wp-config.php for other times, maybe 1s.
define( 'AUTOSAVE_INTERVAL', 1 ); // Autosave interval
I hope and wish, the function is realy better in 2.5.
Wow this post definitely packs a big punch :) thanks for highlighting the autosave failure issue, I get that quite often as well. My drafts fail to save properly so much so that I resort to copying the raw HTML code and pasting it in a text edior every few minutes and before I publish for the post. I can partially blame my ISP for the unstable connection (sometimes the publishing process just go timeout and the whole post is a gone-case).
I’ve been trying to edit the autosave intervals among the wordpress files, thanks for telling me where it is :D
Oh and when I logged in to WordPress today, they say 2.5 beta is out! The dashboard looks so different, I’m very impressed. I hope they don’t change the autosave script since what you’ve provided is a great fix!
…or one of these days I’m gonna cut you into little pieces :)
That’s the idiot-proof way of not losing my precious posts, heh. Oh, and yea sometimes weird things happen when you save or republish a post – the tags just disappear for no reason! I’ve got it a few times, and now I’m forcing myself to either take a mental note of the tags or copy them wholesale into notepad :)
Idiot-proof workarounds are always the simplest, but hey what you’ve provided saves a lot of trouble from all the copy and pasting.
P.S. that’s a very quick reply from you!
@Frank: Thanks for the information. I am looking forward to working with WordPress 2.5. I assume the
define()interval is in minutes?
@teddY: Very wise to copy/paste your post content every few minutes, and especially right before hitting the “Publish” button! I also copy any custom fields into the text file, including tags, meta information, and the title. From what Frank says, it sounds as if customizing the autosave interval is much easier in WP 2.5. In any case, it looks like I posted this information just in time — hopefully it will still help users of previous versions of WP! ;)
@H5N1: Exactly :)
maybe, i think is in seconds, when i tested with 1, then saved evry 1s an edit-area.
Yes, that makes sense.. The autosave function uses an interval defined in seconds for WordPress 2.3 as well. Seconds are better because they enable a greater specificity for the interval. Thanks for the info!
It never even occurred to me that the auto-save wouldn’t actually work. I very often do the Ctrl-A, Ctrl-C ting, and, in fact, just a few minutes ago, I nearly did it. But no… Instead I glanced at the “Saved at…” line and thought, “It’s ok, it has saved it”!
Didn’t anyone tell the WordPress developers that you do a proper read-back of the database?!?!
Apparently not, unfortunately, although some sort of a plugin to enhance the WordPress autosave feature would surely be worth the effort. Just think of all the lost work and time that would be saved with some reliable autosave functionality. Could save into the database as well as to a text file, provide configuration options, time intervals, custom settings — the whole bit! Now, if I could only find the time.. ;)
this just happened to me and it is just infuriating. siiiiiiiighh. i honestly thought wordpess was better than this and i didn’t need to make a hard copy of every draft before posting. i guess i was wrong. thanks for the insightful post and research into this matter. it’s a little late for me but i will heed the all powerful ctrl + a ctrl + c method in combo with notepad2…. man i could freakin eat somebody’s face off right now.
@jay: lol, I feel your pain, brother! The good news is that WordPress 2.7 features a revamped autosave feature that supposedly lets the author know exactly what the status of their post is.. (i.e., saved in the database or not).
I have had trouble with autosave as well. I learned my lesson and write everything in my word processing program now and then copy and past the final version into Word Press.