4 распространенных проблемы с редакциями WordPress, которые нужно исправить

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

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

Проблемы с редакциями WordPress

  1. Изменения увеличат размер базы данных.
  2. Проблема с резервным копированием из-за увеличения размера базы данных.
  3. Конфликт с настраиваемыми полями, созданными с помощью плагинов.
  4. Вызвать медленную загрузку редактора сообщений из-за переполнения памяти.

1. Какого размера потребуется база данных?

Каждая редакция сообщения хранится в вашей базе данных и извлекается при открытии сообщения в редакторе. Чем больше модификаций вы сделаете, тем больше ревизий будет сохранено, что увеличит размер вашей базы данных.

Вот сравнение размера базы данных с и без ревизии сообщения / страницы для сайта, имеющего 500 сообщений / страниц.

Без доработок:

Количество страниц / сообщений 500
Размер каждой страницы / сообщения 50 КБ
Размер базы данных без ревизий 500 * 50 = 25000 КБ = 25 МБ

С исправлениями:

Редакций на страницу / сообщение 5
Всего изменений 500 * 5 = 2500
Размер каждой редакции 50 КБ
Общий размер редакций 2500 * 50 = 125000 КБ = 125 МБ
Общий размер фактических сообщений 500 * 50 = 25000 КБ = 25 МБ
Общий размер базы данных 125 + 25 = 150 МБ
% увеличения размера (150-25) 25 * 100 = 500% (5 раз)

Размер и количество сообщений могут варьироваться в зависимости от вашего фактического сайта, но суть в том, что 25 МБ базы данных станут размером 150 МБ из-за нескольких ревизий WordPress. Более того, в реальном сценарии количество ревизий будет намного больше: от 10 до 20 на пост / страницу, включая одну автоматически сохраненную версию. Это 5-кратное увеличение размера базы данных может вызвать проблемы с размещением в том случае, если ваш хостинг-провайдер ограничивает использование размера базы данных.

2. Проблемы с резервным копированием из-за изменений WordPress

Даже если у вас нет ограничений на пространство для размещения, увеличенный размер базы данных будет беспокоить вас во время резервного копирования базы данных MySQL.

В приведенном выше примере, когда вы пытаетесь экспортировать содержимое базы данных MySQL с помощью phpMyAdmin, ему требуется в 5 раз больше времени, чем требуется на самом деле. Это может превысить ограничение по времени экспорта, установленное вашей хостинговой компанией, и приведет к таймауту с неполным резервным копированием. А если существует ограничение на загрузку, например, 50 МБ, вы никогда не сможете выполнить резервное копирование всего содержимого, что приведет к высокому риску потери содержимого.

Анализ резервной копии покажет вам, что некоторые сообщения отсутствуют и резервное копирование могло быть прекращено между таблицей «wp_post», где хранятся фактические сообщения, а также все ревизии. Вы обнаружите, что дальнейшие сообщения в таблице «wp_post» и любые другие таблицы, такие как «wp_links», «wp_users» и т. Д., Не были скопированы.

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

3. Конфликт настраиваемых полей с исправлениями

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

4. Медленная загрузка редактора WordPress.

Поскольку исправления загружаются при открытии публикации или страницы в редакторе WordPress, большое количество исправлений может вызвать медленную загрузку редактора WordPress Classic или Gutenberg. Иногда вы можете достичь такой степени, что не сможете получить доступ к сообщению из-за огромного количества исправлений, вызывающих переполнение памяти на серверах с низким объемом памяти.

Единственный способ здесь – удалить изменения из базы данных, чтобы вы могли получить доступ и обновить сообщение через редактор внешнего интерфейса WordPress.

Как отключить редакции в WordPress?

Когда вы решили поработать над этими исправлениями, есть три способа решить проблему:

  • Полное отключение функции ревизий.
  • Ограничьте количество ревизий и интервал автосохранения.
  • Удаление существующих ревизий, хранящихся в базе данных.

Щелкните здесь, чтобы просмотреть подробное описание каждой опции.

Хотя люди думают, что исправления вызывают медленную загрузку страницы, это неправда. Изменения не замедлят загрузку вашего сайта, так как они не отображаются в поисковых системах и извлекаются из вашей базы данных только при открытии публикации / страницы в редакторе WordPress. Даже страницы WordPress будут пересматриваться, поскольку WordPress рассматривает страницу также как сообщение.

Похожие записи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *