Реальні застосунки, перевірені від початку до кінця

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.