WordPress обычно живёт на прямых SQL-запросах и массиве костылей вокруг `$wpdb`. Но если в ядро аккуратно втащ

WordPress обычно живёт на прямых SQL-запросах и массиве костылей вокруг `$wpdb`. Но если в ядро аккуратно втащить Doctrine ORM, можно собрать более предсказуемый слой работы с данными без заметной просадки по скорости.

Что тут важно:
- ORM не обязан быть «тормозом» сам по себе. Оверхэд появляется там, где не настроены сущности, lazy loading, кэш и границы запросов.
- Внедрение без переписывания всего ядра возможно, если не ломать текущий data flow и оставить критичные места на нативном SQL.
- Для больших проектов это даёт не красоту ради красоты, а управляемость: модели, связи, миграции, тестируемость, меньше ручной возни с запросами.

Практический вывод: если WordPress превращается из блога в сложную систему с большим количеством сущностей, Doctrine может быть не лишним слоем, а нормальной структурой поверх хаотичного legacy. Главное — не тащить ORM туда, где хватает одного `SELECT` ⚙️