Comment puis-je m'assurer que mon PHP est portable dans tous les environnements de serveurs?

Question

Ce n'est pas une chose rare pour moi de déployer PHP sur un serveur, ou de le déplacer d'un serveur à un autre, et d'avoir complètement échouer avec des erreurs de base de données ou de cookie. J'aimerais mieux éviter ces types de problèmes avant qu'ils ne surviennent.

Quels sont les problèmes potentiels de portabilité en PHP, en ce qui concerne les différents serveurs, systèmes d'exploitation et configurations PHP, et comment peuvent-ils être travaillés? Supposons que je (malheureusement) n'ai aucun contrôle sur l'environnement du serveur, en plus de FTP. (Je vais ajouter une réponse à faire avancer les choses a commencé)

Answer 1

Certains serveurs sont configurés avec des guillemets magiques activés (magic_quotes_gpc=1 dans php.ini), qui appelle automatiquement addslashes() sur $_GET, $_POST, $_COOKIE et $_REQUEST. Il a été introduit à l'origine pour aider les débutants à écrire un code plus sûr, mais son utilisation est maintenant dépréciée.

Pour simuler la désactivation de ce disfonctionnement lors de l'exécution si elle est activée, exécutez le code suivant avant d'utiliser la demande vars (adapté de this comment):

function destroyTheMagic($array, $topLevel = true) { 
    $ret = array(); 
    foreach($array as $key => $value) { 
     if(!$topLevel) 
      $key = stripslashes($key); 
     if(is_array($value)) 
      $ret[$key] = destroyTheMagic($value, false); 
     else 
      $ret[$key] = stripslashes($value); 
    } 
    return $ret; 
} 

if(get_magic_quotes_qpc()) { 
    $_GET = destroyTheMagic($_GET); 
    $_POST = destroyTheMagic($_POST); 
    $_COOKIE = destroyTheMagic($_COOKIE); 
    $_REQUEST = destroyTheMagic($_REQUEST); 
} 

Answer 2

citations magiques sont bien sûr un énorme problème, mais en utilisant un seul fichier php.ini pour tous vos déploiements serait une bonne idée. Ce fichier peut être trouvé dans/etc/php5 (ou quelle que soit la version de PHP que vous utilisez). Cela garantirait que la configuration de PHP sur tous les serveurs est la même (y compris les paramètres de guillemets magiques). Assurez-vous également de vérifier avec la fonction phpinfo() pour vous assurer que vous utilisez la même version de PHP sur tous les serveurs. Aussi, assurez-vous que lorsque vous déployez PHP sur un nouveau serveur, vous avez une liste de tous les paquets que vous avez installés tels que MCrypt, PEAR, bibliothèques PECL, ImageMagick, etc.

Answer 3

En réalité, il y a trop de choses à énumérer . La raison en est qu'il est très difficile d'écrire une application utile avec juste le noyau de php activé (pas d'extensions du tout). Donc si vous voulez que ce soit très portable, vous devrez pouvoir basculer vers différentes extensions (par exemple, il devrait pouvoir utiliser les extensions PDO, MySQL et MySQLi si vous utilisez une base de données MySQL).

En réalité, il y a une tonne de dépendances que vous auriez besoin de vérifier. Ce n'est pas pratique de tous les énumérer ici (pas de loin). Même des choses aussi simples que l'inclusion de chemins peuvent être un problème si vous utilisez Windows ou avec le mode sans échec activé. Et cela ne prend même pas en compte les différents paramètres ini possibles.

Heureusement, il existe une solution relativement simple. Utilisez un cadre. La plupart des frameworks ont des méthodes de secours et peuvent faire les choses de plusieurs façons selon la configuration du serveur. Il y a des tonnes de cadres, donc je ne vais pas entrer dans les détails sur lesquels je recommanderais. En utilisant une couche d'abstraction, ils sont capables de gérer plusieurs configurations possibles (un autre exemple est la technologie de mise en cache, avec des pilotes pour APC, Eacellerator, MySQL, XCache, Memcache, etc.).

La seule autre chose que vous pouvez faire pour être sûr à 100% est de tester. Ce que je recommande est d'écrire autant de tests d'unité, d'intégration et de fonctionnalité que possible. Des outils tels que PHPUnit et Selenium peuvent grandement aider avec ceci. Une fois que vous avez automatisé les tests, je suggère d'utiliser un outil d'intégration continue (tel que Hudson) pour automatiser les tests basés sur la validation SVN. Avec elle, vous pouvez configurer plusieurs plates-formes cibles pour tester avec. Vous pouvez donc exécuter 10 ou 15 serveurs virtuels différents, et tester chaque commit automatiquement pour chaque configuration (Hudson gèrera cela pour vous).De cette façon, vous savez instantanément (enfin, rapidement de toute façon) si votre code fonctionne avec chaque commit sans avoir besoin de faire autre chose de votre part.

Ce n'est pas un problème facile à résoudre. Mais il est résolu avec un peu d'effort et une certaine ingéniosité.

L'autre chose raisonnable que vous pouvez faire est de déclarer les exigences minimales et de les vérifier. Donc, si vous voulez le support de MySQL, vérifiez-le pendant l'installation ... La même chose peut aller avec les paramètres INI ... Il suffit de lister une configuration minimale requise, et vérifiez-la. De cette façon, si quelqu'un arrive avec une « plate-forme non prise en charge », vous n'avez pas besoin de vous inquiéter car on leur dira d'emblée qu'il ne fonctionnera pas ...

Bonne chance ...