Как правильно отключить REVISIONS и AUTOSAVE для всего сайта и отдельно для произвольного типа записи
Существует ли комбинация хуков/функций, которую можно добавить в functions.php
моей темы, чтобы правильно отключить REVISIONS и AUTOSAVE для всей установки WordPress? А если нужно отключить только для определённого типа записей? Поиск в интернете выдаёт различные хаки - от дерегистрации скриптов до вмешательства в файлы ядра. Какой способ считается правильным/приемлемым?

Этот код должен быть размещён в вашем файле wp-config.php
(и нигде больше):
define( 'AUTOSAVE_INTERVAL', 60*60*60*24*365 ); // Установить интервал автосохранения 1 раз в год
define( 'EMPTY_TRASH_DAYS', 0 ); // Очищать корзину немедленно: Ноль дней
define( 'WP_POST_REVISIONS', false ); // Не сохранять ревизии

обновление: когда я добавляю строку с AUTOSAVE_INTERVAL
, это заставляет страницу редактора записи постоянно выполнять javascript-инструкцию, которая включает/отключает кнопки [Обновить] (и [Сохранить черновик] для новой записи), что в конечном итоге значительно снижает отзывчивость всех остальных вкладок в браузере (gchrome18). Хм... какие мысли?

Да, это (вероятно) означает, что он делает постоянные обновления. Попробуй изменить значение на 20000000000
, что должно составлять чуть больше года.

Отключает ли это функцию автосохранения плагина tinyMCE? Похоже, это лишь устанавливает очень большой интервал.

@MichaelRogers Ну, если год кажется вам недостаточным сроком, попробуйте целую жизнь ;)

Привет, я сделал это, но моя установка Wordpress всё равно сохраняет черновики автоматически. В чём дело? @kaiser

@JossieCalderon Зависит от того, где вы это установили. define
нельзя переопределить, так что включите вывод ошибок и убедитесь, что вы разместили это в вашем wp-config.php
.

Чтобы отключить автосохранение в редакторе Gutenberg для WordPress 5.0+ ознакомьтесь с https://stackoverflow.com/questions/10234271/wordpress-auto-draft-disabling/65420515#65420515

Я также ищу способ отключить автосохранение. Но вот что мне ответили в тикете Trac:
Если вам действительно нужна эта функция, вы должны управлять последовательными ID самостоятельно в пользовательском поле, а затем реализовать пользовательскую маршрутизацию URL. Это не должно быть слишком сложно сделать.

Размещение определений (defines) в файле wp-config.php подходит до тех пор, пока вы не включите WP_DEBUG, после чего начнёте получать уведомления PHP 'already defined' в debug.log каждые несколько минут. Некоторые утверждают, что размещение этих определений выше определения ABSPATH поможет.
Однако я могу категорически подтвердить, что лучшее место для ваших определений — это плагин, потому что активированные плагины загружаются до стандартных определений WordPress.
Стандартные определения защищены проверками на существование (if exists), поэтому определения, загруженные вашим плагином, будут иметь приоритет и не вызовут конфликтов или повторяющихся уведомлений PHP в логе отладки.

Нет, wp-config.php
— это единственное правильное место. Если вы получаете ошибки, значит какой-то сломанный код пытается определить константы повторно. Удалите этот код.

@toscho Почему wp-config.php
— это единственное правильное место? Можете пояснить?
