Problèmes Connus

Fibres

Appeller de fonctions et mots clefs PHP qui eux-mêmes appellent cgo dans des Fibres est connu pour provoquer des plantages.

Ce problème est en cours de correction par le projet Go.

En attendant, une solution consiste à ne pas utiliser de mots clefs (comme echo) et de fonctions (comme header()) qui délèguent à Go depuis l'intérieur de fibres.

Ce code risque de planter car il utilise echo dans une fibre :

$fiber = new Fiber(function() {
    echo 'Dans la fibre'.PHP_EOL;
    echo 'Toujours dedans'.PHP_EOL;
});
$fiber->start();

A la place, retournez la valeur de la Fibre et utilisez-la à l'extérieur :

$fiber = new Fiber(function() {
    Fiber::suspend('Dans la fibre'.PHP_EOL));
    Fiber::suspend('Toujours dedans'.PHP_EOL));
});
echo $fiber->start();
echo $fiber->resume();
$fiber->resume();

Extensions PHP non prises en charge

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

Nom	Problème
XDebug	XDebug peut planter, ou se bloquer quand utilisé avec PHP 8.3. Une solution consiste à dwongrader vers PHP 8.2. Ce problème est suivi par XDebug.
Tideways	En mode worker, l'extension Tideways empêche les scripts workers de se terminer correctement ou consomme 100% du CPU. Ce problème a été signalé à Tideways.
ext-openssl	Lors de l'utilisation d'une version statique de FrankenPHP (construite avec la libc musl), l'extension OpenSSL peut planter sous de fortes charges. Une solution consiste à utiliser une version liée dynamiquement (comme celle utilisée dans les images Docker). Ce bogue est suivi par PHP.

Extensions PHP boguées

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

Nom | Problème XDebug | XDebug peut planter, ou se bloquer quand utilisé avec PHP 8.3. Une solution consiste à dwongrader vers PHP 8.2. Ce problème est suivi par XDebug. Tideways | En mode worker, l'extension Tideways empêche les scripts workers de se terminer correctement ou consomme 100% du CPU. Ce problème a été signalé à Tideways. ext-openssl | Lors de l'utilisation d'une version statique de FrankenPHP (construite avec la libc musl), l'extension OpenSSL peut planter sous de fortes charges. Une solution consiste à utiliser une version liée dynamiquement (comme celle utilisée dans les images Docker). Ce bogue est suivi par PHP.

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 autonome 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.

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 est la plus simple et est recommandée pour le développement local.

Si vous voulez vraiment utiliser 127.0.0.1 comme hôte, il est possible de configure 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 inpectez la clef Containers pour identifier la dernière adresse IP attribuée sous la clef IPv4Address, puis incrémentez-la de 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

known-issues.md 7.1 KB Постоянная ссылка История Исходник