OxPHP での WordPress

WordPress は従来型モードのアプリケーションです。物理的なエントリーポイントが数多くあり(index.phpwp-login.phpwp-cron.php、そして wp-admin/ ディレクトリ全体)、そのそれぞれが実在するファイルとしてアクセスされることを前提としています。OxPHP の従来型ルーティングモードは、ENTRY_FILE を設定しない場合のデフォルトであり、これらを正確にそのとおりに配信します。ENTRY_FILE設定しないでください。フレームワークモードではすべてのリクエストが単一のフロントコントローラーに集約されてしまい、wp-admin が壊れてしまいます。

このレシピでは、2 つ目のビルド形態も示します。OxPHP を PHP ベースイメージにコピーするのではなく、OxPHP ランタイムイメージを直接拡張し、ビルダーステージで WordPress 用の拡張モジュールをコンパイルして .so ファイルを組み込みます。

スタック概観

  • OxPHP イメージ: ghcr.io/oxphp/oxphp:0.10.0(PHP 8.5)をそのまま拡張
  • ルーティングモード: 従来型(ENTRY_FILE なし)
  • 追加する拡張モジュール: mysqlipdo_mysqlgdzipintlexifbcmath
  • サービス: OxPHP + MySQL + WP-CLI サイドカー(cli プロファイル)
  • 堅牢化: PHP_DENY_PATHSwp-content/uploads/ 配下での .php の直接実行をブロック
  • 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(OxPHP イメージと同じ ABI、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)は、PHP 8.5 ZTS の ABI タグです。PHP 8.4 の OxPHP イメージ上でビルドする場合、これは 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 [email protected]

OxPHP に関する注意点

Note
  • 従来型モードは必須です。 WordPress は wp-admin/wp-login.phpwp-cron.php などが物理ファイルとして実行される必要があります。ENTRY_FILE は未設定のままにしてください。
  • OxPHP ランタイムイメージには wp バイナリが含まれていません(最小限の配信用イメージです)。CLI 作業は、cli Compose プロファイルの wpcli サイドカーを通じて行い、同じ wordpress/ ボリュームとデータベースを共有します。
  • wp-config.php はコンテナの環境変数を getenv() で読み込みます。 そのため、データベースの認証情報とサイト URL はファイルにハードコードするのではなく Compose 側に置きます。
  • PHP_DENY_PATHS がアップロードディレクトリを堅牢化します。 従来型モードは物理的な .php ファイルを実行するため、脆弱なプラグインによって wp-content/uploads/ にアップロードされたシェルは、そのままでは実行されてしまいます。PHP_DENY_PATHS はこれらのパス配下での .php の実行をブロックし、ディスク I/O が発生するに 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

関連情報