Исправление ошибок на сайте

Клиент: Владелец небольшого интернет-магазина на WordPress.
Проблема: После того как хостинг-провайдер автоматически обновил версию PHP с 7.4 на 8.1, весь сайт перестал открываться. Вместо главной страницы — пустой белый экран (ошибка 500). В логах ошибок — общая фраза «PHP Fatal error».
Что сделано:

1. Диагностика: Включил режим отладки WordPress (WP_DEBUG) и проанализировал логи. Оказалось, что ошибку вызывает устаревший плагин кэширования, который использовал функции, удалённые в PHP 8.1 (create_function()).
2. Исправление: Временно отключил плагин через FTP (переименовал папку плагина), чтобы вернуть сайт к жизни. После этого нашёл более современный аналог плагина, совместимый с PHP 8.1, установил и настроил его.
3. Результат: Сайт снова работает на новой версии PHP, причём скорость загрузки страниц выросла на 20% благодаря оптимизациям в PHP 8.1. Клиент получил рекомендации по мониторингу совместимости плагинов перед будущими обновлениями.

Клиент: Строительная компания, сайт на 1С-Битрикс.
Проблема: Форма обратной связи на сайте перестала отправлять сообщения. Клиент мог потерять несколько заказов, прежде чем заметил проблему. Визуально всё работало, но письма не приходили.
Что сделано:

1. Диагностика: Проверил настройки почты в административной панели Битрикс — всё верно. Тогда протестировал отправку через встроенный почтовый сервис самого хостинга — письма уходили. Значит, проблема в скрипте отправки на сайте.
2. Исправление: Включил логирование ошибок PHP. Обнаружил, что в файле компонента формы используется устаревший метод отправки почты (mail()), который блокировался настройками сервера из-за отсутствия заголовков. Переписал скрипт отправки на использование SMTP-сервера с авторизацией.
3. Результат: Форма снова работает. Прописал в коде обработку ошибок отправки, теперь при сбое пользователь видит понятное сообщение, а не просто «сообщение отправлено».

Клиент: Мебельная фабрика, переходила с устаревшей самописной CMS на Django.
Проблема: После запуска нового сайта структура URL-адресов полностью изменилась. Все старые ссылки, которые были заиндексированы в Яндексе и Google, вели на страницы с ошибкой 404. Посещаемость упала в 3 раза.
Что сделано:

1. Диагностика: Собрал полный список старых URL из логов сервера и данных Яндекс.Вебмастера. Сопоставил их с новыми адресами страниц (категории, карточки товаров, статьи).
2. Исправление: Прописал на сервере правильные 301-редиректы для каждой группы старых страниц. Например, old-site.ru/catalog/divany/ → newsite.ru/category/sofas/. Настроил редиректы для всех изображений, чтобы не терять трафик из картинок.
3. Результат: Поисковые системы начали склеивать старые и новые страницы, позиции и трафик восстановились в течение 1-2 месяцев. Клиент не потерял накопленный ссылочный вес.

Клиент: небольшой интернет-магазин парфюмерии на 1С-Битрикс.
Проблема: При сохранении раздела каталога продукции стала выходить ошибка:

[ErrorException] E_ERROR Maximum execution time of 30 seconds exceeded (0) /var/www/*****/bitrix/modules/search/tools/stemming.php:115

Что сделано:

1. Диагностика: Проверил проблемный раздел каталога. При сохранении раздела инфоблока система запускает процесс индексации этого раздела для поиска. Модуль поиска (search) выполняет морфологический анализ (стемминг) текстовых полей раздела – названия, описания и других символьных полей. Этот анализ реализован в файле stemming.php.
2. Исправление: Увеличил лимит времени выполнения PHP (до 120 секунд) через настройки хостинга - не помогло. Можно было бы отключить стемминг полностью, если морфологический поиск не обязателен (но это снизит качество поиска). Поэтому было принято решение отключить индексацию разделов, т.к. поиск по разделам не используется, клиент подтвердил, что поиск по разделам действительно не нужен.
3. Результат: Сохранение разделов снова работает быстро.