Juste pour partager une petite expérience d’il y a quelques minutes.
En SADant un IRCien je me suis rendu compte qu’il était en PHP 7.3.9.
Il avait des erreurs PHP (create_function) en affichant la page de config du Couteau Suisse (on ne rit pas!). Mais son problème était ailleurs car il n’avait pas les les indicateurs de mise à jour dans la page des plugins de l’espace privé.
Je lui ai donc demandé de descendre le PHP en 7.2, pas d’amélioration et en 7.1 et là ça a fonctionné. Plus d’erreurs PHP et possibilité de faire les mises à jour.
Si on prend l’article de sortie de la 3.2 on voit qu’elle est compatible 7.1.
Si on prend l’article https://www.spip.net/fr_article4351.html de configuration minimale de SPIP 3.2 on voit une compatibilité PHP 7.2 annoncée.
C’est surement vrai sauf que je me demande si on omet pas les plugins-dist dans cette affirmation car les erreurs PHP concernaient à la fois du spip core et des plugins dist voire le CS.
Est-on sur de la compatibilité PHP 7.2 du groupe SPIP+plugins-dist ?
Ensuite, si un plugin annonce une compatibilité avec SPIP 3.2 il devrait aussi être compatible avec PHP 7.2 car sinon ça risque de poser un problème.
Aujourd’hui rien ne permet de vérifier cela sauf à inclure dans le XML dudit plugin la balise PHP.
Alors pour SPIP 3.2 + plugins-dist, avec cette toute nouvelle version, je pense qu’il y a plus aucune erreur à ma connaissance (pas de warnings disgracieux) ;
Il reste cependant des deprecated avec PHP 7.3 par contre en 3.2.
Ils ont été tous soigneusement corrigés (à ma connaissance) en SPIP 3.3-dev + plugins-dist.
De même l’essentiel des deprecated php 7.4 sont corrigées en SPIP 3.3-dev + plugins-dist
Possible d’en avoir un peu plus ?
Parce que j’ai l’impression que ce plugin est un peu décrié alors que je trouve son principe intéressant : une boite à outils où on va piocher les fonctionnalités qui nous intéressent plutôt que d’avoir une dizaine de plugins (voire plus) pour avoir la même chose.
une boite à outils où on va piocher les fonctionnalités qui nous
intéressent
C'est le principe même du système de plugin. On a X plugins, et on
pioche des fonctionnalités dedans qui nous intéressent. Alors avoir un
système de plugins à l'intérieur d'un système de plugin, ça n'a aucun
sens et aucun intérêt pour la compréhension de tout le monde. Un plugin,
une fonctionnalité, basta.
plutôt que d'avoir une dizaine de plugins (voire plus) pour
avoir la même chose.
C'est l'inverse dans SPIP, par rapport à la majorité des autres CMS, on
essaye toujours de n'avoir à peu près aucun doublon et qu'une
fonctionnalité ne soit gérée que par un plugin (un seul plugin pour
composer des menus, un seul plugin pour faire des points géolocalisés,
etc). Lorsqu'il y a doublon, c'est normalement vraiment pour une raison
importante, et c'est très rare. Donc cette phrase est plutôt fausse.
il me semble qu'un travail de fond pourrais être lancé (je sais j'ai cas go go go) , la résistance est qu'un dev préfère souvent partir de zéro, c'est plus facile
je pense qu'a l'avenir (malheureusement) SPIP sera comme WP (pour pas le cité)
un socle avec une multitude de plugin et même des doublons
il me semble qu’un travail de fond pourrais être lancé (je sais j’ai cas go go go) , la résistance est qu’un dev préfère souvent partir de zéro, c’est plus facile
je pense qu’a l’avenir (malheureusement) SPIP sera comme WP (pour pas le cité)
un socle avec une multitude de plugin et même des doublons
En fait, dans ce genre de légendes urbaines penser ne suffit pas.
Il est mieux de démontrer.
En l’occurrence, si on prend la compatibilité SPIP 3.2, je ne suis pas sur qu’il y ait beaucoup de doublons.
Mais la liste est disponible sur Plugins SPIP par exemple, il est donc possible de faire la vérification pour ceux que ça intéresse…
Après comme l’a dit Rasta, il est essentiel de penser plugin = fonctionnalité de façon à créer un écosystème cohérent.
L’approche du Couteau Suisse est une erreur selon moi comme d’ailleurs tous les plugins fourre-tout dont on arrive plus à se débarrasser même quand on a externalisé certaines fonctions.
Après l’époque du troll CS et des blagoulames est révolu alors on va en rester là.
Euh justement la page en question est totalement vide et ne démontre
rien, ne donne aucun exemple probant.
Donc non, il n'y a quasiment aucun doublon dans nos plugins SPIP (je ne
dis pas "pas du tout" mais c'est hyper rare et pas pour les trucs les
plus gros/importants, qui sont tous maintenus en commun de manière unique).
Par contre je sens que ça peut vite de nouveau augmenter si on se met à
développer chacun dans notre coin sur des dépôts privées (git ou autre
c'est pas la technique le problème) au lieu de dépôts communs
communautaires et démocratiques. Untel qui va faire son plugin sur
monorga/plugin1, une autre sur monnom/plugin2, etc. Beurk beurk. #troll
? Non, réalisme du développement en mode "libéral".
Par contre je sens que ça peut vite de nouveau augmenter si on se met à
développer chacun dans notre coin sur des dépôts privées (git ou autre
c'est pas la technique le problème) au lieu de dépôts communs
communautaires et démocratiques. Untel qui va faire son plugin sur
monorga/plugin1, une autre sur monnom/plugin2, etc. Beurk beurk. #troll
? Non, réalisme du développement en mode "libéral".
Pour éclaircir un peu le tableau, sans pour autant me faire l'avocat du diable, je pense que ça n'est pas si problématique que ce que tu penses tant qu'on *communique* sur ce qu'on fait/crée.
Le type de situation problématique que tu cites a déjà eu lieu quand quelqu'un a souhaité un jour partager un plugin tout neuf pour répondre à un besoin, alors qu'un plugin existait déjà pour ça sur la zone. Mais, comme le plugin existant n'était pas documenté (la doc est aussi une forme de communication), cette personne était passée à côté. Je ne tente pas de te convaincre, je crois qu'on est d'accord sur ce point
Juste pour partager une petite expérience d'il y a quelques minutes.
En SADant un IRCien je me suis rendu compte qu'il était en PHP 7.3.9.
Il avait des erreurs PHP (create_function) en affichant la page de config du Couteau Suisse (on ne rit pas!). Mais son problème était ailleurs car il n'avait pas les les indicateurs de mise à jour dans la page des plugins de l'espace privé.
Je lui ai donc demandé de descendre le PHP en 7.2, pas d'amélioration et en 7.1 et là ça a fonctionné. Plus d'erreurs PHP et possibilité de faire les mises à jour.
Chag n'avait vérifié que superficiellement avec PHP 7.2.
Là il vient de passer de nouveau sur irc
après avoir testé de manière plus rigoureuse :
il n'y a pas de pb avec php 7.2.22 = les indicateurs de mises à jours de plugins s'affichent bien.
Il confirme par contre qu'ils ne s'affichent pas en 7.3
