Освоение функций WordPress после обновления и автоматического сохранения

WordPress

Последнее обновление Сен 22, 2021

Содержание

Функция автосохранения WordPress

WordPress Post Revisioning Feature

AutoSave + Versioning = Хаос?

Поделитесь своим опытом

Не все любят ревизии в WordPress. На самом деле, некоторые люди этого не выносят. С одной стороны, неплохо иметь библиотеку послепроектных изменений, чтобы "откатиться", если вы вдруг допустили ошибку. С другой стороны, несколько копий каждого сообщения – отличный способ раздуть вашу базу данных в большенстве случаев бесполезной информацией.

Затем, чтобы усложнить дело, функция автоматического сохранения WordPress, похоже, имеет собственный разум, временами вмешиваясь в процесс пересмотра, даже когда пост-ревизия отключена. В совокупности эти функции после ревизии и автоматического сохранения, как известно, путают и расстраивают пользователей WordPress.

В этой статье я расскажу о том, как полностью контролировать возможности редакции версий в WordPress и функции автоматического сохранения. Мы рассмотрим, как работают эти функции, что они делают делают, когда они сталкиваются, и как остановить безумие раз и навсегда.

Функция автосохранения WordPress

WordPress реализовал функцию AutoSave в версии 2.1. Его функция – периодически (каждые 60 секунд по умолчанию) и автоматически сохраняет сообщение во время работы. Помимо случайного сохранения, AutoSave отлично работает и является настоящей выгодой для большинства пользователей WordPress. В отличие от проверки версий, AutoSave не создает новую запись базы данных для каждого сохранения. Вместо этого для каждого сообщения создается отдельная запись базы данных и обновляется каждым циклом AutoSave. Однако автосохранение не является совершенным, и многие люди находят временной интервал между сохранением слишком коротким или слишком длинным. К счастью, WordPress упрощает изменение интервала автосохранения простым трюком конфигурации :


define('AUTOSAVE_INTERVAL', 300); // in seconds

Просто укажите желаемый интервал автосохранения (в секундах) и добавьте код выше в свой wp-config.php файл, чтобы получить немедленные результаты.

Если вы один из редких людей, предпочитающих писать без функции автосохранения, вот простой способ отключить её вовсе:


function disable_autosave() {
    wp_deregister_script('autosave');
}
add_action('wp_print_scripts','disable_autosave');

Просто добавьте этот фрагмент кода в свою тему functions.php и попрощайтесь с Autosave навсегда!

WordPress Post Revisioning Feature

WordPress реализовала Post Revisioning (aka Version Revisioning) в версии 2.6. Его функция заключается в записи изменений, внесенных в ваши документы, путем хранения уникальных изменений в базе данных. Хотя эта функция может принести пользу нескольким пользователям, широко известно, что большинство пользователей WordPress не нуждаются в этом уровне функциональности. По моему скромному мнению, ревизионная «особенность» является излишней и совершенно чрезмерной. Она должена в идеале быть "вырезана" из ядра (то есть выпущена как плагин), или должна быть опция администратора, чтобы полностью отключить её. Последующая ревизия создает посторонний контент базы данных и, по моему опыту, работает непоследовательно и непредсказуемо. К счастью, есть простой способ отключить её, добавив следующую строку в ваш wp-config.php файл:


define('WP_POST_REVISIONS',false);

Или, если вы предпочитаете сохранять функциональность версий, но хотите ограничить количество разрешенных изменений, добавьте следующую строку в свой wp-config.php файл:


define('WP_POST_REVISIONS',3);

Существует даже способ очистить базу данных, удалив все данные после ревизии. Андрей Некулау показывает нам, как с помощью это сделать при помощи удобной небольшой команды SQL :


DELETE a,b,c FROM wp_posts a 
LEFT JOIN wp_term_relationships b 
ON (a.ID = b.object_id) LEFT JOIN wp_postmeta c 
ON (a.ID = c.post_id) WHERE a.post_type = 'revision'

Этот магический запрос уничтожит все пост-ревизии и связанные метаданные из базы данных.

AutoSave + Versioning = Хаос?

До сих пор все, что представлено в этой статье, довольно просто. На этом этапе я хотел бы обсудить постоянную проблему после реверсии, которая продолжает взрывать мозг любознательным администраторам WP, ведь даже когда пост-ревизия отключается с помощью ранее установленного метода. ИНогда она продолжает работать за кулисами даже после установки WP_POST_REVISIONS переменной false в файл конфигурации WP.

Почему я это говорю? Потому что я испытал следующую серию событий с несколькими различными установками WordPress:

Установка WordPress
Отключить пост-ревизию
Написать сообщение, сохранить его, отредактировать
Обратите внимание на сообщение, в котором говорится следующее:

Существует автосохранение этой страницы, которое является более поздним, чем версия ниже.

Я вижу, как временная метка автосохранения может конфликтовать с фактическим сообщением во время редактирования после публикации, но когда база данных проверяется после получения этого сообщения, обычно обнаруживаются несколько сообщений. По-видимому, WordPress по-прежнему сохраняет пост-ревизии за кулисами, даже когда ревизия отключена. При отключенной ревизии опция сравнения версий никогда не будет показана явно, но сравнительная функциональность продолжает работать. Кроме того, нет возможности изучить список непредвиденных пересмотров сообщений. Они существуют в базе данных, но не в области администратора. Таким образом, чтобы просмотреть и сравнить эти изменения, вам нужно сделать это вручную. Вот рецепт для этого:

Войдите в интерфейс базы данных, например phpMyAdmin
Запустите следующий SQL- запрос:
SELECT * FROM wp_posts WHERE post_type = "revision"

Если этот запрос возвращает результаты, WordPress сохраняет изменения без вашего согласия. Чтобы удалить эти изменения и все их данные, см. Метод, описанный выше. Чтобы просмотреть и сравнить различные версии в WordPress Admin, прежде чем предпринимать действия, выполните следующие шаги (снимок экрана, предоставленный для ясности):

Столбцы столбцов, отображаемые через phpMyAdmin

Определите исходный идентификатор сообщения для каждого набора исправлений
Определите идентификатор ревизии каждой отдельной ревизии
Для каждого набора исправлений, которые вы хотели бы сравнить, введите следующий адрес в адресной строке браузера:
```
http://domain.tld/wp-admin/revision.php?action=diff&right=X&left=Y
```

Отредактируйте домен, чтобы он соответствовал вашим собственному, а затем замените «X» и «Y» на идентификаторы ревизий любых двух ревизий, с которыми вы бы хотели сравнить (порядок не имеет значения).

Повторите эти шаги, чтобы сравнить столько изменений, сколько необходимо. Чтобы просмотреть отдельную ревизию, отредактируйте следующий код с идентификатором нужной версии и введите его в адресную строку браузера:


http://domain.tld/wp-admin/revision.php?revision=N

После того, как вы оценили свои автосохраненные версии, их можно безопасно удалить, либо сразу через SQL- запрос, указанный выше, либо отдельно, просто нажав кнопку удаления (красный «x» в phpMyAdmin) рядом с каждой ревизией в wp_posts таблице.

Поделитесь своим опытом

Мне любопытно узнать, что другие пользователи WordPress думают о функциях пост-ревизии и автоматического сохранения. Вы используете их, и если да, то как они полезны? Испытывали ли вы когда-либо неожиданное или необъяснимое поведение при написании сообщения при использовании функций пост-ревизии? Было бы также интересно узнать, сколько людей считают, что функция пост-ревизии должна была быть включена в ядро WordPress.

Статья была переведена для блога TechBlog.SDStudio.top
Источник: https://digwp.com

Источник записи: