Cette page a été traduite par la communauté et n'est pas forcément à jour. Consultez la version de référence (en anglais).

Cette page a été traduite par la communauté et n'est pas forcément à jour. Consultez la version de référence (en anglais).

Cette page a été traduite par la communauté et n'est pas forcément à jour. Consultez la version de référence (en anglais).

Sponsorisé par
Problèmes connus

Problèmes connus

# Extensions PHP non prises en charge

Les extensions suivantes sont connues pour ne pas être compatibles avec FrankenPHP :

NomRaisonAlternatives
imapNon thread-safejavanile/php-imap2, webklex/php-imap, ImapEngine
newrelicNon thread-safe-
pcovNon thread-safe (SIGSEGV en mode classique)Collecter la couverture avec le SAPI CLI (exécuter PHPUnit/Pest en dehors de FrankenPHP)

# Extensions PHP boguées

Les extensions suivantes ont des bugs connus et des comportements inattendus lorsqu’elles sont utilisées avec FrankenPHP :

NomProblème
datadogInstabilité lors du profilage de FrankenPHP. Ce bug est suivi par DataDog.
blackfireLe support de FrankenPHP est en bêta et n’est pas encore complet.
imagickLes threads OpenMP d’ImageMagick entrent en conflit avec les threads de FrankenPHP, causant instabilité et plantages. Atténuez cela en désactivant le threading d’ImageMagick via \Imagick::setResourceLimit(\Imagick::RESOURCETYPE_THREAD, 1) ou en compilant ImageMagick avec --disable-openmp. OpenMP est déjà désactivé dans les binaires statiques et les paquets officiels apt/apk/rpm, donc seules les images Docker et les installations Homebrew sont affectées.

# Dépasser la limite de mémoire dure de PHP arrête l’ensemble du serveur

Depuis PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12, dépasser memory_limit n’arrête plus le script immédiatement : l’erreur fatale “Allowed memory size exhausted” est déclenchée lors du prochain appel de fonction ou itération de boucle. Si le script alloue au-delà de la limite de mémoire dure avant cela, PHP quitte le processus. La limite dure est par défaut le double de memory_limit (ou memory_limit plus 1 GiB au-dessus de 1 GiB) et peut être modifiée avec le paramètre INI memory_hard_limit_percent.

Le code qui continue de s’exécuter au-delà de memory_limit peut l’atteindre, par exemple une seule allocation plus grande que memory_limit (comme array_merge() sur de grands tableaux) ou des concaténations de chaînes consécutives.

PHP-FPM ne perd qu’un seul processus enfant. FrankenPHP sert toutes les requêtes à partir de threads d’un seul processus, de sorte que chaque requête en cours est perdue et le serveur s’arrête jusqu’à ce qu’il soit redémarré. Exécutez FrankenPHP sous un superviseur qui le redémarre, comme une politique de redémarrage Docker ou Restart= de systemd (déjà configuré dans les paquets deb et rpm).

# get_browser

La fonction get_browser() semble avoir de mauvaises performances après un certain temps. Une solution est de mettre en cache (par exemple, avec APCu) les résultats par agent utilisateur, car ils sont statiques.

# Binaire autonome et images Docker basées sur Alpine

Le binaire entièrement statique et les images Docker basées sur Alpine (dunglas/frankenphp:*-alpine) utilisent musl libc au lieu de glibc et ses amis, pour garder une taille de binaire plus petite. Cela peut entraîner des problèmes de compatibilité. En particulier, le drapeau glob GLOB_BRACE n’est pas disponible.

Préférez utiliser la variante GNU du binaire statique et les images Docker basées sur Debian si vous rencontrez des problèmes.

# Utilisation de https://127.0.0.1 avec Docker

Par défaut, FrankenPHP génère un certificat TLS pour localhost. C’est l’option la plus simple et recommandée pour le développement local.

Si vous voulez vraiment utiliser 127.0.0.1 comme hôte, il est possible de configurer FrankenPHP pour générer un certificat pour cela en définissant le nom du serveur à 127.0.0.1.

Malheureusement, cela ne suffit pas lors de l’utilisation de Docker à cause de son système de gestion des réseaux. Vous obtiendrez une erreur TLS similaire à curl: (35) LibreSSL/3.3.6: error:1404B438:SSL routines:ST_CONNECT:tlsv1 alert internal error.

