Как выбирать плагины и темы WordPress без лишнего риска

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

Цель проверки не в том, чтобы найти плагин без единой уязвимости. Нужно понять, кто его обновляет, какую часть сайта он меняет, как обнаружить проблему и как вернуться назад.

Сначала сформулируйте одну задачу

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

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

Проверяйте источник, а не название архива

Начинайте с официального каталога WordPress.org или сайта известного разработчика. Не устанавливайте «premium»-архивы из файлообменника: экономия лицензии не позволяет установить происхождение кода и канал обновлений.

В каталоге смотрите не только рейтинг. Важнее свежая история изменений, ответы поддержки, совместимость с вашим WordPress и PHP, понятное описание внешних запросов и отсутствие необъяснимого перерыва в сопровождении. Большое число установок не заменяет анализ нужной вам версии.

Определите, какие права и данные получает расширение

Плагин может создавать таблицы, регистрировать cron-события, добавлять роли, принимать загрузки и отправлять данные наружу. До установки ответьте:

• какие персональные и технические данные он читает;
• передаёт ли их третьей стороне;
• где хранит токены;
• какие URL и REST endpoints добавляет;
• что останется после деактивации и удаления.

Если ответы невозможно найти в документации, это эксплуатационный риск, даже когда функция работает.

Снимите исходное состояние

WP-CLI позволяет сохранить список компонентов до изменения. Команды ниже ничего не обновляют и показывают имя, состояние, версию и доступность новой версии:

wp plugin list --fields=name,status,version,update --format=table
wp theme list --fields=name,status,version,update --format=table
wp cron event list --fields=hook,next_run_relative,recurrence --format=table

Запускайте WP-CLI от пользователя публикации и с явным --path, если текущий каталог не является корнем WordPress. Сохраните вывод вместе с dump базы и копией wp-content; это база для сравнения, а не замена полноценного восстановления.

Испытывайте изменение на staging

Staging — закрытая копия сайта с похожими версиями PHP, базы и Nginx. Она не должна отправлять настоящие письма, принимать поисковых роботов или выполнять платежи. Персональные данные лучше обезличить.

После установки активируйте только один кандидат и проверьте:

• главную, запись, поиск и 404;
• вход, редактирование и загрузку файла;
• размер HTML и число внешних запросов;
• PHP-журнал и время ответа;
• новые таблицы, задания cron и роли.

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

Проверяйте целостность там, где есть эталон

Для расширений из WordPress.org WP-CLI может сравнить файлы с контрольными суммами каталога:

wp plugin verify-checksums --all --strict
wp core verify-checksums

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

Совпадение checksum подтверждает файлы известной версии, но не доказывает, что логика плагина подходит вашему сайту.

Обновляйте с наблюдаемым результатом

Перед production-обновлением сделайте согласованную копию базы и изменяемых файлов. Обновляйте один компонент или небольшую связанную группу, затем проходите заранее записанный smoke-набор. Сравнивайте журналы и cron, а не только внешний вид главной.

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

Удаляйте ненужное полностью и проверяемо

Сначала выясните, нужен ли встроенный uninstall для удаления таблиц и настроек. Затем деактивируйте компонент и убедитесь, что сайт продолжает выполнять его бывшую функцию или больше в ней не нуждается:

wp plugin deactivate plugin-slug
wp plugin delete plugin-slug
wp cron event list --format=table

plugin-slug замените точным именем из wp plugin list. После удаления проверьте задания cron, пользовательские роли, таблицы и каталог uploads. Не удаляйте неизвестные таблицы только по похожему префиксу: сначала свяжите их с документацией расширения и резервной копией.

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

Дальше настройте предсказуемый запуск WordPress cron и учтите внешние зависимости при настройке служебной почты.

Источники

• WordPress: plugin directory guidelines
• WordPress: plugin privacy guidance
• WordPress: hardening and plugins
• WP-CLI: verify plugin checksums