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).
Les extensions suivantes sont connues pour ne pas être compatibles avec FrankenPHP :
| Nom | Raison | Alternatives |
|---|---|---|
| imap | Non thread-safe | javanile/php-imap2, webklex/php-imap, ImapEngine |
| newrelic | Non thread-safe | - |
| pcov | Non thread-safe (SIGSEGV en mode classique) | Collecter la couverture avec le SAPI CLI (exécuter PHPUnit/Pest en dehors de FrankenPHP) |
Les extensions suivantes ont des bugs connus et des comportements inattendus lorsqu’elles sont utilisées avec FrankenPHP :
| Nom | Problème |
|---|---|
| datadog | Instabilité lors du profilage de FrankenPHP. Ce bug est suivi par DataDog. |
| blackfire | Le support de FrankenPHP est en bêta et n’est pas encore complet. |
| imagick | Les 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. |
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).
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.
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.
https://127.0.0.1 avec DockerPar 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.3par 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
@phpLes 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 :
-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
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