Is there a hook/function combination that can be added to my theme's functions.php
to properly disable REVISIONS and AUTOSAVE for the entire wordpress installation? What about if just for a certain custom post type? Searching online gives various hacks from deregistering scripts to tampering with core files. What's the acceptable/correct way to do this?
-
Here is better solution: stackoverflow.com/a/30821376/2377343 – T.Todua Feb 2 '16 at 14:30
-
How to disable post revision in wordpress.com website? – Santosh Kumar Dec 11 '16 at 19:12
This should be placed in your wp-config.php
(and no where else):
define( 'AUTOSAVE_INTERVAL', 60*60*60*24*365 ); // Set autosave interval to 1x per year
define( 'EMPTY_TRASH_DAYS', 0 ); // Empty trash now: Zero days
define( 'WP_POST_REVISIONS', false ); // Do not save andy revisions
-
update: when i add the
AUTOSAVE_INTERVAL
line, it makes the post editor page constantly run a javascript instruction that enables/disables the [Update] (and [Save Draft] on a new post) buttons, which also eventually makes all my other browser tabs much less responsive (gchrome18). hmm... thoughts? – Ana Ban Apr 14 '12 at 2:05 -
Yeah, that (propably) means that it's doing constant updates. Try to change it to
20000000000
, which should be a little more than a year. – kaiser Apr 15 '12 at 0:48 -
Does this disable autosave plugin of tinyMCE? Looks like it just sets a big interval only. – Michael Rogers Jun 12 '17 at 14:16
-
@MichaelRogers Well, if you consider a year not enough, give a lifetime a try ;) – kaiser Jun 12 '17 at 19:17
-
1@JossieCalderon Depends on where you set this. A
define
can not be overwritten, so turn on error reporting and make sure, you place it in yourwp-config.php
. – kaiser Aug 13 '18 at 22:38
I'm also looking for how to disable autosave. But here's what I was told in a Trac ticket:
If you really need this feature you should manage the sequential IDs yourself in a custom field and then implement custom URL routing. It shouldn't be too hard to pull that off.
-
hi @wikicms i'm cool with the ids, but thanks for posting. useful for somebody out there for sure, or even me in the future. – Ana Ban Apr 14 '12 at 2:42
Placing the defines in wp-config.php is fine until you turn WP_DEBUG on when you will get 'already defined' PHP notices in the debug.log every couple of minutes. Others claim placing these defines above the ABSPATH define will help.
However, I can categorically confirm the best place to put your defines is in a plugin, because the activated plugins are loaded before the WP default defines.
The default defines are protected with if exists tests, hence your plugin loaded defines will take precedence and will not cause a clash nor the repetitive PHP notices in the debug log.
-
1No,
wp-config.php
is the only correct place. If you get errors, some broken code elsewhere tries to define it again. Remove that code. – fuxia♦ Sep 20 '13 at 20:39 -
@toscho Why is
wp-config.php
the only correct place? Can you elaborate? – jdevlin May 28 '14 at 22:02 -
2@JamesDevlin Maintainability and debugging. You can do that in a very controlled environment, but if you get errors when you place it in
wp-config.php
, something else is broken, moving the defines is not a solution. – fuxia♦ May 28 '14 at 22:35