New to the community? Start here

Possibility to only remove revisions older than 30 days

0

I would like to have an option in Hummingbird to remove only post revisions that are older than 30 days (or a custom amount of days).

Thu, 16 Jan 2020 17:40:53
  • Anton Vanyukov
    • Ex Staff

    Hi Dominique ,

    Revisions tend to clutter the database, so you are better off limiting the number of revisions per post that you keep. This can be done by setting a define in your wp-config.php file. For example, to limit to 3 revisions per post you would add this to wp-config.php:

    define( 'WP_POST_REVISIONS', 3 );

    Best regards,
    Anton

    • Noeste IJver
      • Recruit

      Hi Anton,

      Thanks for the suggestion. However, I don’t think this is quite the same as what I’m asking.

      When writing a post, you’re easily reaching 3 (or whatever amount) revisions, just while you’re writing your article.

      I’d think it would be much better if Hummingbird could clean revisions, after a week/month on automatic basis. That way users can still revert to an earlier post, but the database stays reasonable clean.

      • Anton Vanyukov
        • Ex Staff

        Hi Dominique ,

        You’re mixing up the concepts of optimization. I see that you’re wanting to clear out revisions to keep the database clean. Right? But your suggestion will do the opposite. A “day” for revisions is not a controllable value. You can get 1 revision on one day, 100 revisions on another day. After a month/week you’d end up with hundreds, maybe thousands of revisions. And most of them not that useful. Also, after N-days there won’t be ANY revisions for a post (the schedule will clear them out). Setting revision count to a reasonable value will get you the same 100 or 1000 revisions for your entire blog (depending on how many posts you have), and also provide a small history for all the posts. You can adjust the value depending on your needs.

        Above is the basic theory in layman terms. Now below is the technical side.

        Majority of MySQL servers use the InnoDB storage engine. Unfortunately, the way that it works is once the data is added to the table and written to the filesystem to the ibdata file, that file will never shrink. So if you were to add 100 Mb worths of data to the table, then remove that, the ibdata file would still be 100 Mb in size. I can see that there were some plans on changing that in MySQL 8, but it was a partial solution. In any case, most of the servers don’t run MySQL 8. Writing an uncontrollable amount of revisions to that database will just gradually increase the ibdata file. No matter if you clear those out from the database, you still won’t be able to reclaim the space back. So from the technical perspective, clearing out 1000 of revisions each month is counterproductive in terms of optimization.

        Hope the above explains the reason why it is recommended to control the revision count with the WP_POST_REVISIONS define.

        Best regards,
        Anton

  • Noeste IJver
    • Recruit

    You’re mixing up the concepts of optimization. I see that you’re wanting to clear out revisions to keep the database clean. Right? But your suggestion will do the opposite. A “day” for revisions is not a controllable value. You can get 1 revision on one day, 100 revisions on another day. After a month/week you’d end up with hundreds, maybe thousands of revisions.

    I am aware that a post can build up revisions while editing. That’s handy, as you can go back to an earlier version, while writing/editing. So that’s fine with me, if these revisions would be deleted over time. This doesn’t happen by default in WordPress, right?

    I don’t think the count is a good measurement, as a 100 revisions can be relevant on the day on which you’re writing the post, but not after a few weeks/months.

    I haven’t tested this plugin, but it says that it should be able to clear out revisions after X days: https://wordpress.org/plugins/rvg-optimize-database/

    See:
    [attachments are only viewable by logged-in members]

    Majority of MySQL servers use the InnoDB storage engine. Unfortunately, the way that it works is once the data is added to the table and written to the filesystem to the ibdata file, that file will never shrink. So if you were to add 100 Mb worths of data to the table, then remove that, the ibdata file would still be 100 Mb in size. I can see that there were some plans on changing that in MySQL 8, but it was a partial solution. In any case, most of the servers don’t run MySQL 8. Writing an uncontrollable amount of revisions to that database will just gradually increase the ibdata file. No matter if you clear those out from the database, you still won’t be able to reclaim the space back. So from the technical perspective, clearing out 1000 of revisions each month is counterproductive in terms of optimization.

    So configuring a amount limit for revisions won’t shrink the database size either?

    • Anton Vanyukov
      • Ex Staff

      This doesn’t happen by default in WordPress, right?

      That is correct.

      I don’t think the count is a good measurement, as a 100 revisions can be relevant on the day on which you’re writing the post, but not after a few weeks/months.

      Just out of curiosity, how many times over the past 30 days have you gone back further than several revisions on your posts?

      So configuring a amount limit for revisions won’t shrink the database size either?

      It will.
      Let’s say you’re writing 1 small post (1 page) every day for a year. One post is about 4 kb in the database. Just for the sake of the example, let’s say on average you get 10 post revisions for each post. That’s 4 kb * 10 revisions * 365 days = 14600 (approximately 14 Mb). Even when you clear out those revisions, your ibdata file won’t shrink. On the other hand, setting the limit to 3 revisions, you end up with 4*3*365=4380 (4 Mb). The difference will be much different in live examples where posts tend to be several pages long, with additional page builder codes. So that number can easily rise from 14 Mb to 100 Mb. And that’s only for a year. I have no issues with adding a filter that will allow you to define an “OLDER THAN” limit, just saying that you will be doing it not for optimization reasons.

      Best regards,
      Anton

      • Noeste IJver
        • Recruit

        Just out of curiosity, how many times over the past 30 days have you gone back further than several revisions on your posts?

        Me? Never. I’m a theme developer. My clients are the users of these sites and I know some of them regularly use the revisions. We’ve built a publishing product on top of WordPress and the databases for sites with this product are quite large.

        I still don’t really understand why removing revisions after a certain amount of time won’t free up the database. But if you are certain that it won’t help, don’t feel forced to add it, as it won’t make Hummingbird any better.

        Just to make sure, I would’ve liked it if I could configure how long revisions should be maintained. Of course there should be some kind of minimum amount so there would be a small history, indeed.