WordPress на OxPHP

WordPress — это приложение традиционного режима. У него много физических точек входа (index.php, wp-login.php, wp-cron.php и весь каталог wp-admin/), и к каждой предполагается обращение как к реальному файлу. Традиционный режим маршрутизации OxPHP, используемый по умолчанию, когда ENTRY_FILE не задан, обслуживает их именно так. Не задавайте ENTRY_FILE: режим фреймворка направил бы каждый запрос в единственный фронт-контроллер и сломал бы wp-admin.

Этот рецепт также демонстрирует второй способ сборки. Вместо того чтобы копировать OxPHP в PHP-базу, он расширяет образ рантайма OxPHP напрямую: компилирует расширения WordPress на стадии сборки и подкладывает файлы .so.

Стек вкратце

  • Образ OxPHP: ghcr.io/oxphp/oxphp:0.10.0 (PHP 8.5), расширяется на месте
  • Режим маршрутизации: традиционный (без ENTRY_FILE)
  • Добавленные расширения: mysqli, pdo_mysql, gd, zip, intl, exif, bcmath
  • Сервисы: OxPHP + MySQL + сайдкар WP-CLI (профиль cli)
  • Усиление защиты: PHP_DENY_PATHS блокирует прямое исполнение .php внутри wp-content/uploads/
  • URL: http://localhost:8090 · внутренний http://localhost:9091/health

Структура проекта

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 читает свои настройки из окружения контейнера:

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 и Compose

Этот Dockerfile компилирует расширения на совместимом php:8.5-zts-alpine (тот же ABI, что и у образа OxPHP, — no-debug-zts-20250925) и копирует файлы .so в рантайм 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

Каталог расширений (no-debug-zts-20250925) — это тег ABI для PHP 8.5 ZTS. Если вы собираете на образе OxPHP с PHP 8.4, он превращается в no-debug-zts-20240924. Вычисляйте его во время сборки с помощью php -r 'echo ini_get("extension_dir");', а не прописывайте жёстко.

Установка и первый запуск

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 --admin_email=admin@example.com

Замечания по OxPHP

Note
  • Традиционный режим обязателен. WordPress требует, чтобы wp-admin/, wp-login.php, wp-cron.php и т. д. исполнялись как физические файлы. Оставьте ENTRY_FILE незаданным.
  • Образ рантайма OxPHP не содержит бинарника wp (это минимальный образ для обслуживания запросов). Работа через CLI идёт через сайдкар wpcli в профиле Compose cli, который использует тот же том wordpress/ и ту же базу данных.
  • wp-config.php читает окружение контейнера через getenv(), поэтому учётные данные базы данных и URL сайта заданы в Compose, а не прописаны жёстко в файле.
  • PHP_DENY_PATHS усиливает защиту каталогов загрузок. Поскольку традиционный режим исполняет физические файлы .php, оболочка (shell), загруженная в wp-content/uploads/ через уязвимый плагин, иначе бы выполнилась. PHP_DENY_PATHS блокирует исполнение .php внутри этих путей, сопоставляя их с URI до любого дискового ввода-вывода, так что не возникает оракула существования файлов. Он действует только в традиционном режиме и режиме SPA; в режиме фреймворка он ничего не делает (фронт-контроллер уже предотвращает прямое исполнение .php), поэтому приведённым здесь рецептам в режиме фреймворка он не нужен. См. Дени-лист исполнения PHP.

Проверка

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

Смотрите также

Нашли ошибку? Сообщите →