PHP Upgrade Check для WooCommerce — що зламається після переходу на PHP 8.3, 8.4 чи 8.5

PHP Upgrade Check для WooCommerce перевіряє плагіни й теми магазину перед переходом на новішу версію PHP і показує, що саме зламається: плагін, файл, рядок, сам код і як його виправити. Ви обираєте версію, на яку переходите, — 7.4, 8.0, 8.1, 8.2, 8.3, 8.4 чи 8.5, — а плагін звіряє код з усім, що PHP прибрав або змінив від 7.0 до 8.5. Перевірка працює на тому PHP, що стоїть зараз (від 7.2), тож результат видно до того, як хостинг щось перемкне.

Хостинги переводять сайти зі старих версій PHP: PHP 7.4 не отримує виправлень безпеки з листопада 2022 року, PHP 8.1 — з кінця 2025-го, а PHP 8.2 перестане їх отримувати 31 грудня 2026 року. Для магазину на WooCommerce питання завжди одне: чи працюватиме оформлення замовлення після перемикання. Достатньо одного старого плагіна з прибраною функцією — і замість сторінки покупець побачить фатальну помилку.

Як рахується вердикт. До вердикту йде лише те, що зміниться між версією PHP, на якій сайт працює сьогодні, і цільовою. Код, який падав би вже на поточному PHP, — наприклад, функції mysql_*, прибрані в PHP 7.0, на сервері з PHP 8.3, — або ніколи не виконується, або вже зламаний, і перехід на нову версію його не змінить. Такі знахідки видно у вкладці «Знахідки» з приміткою «у вердикті не враховується», але плагін через них не отримує «Зламається». Закодовані файли і заголовок Requires PHP, вищий за цільову версію, враховуються завжди.

Чого плагін не обіцяє. Перевірка читає код і не бачить того, що трапляється лише під час роботи: null, переданий у функцію PHP, властивість, створену на льоту, дані з бази. «Готово» означає, що для обраної версії PHP у коді нічого не знайдено, а не гарантію. Після перемикання перевірте магазин — передусім оформлення замовлення — і майте резервну копію, яку можна відновити.

Магазин на OpenCart? Для OpenCart 4, 3 і 2.3 є окремий модуль — PHP Upgrade Check для OpenCart.

Що побачить покупець

Нічого. Плагін працює лише в адмінці: сторінки магазину не змінює і на вітрині нічого не показує. Перевірка йде короткими кроками по кілька секунд у вкладці адміністратора, а сайт тим часом працює як завжди.

Журнал роботи в Pro збирає повідомлення PHP під час звичайних запитів сайту, але відвідувачам їх не показує і не змінює того, як PHP та інші плагіни (наприклад, Query Monitor) обробляють помилки: кожне повідомлення передається далі, як і без плагіна. За один запит записується не більше 50 різних повідомлень, у журналі — до 2 000 рядків за останні 60 днів.

Що отримує адмін

• Огляд сервера — версія PHP і до коли вона отримує виправлення безпеки (дані php.net), чи є новіший патч-реліз вашої гілки (з приміткою, що дистрибутиви Linux інколи переносять виправлення без зміни номера), чи підтримує ваша версія WordPress цільовий PHP, якого PHP потребує WooCommerce, чи стоїть ionCube Loader і які розширення PHP зникнуть у новій версії.
• Звіт для обраної версії PHP — лічильники «Зламається», «Закодовано — питайте розробника», «Працює інакше», «Попередження про застаріле», «Готово» і рядок на кожен плагін і тему, must-use плагіни та drop-in. Цільова версія перемикається без нової перевірки.
• Що робити — у рядку плагіна: «Спершу оновіть до 6.2.3, потім перевірте знову», якщо нова версія плагіна сама підтримує цільовий PHP; «Частина коду вже не працює на PHP 8.3 — цей код або ніколи не викликається, або вже зламаний»; позначки «розширення WooCommerce» і «Потрібен PHP 7.4» із заголовка плагіна.
• «Перевірити знову» для одного плагіна чи теми — після оновлення не треба перевіряти весь сайт.

• «Зламається» — код, який перестане працювати на цільовому PHP: файл не завантажиться через синтаксис, якого PHP більше не розуміє, або виклик закінчиться фатальною помилкою. Сюди ж — плагін, у заголовку якого Requires PHP вищий за цільову версію.
• «Працює інакше» — код виконається, але поведе себе не так, як раніше: наприклад, конструктор у стилі PHP 4, який з PHP 8.0 більше не викликається при створенні об’єкта.
• «Попередження про застаріле» — плагін працює, але PHP видає попередження: вони засмічують журнал помилок і в наступних версіях стануть помилками.

• Знахідки — для кожної: рівень і версія PHP, з якої це змінилось, що саме не так і як виправити, посилання на php.net, плагін, файл, рядок і сам код. Фільтр за плагіном і рівнем.
• Захищений код — рядки всередині перевірки версії PHP, function_exists(), extension_loaded() чи defined(), а також власні заміни прибраних функцій у тому ж плагіні позначаються «захищено» і у вердикт не йдуть. Їх видно, якщо обрати у фільтрі.
• CSV — усі знахідки одним файлом для розробника, підтримки хостингу чи автора плагіна: кома або крапка з комою, з BOM і захистом від формул, відкривається в Excel і Google Таблицях.
• WP-CLI: wp catcode-php-check scan, wp catcode-php-check report --target=8.4 --format=json, wp catcode-php-check export report.csv.

• «Здоров’я сайту» — тест, який каже, скільки активних плагінів і тем зламаються на цільовому PHP. Він критичний, коли поточний PHP уже не отримує виправлень безпеки, і рекомендаційний — коли ще отримує.

