Avec le passage d'un serveur de production sous Ubuntu 10.04, je me suis retrouvé bien embêté en constatant que la distribution embarquait par défaut PHP en version 5.3.2.
Je me suis donc retrouvé contraint de remplacer certains Dotclear 2.1.6 par des versions 2.2-alpha[1], mais également de devoir remettre le nez dans le code de quelques uns de mes plugins.
Comme le but principal était avant tout d'éviter aux installations de couiner
, je me suis dans un premier temps contenté d'assurer une écriture (à peu près) saine
pour la compatibilité PHP 5.3.x. Tout cela étant bien suffisant - en apparence - sur de l'existant et une configuration PHP configurée pour de la production[2].
Dans de telles conditions, quelques détails non négligeables m'ont échappé. Tels que la disparition du plugin metadata[3] et le nouveau système de gestion des préférences. Si bien que lorsque j'ai fait parvenir une version modifiée et supposée fonctionnelle pour du 2.2-alpha à l'ami mirovinben, rien n'a fonctionné comme prévu sur une installation Dotclear 2.2-alpha fraîche.
C'est donc pour cette raison que je mets aujourd'hui à disposition une version 1.1-alpha1 du plugin Related, bien brute de décoffrage, exclusivement destinée à du Dotclear 2.2-x, sans la moindre nouveauté hormis le fait que cette version semble fonctionner correctement.
Si ça peut dépanner quelques personnes, ce sera toujours ça de pris.
Commentaires
#1
mirovinben
dimanche 23 mai 2010, 07:32
"iou no ouate ? aïe ame hapi."
Non seulement "cette version semble fonctionner correctement" mais elle fonctionne correctement... il me semble.
#2
Franck
samedi 12 juin 2010, 08:58
Dans le cas ou le plugin sitemaps est modifié pour tenir compte du nouveau système de settings, il faudrait remplacer les lignes
129à132du_prepend.phppar :if ($core->blog->settings->sitemaps->sitemaps_related_url){$freq = $sitemaps->getFrequency($core->blog->settings->sitemaps->sitemaps_related_fq);$prio = $sitemaps->getPriority($core->blog->settings->sitemaps->sitemaps_related_pr);Non ?
#3
Franck
samedi 12 juin 2010, 09:01
Ah et puis ligne
38de_public.phpremplacer :'$core->tpl->setPath($core->blog->settings->related_files_path);'."\n".par
'$core->tpl->setPath($core->blog->settings->related->related_files_path);'."\n".Aussi, non ?
#4
Pep
samedi 12 juin 2010, 12:01
Si tu le dis, c'est que c'est fort possible, oui. :)
#5
Franck
samedi 12 juin 2010, 13:10
En tout cas ça fonctionne pas moins mal :-)
#6
Pep
samedi 12 juin 2010, 13:20
Elle est pourrie à ce point-là, cette version ?
#7
Franck
samedi 12 juin 2010, 14:30
Pas du tout du tout. Elle fonctionne très bien avec ces deux modifs :-)
#8
Dsls
lundi 14 juin 2010, 16:20
Objection, m'sieur !
C'est quoi ce behavior coreBlogGetPosts dans le _public.php du plugin, qui étend systématiquement getPosts, et joue avec les $rs->core->auth->check ???
A priori, ça met un souk aléatoire dans d'autres plugins (gallery, notamment). Tu pourrais déplacer ça dans _admin.php ?
#9
Pep
lundi 14 juin 2010, 16:26
Non.
#10
Dsls
lundi 14 juin 2010, 17:09
Au temps pour moi, le bug n'était pas là, mais il y a bel et bien un dommage collatéral dans templateBeforeBlock. func_get_args retourne les arguments par référence. Faire un array_unshift dessus empêche ceux qui ont aussi redéfini templateBeforeBlock de récupérer correctement les paramètres, s'ils passent après related ...
#11
Dsls
lundi 14 juin 2010, 17:10
(oui, je sais, PHP sainul, tu prêches un convaincu :)
#12
Pep
lundi 14 juin 2010, 18:04
Pas que.
Il y a aussi le système des post_types qui est bancal de naissance dans Dotclear 2.
Sans parler que Related a sans doute été l'un des premiers plugins à être bâti là-dessus et que le gros de son ossature n'a jamais été revu.
J'ai entamé quelques opérations pour un lifting, on verra bien ce que ça donnera.
#13
Dsls
lundi 14 juin 2010, 19:05
A noter, comme alternative à func_get_args, la possibilité de définir directement
templateBeforeBlock($core,$b,$attr) :)
#14
Pep
lundi 14 juin 2010, 20:02
Et d'où func_get_args retournerait un tableau contenant des références ?
#15
Dsls
lundi 14 juin 2010, 20:33
Je pensais que func_get_args retournait une référence vers le tableau des arguments, mais tu me mets un doute, là ...
#16
Dsls
lundi 14 juin 2010, 20:36
Ce qui est louche, chez ovh par exemple : avec array_shift, j'ai une jolie erreur 500 sur une galerie, et elle disparaît en enlevant le array_shift et en incrémentant les index de $args dans related...
#17
Pep
mardi 15 juin 2010, 00:42
Ils ne seraient pas du genre à patcher leur version PHP chez OVH par hasard ?
Parce que d'aussi loin que je me souvienne func_get_args retourne simplement un tableau par copie des arguments, et comme l'array_shift qui suit s'attaque à une variable de la portée locale, j'y vais sans le moindre doute (sauf quand tu viens sournoisement me le semer, hein :-p)...
#18
Pep
mardi 15 juin 2010, 00:48
Et je précise, pour info, que dans le doute, j'ai fait un script de test avec 3 fonctions callbacks reprenant la séquence func_get_args / array_shift, appelées dans une boucle depuis une tierce fonction qui leur transmet une séquence d'arguments elle-aussi captée par un func_get_args (oui, oui, l'équivalent de dcCore::callBehavior, en quelque sorte).
Rien ne bronche et tout se comporte comme je l'ai toujours pensé.
(Bon, j'avoue, je me suis contenté de vulgaires var_dump pour tracer, vu que je n'ai pas xdebug sur cette installation de PHP).
#19
Dsls
mardi 15 juin 2010, 08:23
Bon... j'ai investigué un poil. Le problème disparaît quand on passe en php 5.3. Il subsiste toutefois en php 5.2. Je fais des tests plus poussés ce soir...
#20
Dsls
mercredi 16 juin 2010, 09:57
Bingo, c'est en fait un problème de PCRE qui bouffe toute la stack PHP. Le nouveau moteur de templates n'y est pas pour rien...