Изменение версии php на сервере сайта

Клиент: Корпоративный сайт строительной компании на 1С-Битрикс.
Проблема: Хостинг-провайдер в рамках плановых работ повысил версию PHP на сервере с 7.4 до 8.1. Сайт перестал открываться — вместо него белый экран и ошибка 500. Все внутренние сервисы (интранет, заявки) парализованы.
Что сделано:

1. Экстренная диагностика: Быстро получил доступ к файлам и логам ошибок. В логах увидел множество записей о фатальных ошибках, связанных с устаревшими функциями работы с массивами в кастомном компоненте, написанном специально для этого сайта 5 лет назад.
2. Поиск и исправление ошибок: На тестовой копии (созданной из бэкапа) проанализировал код проблемного компонента. Нашёл участки, использующие функцию each(), удалённую в PHP 7.2+, и неправильную обработку строк. Переписал эти участки на современный, совместимый с PHP 8 код.
3. Адаптация под строгую типизацию: Также обнаружил предупреждения о передаче аргументов неверного типа в несколько методов. Привёл типы в соответствие с требованиями.
4. Тестирование: После исправления на тестовой копии тщательно проверил работу всех форм, каталога и личного кабинета.
5. Применение на боевом сайте: Внёс исправления на боевой сайт. Сайт заработал на PHP 8.1.
6. Результат: Сайт восстановлен за 3 часа. Клиент не только избежал длительного простоя, но и получил заметный прирост скорости работы (PHP 8 быстрее). Я составил отчёт о проделанных изменениях и рекомендации для будущих обновлений.

Клиент: Интернет-магазин подарков на WordPress (существовал 7 лет).
Проблема: Хостинг уведомил, что через месяц поддержка PHP 7.4 прекращается, и сервер будет принудительно переведён на PHP 8.1. Владелец понимал, что сайт может «посыпаться», но не знал, с чего начать.
Что сделано:

1. Анализ текущей версии и кода: Создал полную копию сайта на тестовом поддомене. Включил режим отладки WordPress. Прогнал сайт через плагин совместимости PHP, который выявил множество потенциальных проблем в устаревших плагинах и в теме.
2. Проверка совместимости: Оказалось, что 3 плагина из 15 и сама тема используют устаревшие функции и конструкции. Два плагина уже не обновлялись годами.
3. Поиск и исправление / замена:

• Для двух неподдерживаемых плагинов нашёл современные аналоги с похожим функционалом, установил и настроил их.
• Для темы вручную исправил около 20 участков кода (заменил устаревшие функции mysql_* на mysqli_* и WP_Query, поправил вызовы конструкторов).
• Один плагин удалось обновить до последней версии, где проблемы уже были исправлены разработчиком.

1. Тестирование и откат: После всех исправлений протестировал все ключевые сценарии (оформление заказа, личный кабинет, поиск). В одном месте нашёл ошибку, быстро исправил.
2. Результат: К моменту принудительного переключения хостингом сайт был полностью готов и работал стабильно на PHP 8.1. Клиент не заметил никаких проблем, а скорость загрузки выросла на 25%.

Клиент: Компания с самописной CRM-системой для управления клиентами на PHP 5.6.
Проблема: Система работала на древней версии PHP, которая больше не получала обновлений безопасности. Хостинг требовал срочного перехода на PHP 7.4 или выше, иначе аккаунт мог быть заблокирован из-за уязвимостей. Прямой переход с 5.6 на 7.4 был невозможен — код буквально разваливался.
Что сделано:

1. Анализ кода: Провёл полный аудит кода CRM (более 50 000 строк). Выявил использование устаревших функций: mysql_* (заменять на mysqli или PDO), ereg (заменять на preg_match), конструкторы с именем класса, и множество других несовместимостей.
2. Поэтапная адаптация: Разбил работу на этапы: сначала переход на PHP 7.0 (исправление самых критичных ошибок), затем на 7.2, затем на 7.4. После каждого этапа тщательно тестировал все функции CRM.
3. Исправление предупреждений: В процессе также исправил множество предупреждений (warnings), которые не ломали систему, но засоряли логи и могли привести к проблемам в будущем.
4. Документирование: Составил подробный отчёт обо всех изменениях и рекомендации для дальнейшей поддержки.
5. Результат: CRM успешно перенесена на PHP 7.4. Система работает быстрее и стабильнее, критические уязвимости закрыты. Клиент избежал блокировки хостинга и потенциальной потери данных.