Je développe sous PHP 7 et le framework openMairie n’est pas compatible en l’état. Bien que je ne rencontre pas de Fatal Error, mes logs Apache sont pollués par des Warning et des Deprecated. Cela rend plus compliqué le debug et casse le développement réalisé en AJAX. Outre mon propre confort cela permettrait de faire tourner des instances applicatives sur des environnements plus récents.
Après analyse il y a trois opérations à réaliser. Elles sont pleinement rétrocompatibles PHP 5.
La librairie DB de Pear v1.7.14 est incompatible PHP 7
→ mettre à jour vers la v1.9.2
La méthode database::isError() doit être statique
→ corriger sa déclaration et remplacer $this par self
Les prototypes des méthodes doivent être identiques
→ corriger le générateur
→ corriger la classe dbForm
→ corriger les classes filles (concerne également les applications en sus du Framework)
J’ai corrigé le framework dans ce sens sur une nouvelle branche :
svn+ssh://scm.adullact.net/svn/openmairie/openmairie_exemple/branches/compatibilite_php7
Les tests passent. J’ai également fixé openADS sur cette branche, puis effectué une génération complète et corrigé les prototypes des méthodes surchargées. Les tests passent également.
Ce sujet a pour objectif de démarrer la discussion sur la compatibilité PHP 7 du framework openMairie, puis le cas échéant intégrer la branche en question dans le trunk.
Pouvez-vous détailler les opérations pour “corriger les prototypes” pour une application:
-quels fichiers sont à modifier ?
-quelle est la modification opérée ? peut-être un exemple ?
-est-ce facile à automatiser (batch, fonction avancée d’éditeur , …) ?
Je citerai en exemple la méthode setValFAjout($val = array()). Son prototype (nommage de la méthode et prise en compte d’un argument étant un tableau vide par défaut) doit être identique dans :
le générateur (fait sur le framework, suffit d’une génération complète sur l’application) ;
la classe dbForm (fait sur le framework, rien à faire sauf si surcharge) ;
les classes filles dont la méthode est surchargée et son prototype non conforme (à voir dans automatisation).
Étant donné qu’il s’agit d’un travail ponctuel, pour openADS j’ai corrigé manuellement les prototypes en faisant une recherche globale des méthodes de dbForm.
C’est un traitement fastidieux qui reste à reproduire pour chaque application. On pourrait créer un script qui corrige le prototype et l’appel au parent.
Cela se corse si on garde un prototype strict (nommage arguments identique). PHP 7 ne l’oblige pas mais pour la cohérence je l’ai fait sur openADS. Il se peut que la variable, cependant en général dépréciée ($dnu1 et $dnu2 qui sont respectivement $db et $DEBUG), soit utilisée à l’intérieur du code procédural. Je n’ai pas rencontré ce cas excepté lors de l’appel au parent.
Si ce travail sur l’application n’est pas effectué cela ne posera pas de problème sous PHP 5 mais on rencontrera toujours des erreurs avec la version 7.
En effet, l’automatisation semble assez accessible sans trop de prise de risque entre objet générés et objet surchargé, et objets dérivés des surchargés.
Concernant la reprise de $dnu1 et $dnu2, la tentation est grande quand on a pas d’application ancienne à maintenir d’en profiter pour s’en débarrasser.
Pourriez-vous faire un ticket sur la forge ?
Désolé de ma réponse tardive. Après réflexion, étant donné que la compatibilité PHP 7 ne fait pas partie de la feuille de route du framework il est plus approprié de continuer la discussion ici.
Je pense que votre suggestion d’automatisation des corrections des prototypes est une bonne idée. Si vous avez la possibilité de créer un script, n’hésitez pas à le partager ici. On peut ajouter des pièces jointes aux réponses.
En pièce jointe le script SHELL unix Gzippé (et maquillé en .doc ;o) d’aide à la migration applicative openMairie PHP7 que j’ai utilisé.
Je l’ai testé par rapport aux modifications apportées sur openADS, et utilisé sur openMarchéForain (sous PHP5).
Il reste adaptable, notamment pour les classes dérivées des classes surchargeant les classes métiers générées.update_php7.sh.doc (2,0 Ko)