Turn off “Post Revision”-feature
-
Hi!
I don’t like the “Post Revision”-Feature at all because it creates a alot of useless database-entries.. Can anyone please tell me how to turn it off? I’ve tried to comment out some related functions but since my latest SVN-update on 12th May WordPress starts creating revisions again..Just an idea: Would be great to turn that feature off in the Options/Write-Settings…
-
Otto, you are kidding me? No downside? Let’s see, wordpress already has a number of poorly constructed queries that don’t use indexes on the wp-post file, which in turn makes certain functions slow. Adding extra posts to that file (remember, not indexed, so they will have to be handled anyway) isn’t a “no downside” issue. Adding potentially huge amounts of data to an active datafile that won’t be used by 99.9% of the people who touch it (visitors to the blog will never see the revisions) isn’t good design.
As for you options comment, I can’t even answer, except to say “wow”.
Let’s see, wordpress already has a number of poorly constructed queries that don’t use indexes on the wp-post file, which in turn makes certain functions slow.
Easily remedied by adding indexes to the database, if needed. I’ve run it up to 20-30k posts and noticed no heavy slowdown with default settings. I admit that it would be nice if some of the more obvious indexes were added to the schema by default.
Adding potentially huge amounts of data to an active datafile that won’t be used by 99.9% of the people who touch it (visitors to the blog will never see the revisions) isn’t good design.
So, do you think that wiki’s tracking all the history is a bad idea as well? Revision tracking is useful only in edge cases, I grant you, but I reiterate that space is cheap and even the edge benefits outweigh the extremely minor costs.
As for you options comment, I can’t even answer, except to say “wow”.
Why? That’s an obvious principle of modern UI design. Do not make things too complex. Adding options that are largely useless is bad design. Disabling the revisions is largely useless. There’s no real case to argue for disabling it. Your arguments do not support disabling it, they support fixing other issues (poor indexing, for example).
At much more than 10k posts, the display time for simple pages gets longer, searches because slower, and so on. In part, it is because of the query that selects the posts for display, it has always had a pretty major flaw in it’s layout, the query is done in a way that makes the indexes pretty useless. I have added indexes to all the blogs I run just to be able to keep up with day to day, especially on the larger ones.
Adding significant numbers of extra records is never a good idea. Just correcting a typo is a new records. Notice 2 or 3 on seperate shots and suddenly you have 4 times the data for the same post.
Wiki is different from a blog, in that most of us are the only ones editing our own blog, or at most 2 or three people. Wiki had to add in an edit history mostly to deal with people defacing entries. Wikis are a very, very different game, and they use a significantly different methodology in order to avoid DB issues. It’s like a car, putting a ferrari body on a yugo still leaves you with a yugo.
In the case of wordpress, it would have been better to add a table called wp_revisions, where the old post is written off to each time the edit screen is accessed. The only time you need to look at revisions is during admin time, your blog readers aren’t checking your revisions and certainly you aren’t showing them to the search engines. Those combine for 99.9% of all wp_post queries, so why do it any other way?
The reasons for disabling it? Because the vast majority of the people writing personal blogs don’t need it. Most write a post and that’s that, and they might fix a typo. They don’t have 10 people coming in writing stuff, they aren’t worried about anyone defacing a post, etc. I am sure that some people may use it to recover a post when they do something like accidentally remove a post, but for the most part it is going to be tons of data that most people will never use, and that will go stale almost immediately.
Modern UI design says “give the users the options”, not “lock them into a single way of thinking”. Using that logic, there would be no need for plugins or themes because we would just all use the one right theme that someone has selected for us.
Why’s post revisions turned on by default, btw?
Space is virtually unlimited, granted, but let’s say I do have just a little paid space that currently runs “close to the wind”, but still runs fine. With an upgrade to 2.6, possibly doubling your DB size, I’d have to buy another bunch of space just because I’ve updated to an unwanted feature.
Opt-In’ify this feature, and noone will ever complain again.
I think the revision system is great, and definitely an important step for WordPress in being used not only as a personal blogging system but also as a full featured CMS for larger organisations.
However, something I find very strange about the design now, not using a seperate table for the revisions, is that a lot of data is stored for nothing. All fields in the wp_post table that are not subject to the revision system (comment_count, ping_status etc.) are just duplicated and take up space for no reason. A seperate table could hold less fields and theoretically save loads of space and performance.
And at the very least the diff system (which is great btw) could be used to see if title or body text were changed with the edit. It might just be a custom field or something plugin related that was edited, and an entire new revision row is a waste of space.
(seems like the post ID is maintained, never mind my rant about the IDs).
I don’t like the post revision feature as well. It’s not an issue of whether I have enough space or not in the database for those extra entries. I simply do not need them. Thus these entries are gonna be sitting in the database, rotting away and collecting dust. Now that’s not a very good use of resources is it?
I think that some sites (like what microkid mentioned) such as larger organisations would love the feature, but in any case, I think an option to turn it off would be great. That way, it’ll satisfy all users. (:
Otto: I’ve always had good impressions of the main WP support team here, but sadly, you have tarnished that image. I think you just failed to understand that the majority of users are using WP for a simple blog and do not need the post revision feature. It is not about “SPACE IS CHEAP.” Only a minority (when compared relatively) are using it as a full-fledged CMS.
Meanwhile, thanks for the temporary fix, Gamerz.
Ahh…Gamerz: I’m not sure if your fix is working. The IDs are still jumping whenever I edit something. I think all it does is to take away the “Post Revisions” portion from post.php. =/
And even auto-saves are now being assigned their own IDs? This is bad. =( Is there a quick fix we could use to undo this? (ie. go back to the 2.5 way of doing things.)
Honestly, I really don’t like the “Post Revision” feature. The reason has been told by other members, and I really wish there could be a choice to turn it OFF.
fantasycrusader, we were discussing the ID issue here, I found a solution that might help you.
Let’s not forget all the good work the main development team has done all this time. Even though you might not be happy with this new feature or the way it’s been implemented, the motivation behind it is clearly to make WordPress better. It’s an open source community, so instead of pointing fingers, try to put your effort in coming up with ways how to improved it.
I think the post revision feature is a great addition to the software, but must register my vote that it should:
1. be easy to enable/disable through settings
2. result in revisions being stored in a separate table, leaving only the most current version in the main posts tableI’d like to add that it might be nice to introduce some kind of pruning mechanism, so that revisions over X days are automatically removed (some might consider revisions over 28 days to be no longer required for example) or a maximum of Y revisions are kept. Naturally values would be user definable through the interface.
One of my installations is a prime example of a single-user system and I am a prime example of a user who always makes (multiple) minor adjustments to posts after they have been published, no matter how much I read and re-read the draft version.
I am on paid hosting, but space is limited and although a single revision doesn’t take up a lot of space, effectively tripling or quadrupling the size of each post is a concern.
Thanks.
Before reading this and similar threads I didn’t even know the function is there. Only when I pay attention, I see that there are jumps in post ids. Besides that I don’t need the function myself, I wonder what’s the use of it, because I can’t find where the revised posts are. Do I have to get them from the database manually or are they hidden in a place where I haven’t looked? Why not just under “manage” and “revised posts” or something?
I bet you’re the kind of person who actually manually goes through and deletes old email too, right? You really have to get over this “it takes up space” thing. Space is cheap and virtually unlimited. ??
No with my web host it isn’t. I’m limited to how much I can store in a database. Also, every time I want to backup the database, I have to download the whole thing. If it grows larger and larger, full of revisions, I have to download much more.
Excessive and useless options harm usability and make systems confusing.
There’s nothing excessive or useless about it. Why does WordPress have to go down the Microsoft “force users to do things exactly as well tell them” route? By all means, have an “advanced” options screen somewhere, or even just a text file with advanced options that non-technical users don’t ever need to see.
There needs to be an option to disable autosave (at least when editing existing posts – for never published posts it isn’t an issue).
There’s no real case to argue for disabling it.
So many people asking how to disable it is a pretty good case. People don’t want lots of extra entries in their database. Lots of plugins are broken now too because the meaning of a “post” in the database has changed.
There absolutely should be a button to turn it off. It has nothing to do with whether a particular person likes it or not. There are just certain options that beg to have an on and off button because users will be split on whether they want it or not. Customer service does not necessarily give an option when 1% want a feature. But I bet if turning it off was an option 1/3 of the people who thought about it would turn it off.
For the record, I sort of like the feature and probably would not turn it off unless I saw it impacting my site negatively in some fashion. But, I still think it should be there for those who do want it off.
The only thing I don’t like is how it saves a backup even if I don’t make any changes. Sometimes I open a page or post to look at something or copy something from the post. Then the next time I open the post, I get the big pink banner saying “There is an autosave of this page that is more recent than the version below. View the autosave”. That is annoying.
It seems ridiculous that “those in charge” are refusing to add an option – just one small checkbox – for this because it makes WordPress “cluttered and confusing”. Yet they were perfectly happy to add in a hugely confusing, obtrusive and wide-reaching feature such as revision control to WordPress in the first place.
If you don’t like this feature and would like an option added, please go to WordPress Trac and add your support to ticket #7360.
07/21/08 17:58:02 changed by ryan ?
status changed from new to closed.
resolution set to wontfix.
milestone deleted.Thank you :-/
But thank YOU!
07/23/08 03:45:08 changed by DD32 ?
Just a quick note: I’ve released a plugin which allows you to define the Revisions default setting from the admin, As well as on a per-post/page basis: https://dd32.id.au/wordpress-plugins/revision-control/
- The topic ‘Turn off “Post Revision”-feature’ is closed to new replies.