Реальные приложения, проверенные от начала до конца

ENTRY_FILE=index.php выбирает режим фреймворка: public/ становится корневым каталогом документов, поэтому .env, app/ и vendor/ недоступны по HTTP.

Окружение контейнера переопределяет .env — загрузчик dotenv в Laravel никогда не переопределяет реальные переменные окружения, поэтому DB_HOST и APP_ENV, заданные в Compose, имеют приоритет.

Образ для разработки повторно проверяет OPcache при каждом запросе; правки в примонтированном (bind-mount) каталоге src/ применяются мгновенно.

Скелет работает только на базовых расширениях (ctype, iconv, xml); нативные intl и mbstring добавлены, потому что реальные приложения их используют, и они быстрее полифилла.

APP_ENV берётся из окружения контейнера — Symfony отдаёт приоритет реальным переменным окружения над .env.

Статические ресурсы сопоставляются с реальными файлами в public/ и отдаются с диска, обращаясь к index.php только при промахе.

Ни базы данных, ни дополнительных сервисов — минимально возможное развёртывание OxPHP: один образ, один процесс.

yiisoft/assets публикует статические файлы в public/assets/<hash>/ — реальные файлы на диске, без ухищрений с переписыванием URL.

Традиционный режим обязателен: wp-admin/, wp-login.php и wp-cron.php должны выполняться как физические файлы — ENTRY_FILE остаётся незаданным.

PHP_DENY_PATHS блокирует выполнение .php внутри wp-content/uploads/ — шелл, загруженный через уязвимый плагин, никогда не запустится; совпадение проверяется до обращения к диску, не раскрывая факт существования файла.

Работа через CLI идёт через sidecar-контейнер WP-CLI, разделяющий тот же том и базу данных; wp-config.php читает учётные данные через getenv().

RewriteCond !-f + RewriteRule ^ index.php в Drupal — это в точности режим фреймворка: отдавать существующие файлы, а всё остальное направлять на web/index.php.

Агрегированные CSS/JS в web/sites/default/files/ отдаются с диска как статические файлы.

Первый холодный запрос прогревает Twig и кеши (~15 с); после этого ответы занимают единицы миллисекунд — это прогрев Drupal, а не накладные расходы OxPHP.

Ресурсы панели управления (web/cpresources/<hash>/) — реальные файлы на диске, отдаваемые в режиме фреймворка.

Используйте MySQL 8.4 LTS, а не 9 — Craft проверен на 8.x.

Настройки базы данных берутся из окружения контейнера (CRAFT_DB_*), поэтому они находятся в Compose.

october:mirror public воспроизводит белый список ресурсов October для nginx: public/ содержит только index.php и симлинки */assets; темы, config/, .env и vendor/ остаются вне веб-корня.

SYMLINK_ALLOW_PATHS=/var/www/html обязателен — симлинки зеркала указывают обратно в дерево проекта, что OxPHP по умолчанию блокирует.

Не забудьте про tailor:migrate: blueprint-ы Tailor из демо-темы получают свои таблицы отдельно от october:migrate.

Версионированные URL статики (/static/version<N>/…) требуют одного самоссылающегося симлинка внутри pub/static — nginx убирает этот сегмент правилом rewrite, а OxPHP ничего не переписывает.

Запускайте production-режим: режим разработчика генерирует DI-классы во время запроса, рискуя гонками в многопоточном пуле воркеров.

MySQL требует --log_bin_trust_function_creators=1; composer install выполняется через собранный образ PHP 8.4, а не через стандартный composer:2.

Два физических фронт-контроллера — index.php и admin/index.php — поэтому традиционный режим; в режиме фреймворка админка направлялась бы в контроллер витрины.

Веб-корень совпадает с корнем проекта, поэтому PHP_DENY_PATHS=/system/**,/install/** блокирует прямое выполнение внутренних файлов; dotfiles по умолчанию уже отвечают 404.

Маршрутизация по умолчанию через query-параметры (index.php?route=…) работает без единого правила rewrite.