Как тестировать совместимость WordPress с PHP на разных версиях плагинов

Тестирование совместимости WordPress с PHP означает проверку того, корректно ли ведёт себя ваш плагин на каждой комбинации версий PHP и WordPress, которую вы поддерживаете. С помощью песочницы WordPress на wp.run вы можете запускать чистые тестовые установки, например PHP 8.4 с WordPress 6.9, и повторять один и тот же дымовой тест без локальных серверов и риска для продакшна.

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

Почему совместимость WordPress с PHP требует матрицы

Плагин может пройти на одном стеке и упасть на другом. Изменения PHP могут обнажить устаревший синтаксис, более строгое поведение типизации, удалённые функции или предупреждения, которые не проявлялись на более старой среде выполнения. Изменения WordPress могут затронуть поведение редактора, хуки, REST-эндпоинты, экраны администратора и встроенный JavaScript.

Вот почему одной проверки «работает на моей машине» недостаточно. Тестирование совместимости плагина должно охватывать комбинации, которые реально используют ваши пользователи:

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

Составьте небольшую матрицу версий PHP x WordPress

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

1. Старейший поддерживаемый стек. Это выявляет синтаксические ошибки или использование API, ломающее пользователей, которые ещё не обновились.
2. Рекомендуемый текущий стек. Это стек, который вы ожидаете использовать для большинства новых тестов и демо.
3. Новейший стек. Это выявляет будущие изменения PHP и WordPress до того, как пользователи сообщат о них.

На wp.run модальное окно запуска поддерживает явный выбор версий WordPress и PHP. Вы также можете использовать URL запуска, когда хотите запустить песочницу WordPress по воспроизводимой тестовой ссылке, например:

https://wp.run/new?php=8.4&wp=6.9

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

https://wp.run/new?plugin=woocommerce&php=8.4&wp=6.9

Для собственных сборок плагинов загрузите ZIP в wp-admin и запишите точную сборку в своих заметках. Каждая строка матрицы должна иметь стек, версию плагина, выполненные проверки и результат.

Как тестировать совместимость плагина с PHP 8.4 на wp.run

Используйте этот рабочий процесс, когда вам нужно протестировать поведение плагина на PHP 8.4 без перестройки локальной среды.

1. Запустите целевой стек. Нажмите Запустить WordPress, выберите PHP 8.4 и версию WordPress, которую хотите проверить, затем создайте песочницу. wp.run создаёт временную установку WordPress с учётными данными администратора и URL *.wprun.site.
2. Подтвердите среду. Откройте wp-admin, затем проверьте Инструменты -> Состояние сайта -> Информация, чтобы подтвердить версии PHP и WordPress перед началом тестирования.
3. Установите или активируйте плагин. Загрузите поддерживаемый пресет через параметр URL запуска или загрузите ZIP вашего плагина в wp-admin. Сохраните точную сборку плагина в своей тестовой записи.
4. Выполните проверку активации. Активируйте плагин и следите за фатальными ошибками, уведомлениями администратора, отсутствующими зависимостями, петлями перенаправления и сбоями мастера установки.
5. Запустите основную функцию. Выполните наименьший реальный рабочий процесс, для которого существует плагин: создайте форму, завершите оформление заказа, добавьте блок, создайте карту сайта, импортируйте контент или запустите запланированную задачу.
6. Проверьте поверхности администратора и фронтенда. Откройте редактор блоков, настройки плагина, вывод публичной страницы, REST-эндпоинты при необходимости и консоль браузера.
7. Повторите на следующем стеке. Запустите следующую версию PHP или WordPress и выполните тот же чеклист. Меняйте одно измерение за раз при изоляции ошибок.

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

Добавьте статическое сканирование, но не останавливайтесь на нём

Статические сканеры совместимости полезны, потому что они выявляют паттерны кода до выполнения. Урок Learn WordPress по тестированию продуктов на совместимость с версиями PHP охватывает два распространённых подхода: ручное тестирование в целевой PHP-среде и сканирование с правилами PHPCompatibility через PHP_CodeSniffer.

Используйте оба сигнала вместе:

• Сначала статическое сканирование. Найдите очевидное использование удалённых функций, устаревших сигнатур и версионно-специфического PHP-синтаксиса.
• Затем тест в песочнице. Убедитесь, что плагин запускается, отображает пользовательский интерфейс, записывает ожидаемые опции и выполняет свой реальный рабочий процесс на целевом стеке.
• Наконец, запись о регрессии. Запишите, что не прошло, точные версии PHP/WP/плагина и является ли проблема предупреждением, фатальной ошибкой, сломанным интерфейсом или проблемой с данными.

