Следующим шагом будет быстрая сортировка основных элементов с автоматической загрузкой данных. Вот быстрая команда SQL, которую можно использовать для составления списка 10 лучших:
SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 10;
Опять же, возможно, вам придется подкорректировать приведенный выше запрос, если ваш сайт WordPress использует другой префикс, отличный от wp_
.
Содержание
Исследование отдельных данных автозагрузки в wp_options
Следующим шагом будет изучение некоторых наиболее часто загружаемых автоматически данных, которые мы получили выше через запрос к БД.
301_redirects
Как мы можем видеть выше, самым первым и самым большим вариантом автозагрузки является 301_redirects
. Вероятно, это напрямую связано с плагином перенаправления на сайте или плагином WordPress SEO, который также имеет функцию редиректа. В этом случае лучшей рекомендацией является реальная реализация редиректов на уровне сервера.
Почему? Потому что использование бесплатных плагинов WordPress для реализации редиректов иногда может вызвать проблемы с производительностью, так как большинство из них используют функцию wp_redirect, которая требует дополнительного выполнения кода и ресурсов. И, конечно, это также автозагрузка данных в таблице wp_options
.
wpurp_custom_template_
Следующим по величине параметром автозагрузки данных был wpurp_custom_template_#
. Мы видим, что для него существует довольно много различных строк. Обычно вы можете найти название этой опции и соединить точки, заглянув в папку тем или плагинов. В данном случае мы выполнили команду grep с сервера, чтобы проверить, сможем ли мы найти его. Вы также можете проверить его через SFTP.
grep -Ri "wpurp_custom_template_"
Однако вышеуказанная команда ничего не дала, поэтому пришлось залезть в Google и выполнить поиск. Быстро обнаружилось, что это было связано с плагином WordPress, который больше не был установлен на сайте, известным как WP Ultimate Recipe. Это классический пример ненужных данных, оставленных в автозагрузке. Скоро я опубликую подробное руководство по удалению плагинов WordPress правильным способом. Под правильным способом я подразумеваю реальную очистку оставленных данных.
um_cache_userdata_
Следующим по величине параметром автозагрузки данных был um_cache_userdata_#
. Мы видим, что для этого параметра существует довольно много различных строк. Так как эта строка находилась в самом низу, мы быстро модифицировали нашу команду MySQL, чтобы показать 40 основных автозагружаемых данных:
SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 40;
Или суммируйте все значения с этим префиксом:
SELECT 'sum size in KiB', ROUND(SUM(length(option_value))/1024,0) FROM wp_options WHERE autoload='yes' AND option_name like "um_cache_userdata_%"
Мы увидели, что в таблице wp_options
стало гораздо больше записей для um_cache_userdata_#
. Мы снова запустили команду grep
для проверки папок plugins и themes (плагинов и тем).
grep -Ri "um_cache_userdata_"
Затем мы смогли быстро определить, что это связано с плагином Ultimate Member. Еще один быстрый поиск в Google дал несколько хороших решений этой проблемы (см. статью). Никогда не стоит недооценивать силу поиска Google! Оказалось, что в плагине есть несколько различных вариантов решения этой проблемы:
- Ultimate Member > Dashboard > User Cache > Clear Cache (Очистить кеш)
- Ultimate Member -> Settings -> Advanced -> Stop caching user’s profile data (переключить в ON), затем Save Changes
Другой способ посмотреть, что такое автозагрузка, - это нажать кнопку редактирования, где может быть указан каталог плагина/темы или сайт разработчика.
Cron Jobs
Еще один частый вариант, который мы видим при большом количестве автозагружаемых данных, - это cron. Это может быть что угодно, связанное с cron (крон).
Поэтому вы можете нажать кнопку "редактировать", чтобы увидеть причину. Вот пример ниже, в котором было очевидно, что причиной проблемы является "do_pings". Опять же, быстрый поиск в Google выявил быстрое решение для очистки do_pings
.
Очистка таблицы wp_options
Если вы часто видите то, о чем мы говорили выше, то, вероятно, пришло время очистить все данные автозагрузки в таблице wp_options
. Также рекомендуется постараться свести количество строк в таблице wp_options
к минимуму. Пожалуйста, всегда делайте резервные копии перед удалением данных в вашей базе данных. Если вам неудобно делать это самостоятельно, мы всегда рекомендуем нанять разработчика WordPress.
Как мы делали ранее, вам нужно войти в phpMyAdmin. Нажмите на свою базу данных с левой стороны, а затем на вкладку SQL. Затем введите следующую команду и нажмите Go:
SELECT * FROM `wp_options` WHERE `autoload` = 'yes'
Возможно, вам придется подкорректировать приведенный выше запрос, если ваш сайт WordPress использует другой префикс, отличный от wp_
. Это покажет вам все данные в таблице wp_options
, которые настроены на автозагрузку.
Прокручивая вниз строки, мы видим всевозможные плагины, которые больше не установлены или не используются сайтом. Это всего лишь пример, который мы будем использовать, но в данном случае мы заметили кучу строк Jetpack. Но Jetpack больше не использовался на данном сайте.
Всегда полезно проверить документацию разработчика плагина, поскольку иногда у них есть возможность очистить оставленные таблицы. В этом случае иногда безопаснее и проще просто установить плагин снова, проверить опцию автоматической очистки, а затем корректно удалить плагин. Однако мы покажем вам, как очистить таблицы вручную.
Итак, в данном случае мы выполним следующий запрос, чтобы найти автозагруженные данные в таблице wp_options
от плагина Jetpack. Чтобы изменить запрос на свой собственный, просто замените %jetpack%
.
SELECT *
FROM `wp_options`
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%jetpack%'
Затем вы можете выделить все строки и нажать Delete (Удалить).
Или вы можете выполнить следующую команду:
DELETE
FROM `wp_options`
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%jetpack%'
В итоге мы увидим следующую картину:
Затем вы можете повторить процедуру для дополнительных данных автозагрузки, оставленных плагинами и темами в таблице wp_options
.
Очистка Transients
Transients или временные данные - это способ кэширования данных на определенное время в WordPress. В отличие от хранения данных в кэше объектов, временные данные (или переходные) хранятся только временно, с расчетом на то, что они будут периодически обновляться. Переходные данные всегда создаются с заданным максимальным временем жизни, после чего оно истекают и данные удаляются.
Если вы не используете кэш объектов, WordPress хранит временные записи в таблице wp_options. Обычно они имеют срок действия и со временем должны исчезнуть. Однако это не всегда так. Мы видели некоторые базы данных, в которых были тысячи старых временных записей. Также важно отметить, что переходные записи по умолчанию не подлежат автозагрузке. Вы можете использовать запрос, подобный приведенному ниже, чтобы узнать, есть ли какие-либо переходные данные в автозагрузке.
SELECT *
FROM `wp_options`
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%transient%'
Однако лучшим и более безопасным вариантом будет использование бесплатного плагина Transient Cleaner, который может очистить только просроченные (expired) временные данные из таблицы wp_options
.