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.

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?

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.

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.

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.

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.

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.

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