Si vous utilisez Linux, une solution est d’utiliser le pilote de réseau “hôte” :

docker run \
    -e SERVER_NAME="127.0.0.1" \
    -v $PWD:/app/public \
    --network host \
    dunglas/frankenphp

Le pilote de réseau “hôte” n’est pas pris en charge sur Mac et Windows. Sur ces plateformes, vous devrez deviner l’adresse IP du conteneur et l’inclure dans les noms de serveur.

Exécutez la commande docker network inspect bridge et inspectez la clé Containers pour identifier la dernière adresse IP attribuée sous la clé IPv4Address, puis incrémentez-la d’un. Si aucun conteneur n’est en cours d’exécution, la première adresse IP attribuée est généralement 172.17.0.2.

Ensuite, incluez ceci dans la variable d’environnement SERVER_NAME :

docker run \
    -e SERVER_NAME="127.0.0.1, 172.17.0.3" \
    -v $PWD:/app/public \
    -p 80:80 -p 443:443 -p 443:443/udp \
    dunglas/frankenphp

Caution

Assurez-vous de remplacer 172.17.0.3 par l’IP qui sera attribuée à votre conteneur.

Vous devriez maintenant pouvoir accéder à https://127.0.0.1 depuis la machine hôte.

Si ce n’est pas le cas, lancez FrankenPHP en mode debug pour essayer de comprendre le problème :

docker run \
    -e CADDY_GLOBAL_OPTIONS="debug" \
    -e SERVER_NAME="127.0.0.1" \
    -v $PWD:/app/public \
    -p 80:80 -p 443:443 -p 443:443/udp \
    dunglas/frankenphp

# Scripts Composer faisant référence à @php

Les scripts Composer peuvent vouloir exécuter un binaire PHP pour certaines tâches, par exemple dans un projet Laravel pour exécuter @php artisan package:discover --ansi. Cela échoue actuellement pour deux raisons :

  • Composer ne sait pas comment appeler le binaire FrankenPHP ;
  • Composer peut ajouter des paramètres PHP en utilisant le paramètre -d dans la commande, ce que FrankenPHP ne supporte pas encore.

Comme solution de contournement, nous pouvons créer un script shell dans /usr/local/bin/php qui supprime les paramètres non supportés et appelle ensuite FrankenPHP :

#!/usr/bin/env bash
# /usr/local/bin/php
args=("$@")
index=0
for i in "$@"
do
    if [ "$i" == "-d" ]; then
        unset 'args[$index]'
        unset 'args[$index+1]'
    fi
    index=$((index+1))
done

/usr/local/bin/frankenphp php-cli ${args[@]}

Ensuite, définissez la variable d’environnement PHP_BINARY au chemin de notre script php et lancez Composer :

export PHP_BINARY=/usr/local/bin/php
composer install

# Résolution des problèmes TLS/SSL avec les binaires statiques

Lorsque vous utilisez les binaires statiques, vous pouvez rencontrer les erreurs suivantes liées à TLS, par exemple lors de l’envoi de courriels utilisant STARTTLS :

Unable to connect with STARTTLS: stream_socket_enable_crypto(): SSL operation failed with code 5. OpenSSL Error messages:
error:80000002:system library::No such file or directory
error:80000002:system library::No such file or directory
error:80000002:system library::No such file or directory
error:0A000086:SSL routines::certificate verify failed

Comme le binaire statique ne contient pas de certificats TLS, vous devez indiquer à OpenSSL l’installation de vos certificats CA locaux.

Inspectez la sortie de openssl_get_cert_locations(), pour trouver l’endroit où les certificats CA doivent être installés et stockez-les à cet endroit.

Warning

Les contextes Web et CLI peuvent avoir des paramètres différents. Assurez-vous d’exécuter openssl_get_cert_locations() dans le bon contexte.

Les certificats CA extraits de Mozilla peuvent être téléchargés sur le site de cURL.

Alternativement, de nombreuses distributions, y compris Debian, Ubuntu, et Alpine fournissent des paquets nommés ca-certificates qui contiennent ces certificats.

Il est également possible d’utiliser SSL_CERT_FILE et SSL_CERT_DIR pour indiquer à OpenSSL où chercher les certificats CA :

# Définir les variables d'environnement des certificats TLS
export SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt
export SSL_CERT_DIR=/etc/ssl/certs
Editer cette page