CMS и e-commerce-платформы — это не просто «ещё один фреймворк». В Laravel, Symfony, Yii или Slim и Mezzio вы строите приложение вокруг выбранной архитектуры. В WordPress, Drupal, TYPO3, Magento, OpenMage или WooCommerce вы входите в уже готовую предметную систему: страницы, пользователи, роли, темы, плагины, меню, медиа, каталог, корзина, checkout, заказы, налоги, доставка, админка.

Главная разница практическая: кастомизация здесь должна уважать ядро платформы. Хороший PHP-код для CMS обычно не «переписывает всё правильно», а аккуратно встраивается в extension points: hooks, events, modules, themes, templates, service container, observers, plugins/interceptors. Это напрямую связано с Composer, Packagist и composer.json, composer.lock, install/update и audit, Конфигурация безопасности PHP, XSS, экранирование вывода и шаблоны и CSRF и state-changing запросы.

flowchart TD
    A[HTTP request / admin action] --> B[Core CMS или commerce runtime]
    B --> C{Extension points}
    C --> D[Plugins / modules / extensions]
    C --> E[Hooks / events / observers]
    C --> F[Themes / templates / blocks]
    D --> G[Custom business logic]
    E --> G
    F --> H[Rendered HTML / API response]
    G --> I[(DB, cache, search, queues)]
    G --> H
    J[Updates и security patches] --> B
    J --> D
    K[Core edits] -. высокий риск конфликтов .-> B

Почти у всех PHP CMS есть похожие слои. Core хранит базовую модель платформы: routing, users, permissions, content model, admin UI, APIs, update mechanism. Extension layer добавляет поведение: plugin, module, extension, package. Theme layer отвечает за внешний вид, templates, blocks, regions, assets. Событийный слой связывает всё вместе: WordPress hooks, Drupal events/hooks/plugins, TYPO3 extensions и event listeners, Magento observers и plugins.

Типичный безопасный путь кастомизации выглядит так: сначала ищут готовый extension point, затем пишут маленький plugin/module, затем переопределяют template или theme-слой, и только в крайнем случае делают patch поверх vendor/core. Прямое редактирование core почти всегда создаёт долг: обновления перестают применяться чисто, security patches конфликтуют, а новый разработчик не понимает, где заканчивается платформа и начинается локальный проект.

Мини-пример на WordPress показывает идею hook-based разработки:

<?php
/**
 * Plugin Name: Example Product Badge
 */

add_filter('the_title', function (string $title, int $postId): string {
    if (get_post_type($postId) !== 'product') {
        return $title;
    }

    return 'Новинка: ' . esc_html($title);
}, 10, 2);

Даже такой короткий код уже показывает две нормы CMS-разработки: поведение подключается через hook, а вывод экранируется по контексту. Подробнее про эту сторону PHP см. XSS, экранирование вывода и шаблоны.

WordPress начинался как blog/CMS, но вырос в платформу для сайтов, редакционных проектов, лендингов, личных кабинетов и магазинов. Его базовая модель расширения — plugins, themes, actions и filters. Actions позволяют выполнить код в определённой точке жизненного цикла, filters — изменить значение и вернуть его обратно. Тема управляет presentation layer; plugin обычно должен хранить бизнес-логику, интеграции, custom post types, shortcodes, blocks, REST endpoints.

WooCommerce добавляет e-commerce-домен поверх WordPress: products, variations, cart, checkout, coupons, orders, payments, shipping, tax logic. Его тоже кастомизируют через actions, filters и template overrides. Практическое правило: сначала используйте hook, затем настройку, затем child theme override, и только потом думайте о замене шаблона целиком. Это снижает шанс сломать обновление WooCommerce.

Сильная сторона WordPress — огромная экосистема и низкий порог входа. Слабая — риск «плагинового комбайна»: десятки расширений от разных авторов, конфликтующие hooks, устаревшие зависимости, непредсказуемый performance. Для серьёзного проекта WordPress надо вести как обычный PHP-продукт: staging, backups, dependency inventory, security updates, least privilege для админов, проверка вывода и форм.