Статические инструменты могут показать, что строка кода потенциально несовместима. Песочница показывает, работает ли плагин по-прежнему как полноценный продукт WordPress.

Что проверять при тестировании версий WP

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

Проверяйте эти области в каждой строке матрицы:

• Активация и деактивация. Плагин должен активироваться чисто, деактивироваться чисто и не оставлять сайт в сломанном состоянии.
• Путь обновления. Сначала установите предыдущую версию плагина, создайте тестовые данные, затем обновитесь до новой версии плагина и убедитесь, что миграции выполняются.
• Экраны администратора и редактора. Откройте каждое меню, добавленное плагином. Если он затрагивает блоки, шорткоды, встраивания, пользовательские типы записей или мета-боксы, тестируйте редактор на каждой версии WordPress.
• Вывод фронтенда. Убедитесь, что шаблоны, шорткоды, ресурсы, перенаправления, потоки оформления заказа, формы или виджеты отображаются как ожидается.
• REST, AJAX и запланированные задачи. Отправьте соответствующие запросы к эндпоинтам и проверьте зависящее от cron поведение, где плагин полагается на фоновую работу.
• Чистота удаления. Деактивируйте и удалите плагин в одноразовой песочнице, чтобы проверить, приемлемо ли его поведение при очистке.

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

Практическая матрица для релиза плагина

Вот компактная матрица для команды разработчиков плагина, готовящей релиз:

Используйте матрицу как критерий выпуска, а не запоздалую документацию. Если строка не проходит, скопируйте точные шаги, включите вывод отладки или скриншоты и прикрепите временный URL песочницы, пока он ещё доступен.

Распространённые ошибки совместимости, на которые следует обратить внимание

Большинство ошибок совместимости укладываются в несколько паттернов:

• Фатальная ошибка при активации. Обычно вызвана удалёнными PHP-функциями, отсутствующими классами, проблемами автозагрузки зависимостей или кодом, выполняющимся слишком рано.
• Предупреждения, которые становятся шумными в новых версиях PHP. Динамические свойства, nullable-аргументы, предположения о строгой типизации и устаревшие сигнатуры могут заполнять логи, даже когда страница, кажется, работает.
• Поломка редактора. Плагин может нормально работать на фронтенде, при этом его интеграция с редактором блоков ломается на новой версии WordPress.
• Сбои AJAX, REST или обновления. Обработка nonce, регистрация маршрутов, сохранённые опции или пользовательские таблицы могут обнажать слабые предположения.
• Конфликты зависимостей. Два плагина могут поставлять несовместимые версии общей PHP-библиотеки или JavaScript-пакета.

Когда строка не проходит, не переходите сразу к «PHP несовместим». Перезапустите тот же плагин на той же версии WordPress с предыдущей версией PHP, затем измените WordPress, сохранив PHP постоянным. Изоляция одного измерения — это то, как вы находите реальную линию разлома.

Где вписывается песочница

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

Практический рабочий процесс многоуровневый: сканируйте код, запускайте автоматизированные тесты, используйте песочницы wp.run для проверок продукта на уровне версий PHP и WordPress, затем переходите к промежуточному серверу только тогда, когда вам нужно проверить конкретный сайт.

Часто задаваемые вопросы

Что такое совместимость WordPress с PHP?

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

Как протестировать плагин на PHP 8.4?

Запустите песочницу wp.run с PHP 8.4, подтвердите версию PHP в состоянии сайта, установите плагин, затем выполните проверки активации, администратора, редактора, фронтенда, REST/AJAX и удаления. Повторите тот же чеклист на предыдущей версии PHP, если нужно изолировать ошибку, специфичную для PHP.

Означает ли совместимость ядра WordPress, что мой плагин тоже совместим?

Нет. Ядро WordPress может быть совместимо с версией PHP, пока плагин всё ещё не работает из-за собственного кода, зависимостей, пользовательского интерфейса администратора или логики обновления. Используйте диаграмму совместимости ядра WordPress как базовый уровень, затем тестируйте плагин отдельно.

Сколько комбинаций PHP и WordPress нужно тестировать?

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

Сделайте тестирование совместимости повторяемым

Лучший процесс совместимости скучен: одна матрица, один чеклист, один журнал результатов, повторяемый для каждого release candidate. wp.run предоставляет быстрый слой среды для этого процесса: чистый WordPress, выбираемые версии PHP и WordPress, сгенерированный доступ администратора и временные песочницы, которые можно выбросить по завершении каждой строки.