35 Comments


  1. Trac is not an acronym :)

    Also, link to the Trac bug. There should be comments on why it was marked as “won’t fix”, which I’m sure are valid.


    1. I’ve added a link to the ticket and the reasons for not adding options to control Post Revisions are stupid. Also, I’m not sure what you mean by TRAC is not an acronym as that is what the system is referred to, WordPress Trac.


  2. I use the same Plugin; and would like to see at least that functionality built into the core of WordPress. Some of my posts are written over several days, and I can save the content a dozen or more times. Those revisions soon start to mount up, even on a little blog like mine.

    …paul’s last blog post..Friday Foto


  3. OK, so where I do start on this?

    1. The entire feature should have been a plugin only. This is not something that most users need, if anything it is something that most users explicitly do not need. All users, answer this, have you ever used it to go back on a post? I haven’t.

    2. The whole concept is ill defined. I don’t see any good reason to have revisions for posts. Blog posts, as the blogosphere has communicated over and over again, should not be changed except to add updates. When they are changed they should explain what has changed. Therefore post revisions should all be deleted the moment the publish button is pressed, that is, if it really must be applied to posts at all.

    3. The feature is really an attempt to fill the gap with CMS systems. In that respect I don’t think it is a bad idea, when it is applied to pages. If it only applied to pages you really wouldn’t need the setting.

    4. If it really must be in the core, and it really must be turned on for posts and pages then these controls really must be in the core, and you must be able to turn it off.

    Andrew’s last blog post..How modular should a theme be?


  4. @Jeffro – You’re writing Trac in uppercase, as if it is an acronym. It should be called “Trac”, with a single upper case “T” to begin the word (it is a proper noun), followed by lowercase letters. It is not “TRAC”.

    With regards to that actual ticket, it was closed because it was possible to add a define to wp-config.php, not to remove the option entirely.


  5. @Andrew – The thing is, you can disable it. I’ve just confirmed by looking at the source code that you can add define('WP_POST_REVISIONS', false); and it will disable them entirely.

    @Jeffro – I checked the source code of WP and inserting that define should disable them completely. Make sure that it’s before wp-settings is included. If you’re still having problems, hit me up via IM or IRC and I’ll check it out.

    (Also, CommentLuv should remember me unticking it. It’s a pain to have to untick it every time.)


  6. @Ryan McCue – But you come at this from a developers point of view. Adding that line to the WP Config file is a no brainer. Try telling a Novice WordPress user to do that and it’s not that easy. Sure, the argument could be made that new users won’t know about post revisions or won’t care and perhaps that is a problem in and of itself.

    I’ve fixed the CommentLuv issue as I had the plugin set to have the box checked by default.


  7. @Jeffro – It’s a single line to copy and paste. Nothing can go wrong. Most users that will want to disable this will be the ones who know about their database. Most users set their database up and forget about it, without caring how big it gets. Only those who have some knowledge of WordPress will care about it at all.

    On the other hand, look at it from an interface perspective: more options in the UI creates more clutter. Having an option for every single thing in the options would expand them greatly, at little to no benefit. There are tonnes of hidden options available at the moment which most users don’t know about, because they don’t need them.

    In case you’re wondering about whether clutter in the options matters, take a look at this wonderful essay by Joel Spolsky.


  8. @Ryan McCue -I don’t really want it turned off though. I want it to be properly thought out in the first place so it doesn’t need turning off.

    It is also worth noting that it is the people who don’t know that are the ones who really need it to work properly and not clutter up their database. Who is it that gets blaned when their hosting gets $10 more expensive overnight for reasons they can’t understand. They just start bitching about WordPress.

    Honestly, I would take an extra option over 600+ extra post entries per year without a second thought.

    Andrew’s last blog post..How modular should a theme be?


  9. @Ryan McCue – even with the ability to turn it off with one line of code in the config file, now end users are stuck with everything or nothing with no inbetween. Which in the end, that plugin I mentioned above allows me to keep post revisions turned on but I now only have a maximum of two post revisions which I am totally comfortable with.

    We will have to agree to disagree but with something like Post Revisions which affects the database, effects every post and page in WordPress, there should be an easy way to manipulate how something like that works without a plugin considering it is a core feature.


  10. define('WP_POST_REVISIONS', 2);

    Will do the same as the plugin.

    now – imagine what havoc runs amok in WordPressMU when post revisions are left as-is. :D

    I worked on a single WP blog that had default revisions applied for maybe a month or two. Over half the size of the database was purely revisions. Granted, this was a busy blog with multiple authors and posts per day, but also multiple editing of posts. All of them saved.

    While I think it definitely should be optional, at least it can be easily disabled.


  11. @Jeffro – Controlling post revisions isn’t something most people will want. Remember that while you may not be a programmer, you are still a power user of WordPress and most users will not care about the size. People I’ve helped in the #wordpress chatroom are grateful for the fact that they can revert to a previous version and that it’s built in. But, I will have to agree to disagree on this one. :)

    @Andrew – If your host has arbitrary limits on database size, you should be looking for a new host. Most hosts limit the number of databases you get, but never the size of the databases themselves.


  12. If the db gets *too* large, it gets unwieldy to manage. phpMyAdmin has a 16MB limit by default, and I’ve seen that on many hosts. If I’m working for a client, then I don’t really have a say in where they currently host, but it makes my job easier if I don’t have to figure how to move a 40MEG database with limited access. :)

    Ssh? Sure, no problem then.

    Even if I weren’t moving hosts, even digging aroudn in a large database becomes more of a chore than it needs to.

    (gah, just noticed you were talking to AndreW.)

  13. D

    Post Revisions feature is poorly implemented. They’re not thinking of the diversity of WP users that exists now. It may be fine for people who just use WP as a personal diary type of blog, and maybe they revise a post 3 times for minor edits, but it is not necessarily good for people who use WP to build other types of websites, and that is getting more and more common. WP should make itself flexible for alternative users. I recommend disabling it via manual wp-config technique if you’re a power-user, for example a live-sports website where you update each Post some 100-200 times as the game develops (just one example of an ordinary sort of WP user who who revises a single post dozens of times, this may not be common but it is not unheard of or unreasonable to want this ability).

    The radically increased size of the database makes backups more unwieldy. It makes backup files bigger (and some of us back-up daily). It is multiplied if you keep several blogs within the same database (using different table pre-fixes, a long-standing feature of WP). If you wanted to do a selective search-and-replace of some word in your database it would now take much longer to sift through multiple copies. The way they implemented it without an option to limit the amount of Revisions saved, has driven away some users & is giving bad publicity to WP.

    It also broke the #1 podcasting method that existed in the World before this feature: PodPress plugin, on WP blog, was the leading method to Podcast, until this feature broke PodPress for untold 1000′s of users. You can blame PodPress’s developer for not updating on a moment’s notice, if you want, but WP should have looked at this and helped save PodPress in order to remain the best podcasting platform. Instead WP just suddenly debuted this feature that no one understood, and they looked away while PodPress faded, leaving it to 3rd parties to solve how-to-podcast in WP 2.7+ (and there’s still not a really great solution, wheras 2 years ago anyone would tell you that PodPress on WordPress was a great solution for podcasting).

    Some of the developer types are as stubborn as a mule on this question particularly on the “support” forum. That has also driven people away. They need to learn some marketing & public relations basics, and look at the big picture instead of getting so excited to whip out a new feature on short notice. Matt M. should make it his personal job to step back & look at the big picture. Yes this feature is cool, but is it production-ready? Does it break stuff? Is it good for the wide world of WP users that we have & that we want to switch over to WP in reality?


  14. I am really glad to see this post generate so much comment! It seems to be a good time to start looking into improving Post Revision and its implementation.

    I like the feature itself, but am not fond of the fact that it’s not even an option that can be controlled in the admin panel. Since it is now a core function, it would make sense that managing the different versions should be built within the core WP rather than relying on the excellent 3rd party plugins developed so far.

    Some people have already suggested that the functionality of Post Revisions may be better provided by a plugin rather than within core. Hopefully some of the WordPress developers can re-consider the current position please?


  15. Poor post revisions could use an interface in the core. Yea it’s a trivial configuration change, but I see why the mid-technical users get freaked out when revisions get numerous. This really gets noticeable on sites with decent amount of users.

    For me the downturn in the economy means no new hardware for a while, so I won’t be expanding my database servers. I’m limiting to 5 revisions for now to see how much data will expand. File sizes and time to backup databases will part of that benchmark test before I increase revisions.

    BUT… Big coolness for having a revision trail. Digging in the code also reveals there might be some interesting uses and may also lead to a way to save and authorize editing changes. It’s on my plugin wish list.


  16. I like my database to stay trim. I just had Bluehost drop one of my clients because their database grew too large too fast (Counterize sucks). Making a lot of posts/revisions could really beef up your DB.

    Tiny WordPress is a happy WordPress :)


  17. I’m always a fan of not using a plugin unless I have to. Here’s a few tips to do it yourself. As mentioned above, the following added to your wp-config.php would limit revisions to a maximum of 2 for a post (older ones get overwritten by the newer ones):

    define('WP_POST_REVISIONS', 2);

    The following line would limit revisions to be saved once every two minutes (120 seconds) when added to the wp-config.php file:

    define('AUTOSAVE_INTERVAL', 120);

    To delete all revisions from your blog, execute the following SQL query from your phpMyAdmin:

    DELETE FROM wp_posts WHERE post_type = “revision”;

    Hope this helps someone.


  18. @John Kolbert – Thanks John. While that will indeed help someone somewhere, not having a way to configure how the feature works in the backend is the core of the problem. I only appreciate software ASSUMING things for me when it assumes right. If it assumes wrong and doesn’t provide a way for me to correct it, I get very angry.


  19. @D -I agree that the feature is poorly implemented, I won’t rehash that myself now. However, I seem to recall that the developers did note that it broke PodPress and did actually offer a patch for it, but it was never implemented.

    Does anyone else recall that or did I dream it?



  20. @D – @Andrew – PodPress broke with the introduction of revisions. I can’t remember the exact reason why but I think it was saving the post meta against the revision instead of the post.

    A patch was made (I think by Andrew Ozz) and made available to the PodPress author but they did not commit it and release an update.

    I think in more recent versions of WordPress and second level of protection was added to add/update_post_meta() to stop it being added to post revisions as well (but this is only a hazy memory)

    Personally I don’t see what all the fuss is about, post revisions are a very important feature that allow you to work out what has changed and go back in time when a mistake has been made.

    We do understand how some people might not want post revisions and that is why a simple define will turn them off / configure them.

    However, 90% of users will not want to configure this functionality and therefore it makes no sense to add an extra amount of UI to configure it. The configuration is meant to be one time only not an ongoing changing thing so adding UI for it makes little sense.

    Peter Westwood’s last blog post..WordPress Milestones



  21. @John Kolbert – Thanks John Kolbert! I’ll definitely be using ’2′ as my guideline. Just out of interest… this does work retrospectively?? In the sense that if I add it on now, WordPress will automatically remove the previous revisions, leaving just 2?

    p/s: Sorry about the newbie question but I just wanted to make sure :)


  22. I’ve seen this subject debated on the WP forum and on a few blogs at the time this feature was released. It’s a great feature for some situations, but most single-user blogs are rarely going to have the need for this feature.

    The first thing I do when prepping a wp-config.php file for a new WP install is to include the following beforehand:

    /** Change X to the number of post revisions you want WordPress to save to the database **/
    define ('WP_POST_REVISIONS', false);

    I turn them off completely, as I don’t want the headache of having to go back in and remove the old revisions from the database.

    PS/Jeff, seems you didn’t install the Filosofo Comments Preview plugin on this blog. Could that be installed on this one too? :)


  23. @Flick – I’m actually not sure if it works retrospectively. My guess is that it doesn’t and that it will just prevent future posts, though I’m not positive about it.


  24. Perhaps adding the ability to control the number of revisions stored via the wp-config.php file would be a good compromise?

    Adding it as a core feature in the admin panel seems a little overkill. But adding a simple line in the wp-config.php file which could be uncommented when necesary seems fairly reasonable to me. Controlling how often the revisions are stored is not as useful IMO as controlling the number of revisions but at least it offers some control to prevent the database size exploding.


  25. @Ryan – But even you’re compromise requires the editing of the WP-Config file which is unsatisfactory considering the majority user group which uses WordPress and that user group is not made up of advanced users. I still think the best solution is in the WRITING section of the SETTINGS area, there is one line for Revisions. First, you can control whether revisions are used on posts, pages, both, or disabled. Second, a drop down menu or a text field where you can select the maximum number of revisions that are created for the previous selection.

    Instead, what we have here is the assumption that ALL WordPress users will want Post Revisions enabled as well as seemingly an infinite number of revisions created. And to top it all off, end users probably don’t even know what’s happening.

    I was thinking about this issue at work and I got fired up about it yet again because it’s just plain stupid the way in which your common end user has no control over that feature because it’s assumed that most users won’t bother to configure it and it is UI bloat. I feel as though it’s current implementation is a slap to the face of WordPress users.

    How about the UI admin option to customize how many lines the post box should be even though in the visual editor, you can drag the corner of the box to meet your requirements. Is that UI Bloat?


  26. @Jeffro – I would also want a checkbox option to delete revisions on publication.

    This has got me thinking about UI bloat thought and I think the following could be moved out of UI into wp-config, after all they only need to be set once, and could be part of the setup. After that there is almost never any need to change them unless you are already doing something much more significant.

    WordPress Address URL
    Blog Address URL
    Email Address (the admin one)
    Timezone
    Date Format
    Time Format
    Week starts on
    Remote Publishing (debatable)
    Encoding for pages and feeds
    The entire privacy page
    The entire permalink settings page
    The entire miscellaneous page

    If we can all agree that these are not needed in the UI then we can start a campaign to really clean out WordPress.


  27. @Andrew: The encoding for pages/feeds could be moved, but the rest of them need to stay in the UI. The whole purpose of this discussion (I thought) was to get the settings for the post revisions into the WP admin UI, to keep end-users from having to edit wp-config.php to set their preferences.

    The less often a user has to mess with wp-config.php, the better. WP has a lot of inexperienced users who could totally bork their blogs if they have to constantly edit the config file. For all users, it is just a pain to have to make those changes in the config file when the UI already exists to take care of them.

    Permalinks: This needs to stay in the UI. Troubleshooting an issue with someone’s blog may require setting the permalinks back to default and then reset them back. There are plugins (for example, WP Download Monitor) that require you to reset your permalinks after the plugin is upgraded. A user shouldn’t have to mess with the config file to do this.

    Timezone: For those of us who have DST, we would have to edit wp-config.php to change the timezone twice a year. Why move it, when we can already reset it via the UI?

    These are just a couple of items you mentioned, but there are reasons why each of them need to stay in the UI, since they are already there. The config file should be a “set it and forget it” once WP is installed.

    How about we work together to get the post revisions setting into the UI instead?


  28. @Kim -

    Kim, I’m in total agreement with you. I work with many newbie business owners, who just aren’t “techie”. While some of the skills seem simple to us, it’s an advanced skill to someone who doesn’t understand why you shouldn’t copy and paste from Word!

    It’s also the non-techie users that need to be protected from the dreaded db bloat. Many don’t know enough about data bases for the thought to even occur to them. While we don’t need the bloat either, at least we know where to go for help and how to implement the solution.

    Expecting new or non-tech folks to dig into code is sort of like expecting every new driver to be able to change the head gasket. The skills may come with time but shouldn’t be required to drive the car.

    I like the idea of short & sweet settings being in the UI because I can simply tell people to “change this setting to “X” and there is no chance of them making an oops involving other code.



  29. @John Kolbert – Sorry about my late reply, and thanks for taking the time to actually write back :)


  30. I’m developing my WordPress site locally and suddenly noticed how many post revisions I had built up.
    I looked around the Dashboard to find an option to delete them or limit them… you know the rest.
    Found this post and agree totally with you… will my database just keep filling up with post revisions until it bursts?
    I’m using WordPress 2.8.4, do you recommend the same plugin that you are using to limit post revisions? And… how do I delete the revisions that I have already built up?

Comments are closed.