Drupal чаще выбирают для сложных content-моделей, ролей, editorial workflows, multilingual, headless/API-сценариев и проектов, где контент — не просто «страница с полями». Его расширения называются modules, визуальный слой строится через themes, а современный Drupal активно использует Symfony-компоненты, service container, routing, events и YAML-конфигурацию. Поэтому он ближе к инженерной CMS, чем к «быстро поставить сайт из админки».

TYPO3 занимает похожую enterprise-нишу, особенно в Европе: долгоживущие сайты, сложные права редакторов, multisite, structured content, site packages, extensions, LTS-релизы. В TYPO3 важно понимать разницу между core и extensions: безопасность проекта зависит не только от версии ядра, но и от состояния расширений. Это та же логика, что в composer.lock, install/update и audit: уязвимость может приехать не из вашего кода, а из установленного пакета.

Drupal и TYPO3 обычно требуют больше дисциплины на старте, чем WordPress. Зато они лучше держат проекты, где нужны governance, роли, сложная модель контента и предсказуемая поддержка. Если проект фактически становится custom application, стоит сравнить их с Symfony и Выбор PHP-фреймворка, а не выбирать CMS только потому, что «там уже есть админка».

Magento Open Source и Adobe Commerce — e-commerce-платформы, где предметная модель гораздо тяжелее, чем в обычной CMS: catalog, price rules, inventory, checkout, quote/order lifecycle, customer groups, payment gateways, shipping methods, tax calculation, indexing, cache, message queues. Здесь нельзя оценивать платформу только по тому, насколько быстро можно сверстать страницу товара.

В Magento 2-линии расширение строится через modules, dependency injection, XML-конфигурацию, events/observers, plugins/interceptors, service contracts, declarative schema и generated code. Plugin/interceptor может выполнить код до, после или вокруг публичного метода, не меняя сам класс. Это мощно, но опасно: around-plugin в неподходящем месте может незаметно сломать checkout или performance.

OpenMage — community-driven продолжение Magento 1 для существующих магазинов, которым нужно оставаться на Magento 1-подобной базе после EOL. Его разумно рассматривать как путь поддержки легаси-магазина, а не как очевидный выбор для нового e-commerce-проекта. В OpenMage особенно важно избегать хаотичных core edits: patches, Composer и понятный diff дают больше шансов безопасно накатывать обновления.

CMS-проект чаще ломается не из-за «плохого PHP», а из-за плохой эксплуатации: забытые плагины, админка с лишними правами, включённый debug на проде, незафиксированные зависимости, отсутствие staging, отключённые security updates, ручные правки vendor/core. Поэтому платформа не отменяет темы из Конфигурация безопасности PHP: display_errors не должен светить детали на проде, session/cookie-настройки должны соответствовать риску, загрузка файлов требует строгих ограничений, а state-changing формы нуждаются в CSRF-защите.

Для dependency flow полезно разделять две ситуации. Если проект управляется через Composer, production обычно получает composer install по lock-файлу, а composer update делается осознанно в отдельной ветке с тестами и review. Если сайт обновляется через админку CMS, всё равно нужен эквивалентный процесс: staging-копия, список изменений, проверка тем и расширений, backup базы и файлов, быстрый rollback plan.

Граница кастомизации простая: чем ближе изменение к core, checkout, auth, permissions, payments и output rendering, тем выше цена ошибки. Для небольшого сайта достаточно аккуратного plugin/theme-подхода. Для магазина или enterprise CMS нужна инженерная дисциплина уровня обычного backend-сервиса: PHPUnit, моки и стабы, CI, линтеры и автоматические проверки, аудит зависимостей и наблюдаемость.

• Выбор PHP-фреймворка — когда CMS уместнее framework-first разработки, а когда мешает.
• Laravel, Symfony, Yii, Slim и Mezzio — соседние варианты без готовой CMS/e-commerce предметной модели.
• Composer, Packagist и composer.json и composer.lock, install/update и audit — управление зависимостями, lock-файлом и аудитом.
• Конфигурация безопасности PHP, XSS, экранирование вывода и шаблоны, CSRF и state-changing запросы — security-база, которую платформа не заменяет.
• HTTP-заголовки, ответы и редиректы и Загрузка файлов — частые зоны риска в CMS-проектах.