Le 02/08/2013 08:00, Franck Paul a écrit :
Le 2 août 2013 02:18, pascal chevrel <[email protected]
<mailto:[email protected]>> a écrit :
J'ai peut être trouvé quelque chose de mon modeste niveau pour aider
au code de dotclear. J'ai ouvert un premier ticket et fait une Pull
Request
(https://bitbucket.org/__dotclear/dotclear/pull-__request/38/ticket-1461-__replace-all-calls-to/diff
<https://bitbucket.org/dotclear/dotclear/pull-request/38/ticket-1461-replace-all-calls-to/diff>)
en espérant avoir tout bien fait comme il faut :)
Pour les PR sur Clearbricks, ça serait plus facile de les faire sur le
dépôt Clearbricks de Bitbucket je pense.
Là ma PR ne touche pas à clearbricks, elle remplace les appels à la
méthode clearbricks dans le code Dotclear par des appels à la fonction
native PHP.
Je regardais un peu les fonctions de clearbricks et j'ai trouvé
cette méthode qui réinvente la roue puisqu'il existe une même
fonction native (et pas récente, je vous parle de PHP 4 là ;) ) qui
fait exactement la même chose.
Je crois que c'était, à l'époque, pour pallier quelques restrictions
d'hébergeurs qui ne voulaient pas qu'on fouille trop dans leur filesystems.
Je vais tester sur OVH/Fre/Online où j'ai des comptes pour voir, mais
même dans ce cas, je pense qu'il faudrait patcher Clearbricks cette fois
ci pour qu'il utilise la fonction native si elle est activée et sa
réimplémentation autrement.
J'ai ensuite regardé une autre méthode ( path:real() ), et ça fait
exactement la même chose que la fonction realpath() native de php
depuis 5.0. Au passage j'ai fait un benchmark et la méthode
clearbricks est 20 fois plus lente que la méthode native.
Gloups :-)
oui, ya plein de regex dans cette méthode et les regex c'est pas
seulement illisible, c'est cher :)
Juste dans lib.files.php, je vois plusieurs autres méthodes qui me
semblent bien exister en PHP natif, même si on se cantonne à 5.2
Il y a probablement pas mal de choses à revoir dans CB si, en effet, on
limite la version de PHP à la 5.2 (tant pis pour Free et ses pages
perso), voire tant qu'on y est à la 5.3 puisque la 5.2 n'est plus
supportée (d'ailleurs la 5.3 ne va pas l'être encore longtemps).
Encore 11 mois de support officiel (patchs de sécu) pour la 5.3, moi la
5.3 je suis pour, ne serait-ce que pour pouvoir utiliser __DIR__ au lieu
de dirname(__FILE__) dans les includes :D (sinon, les fonctions
anonnymes, closures et les variables fonctions qui vont avec, c'est cool
aussi)
Avant que je fasse d'autres pull requests pour remplacer ces
méthodes qui réinventent la roue, sont probablement moins fiables
que les fonctions natives et sont plus lentes, est-ce qu'il y a une
bonne raison qui m'a échappée pour qu'elles aient été créées (en
dehors de la dette technique bien sûr) ?
Il faut quoi qu'il en soit qu'on décide d'une version minimale de PHP à
adopter — faire une revue des gros hébergeurs et leurs versions de PHP ?
— et revoir CB en conséquence.
Note que ma première PR est pour remplacer l'utilisation d'une fonction
clearBricks pour son équivalent en natif qui existait déjà en PHP 4.0 et
que certaines fonctions sont l'équivalent de fonctions qui ont été
ajoutées en 5.0 ou 5.1 qui est déjà le minimum actuel des pages perso de
free, donc pour celles là je pense qu'on peut envisager d'utiliser des
fonctions natives, ça fait moins de dépendances envers clearbricks, je
pense qu'il ne faut utiliser les méthodes clearbricks que lorsque ça
apporte des solutions qui ne sont pas déjà dans le langage.
A+
Pascal
--
Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
