Prawdziwe aplikacje, zweryfikowane od początku do końca

ENTRY_FILE=index.php wybiera tryb framework: public/ staje się katalogiem głównym dokumentów, więc .env, app/ oraz vendor/ nigdy nie są osiągalne przez HTTP.

Środowisko kontenera nadpisuje .env — loader dotenv Laravela nigdy nie nadpisuje prawdziwych zmiennych środowiskowych, więc DB_HOST i APP_ENV ustawione w Compose wygrywają.

Obraz deweloperski ponownie waliduje OPcache przy każdym żądaniu; zmiany w podmontowanym katalogu src/ (bind mount) obowiązują natychmiast.

Szkielet działa na samych podstawowych rozszerzeniach (ctype, iconv, xml); natywne intl i mbstring są dodane, ponieważ prawdziwe aplikacje z nich korzystają i biją na głowę polyfill.

APP_ENV pochodzi ze środowiska kontenera — Symfony czyta prawdziwe zmienne środowiskowe zamiast .env.

Statyczne zasoby są odwzorowywane na rzeczywiste pliki w public/ i serwowane z dysku, a do index.php trafiają tylko w razie nietrafienia.

Bez bazy danych, bez dodatkowych usług — najmniejsze możliwe wdrożenie OxPHP: jeden obraz, jeden proces.

yiisoft/assets publikuje pliki statyczne do public/assets/<hash>/ — prawdziwe pliki na dysku, bez akrobacji z przepisywaniem adresów URL.

Tryb tradycyjny jest obowiązkowy: wp-admin/, wp-login.php i wp-cron.php muszą wykonywać się jako fizyczne pliki — ENTRY_FILE pozostaje nieustawione.

PHP_DENY_PATHS blokuje wykonywanie .php w wp-content/uploads/ — powłoka wgrana przez podatną wtyczkę nigdy się nie uruchomi; dopasowanie następuje przed operacjami I/O na dysku, bez wyroczni istnienia plików.

Praca z CLI odbywa się przez sidecar WP-CLI współdzielący ten sam wolumen i bazę danych; wp-config.php odczytuje dane uwierzytelniające przez getenv().

Konstrukcja RewriteCond !-f + RewriteRule ^ index.php w Drupalu to dokładnie tryb framework: serwuj istniejące pliki, a resztę przekazuj do web/index.php.

Zagregowane pliki CSS/JS w web/sites/default/files/ są serwowane z dysku jako pliki statyczne.

Zimne pierwsze żądanie rozgrzewa Twiga i pamięci podręczne (~15 s); potem odpowiedzi mieszczą się w jednocyfrowej liczbie milisekund — to rozgrzewka Drupala, nie narzut OxPHP.

Zasoby panelu sterowania (web/cpresources/<hash>/) to prawdziwe pliki na dysku, serwowane przez tryb framework.

Używaj MySQL 8.4 LTS, nie 9 — Craft jest zweryfikowany pod kątem 8.x.

Ustawienia bazy danych pochodzą ze środowiska kontenera (CRAFT_DB_*), więc znajdują się w Compose.

october:mirror public odtwarza nginxową białą listę zasobów Octobera: public/ zawiera tylko index.php oraz dowiązania symboliczne */assets; motywy, config/, .env i vendor/ pozostają poza katalogiem webroot.

SYMLINK_ALLOW_PATHS=/var/www/html jest wymagane — dowiązania symboliczne kopii lustrzanej wskazują z powrotem do drzewa projektu, co OxPHP domyślnie blokuje.

Nie zapomnij o tailor:migrate: blueprinty Tailora w motywie demonstracyjnym dostają swoje tabele osobno od october:migrate.

Wersjonowane statyczne adresy URL (/static/version<N>/…) wymagają jednego samoodwołującego się dowiązania symbolicznego wewnątrz pub/static — nginx usuwa ten segment regułą przepisywania, a OxPHP nie przepisuje.

Uruchamiaj w trybie produkcyjnym: tryb deweloperski generuje klasy DI w czasie żądania, ryzykując wyścigi w wielowątkowej puli workerów.

MySQL potrzebuje --log_bin_trust_function_creators=1; composer install działa przez zbudowany obraz PHP 8.4, a nie standardowy composer:2.

Dwa fizyczne kontrolery frontowe — index.php i admin/index.php — więc tryb tradycyjny; tryb framework skierowałby panel administracyjny do kontrolera sklepu.

Katalog webroot to katalog główny projektu, więc PHP_DENY_PATHS=/system/**,/install/** blokuje bezpośrednie wykonywanie plików wewnętrznych; pliki z kropką i tak domyślnie zwracają 404.

Domyślny routing przez zapytania (index.php?route=…) działa bez żadnych reguł przepisywania.