
Готовый промпт
Ты — PHP/WordPress-разработчик и code reviewer. Проведи аудит совместимости существующего WordPress-плагина при переходе на новую PHP-версию.
ВХОД: исходный ZIP/репозиторий [путь], текущая и целевая версии PHP [указать], WordPress [версия], composer.json и используемые зависимости [приложить], логи ошибок [если есть].
1. Сначала проанализируй все PHP-файлы и зависимости, не изменяя production. Найди потенциальные TypeError, несоответствия типов возврата, deprecated/removed API, динамические свойства, некорректные nullable-параметры и иные несовместимости, актуальные для указанного перехода.
2. Укажи для каждого риска: путь:строка, фрагмент кода, доказательство, что проблема применима к целевой PHP, влияние, безопасное исправление. Без контекста не объявляй подозрение дефектом.
3. Предложи минимальный diff и обратимую стратегию миграции. Не скрывай ошибки отключением error_reporting; не исправляй код ядра WordPress или сторонних плагинов.
4. Запусти php -l для доступных файлов; проверь фактическую версию PHP в окружении. Если целевой PHP недоступен, явно отметь, что совместимость с ним не проверена.
5. При доступных тестах проведи PHPUnit/интеграционные проверки; ручные проверки запиши отдельно, не выдумывай PASS.
6. Выдай матрицу: проблема → доказательство → исправление → результат теста → остаточный риск.
7. Подготовь инструкцию staging-проверки и отката версии PHP/плагина.
РЕЗУЛЬТАТ: отчёт, минимальные исправления, список реально выполненных тестов и запрет публикации до ручной приёмки.
При смене PHP WordPress-плагин может перестать работать из-за несовместимых типов, устаревших функций или сторонних зависимостей. Этот промпт заставляет агента проверять конкретную версию PHP и конкретный исходный код, а не говорить «совместим» по одному успешному lint.
Когда использовать
Перед повышением PHP на хостинге, переносом WordPress между серверами, обновлением старого плагина или устранением фатальной ошибки TypeError.
Подготовьте данные
- Исходники плагина и точные версии WordPress, PHP, зависимостей.
- Результаты
php -v,php -mи доступные логи, очищенные от персональных данных и секретов. - Информацию о базе, WP-CLI, мультисайте и критичных функциях.
- Политики деплоя и отката.
Проверка результата
У агента должен получиться список нарушений с файлами и строками, а не общие рекомендации. Простая синтаксическая проверка PHP не доказывает совместимость поведения с целевым рантаймом. На staging отдельно проверьте активацию, HTTP/AJAX, сохранение настроек, cron, загрузку файлов, авторизацию и ZIP-импорт (если он есть).
Для редакции
Не включайте в статью утверждения, что конкретный релиз WordPress или библиотека протестированы, если таких тестов не было. Для построения тестов пригодится практика PHPUnit.
Источник: https://make.wordpress.org/core/handbook/testing/automated-testing/phpunit/
Материал был полезен?
Помогите нам сделать материалы точнее и понятнее.