WordPress REST API и интеграции: когда сайт должен разговаривать с CRM

API, webhooks, очереди и обработка ошибок.

WordPress сам по себе не делает сайт быстрым или медленным. Результат определяют тема, плагины, модель данных, запросы к БД, сервер и процесс обновлений. Большой проект лучше воспринимать не как набор страниц, а как приложение с сущностями и связями.

Не чинить то, что ещё не диагностировано

Один и тот же внешний симптом может появляться по разным причинам. Сначала стоит записать конкретный сценарий: URL, устройство, шаг, момент появления и последние изменения.

Первые проверки без переделки сайта

• Разделить шаблоны и бизнес-логику.
• Предусмотреть retry для временных 429/5xx и безопасную идемпотентность.
• Проверить тему и плагины на дублирование функций.
• Проверить тему, child theme и точки кастомизации до обновления.
• Проверить версии PHP, WordPress и критических плагинов на совместимость.

Что чаще оказывается источником

В WordPress важно отделить симптом от источника: тема, плагин, запрос к БД, cron, интеграция или сервер могут выглядеть одинаково — «сайт глючит».

CPT, таксономии, ACF, REST API и собственные модули позволяют построить управляемую систему. Но каждый новый плагин или meta-слой имеет стоимость: обновления, совместимость, безопасность и дополнительные запросы.

Популярные ложные решения

• хранить всё в случайных postmeta
• делать тяжёлые WP_Query внутри циклов
• править ядро или файлы плагинов напрямую
• ставить несколько плагинов с одной функцией

Самый дорогой путь — лечить архитектурную проблему ещё одним плагином, не понимая, что уже происходит в теме и базе.

Проверка после исправления

• ошибки интеграций
• число SQL-запросов
• autoload size
• время PHP-ответа

Я бы фиксировал изменения через staging, логи и измерения до/после. Иначе легко удалить полезную функцию и оставить настоящую причину.