Архитектура WordPress без мифов.
WordPress сам по себе не делает сайт быстрым или медленным. Результат определяют тема, плагины, модель данных, запросы к БД, сервер и процесс обновлений. Большой проект лучше воспринимать не как набор страниц, а как приложение с сущностями и связями.
До начала работ
В WordPress важно отделить симптом от источника: тема, плагин, запрос к БД, cron, интеграция или сервер могут выглядеть одинаково — «сайт глючит».
- Разделить шаблоны и бизнес-логику.
- Проверить версии PHP, WordPress и критических плагинов на совместимость.
- Нормализовать API-интеграции и обработку ошибок.
- Проверить тему, child theme и точки кастомизации до обновления.
Как я бы прошёл эту задачу
- Проверить тему и плагины на дублирование функций.
- Составить карту сущностей и связей.
- Нормализовать API-интеграции и обработку ошибок.
- Разделить шаблоны и бизнес-логику.
- Измерить SQL, autoload и cron.
- Выбрать подходящее хранилище для каждого типа данных.
Точки риска по дороге
Хорошая архитектура означает, что контент можно менять без программиста, повторяемые сущности не копируются вручную, интеграции журналируют ошибки, а новая функция не требует переписывать половину темы.
- править ядро или файлы плагинов напрямую
- ставить несколько плагинов с одной функцией
- отправлять данные в CRM без логов
Самый дорогой путь — лечить архитектурную проблему ещё одним плагином, не понимая, что уже происходит в теме и базе.
Проверка на реальном сценарии
Перед публикацией я бы повторил не только изменённый шаг, но и соседние сценарии: мобильную версию, формы, аналитику, интеграции и страницы того же шаблона.
- число SQL-запросов
- autoload size
- ошибки интеграций
- время PHP-ответа
Когда работу можно считать законченной
После работы должны остаться понятные доступы, зафиксированные изменения и способ повторно проверить результат.
Если эту задачу нужно внедрить, а не только разобрать
Можно собрать план внедрения, проверить зависимости и довести изменение до работающего production-сценария.