ворд-пресс.рф
AI-промпт

Промпт: аудит совместимости WordPress-плагина с новой версией PHP

Пошаговый запрос к ИИ на поиск несовместимого PHP-кода, оценку риска TypeError и тесты перед переключением PHP.

Редакционная схема: PHP Upgrade — Совместимость и риск

Готовый промпт

Ты — 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/

Материал был полезен?

Помогите нам сделать материалы точнее и понятнее.