Exemples de déploiement

Ces guides montrent comment exécuter neuf applications PHP populaires sur OxPHP, chacune sous forme de projet Docker Compose autonome. Chaque recette a été construite et vérifiée de bout en bout : la vitrine, le panneau d'administration, les fichiers statiques et l'endpoint de santé interne d'OxPHP répondent tous 200.

Chaque page est une recette complète, prête à copier-coller : un Dockerfile, un docker-compose.yml, les commandes d'installation et les détails propres à OxPHP que la documentation d'origine de l'application (rédigée pour nginx + PHP-FPM) ne couvre pas.

Les applications

Ce que chaque recette a en commun

Partir de l'image OxPHP publiée

OxPHP fournit un runtime PHP prêt à l'emploi sous la forme de ghcr.io/oxphp/oxphp (PHP 8.5 par défaut ; une variante PHP 8.4 est publiée sous ghcr.io/oxphp/oxphp:<ver>-php8.4-alpine<X>). L'image publiée contient déjà le binaire oxphp, libphp.so, l'extension SAPI d'OxPHP, la CLI PHP et l'outillage compatible Composer. Les recettes l'étendent selon l'une des deux approches suivantes :

1. Copier OxPHP dans une base php:*-zts-alpine (utilisé par Laravel, Symfony, Yii3, Craft, Magento, OpenCart, Drupal, October). Une construction multi-étapes assemble une image dev à partir de quatre étapes :

   Dockerfilecopy

   FROM php:8.4-zts-alpine3.23 AS php-base # your app's PHP extensions FROM composer:2 AS composer # the Composer binary FROM ghcr.io/oxphp/oxphp:0.10.0-php8.4-alpine3.23 AS oxphp # OxPHP artifacts FROM php-base AS dev # final image # ... copy the oxphp binary, bridge library, and SAPI extension across: COPY --from=oxphp /usr/local/bin/oxphp /usr/local/bin/oxphp COPY --from=oxphp /usr/local/lib/liboxphp_bridge.so /usr/local/lib/ COPY --from=oxphp /usr/local/lib/php/extensions/ /tmp/oxphp-ext/ RUN cp /tmp/oxphp-ext/*/oxphp_sapi.so "$(php -r 'echo ini_get("extension_dir");')/" \ && echo "extension=oxphp_sapi.so" > /usr/local/etc/php/conf.d/oxphp-ext.ini

2. Étendre directement le runtime OxPHP (utilisé par WordPress). Une étape de build compile les extensions contre un php:*-zts-alpine correspondant et dépose les fichiers .so dans l'image OxPHP.

Consultez le Guide Docker pour le modèle multi-étapes canonique, et examples/dockerfile/ dans le dépôt pour une version prête à copier.

Choisir délibérément la version de PHP

L'image ghcr.io/oxphp/oxphp:<ver> par défaut utilise PHP 8.5. C'est parfait pour les frameworks modernes (Laravel, Symfony, Yii3, Craft). Les bases de code plus anciennes ou plus conservatrices — Magento, OpenCart, Drupal, October CMS — épinglent PHP 8.4 via le tag …-php8.4-alpine…, car leurs piles de composants sont antérieures à 8.5 et y émettent des dépréciations. Chaque recette indique laquelle elle utilise et pourquoi.

Choisir le mode de routage selon la forme de l'application

Le mode de routage d'OxPHP correspond directement à la façon dont l'application est organisée :

• Mode framework (ENTRY_FILE=index.php) — un unique contrôleur frontal dans un répertoire public/ (ou web/, pub/) ; les fichiers statiques existants sont servis depuis le disque, tout le reste est dispatché vers index.php. À utiliser pour Laravel, Symfony, Yii3, Craft, Magento, Drupal, October.
• Mode traditionnel (pas d'ENTRY_FILE) — plusieurs points d'entrée PHP physiques (par exemple index.php plus un répertoire admin/) servis comme de vrais fichiers. À utiliser pour WordPress et OpenCart.

Installer via le même conteneur

L'image dev embarque la CLI PHP et Composer (ainsi que drush, wp, bin/magento, php yii, php craft, php artisan selon le cas), si bien que chaque commande d'installation et de maintenance s'exécute à l'intérieur du conteneur en cours d'exécution — sans chaîne d'outils séparée :

Paramètres de sécurité par défaut qui s'appliquent partout

OxPHP vous offre gratuitement plusieurs protections que nginx + PHP-FPM exigent de configurer explicitement :

• Blocage des chemins commençant par un point — .env, .git/, .htaccess et tout autre chemin dont un segment commence par un point renvoient 404 sans configuration. C'est pourquoi exécuter une application depuis un répertoire qui contient aussi .env ne le divulgue pas.
• Liste de refus d'exécution PHP (PHP_DENY_PATHS) — utilisée par les recettes en mode traditionnel : OpenCart bloque les scripts system/ et install/ ; WordPress bloque l'exécution de .php sous wp-content/uploads/. (Sans effet en mode framework, où aucun .php arbitraire n'est jamais exécuté directement.)
• Chemins de liens symboliques autorisés (SYMLINK_ALLOW_PATHS) — utilisés par October CMS pour qu'OxPHP suive les liens symboliques d'assets produits par october:mirror public, tout en continuant à bloquer les échappements par lien symbolique partout ailleurs.

Les recettes

Les pages sont regroupées par type d'application, en miroir de l'organisation des répertoires :

Framework — framework/

• Laravel — l'application canonique en mode framework
• Symfony — squelette minimal, sans base de données
• Yii3 — le plus épuré de tous ; extensions de base uniquement

CMS — cms/

• WordPress — mode traditionnel, build d'extension au runtime, sidecar WP-CLI
• Drupal — mode framework, PDO + drush
• Craft CMS — mode framework, installation pilotée par la console
• October CMS — mode framework avec un miroir public/ et SYMLINK_ALLOW_PATHS

E-commerce — ecommerce/

• Magento — la plus lourde : OpenSearch, PHP 8.4, lien symbolique de version pour les fichiers statiques
• OpenCart — mode traditionnel avec deux contrôleurs frontaux et PHP_DENY_PATHS