• Pro: журнал роботи — попередження про застаріле й фатальні помилки PHP під час роботи сайту, згруповані за плагіном і темою, з файлом, рядком, кількістю повторів, датою і версією PHP. Увімкніть його перед перемиканням PHP і перегляньте після: він ловить те, чого не видно в коді.
• Pro: перевірка після оновлень — плагін чи тему, які оновив WordPress, плагін перевіряє знову у фоні, і звіт показує їхній новий вердикт.
• Pro: щотижневий звіт — перевірка у фоні раз на тиждень і лист з результатом на вказану адресу або адміністраторові сайту.

Як це працює — крок за кроком

1. Інструменти → PHP Upgrade Check. Плагін одразу показує, на якому PHP працює сайт і до коли ця версія отримує виправлення безпеки.
2. У «Переходимо на PHP» лишаєте рекомендовану версію (для сайтів на PHP, старшому за 8.3, — 8.3, далі — наступна гілка) або обираєте свою і натискаєте «Запустити перевірку».
3. Плагін складає список коду: активні плагіни, тема (дочірня й батьківська), must-use плагіни, drop-in; за бажанням — неактивні. Теки tests пропускаються, бо на робочому сайті не виконуються.
4. Кожен PHP-файл читається токенайзером PHP і звіряється з правилами: прибрані функції, розширення й константи, синтаксис, який більше не завантажується, змінена поведінка, застаріле в PHP 8.0–8.5. Нічого не виконується. Перевірка йде кроками по кілька секунд; закрили вкладку — «Продовжити перевірку» дорахує з того самого місця.
5. Звіт: вердикт на кожен плагін і тему, «Деталі» — знахідки з виправленнями, CSV для розробника. Інша цільова версія — у тому самому звіті, без нової перевірки.
6. Далі — за підказкою на екрані плагіна: повна резервна копія, оновлення плагінів і перевірка знову, питання авторам того, що «Зламається» чи «Закодовано», пробне перемикання на копії сайту, потім — у панелі хостингу в спокійний час і одразу перевірка головної, товару, кошика й оформлення замовлення. Якщо щось зламалось, PHP повертається в панелі назад — файли й база лишаються як були.

Тестовий магазин з 76 плагінами (разом з неактивними), темами, must-use плагінами і drop-in — 40 731 файл — плагін перевірив за 53 секунди дванадцятьма кроками, пам’ять — до 94 МБ, жоден запит не впирався в max_execution_time 30 секунд. При жорсткому memory_limit 128M два файли по ~1 МБ, які не вмістились би в пам’ять, плагін пропустив і назвав у звіті. Файли понад 3 МБ теж пропускаються з позначкою.

Що під капотом

• Токенайзер PHP (token_get_all()) замість виконання коду: файли лише читаються, нічого не підключається, код не залишає сервер.
• Правила для змін PHP 7.0–8.5: синтаксис, що не завантажується (фігурні дужки для елемента рядка, вкладений тернарний оператор без дужок, (real) і (unset), =& new, класи з новими зарезервованими назвами), прибрані функції (each(), create_function(), get_magic_quotes_gpc(), money_format(), родина ereg та інші), прибрані розширення (mysql, mcrypt, xmlrpc, imap, pspell, oci8), виклики, що стали фатальними (implode() з масивом першим, parse_str() без результату, mktime() без аргументів), змінена поведінка (конструктори в стилі PHP 4, is_resource() на ресурсах, що стали об’єктами, assert() з кодом у рядку), застаріле до PHP 8.5 (неявно nullable параметри, типи повернення для 188 вбудованих класів та інтерфейсів, utf8_encode(), strftime(), FILTER_SANITIZE_STRING, E_STRICT, curl_close(), imagedestroy() та інше).
• Звірка з самим PHP: на 40 768 файлах 70 плагінів перевірка знайшла всі 557 попереджень про застаріле, які PHP 8.5 видає під час компіляції, а файли, що не компілюються на PHP 8.5, збіглися з файлами, де вона знайшла синтаксис, що не завантажується (10 з 10). Знахідки однакові, на якому б PHP — 7.4, 8.3 чи 8.5 — перевірка не працювала.
• Захищений код — перевірка версії PHP, function_exists(), extension_loaded() чи defined() навколо коду або перед &&, || і ?, а також власні заміни прибраних функцій у плагіні розпізнаються, щоб не лякати кодом, написаним під обидві версії.
• Кроки з блокуванням: перевірка йде кроками по одному — друга вкладка, WP-Cron і WP-CLI не читають ті самі файли одночасно; запобіжник пам’яті пропускає завеликі файли й називає їх у звіті; тека без прав читання не обриває перевірку — звіт каже, скільки файлів не вдалося прочитати.
• Дані php.net про гілки PHP кешуються на 12 годин; якщо запит вимкнено, плагін бере вбудований список. Таблиця сумісності WordPress і PHP вбудована в плагін.
• Свої таблиці для знахідок і журналу роботи; видалення плагіна прибирає таблиці, налаштування й завдання крону, на мультисайті — на всіх сайтах.

Як встановити

1. Плагіни → Додати новий → Завантажити плагін: оберіть catcode-php-upgrade-check-for-woocommerce-free-1.0.0.zip і активуйте.
2. Інструменти → PHP Upgrade Check → оберіть версію в «Переходимо на PHP» → «Запустити перевірку».
3. Перегляньте звіт, «Деталі» з виправленнями і, якщо треба, завантажте CSV для розробника.
4. Для Pro: завантажте Pro-збірку плагіна поверх безкоштовної (WordPress запропонує замінити встановлену версію) і вставте ліцензійний ключ з листа на вкладці «Налаштування» — або натисніть там «Спробувати Pro 7 днів».