Содержание
Разработчики ненавидят WordPress не столько саму CMS, сколько экосистему вокруг неё: легаси-код, уходящий корнями в 2005 год, архитектуру, где ядро пронизано глобальными функциями и процедурным стилем (в противовес ООП), а также низкое качество тысяч бесплатных плагинов и тем. Главные причины: постоянные уязвимости из-за плохих плагинов (где любой новичок может написать дыру), медленная производительность, устаревшая система хранения данных (wp_postmeta), а также «культ пользователя», когда разработчику приходится подстраиваться под редактора Gutenberg, а не писать чистый код. Многие также ненавидят необходимость поддерживать совместимость со старыми версиями PHP и браузерами, что тормозит внедрение современных стандартов.
Архитектурный хаос: почему WordPress — это «каша» для программиста
В отличие от современных фреймворков (Laravel, Symfony, Django), WordPress не следует принципам ООП (объектно-ориентированного программирования) в ядре. Вместо классов и инъекции зависимостей — глобальные функции, которые переопределяются через хуки (add_filter, add_action).
- Глобальное пространство имён: Функции
wp_head(),the_content(),get_option()живут в глобальном пространстве, что приводит к конфликтам с плагинами. Невозможно создать изолированный модуль — всё влияет на всё. - Смешение логики и представления: Шаблоны тем (например,
header.php) содержат PHP-код, который лезет в базу данных и бизнес-логику, а не только в HTML. Это порождает спагетти-код. - Нет современного роутинга: WordPress использует правила перезаписи (mod_rewrite) и собственную систему "query_vars", которая далека от удобства фреймворков (где вы пишете
Route::get('/user/{id}')).
Попытка написать на WordPress сложный кастомный проект (например, CRM с тысячами типов записей) превращается в борьбу с архитектурой, а не в продуктивную работу.
Плагины — главная головная боль (ад для сопровождения)
Когда разработчик говорит «ненавижу WordPress», он чаще имеет в виду «ненавижу экосистему сторонних плагинов». На маркетплейсах тысячи плагинов, написанных людьми разной квалификации.
- Безопасность: По статистике, 90% взломов WordPress происходят через уязвимые плагины и темы, а не через ядро. Поддерживать 30-40 плагинов на одном сайте — это риск получить дыру каждую неделю.
- Совместимость: Два плагина могут конфликтовать из-за одной глобальной переменной или хука. Выключишь один — сломается другой.
- Производительность: Каждый плагин загружает свои CSS/JS, делает лишние SQL-запросы. Сайт на 10 «нужных» плагинах тормозит как черепаха.
- Обновления: После обновления ядра или плагина сайт может полностью лечь. Разработчикам приходится перед каждым обновлением делать бэкап и тестировать в стенде, что отнимает часы.
Ситуация сравнима с Joomla, где расширений меньше, но они в среднем качественнее (проходят проверку сообществом). В WordPress же любой желающий может залить плагин в репозиторий.
| Проблема | WordPress | Фреймворк (Laravel/Symfony) |
|---|---|---|
| Безопасность (ядро) | Высокая (ядро хорошее) | Высокая (зависит от кода) |
| Безопасность (экосистема) | Низкая (из-за плохих плагинов) | Высокая (вы сами пишете весь код) |
| Сложность кастомизации | Средняя (приходится обходить ограничения) | Низкая (пишете как хотите) |
Производительность и проблема «умных» запросов
Разработчики ненавидят WordPress за его непредсказуемую скорость на больших данных. База данных WordPress (особенно таблицы wp_posts и wp_postmeta) не оптимизирована под миллионы записей.
- Мета-поля (postmeta): Хранение дополнительных полей в таблице
key-valueприводит к огромному количеству JOIN-запросов. Чтобы получить 20 полей для 1000 товаров, WordPress может сделать 20 * 1000 = 20 000 запросов (если не использовать кэш). - Процедурный подход: Многие плагины вызывают
WP_Queryнапрямую в шаблонах, создавая дополнительные запросы к БД на каждой странице. - Отсутствие встроенного кэша объектов: Требуется установка Redis или Memcached через плагины, а это дополнительная сложность.
Разработчик, привыкший к Eloquent ORM в Laravel или к Doctrine в Symfony, испытывает боль от необходимости писать raw SQL или возиться с pre_get_posts.
«Магия» вместо предсказуемости (хуки, шорткоды)
Система хуков (actions/filters) в WordPress — это мощно, но это же и проклятие.
- Невозможно просто взять и понять, где именно выполняется код. Один хук может быть вызван из ядра, из плагина, из темы. Проследить поток выполнения без IDE и плагина Debug Bar — задача для детектива.
- Шорткоды (
[gallery]) позволяют вставлять динамические элементы в текст. Но шорткод может выполнять любой PHP-код, что создаёт риски и замедление.
В сравнении: в Joomla события (плагины) более структурированы, а в Laravel — сервис-провайдеры и инъекция зависимостей. WordPress же застрял в 2005 году, когда «магия» считалась удобной.
Редактор Gutenberg (блоковый редактор) — боль для разработчика
Хотя Gutenberg хорош для конечных пользователей, разработчики его ненавидят.
- Создание кастомного блока требует знания React, JSX, Webpack и современных фронтенд-инструментов, что для PHP-разработчика может быть сложно.
- Блоки хранятся в базе как HTML-комментарии, что затрудняет миграцию и парсинг.
- Рендеринг блоков на сервере (через
render_callback) медленный.
Разработчикам, привыкшим к классическим мета-боксам (ACF), приходится переучиваться на блоки, а legacy-проекты на ACF будет очень трудно мигрировать.
WordPress vs Joomla: что хуже для разработчика
Сравнивая с Joomla, можно сказать, что Joomla архитектурно строже (MVC, более чёткое разделение логики, компоненты, модули, плагины), но её тоже часто критикуют за устаревший код. Однако Joomla менее популярна, поэтому разработчики вынуждены работать с WordPress из-за спроса, что вызывает дополнительную фрустрацию. Многие разработчики на Joomla избегают WordPress, потому что там «всё смешано в кучу».
Конструкторы (SitePro.by, Tilda) не сравниваются — это вообще другой уровень абстракции, где нет программирования. А вот разработчики на фреймворках (Laravel) смотрят на WordPress свысока.
Резюме от эксперта
Ненависть к WordPress у разработчиков — это, по сути, профессиональная инверсия. WordPress сделал сайты доступными миллионам, но для программиста, который привык к чистой архитектуре, тестируемости и современным практикам, WordPress — это возвращение в прошлое. Однако, как говорится, «WordPress плох, но всё остальное ещё хуже» (имеется в виду время на разработку). Многие ненавидят WordPress, но продолжают на нём зарабатывать, потому что 43% сайтов в мире — это WordPress. Если вы разработчик, знайте: WordPress — это работа, но не искусство. Если вы любите чистый код и ООП — идите в Laravel или Symfony. Если вы хотите много заказов (и не боитесь хакерских атак и легаси) — оставайтесь в WordPress.
