Minor changes checkbox for post revisions / possible new table for revisions

[lilyfan]

The post revisions feature at WordPress 2.6 creates one post for each revisions. Only if a user changed just one word/character, WordPress inserts one row to the DB. I think this is a wastefulness behavior.

I propose adding a "Minor Chagnes" checkbox at edit post panel. If it is ON, new version is replaced to the last revision, insted of inserting the new one. Therefore, no new revision is created for minor chages.

[rawalex]

My suggestion would be to create a table called wp_revisions, and write off the old version to the revision table instead. If someone wants to revert, it would be simple to pull a list of revisions. Further,it would be very simple to create a process that removed revisions after a set amount of time (say 30 days, adjustable in the admin) to avoid ending up with a big database.

It would also allow a potential variant of keeping only the last revision, as an example, for any post.

Revisions also need to be a settings option. Quite simply, enough people don't need revision history at all, so why subject them to all the db overhead and such for no reason?

[DD32]

Further,it would be very simple to create a process that removed revisions after a set amount of time (say 30 days, adjustable in the admin) to avoid ending up with a big database.

Absolutely no reason why that cant be done with the post stored in the *_posts table. The post_type is set to 'revision' and theres Indexes on the appropriate fields to speed lookups

It would also allow a potential variant of keeping only the last revision, as an example, for any post.
Quite simply, enough people don't need revision history at all

Well, Revisions are a great benfit to many people, However many people do not realise how useful they are, However, It is both possible to disable completely, And also limit it to storing x number of Revisions (Excluding autosaves): ​http://trac.wordpress.org/ticket/6775#comment:29

so why subject them to all the db overhead and such for no reason?

I do believe the Overhead would be very minimal, Database indicies are used for a reason, To speed lookups and filtering, The post table probably allready contains more attachments than posts for some people as it is.

[rawalex]

Replying to DD32:

Absolutely no reason why that cant be done with the post stored in the *_posts table. The post_type is set to 'revision' and theres Indexes on the appropriate fields to speed lookups

If the tables were properly indexed, if the queries were all good, and people didn't abuse the existing functions to extract data, you might be onto something. But the reality is that many of the queries used are not that effecient, and plugins like the google sitemap can just about wipe a virtual out.

Quite simply, enough people don't need revision history at all

Well, Revisions are a great benfit to many people, However many people do not realise how useful they are, However, It is both possible to disable completely, And also limit it to storing x number of Revisions (Excluding autosaves): ​http://trac.wordpress.org/ticket/6775#comment:29

I don't deny that revisions are a benefit to many people. Glasses are a benefit to many people, but if you don't need them, they are pointless. Seeing that it is so easy to tune this setup, what would it hurt to have something in the settings that would allow this to be decided by the individual blog owner and not to a single programmer with a personal opinion?

I do believe the Overhead would be very minimal, Database indicies are used for a reason, To speed lookups and filtering, The post table probably allready contains more attachments than posts for some people as it is.

Indexing is only part of the game, it cannot make up for horrible queries, poorly created joins, or other poor query habits. Indexes can't solve every problem, and those poorly written queries will ignore the indexes or waste them if not done right.

My suggestion would be create a test blog with 10,000 posts and 4 revisions per post, and then start running queries, sitemaps, and such. Then let me know how the performance changes when you delete the 40k revisions. I think you will see a minor difference in normal things like page builds, tags, etc.

[DD32]

Indexing is only part of the game, it cannot make up for horrible queries, poorly created joins, or other poor query habits. Indexes can't solve every problem, and those poorly written queries will ignore the indexes or waste them if not done right.

Then its the Queries which need to be optimized rather than the Database table in that case. More data is *allways* going to take longer to filter, I'll give you that.

[rawalex]

Then its the Queries which need to be optimized rather than the Database table in that case. More data is *allways* going to take longer to filter, I'll give you that.

More importantly, the vast majority of the queries done on this table (every normal page view) doesn't need this data. It isn't a complicated concept, it is very basic design: Don't load up tables with irrelevant data.

The other part is the idea that something like this wouldn't have a user option. Wordpress has plenty of options for much less relevant and important thing.

[ryan]

We may do a separate table in the future. An earlier implementation did use a separate table, but then this approach was tried. We're watching how things handle on wordpress.com, where we have some huge posts tables. Regardless, this is a discussion for the hackers list.

[FolioVision]

Hello ryan and everybody!

Sorry to reopen the old ticket, but this is still a problem. Adding this feature would make Wordpress faster, more scalable, better for bigger sites and more professional.

Our biggest site has 14,000 posts and 30,000 revisions right now. We are not storing any attachments in database. We had to delete revisions before to make the site faster.

This site was using Wordpress for last 5 years. Why not improve the core to make it possible to use Wordpress for another 5 years as the site grows? I'm sure there are tons of sites like this which might even need to be migrated from Wordpress to something bigger to solve issues like this.

Thanks,
Martin

[SergeyBiryukov]

Version field indicates when the enhancement was initially suggested.

[FolioVision]

Hello Sergey,

I changed the version to 3.3.1 to indicate that this is still a problem with the latest versions of Wordpress.

We are limiting the number of revision to 10, but deleting revisions older than month decreased the size of our database by 30% or so and also improved the performance. There are plugins to handle this, but what if we want to keep the revision somewhere? Why can't this just be fixed in core?

Hello ryan,

could you please share a bit of what you learned on wordpress.com in 4 years?

Perhaps just storing the revisions elsewhere would not help the Wordpress performance and scalability so much. What other possibilities are being considered? How can the database structure be improved for speed on big sites?

Thanks,
Martin

[gonzalorti]

The "minor changes" option sounds interesting.

But what I see would be a fundamental improvement is:

a) To stock the revisions (and autosaves) into a separate table

b) To clean the autosaves once you have published or updated the post.

Other interesting future improvements I suggest:

• To stock the attachments into a separate table (as to keep clean the main post table).
• To have the possibility in the options menu to:
  • Fix the maximum of revisions per post.
  • Help to clean revisions with a "delete all" option or an option for deleting automatically revisions older than X days/weeks/months/years.

[westi]

If revisions are causing significant performance problems on some hosts/sites then it is likely that the same performance issues would still occur without revisions in the posts table once the site had a large amount of content.

Rather than moving revisions to a new table, which doesn't work with how we have chosen to structure the underlying db and would generate a large amount of work we would do better to look into specific slow downs that revisions cause.

To do this we need specific examples of revisions slowing down queries / sites so that they can be investigated in detail.

On WordPress.com revisions continue to be a useful feature for end-users and have not causes us any big issue, in recent releases WordPress itself has worked on some of the large site scaling issues that come up with/without revisions and continues to do so.

The idea of a Minor Changes checkbox is interesting but I'm not sure that it should overwrite the previous revision but rather make note of the fact that the change was minor and present it differently - we will consider this as part of the work on Revisions for 3.6.

For now I'm going to close this ticket as WONTFIX again because we have no desire or plans to seperate out revisions or attachments into seperate tables and would rather address individual scaling issues as individual tickets.