WordPress na OxPHP

WordPress to aplikacja działająca w trybie tradycyjnym. Ma wiele fizycznych punktów wejścia (index.php, wp-login.php, wp-cron.php oraz cały katalog wp-admin/), z których każdy ma być osiągany jako rzeczywisty plik. Tryb tradycyjnego routingu w OxPHP, domyślny gdy ENTRY_FILE nie jest ustawiony, obsługuje je dokładnie w ten sposób. Nie ustawiaj ENTRY_FILE: tryb frameworkowy kierowałby każde żądanie do jednego kontrolera frontowego i zepsuł wp-admin.

Ten przepis pokazuje też drugi wariant budowania. Zamiast kopiować OxPHP do bazowego obrazu PHP, rozszerza bezpośrednio obraz środowiska uruchomieniowego OxPHP, kompilując rozszerzenia WordPressa w etapie budowania i wrzucając do niego pliki .so.

Stos w pigułce

  • Obraz OxPHP: ghcr.io/oxphp/oxphp:0.10.0 (PHP 8.5), rozszerzany w miejscu
  • Tryb routingu: Tradycyjny (bez ENTRY_FILE)
  • Dodane rozszerzenia: mysqli, pdo_mysql, gd, zip, intl, exif, bcmath
  • Usługi: OxPHP + MySQL + sidecar WP-CLI (profil cli)
  • Utwardzenie: PHP_DENY_PATHS blokuje bezpośrednie wykonanie .php w wp-content/uploads/
  • URL: http://localhost:8090 · wewnętrznie http://localhost:9091/health

Układ projektu

text
wp-oxphp/ ├── Dockerfile ├── docker-compose.yml └── wordpress/ # the WordPress tree (download from wordpress.org) └── wp-config.php # reads WORDPRESS_* environment variables

wordpress/wp-config.php odczytuje swoje ustawienia ze środowiska kontenera:

wp-config.php
define( 'DB_NAME', getenv( 'WORDPRESS_DB_NAME' ) ?: 'wordpress' ); define( 'DB_USER', getenv( 'WORDPRESS_DB_USER' ) ?: 'wordpress' ); define( 'DB_PASSWORD', getenv( 'WORDPRESS_DB_PASSWORD' ) ?: 'wordpress' ); define( 'DB_HOST', getenv( 'WORDPRESS_DB_HOST' ) ?: 'db:3306' ); $__site_url = getenv( 'WORDPRESS_SITE_URL' ) ?: 'http://localhost:8090'; define( 'WP_HOME', $__site_url ); define( 'WP_SITEURL', $__site_url );

Dockerfile i Compose

Ten Dockerfile kompiluje rozszerzenia względem pasującego php:8.5-zts-alpine (to samo ABI co obraz OxPHP, no-debug-zts-20250925) i kopiuje pliki .so do środowiska uruchomieniowego OxPHP:

Dockerfile
# ── Stage 1: compile WordPress PHP extensions against PHP 8.5 ───── FROM php:8.5-zts-alpine3.23 AS ext-builder RUN apk add --no-cache \ icu-dev libzip-dev libpng-dev libjpeg-turbo-dev freetype-dev oniguruma-dev \ && docker-php-ext-configure gd --with-jpeg --with-freetype \ && docker-php-ext-install -j"$(nproc)" \ mysqli pdo_mysql gd zip intl exif bcmath RUN EXT_DIR=$(php -r 'echo ini_get("extension_dir");') && mkdir -p /ext-out \ && cp "$EXT_DIR"/mysqli.so "$EXT_DIR"/pdo_mysql.so "$EXT_DIR"/gd.so \ "$EXT_DIR"/zip.so "$EXT_DIR"/intl.so "$EXT_DIR"/exif.so \ "$EXT_DIR"/bcmath.so /ext-out/ # ── Stage 2: OxPHP runtime with WordPress extensions ───────────── FROM ghcr.io/oxphp/oxphp:0.10.0 AS runtime USER root RUN apk add --no-cache icu-libs libzip libpng libjpeg-turbo freetype oniguruma # Drop the compiled extensions into OxPHP's PHP 8.5 extension dir COPY --from=ext-builder /ext-out/*.so \ /usr/local/lib/php/extensions/no-debug-zts-20250925/ RUN { \ echo "extension=mysqli.so"; echo "extension=pdo_mysql.so"; \ echo "extension=gd.so"; echo "extension=zip.so"; \ echo "extension=intl.so"; echo "extension=exif.so"; \ echo "extension=bcmath.so"; \ } > /usr/local/etc/php/conf.d/wordpress-extensions.ini RUN { \ echo "upload_max_filesize=64M"; echo "post_max_size=64M"; \ echo "memory_limit=256M"; echo "max_execution_time=300"; \ echo "max_input_vars=3000"; \ } > /usr/local/etc/php/conf.d/wordpress.ini EXPOSE 80
Note

Katalog rozszerzeń (no-debug-zts-20250925) to tag ABI dla PHP 8.5 ZTS. Jeśli budujesz na obrazie OxPHP z PHP 8.4, staje się on no-debug-zts-20240924. Wyznaczaj go w czasie budowania za pomocą php -r 'echo ini_get("extension_dir");', zamiast wpisywać go na sztywno.

Instalacja i pierwsze uruchomienie

bash
docker compose up -d --build docker compose run --rm wpcli wp core install \ --url=http://localhost:8090 --title="OxPHP WordPress" \ --admin_user=admin --admin_password=admin [email protected]

Uwagi dotyczące OxPHP

Note
  • Tryb tradycyjny jest obowiązkowy. WordPress wymaga, aby wp-admin/, wp-login.php, wp-cron.php itp. wykonywały się jako fizyczne pliki. Pozostaw ENTRY_FILE nieustawiony.
  • Obraz środowiska uruchomieniowego OxPHP nie zawiera binarki wp (jest to minimalny obraz serwujący). Praca z CLI odbywa się przez sidecar wpcli w ramach profilu Compose cli, współdzielący ten sam wolumen wordpress/ i bazę danych.
  • wp-config.php odczytuje środowisko kontenera za pomocą getenv(), więc dane dostępowe do bazy i adres URL witryny są w Compose, a nie zaszyte na sztywno w pliku.
  • PHP_DENY_PATHS utwardza katalogi uploadów. Ponieważ tryb tradycyjny wykonuje fizyczne pliki .php, shell wgrany do wp-content/uploads/ przez podatny plugin w przeciwnym razie by się uruchomił. PHP_DENY_PATHS blokuje wykonanie .php w tych ścieżkach, dopasowując je do URI przed jakąkolwiek operacją I/O na dysku, więc nie ma wyroczni istnienia. Działa tylko w trybie tradycyjnym i SPA; w trybie frameworkowym jest to operacja bez efektu (kontroler frontowy już zapobiega bezpośredniemu wykonaniu .php), dlatego przepisy dla trybu frameworkowego w tym miejscu go nie potrzebują. Zobacz Lista blokowania wykonywania PHP.

Weryfikacja

bash
curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8090/ # 200 curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8090/wp-login.php # 200 (physical file) curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8090/wp-content/uploads/x.php # 404 (PHP_DENY_PATHS) curl -s -o /dev/null -w "%{http_code}\n" http://localhost:9091/health # 200

Zobacz też

Znalazłeś błąd? Zgłoś go →