[spip-dev] Un tour sur le contrôle de la vesion PHP dans la 3.2-dev

Dev
1

Coucou,

j’ai fait quelques grep pour voir où SPIP en était dans ses contôles de version PHP.

1/ recherche des appels à phpversion()

grep -rin phpversion *

ecrire/inc/cookie.php:60: ($httponly and strnatcmp(phpversion(), ‘5.2.0’) >= 0) ?
ecrire/inc/filtres.php:4727: if (substr(phpversion(), 0, 5) == ‘5.4.0’ and !@gzinflate($env)) {
ecrire/inc/filtres_ecrire.php:454: if (version_compare(phpversion(), _PHP_MIN) == -1) {
ecrire/inc/filtres_ecrire.php:456: array(‘min’ => _PHP_MIN, ‘version’ => phpversion()));
ecrire/inc/install.php:169: $p = phpversion();
ecrire/inc/session.php:631: if (version_compare(phpversion(), ‘5.4.0’, ‘>=’)) {
ecrire/plugins/get_infos.php:128: $ret[‘procure’][‘php’] = array(‘nom’ => ‘php’, ‘version’ => phpversion());
plugins-dist/safehtml/lib/safehtml/classes/HTMLSax3/Decorators.php:75:if (version_compare(phpversion(), ‘4.3’, ‘<’) && !function_exists(‘html_entity_decode’) ) {
plugins-dist/safehtml/lib/safehtml/classes/HTMLSax3.php:223: if (version_compare(phpversion(), ‘4.3’, ‘ge’)) {

Selon moi, le test dans inc/cookie peut être supprimé.

dans inc/filtres_ecrire, je ne vois pas bien à quoi ça sert.

dans le plugin safehtml, il me semble qu’il faut plutôt chercher une alternative à cette lib.

c’est surtout dans inc/install que le boutot devrait se faire (la version minimum y est toujours 5.1.0 d’ailleurs…

2/ recherche de l’utilisation de _PHP_MIN :

grep -rn _PHP_MIN *

ecrire/inc/filtres_ecrire.php:454: if (version_compare(phpversion(), _PHP_MIN) == -1) {
ecrire/inc/filtres_ecrire.php:456: array(‘min’ => _PHP_MIN, ‘version’ => phpversion()));
ecrire/inc_version.php:36:define(’_PHP_MIN’, ‘5.3.0’);

idem pour inc/filtres-ecrire

ecrire/inc_version.php, OK.

3/ recherche de PHP_VERSION_ID :

grep -rn PHP_VERSION_ID *

ecrire/inc/flock.php:460: if (!defined(‘PHP_VERSION_ID’) || PHP_VERSION_ID < 50300) {
ecrire/inc/utils.php:2298: // PHP_VERSION_ID dispo depuis PHP 5.2.7
ecrire/inc/utils.php:2299: if (!defined(‘PHP_VERSION_ID’)) {
ecrire/inc/utils.php:2301: define(‘PHP_VERSION_ID’, ($version[0] * 10000 + $version[1] * 100 + $version[2]));
ecrire/inc/utils.php:2331: if (PHP_VERSION_ID<50300) {

les 2 tests dans in/utils ne sont plus nécessaires

dans inc/flock, c’est la fonction spip_clearstatcache qui n’est plus utile et qui pourrait être remplacée par la fonction native partout :

3bis/

grep -rn spip_clearstatcache *

ecrire/inc/filtres.php:5758: spip_clearstatcache(true, $filename); // eviter que PHP ne reserve le vieux timestamp
ecrire/inc/flock.php:459:function spip_clearstatcache($clear_realpath_cache = false, $filename = null) {
ecrire/inc/flock.php:474: spip_clearstatcache(true, $filepath);
plugins-dist/compresseur/inc/compresseur_concatener.php:139: spip_clearstatcache(true, $nom_tmp);
plugins-dist/compresseur/inc/compresseur_concatener.php:151: spip_clearstatcache(true, $nom);
plugins-dist/compresseur/inc/compresseur_minifier.php:300: spip_clearstatcache(true, $file);

4/ enfin, recherche de PHP_VERSION_ID :
grep -rn PHP_VERSION_ID *

ecrire/inc/flock.php:460: if (!defined(‘PHP_VERSION_ID’) || PHP_VERSION_ID < 50300) {
ecrire/inc/utils.php:2298: // PHP_VERSION_ID dispo depuis PHP 5.2.7
ecrire/inc/utils.php:2299: if (!defined(‘PHP_VERSION_ID’)) {
ecrire/inc/utils.php:2301: define(‘PHP_VERSION_ID’, ($version[0] * 10000 + $version[1] * 100 + $version[2]));
ecrire/inc/utils.php:2331: if (PHP_VERSION_ID<50300) {

idem que 3/

J’ai un patch tout prêt pour le core. Reste à savoir si le plugin compresseur (qui utilise spip_clearstatcache() supporterai l’appel natif dans une version antérieure à 3.2-dev

Des avis ?

Bisou,

2

Salut,

plutôt que de se raccrocher sur la version la plus basse possible, est-ce qu’il ne vaudrait pas mieux envisager de faire une version compatible que pour php >= 5.5 ? Cela permettrait de faire du nettoyage dans le code, n’est-ce pas ? Et peut-être d’envisager des pistes d’amélioration non explorées à cause de ce maintient de compatibilité ?

Pour rappel, PHP 5.4 est obsolète depuis l’année dernière http://php.net/supported-versions.php

Forcer à utiliser PHP 5.5 (ou 5.6) pour une prochaine version majeure est l’occasion d’inciter les utilisateurs à éviter les hébergeurs moisis qui ne maintiennent pas leur hébergement.

A y réfléchir, ce type de contrainte ne peut certainement se faire qu’avec un changement de version majeure (donc une 4.0)…

.Gilles

3

Hello,

Beaucoup d’hébergements tournent sur Debian stable qui met toujours un temps fou à suivre sur PHP (De mémoire c’est php 5.4).
Du coup, je pense qu’il serai plus judicieux de suivre l’évolution de Debian là dessus, histoire de ne pas forcer les hébergeurs à changer de distribution.

4

oups, j’ai oublié spip-dev :slight_smile:

5

Allez, poum ! c’est poussé ! à vos test ! :slight_smile:

S’il est décidé que finalement, c’est PHP5.4 le minimum, il sera possible de supprimer 2 tests supplémentaires :

ecrire/inc/filtres.php:4727: if (substr(phpversion(), 0, 5) == ‘5.4.0’ and !@gzinflate($env)) {

et

ecrire/inc/session.php:631: if (version_compare(phpversion(), ‘5.4.0’, ‘>=’)) {

6

C'est super cool, merci !

De manière général si on peut utiliser PHP_VERSION_ID pour les tests de version qui demeurent, je pense que ce serait le plus rapide (plutôt que les substr ou version_compare)

7

C’est fait. :wink:

8

James a écrit le 30/01/2016 14:48 :

Coucou,

Coucou,

dans le plugin safehtml, il me semble qu'il faut plutôt chercher une
alternative à cette lib.

Il pourrait y avoir cette alternative :
svn://zone.spip.org/spip-zone/_plugins_/htmlpurifier

9

Je me suis déjà exprimé sur cette lib (spip-zone, 4 janvier)

à mon avis, les filtres PHP pourraient largement faire l’affaire : http://php.net/manual/fr/book.filter.php

10

James a écrit le 31/01/2016 11:51 :

Je me suis déjà exprimé sur cette lib (spip-zone, 4 janvier)

Ici donc :
http://thread.gmane.org/gmane.comp.web.spip.zone/39563

11

Cet e-mail a été envoyé depuis un ordinateur protégé par Avast.
www.avast.com |

12

Je me suis déjà exprimé sur cette lib (spip-zone, 4 janvier)

Sur le fait que ça nécessite PHP 5.2, alors que SPIP était compatible 5.1.

Attention, il y a toujours une compatibilité assurée avec PHP 5.1 dans
SPIP. Elle concerne SPIP 3.0 et SPIP 3.1
La proposition initiale de remplacement de safehtml n'était pas vraiment
précise quant à la version cible de SPIP, d'où mes interventions.

Rien ne nous force à garder cette compatibilité pour la prochaine version
majeure.

Tu as remarqué que la prochaine version *mineure* (3.2) requiert désormais
PHP 5.3. Donc, a fortiori, la prochaine version *majeure* (4.0) ne
régressera pas sur cette contrainte.

Il reste que safe_html n'est plus maintenue, et qu'on peut laisser passer
des trous de sécurité à nous baser sur une librairie obsolète.

à mon avis, les filtres PHP pourraient largement faire l'affaire :
PHP: Filter - Manual

Pourquoi réinventer la roue si on peut s'appuyer sur une librairie solide

et maintenue séparément ?

Ce serait juste regrettable de passer à une version de PHP qui introduit
des filtres natifs (compilés, donc plus rapides, et solides, et maintenus)
et de s'appuyer sur une lib lente, avec une doc pas très à jour, et, à ce
que j'ai pu lire jusqu'à aujourd'hui, pas compatible avec PHP 5.6 et PHP 7.
:slight_smile:

J'ai regardé rapidement aujourd'hui où et comment était utilisé safehtml
dans SPIP. Comme l'a dit Fil sur la zone, son remplacement va demandé
beaucoup de tests, et pas qu'un simple test fonctionnel sur des raccourcis
typo... ce remplacement va changer beaucoup de choses dans le code si on
veut que ce soit propre. Alors je me dis : autant y gagner quelque chose,
non ?

C'est n'est que mon avis, mais je pense que HtmlPurifier n'est pas une
bonne alternative. Maintenant, je n'ai pas l'intention de faire un blocage
là-dessus.

13

Cet e-mail a été envoyé depuis un ordinateur protégé par Avast.
www.avast.com |