Bonjour,
Nous sommes donc partis pour versionner SPIP 4.0 à la place de SPIP 3.3 la prochaine version.
Nous sommes quelques un·es à proposer qu'on retire des plugins-dist certains plugins (*ils seront toujours disponibles via la gestion des plugins* pour les réactiver — ça ne veut pas dire qu'ils ne seront plus maintenus par la communauté)
Déjà retiré
hello,
personnellement ça fait quelques années que je retire « pétitions », « brèves » et « organiseur » de plugins-dist pour les mettre dans le dossier plugins.
Donc ça m’arrange et je trouve très bien pour ceux-là.
Pour « squelettes par rubrique » pas d’objection mais le problème est peut-être plus la cohérence avec la doc de SPIP…
Pour « vertebres » je suis pour aussi, « jquery ui » ok c’est fait, mais pour « compagnon » et « aide » je ne trouve pas d’argument pour les retirer : à mon avis il faut les garder !
Bonjour,
J'ai un doute sur le retrait de ces deux plugins d'aide :
- Perso le compagnon m'agace et s'il y avait un bouton pour le désactiver entièrement par auteur j'aimerais bien... Le supprimer entièrement ? Est-ce que ça ne donne pas tout de même une (petite) aide aux gens qui découvrent SPIP ?
- Aide : livrer SPIP sans aide pour les rédacteurs c'est un peu dommage. Mais c'est vrai qu'aujourd'hui c'est plutôt obsolète, il y a peu de choses utilisables. Est-ce que ce serait imaginable que le plugin aille chercher une aide uniquement rédacteur basée sur des articles de spip.net qu'on identifierait par exemple avec un mot clé SPIP_4.0 ? ou une sélection d'articles listée quelque part ? L'idée serait d'en faire une aide vraiment utile avec les "trucs et astuces" utiles au rédacteur
Jacques
Hello,
JQuery UI
Déjà avant tout soulignons que nous avons déjà enlevé « jquery-ui » des
plugins-dist car cette librairie javascript n’est plus maintenue, et
nous avons ajouté les alternatives JS (un « picker » de date et un
« sortable ») dans le core pour les utilisations principales qu’il y avait.
Ah c’est une bonne raison, par contre, ce n’est pas la seule dans ce cas, j’y reviendrai plus loin.
Vertèbres
Un outil de visualisation des tables SQL de SPIP. Ce plugin n’a
pratiquement pas bougé depuis sa sortie. Il est avantageusement
remplaçable par le plugin « Adminer ».
+1
Organiseur
Les plugins comme Agenda ou Manuel du site sont parfois selon le besoin
aussi une alternative.
Ou Pense-bêtes. Donc +1
Brèves
+2
Squelettes par rubriques
Ça permet de faire des squelettes tel que « article=3.html ». Gourmands en
performance pour retrouver ces squelettes, on préfère utiliser
maintenant d’autres méthodes, notamment avec le plugin Compositions.
+1
Pétitions
+1, c’est rare d’utilisation donc pas forcément nécessaire en Dist.
Compagnon ?
Non je pense qu’il faut le garder.
Aide ?
Devrait être indispensable mais est-il vraiment consulté dans l’état.
Néanmoins, psychologiquement je dirais qu’il faudrait le garder.
Et donc pour la fin je reviens sur TextWheel et sa librairie sfyaml ultra moisie en m’inscrustant dans le fil de Mathieu qui a surement plus de chance d’être répondu que le mien…
Pourquoi la conserver ainsi ?
Donc deux solutions, on prend la branche JSON que j’ai proposé et qui assure la compatibilité voire le fallback avec l’existant YAML si on trouvait des problèmes, soit on ajoute le plugin YAML dans le Core puisque celui-ci nécessite ce format en le mettant à jour de ses librairies.
Maintenant, franchement je ne vois pas pourquoi le JSON poserait des problèmes à partir du moment où obtient les mêmes tableaux de wheels en décodant le YAML ou le JSON.
À débattre
Bonjour,
J'ai un doute sur le retrait de ces deux plugins d'aide :
- Perso le compagnon m'agace et s'il y avait un bouton pour le désactiver entièrement par auteur j'aimerais bien...
C'est une piste à étudier pour Compagnon, probablement pas trop complexe à mettre en place. Mais faut trouver l'UI qui va avec.
[...]
- Aide : livrer SPIP sans aide pour les rédacteurs c'est un peu dommage. Mais c'est vrai qu'aujourd'hui c'est plutôt obsolète, il y a peu de choses utilisables. Est-ce que ce serait imaginable que le plugin aille chercher une aide uniquement rédacteur basée sur des articles de spip.net qu'on identifierait par exemple avec un mot clé SPIP_4.0 ? ou une sélection d'articles listée quelque part ? L'idée serait d'en faire une aide vraiment utile avec les "trucs et astuces" utiles au rédacteur
Alors… Je n'ai aucune idée de comment ça pourrait se faire (sans douleur, énergie, temps disponible). Mais jusqu'à présent tout le monde a renoncé parce que c'était trop compliqué (conserver l'aide pour les anciens SPIP, les traductions, faire des aides adaptées à la version...) Tellement que bah… ça a fait statut quo — on touche rien, on attend la providence.
Pour ma part, si le lien "Aide" du bandeau amenait par exemple à un site externe, ça pourrait peut être convenir : et ça permettrait d'enlever tous (ou partie) des [?] assez disgracieux (en tout cas sur la page article, il y en a beaucoup trop je pense)
Mais même pour un site externe (tel que rediger.spip.net par exemple) bah il faut du temps, de l'énergie, de la volonté pour mettre ça en place.
Tout n'est pas mauvais dedans pourtant : certaines choses n'ont pas changé (l'aide sur la date de publication par exemple). Mais pour d'autres éléments (je parle même pas des captures d'écran) on trouve : «la page de « Configuration précise » ... choix interface simplifiée / interface complète, ... » ou encore le «cookie de correspondance» (enlevé aussi)... C'est assez trompeur quoi.
MM.
Pour l'instant, un des arguments répondu, était que les wheels font parfois de nombreuses choses compliquées, dans un ordre précis, et que le YAML permet de faire des commentaires entre chaque morceau, ce qui n'est pas le cas du JSON.
https://git.spip.net/spip/textwheel/src/branch/master/wheels/spip/spip-listes.yaml#L31
Après les wheels… c'est un système qui me parait obsolète de nos jours, où il y a des vrais parseurs de grammaire désormais performants (avec PHP 7, PHP 8), et on devrait utiliser ça dans le futur plutôt que des regexs.
Concrètement les wheels actuelles, donc qui ont des commentaires dans le YAML, ces fichiers n'ont pas bougé depuis… 10 ans… 7 ans… suivant les fichiers.
Du coup c'est peut-être pas grave de ne plus avoir ces commentaires. En tout cas placés à cet endroit.
Bonjour,
Un retour d'un utilisateur, pour soutenir la tendance : plugin "Aide" à conserver !
(voire monter un plugin générique :Aide + Manuel + Compagnon + ... formule intégrée ?)
Mais peut-etre peut-on aussi intégrer l'accès au document Spip_redacteur d'Erational
(d'ailleurs déjà refondu en .ODT et mis-à-jour/en-ligne pour SPIP 3.2 :
https://www.spippourlesnuls.fr/vous-accueillir/guide-du-redacteur-spip-3-2/ )
avec un simple menu d'appel par page en boite_latérale (ou en pop-up pour smartphones) ?
Dès que l'interface SPIP 3.3/4. sera finalisée, j'en ferai la version ad'hoc
ainsi sans doute qu'une extension pour les logos et images,
mais là j'aurai besoin de relecteurs pour me signaler les oublis & inconnus 
;-(
Hello,
Maintenant, franchement je ne vois pas pourquoi le JSON poserait des problèmes à partir du moment où obtient les mêmes tableaux de wheels en décodant le YAML ou le JSON.
Pour l’instant, un des arguments répondu, était que les wheels font parfois de nombreuses choses compliquées, dans un ordre précis, et que le YAML permet de faire des commentaires entre chaque morceau, ce qui n’est pas le cas du JSON.
https://git.spip.net/spip/textwheel/src/branch/master/wheels/spip/spip-listes.yaml#L31Après les wheels… c’est un système qui me parait obsolète de nos jours, où il y a des vrais parseurs de grammaire désormais performants (avec PHP 7, PHP 8), et on devrait utiliser ça dans le futur plutôt que des regexs.
Concrètement les wheels actuelles, donc qui ont des commentaires dans le YAML, ces fichiers n’ont pas bougé depuis… 10 ans… 7 ans… suivant les fichiers.
Du coup c’est peut-être pas grave de ne plus avoir ces commentaires. En tout cas placés à cet endroit.
Oui cy_altern a remonté le même sujet.
Après il faut relativiser le nombre de commentaires.
Mais comme le propose cy_altern on peut insérer ces commentaires dans un index « _commentaires: ».
Moi j’avais proposé un readme.
Donc je pense que ça doit pouvoir se gérer facilement.
Après oui c’est obsolète les wheels si on se positionne pour intégrer markdown mais c’est une première étape de nettoyage.
Je ne suis pas sur qu’on change aussi facilement de langage.
Je crois qu'on est à peu près tou⋅tes d'accord pour dire que dans l'absolu, avoir de l'aide c'est bien *mais* que énormément de choses sont obsolètes (en contenu et en affichage, capture).
La question est donc : est-ce qu'il ne vaut pas mieux aucune aide, qu'une aide obsolète ?
Pour l'instant j'ai plutôt tendance à penser que c'est mieux sans.
Et peut-être qu'aucune aide visible pendant un moment nous poussera mieux à nous saisir du sujet, possiblement en imaginant ensemble un nouveau système plus pérenne, en prenant le temps de le concevoir de 0. Sans essayer de réparer le système actuel qui ne va pas du tout (le fait d'avoir la même aide quelque soit la version notamment).
Pour faire cours
- oui pour ceux "pas d'objections", mais il faudra faire un gros travaille sur la doc
- à debattre
a. Pour l'aide, je ne sais pas, je ne l'utilise pas, mais si j'ai bien compris le problème principal se situe dans la manière de maintenir cette aide ?
b. Pour le compagnon, je dirais à garder, mais est-ce qu'on ne pourrait pas avoir quelque chose qui detecte la première connexion à l'espace privé, et nous demande "Connaissez vous spip" > si oui desactive le compagnon
C. pour les wheels suite aux remarques d'Eric
a. OK pour passage en JSON avec les ajustements de cy_altern
b. Reflechissions à plus long terme sur la syntaxe et les outils, mais le but c'est de sortir une 4.0, pas de refaire SPIP (par exemple Markdown, oui pq pas, mais il a aussi des limite !)
c. Surtout si on sort les wheels maintenant, j'ai peur de choses qu'on aurait pas pensé qui existe que dans les wheels mais pas dans le core de SPIP
Un peu pareil : Ok pour tout supprimer mais garder le compagnon et l'aide
qui, tout insuffisants voire imparfaits qu'ils sont,
sont tout de même une utile ligne guide pour qui débarque.
Ou si ce n'est pas l'aide actuelle, un équivalent modernisé...
sous la forme d'un compagnon multiplié, escamotable mais persistant ?
JL
Pareil pour moi.
En insistant sur le fait de bien communiquer sur ces retraits.
Notamment « squelettes par rubrique », sur lequel pas mal de vieux squelettes doivent se reposer (mais en soi ça semble préférable de plus en faire une solution officielle/recommandée en le distribuant par défaut).
Pour ma part, si le lien "Aide" du bandeau amenait par exemple à un site externe, ça pourrait peut être convenir : et ça permettrait d'enlever tous (ou partie) des [?] assez disgracieux (en tout cas sur la page article, il y en a beaucoup trop je pense)
OK, ce serait sans doute le plus simple à mettre en place
Mais même pour un site externe (tel que rediger.spip.net par exemple) bah il faut du temps, de l'énergie, de la volonté pour mettre ça en place.
Est-ce qu'il ne serait pas possible de faire ça à l'économie, en ciblant uniquement aide rédacteur. Il existe déjà beaucoup de choses. Serait-il possible d'alimenter une nouvelle rubrique sur spip.net en se servant d'un plugin comme polyhierarchie ? Du coup on mettrait dans cette nouvelle rubrique tous les articles qui touchent la rédaction en 4.0.
Tout n'est pas mauvais dedans pourtant : certaines choses n'ont pas changé (l'aide sur la date de publication par exemple). Mais pour d'autres éléments (je parle même pas des captures d'écran) on trouve : «la page de « Configuration précise » ... choix interface simplifiée / interface complète, ... » ou encore le «cookie de correspondance» (enlevé aussi)... C'est assez trompeur quoi.
Il ne resterait "plus qu'à" faire le tri des patates, reprendre les articles où des choses obsolètes sont mélangées...
Jacques
Matthieu Marcillaud a écrit le 29/04/2021 à 17:07 :
Bonjour,
Bonjour
+1 sur tout sauf :
Compagnon ?
---------Là c'est plus subjectif et plus fortement sujet à discussion.
Le
compagnon offre des infos aux nouveaux visiteurs. Il était fait pour avoir un accueil plus agréable lors des premières installations.
Est-ce que le rendre inactif pour les webmestres ne serait pas une solution simple de ne plus le voir pour "nous", mais qu'il soit encore disponible pour les autres ?
Aide ?
----Là encore plutôt sujet à discussion. Ce plugin ajoute les icones [?] à différents endroits de l'espace privé. Mais cette aide n'est plus à jour et est la même pour toutes les versions de SPIP. Quand elle n'est pas obsolète.
1) Il faut la garder pour le côté rassurant
2) quand j'ai besoin de la syntaxe pour les ancres ou pour les notes de bas de page utilisées plusieurs fois ou nommées (genre explicitement * au lieu d'un numéro), j'utilise l'aide de SPIP
Matthieu Marcillaud a écrit le 29/04/2021 à 17:07 :
Bonjour,
Re bonjour,
Squelettes par rubriques
------------------------Ça permet de faire des squelettes tel que "article=3.html". Gourmands en performance pour retrouver ces squelettes, on préfère utiliser maintenant d'autres méthodes, notamment avec le plugin Compositions.
Ça pourrait être utile d'avoir une page utilitaire qui scannerait les racines du path pour voir si des fichiers correspondent à cette utilisation pour le signaler ?
Idem pour scanner les squelettes à la recherche de (BREVES) et autres ?
+1 pour sortir tous les plugins cités, ils seront toujours ré-installables pour les nostalgiques 
Oui, n'empêche que les squelettes articles=xx.html ou articles-xx.html, on peut dire ce qu'on veut, ça rend bien souvent service.
Et quand c'est natif, ...c'est simple à mettre en œuvre (!!!) et pour des débutants, c'est une technique vraiment accessible.
M'enfin, bon, mon brave monsieur, tout change, faut vivre avec son temps !
De toute façon, 10 000 mercis pour tout ce que vous faites et ce superbe SPIP ;-))
J'avoue que c'est le seul sur lequel j'ai un doute...
Il risque de péter des vieux squelettes, et comme tu dis c'est une technique utile.
Mais bon, y'a déjà des choses qui cassent, et le plugin compositions est quand même vraiment fait pour ça.
Ce sera précisé dans les notes de mises à jour.
j'ai tendance à dire que oui c'est pratique pour du dev rapide... mais ca coince vite les gens sur des choses pas idéales.
je connais des associations qui aimeraient rendre generique leur squelettes mais qui sont coinciés pour avoir pris ce biais d'écrire en dur un numéro de rubrique...
Re,