Je pense que je viens de tomber sur un problème de compatibilité PHP avec la classe DateInterval. Depuis quelques temps je me suis rendu compte aussi que j’utilisais pas mal de fonctions PHP disponibles uniquement depuis des versions assez récentes de PHP.
Je pense que ça risque de continuer et d’une certaine façon ça me parait être une bonne chose pour le code si on sait la gérer.
Donc ma question : ne pourrait-on pas trouver un mécanisme de vérification de la compatibilité PHP requise par un plugin afin de le rendre incompatible au besoin. On pourrait imaginer quelque chose comme :
un attribut php de paquet à l’instar de celui de spip
Pour ma part, un attribut “php” ajouté à serait le bienvenu.
Soit on reprend la mécanique déjà présente des crochets et des point-virgules.
Soit on simplifie en ne mettant qu’un numéro de version sous la version x.y.z, indiquant la version minimum de PHP.
Soit on introduit une écriture telle que “>=5.1.0”, “>5.1.0”…
La solution la plus logique serait la première… Car on est habitué à cette nomenclature.
Et pour que tout cela soit pris en compte, il faudra faire évoluer SVP pour reconnaitre la version de PHP présente sur le serveur, et la version minimum demandée par un plugin.
Il serait cool que cette nouveauté soit pris en compte aussi bien sur SPIP 3.1 (logique) que SPIP 3.0.
Pour info, Drupal utilise un attribut “php” dans son descriptif de modules pour indiquer la version minimum nécessaire.
La proposition d’utiliser un attribut de paquet (donc aussi de la balise spip) n’est pas simple à implémenter.
J’ai donc testé une autre solution qui consiste à utiliser un necessite et un procure:
dans SPIP, lors de la lecture du paquet.xml (get_infos) je rajoute après la lecture elle-même par infos_paquets un procure nom=“php” et dont la version est retournée par la fonction phpversion() de PHP. De fait, on considère que SPIP procure la version courante du serveur.
dans un plugin de test, je rajoute un necessite nom=“php” et une compatibilite=[5.3.0;[ par exemple.
En utilisant un PHP 5.2.17 j’obtiens l’erreur cherchée.
L’intérêt de cette solution est d’être très simple à mettre en oeuvre en 3.1 et 3.0 : deux lignes de codes dans get_infos.
Si c'est dans la base SPIP, comment est-ce qu'on le gère lors de la migration d'un site vers un autre serveur qui risque d'utiliser une version différente de PHP ?
Si c'est dans la base SPIP, comment est-ce qu'on le gère lors de la
migration d'un site vers un autre serveur qui risque d'utiliser une
version différente de PHP ?
Non non, ce n'est pas dans la base Klaus L'info est renvoyé par la fonction phpversion() de PHP, cf :
L'info est renvoyé par la fonction phpversion() de PHP, cf :