Après avoir pas mal secoué les vis et les boulons pour l’Auberge, je pense que j’en suis à déterminer ce que je vais bien pouvoir entreprendre pour la suite du développement de la 2.17.
Probablement :
- Refonte de la CSS de l’admin pour mettre à plat la gestion des couleurs (pour l’instant sous forme de variables SASS)
- J’ai vu des trucs bizarres côté gestion des droits, mais c’est un gros morceau surtout qu’il faut assurer la compatibilité ascendante
- Toujours envie de jouer avec Javascript, histoire de moderniser ce que je peux, et faire sans jQuery autant que faire se peut
Et puis les questions :
- Est-ce qu’on abandonne le support de PHP 5 pour requérir a minima PHP 7 ? je mettrais bien en place du typage un peu partout
- On a atteint les limites du moteur de wiki, est-ce qu’il faut envisager un changement plus radical comme une réécriture du moteur ?
- Idem côté gestionnaire de média, mais je pense que je n’y toucherai pas de sitôt
- J’envisage de mettre en place une gestion de dépôts alternatifs pour les plugins et les thèmes
- Une API Rest ? Et si oui, avec quelle portée ?
En fait le problème majeur c’est qu’avec l’Auberge, j’ai repris goût au travail en commun et repasser en mode solo n’est guère séduisant, surtout que les projets annexes qui avaient semblé montrer quelques signes de reprises — comme la refonte du site Dotclear — ont retrouvé un encéphalogramme complètement plat.
1 De Philippe -
Alors dans l’ordre :
Là je t’en ai mis une tartine, mais c’est encore une fois toi le patron :)
2 De biou -
Je veux bien filer un coup de main sur l’accessibilité. Je sais que c’est déjà vachement bien et chapeau à celleux qui ont bossé dessus, mais s’il y a des petites choses à améliorer, je veux bien m’en charger.
Sur les fonctionnalités, je ne suis pas le bon interlocuteur. Je pense toujours qu’il y a trop de fonctionnalités et qu’il faudrait supprimer des trucs (ex: doit-on maintenir la syntaxe wiki là où plein d’autres cms ne supportent que des variantes de markdown?, est-ce que les rétroliens pourraient être sortis dans un plugin? pourquoi deux plugins ckEditor? doit-on garder le thème blowup qui est assez daté visuellement? doit-on garder le support xml-rpc, basé sur une librairie pas mise à jour depuis 2003 (incutio)? doit-on garder le support nntp dans clearbricks?)
Je pense que ça ne sert plus à rien de supporter PHP5 parce que 5.6 est end of life depuis le 1er janvier 2019 https://www.php.net/supported-versi… et c’est donc un problème de sécurité de faire tourner un site sur PHP5. De plus PHP8 arrive en fin d’année.
Pour l’API Rest, ça peut être intéressant. J’ai joué récemment avec le XML-RPC et franchement ce n’était pas super pratique. Au niveau de la portée, je vois 2-3 trucs:
Il faut sûrement commencer petit et attaquer là où ça peut être directement utile. Genre l’admin?
Sur la CSS de l’admin, est-ce qu’il ne serait pas possible d’augmenter un peu la taille de la font par défaut?
Comme dit Philippe, c’est toi le boss, et les conseilleurs ne sont pas les payeurs…
3 De Bernard -
vieuxthème blowup, car même si “daté”, il reste une possibilité de construire son propre thème. Peut-être au contraire l’améliorer - par ex en lui permettant de se baser sur des aorakit ? - mébon, chais si c’est possible…Quant à
, ben c’est peut-être pas complétement “mort”… Tant qu’il y a de la vie…A suivre, donc, puisque, capitaine, le bateau
Il navigue [et] en pèr’ peinard
Sur la grand-mare des canards
4 De Franck -
Je réponds dans le désordre et incomplètement, j’ajouterai des commentaires au fur et à mesure :
Philippe pour les couleurs, c’est un peu l’idée, pouvoir ouvrir à des thèmes supplémentaires ; mais avant ça il faut remettre à plat la CSS et basculer sur des couleurs via des variables CSS. Ça va demander un peu de temps.
Pour les dépôts j’avais en tête l’idée de pouvoir dire : « Mon plugin/thème aura ses mises à jour disponible sur tel dépôt Github/Gitea/… via une archive zip (de même format que celle dispo sur DA) »
Biou j’avais déjà en tête de te piller ce que tu avais fait sur le plugin commentsWikibar pour l’appliquer à dcLegacyEditor (autant reprendre du code bien fait et qui rend les choses plus accessibles) ;-)
Je vais garder la syntaxe wiki, c’est celle que j’utilise pour 99,9% de mes billets. Et puis elle a deux/trois trucs super pratiques que n’a pas MD. Par exemple je peux inclure du wiki MD dedans (et pas l’inverse), par ailleurs la gestion des notes de bas de page est top avec le wiki Dotclear.
Concernant les (vieux) thèmes, je suis d’accord, on pourrait élaguer et peut-être en ajouter un ou deux neufs ou a minima récents.
XML-RPC, ça pourrait sauter, en effet, surtout si on développe une API qui fait le job !
Quant à nntp dans Clearbricks, j’suis d’ac aussi, on pourrait « moderniser » ; cela dit, y’a surement plus à faire avec CB, mais ça pourrait devenir un gros chantier et je veux pas charger démesurément la/ma barque.
La taille de police de l’admin est réglable dans les préférences utilisateur (5 niveaux de taille). C’est pas suffisant ? C’est une vraie question, j’suis pas expert a11y.
Question API, côté admin, j’en fait déjà plein (de l’Ajax) avec mes petits modules de tableau de bord qui se mettent à jour sans recharger la page ; c’est cool et fun à coder je trouve.
Voilà rapidement ce que j’en pense…
Vais aller voir ce que ça va donner ce nouveau PHP 8 ; j’avoue ne pas avoir encore mis mon nez dedans :-p
5 De Tomek -
Alors de mon côté, mes priorités en tant qu’utilisateur :
Sinon :
Au sujet de la refonte : y a-t-il eu une suite au message de Mathieu M sur le forum pour donner un coup de main ?
Perso, je suis OK pour relancer une discussion avec tous les gens motivés. :-)
6 De mirovinben -
Heu,… Vous êtes sûr de votre coup quand vous affirmez que la dernière version de Dotclear peut encore fonctionner sous PHP5 ? Il me semble que la 2.14 couinait déjà…
Tomek, non je ne vais pas râler. Trop fatigant… :-)
7 De Llu -
Je me permets de répondre pour la taille de la police plus grande par défaut de l’admin. Ça n’est pas pour l’accessibilité. Ce qui est demandé, c’est que l’utilisateur puisse agrandir la taille (avec le zoom navigateur) sans perte d’information.
La taille par défaut de 16px pour le corps de texte (j’ai pas l’équivalent en unité relative en tête) est présentée comme une bonne pratique d’accessibilité, mais ce n’est pas une obligation. Souvent les gens pensent que c’est mieux pour tout le monde, mais c’est faux.
En fonction des déficiences visuelles (vision tunnel) ou préférences de lecture, c’est une taille de police moins élevée qui sera jugée plus lisible.
Sinon, pour revenir au billet, je comprends que bosser seul ne soit pas aussi motivant, car moi aussi ça ne me motive pas trop.
Je pense qu’on a surtout besoin de réussir à se coordonner et trouver des moments communs pour bosser ou à défaut une façon de bosser ensemble de manière asynchrone.
Est-ce qu’on ne pourrait pas se retrouver sur le Slack ou Discord Dotclear ? Peut-être se fixer des rendez-vous ?
Je peux me coordonner avec biou pour bosser sur l’accessibilité.
Côté refonte, pareil, je veux toujours bien donner un coup de main, surtout que je pense vraiment que le job n’est pas si démesuré. On pourrait repartir d’un moteur Dotclear neuf et ne pas essayer de reproduire l’architecture existante sur le site (que personne ne comprend à part les personnes à l’origine de cette configuration :p).
Je renvoie un mail à ce sujet.
8 De Philippe -
C’est bien ici la liste du Père Noël ?
Dans la refonte de l’admin, j’aimerais ajouter le téléchargement depuis les serveurs dotclear des jeux d’icônes pour le plugin tidyAdmin, plutôt que de venir les chercher chez toi à chaque fois que j’en ai besoin ;)
Et ledit plugin pourrait aussi permettre le changement de thème, quand ça sera prêt
9 De Franck -
Philippe tu dois être le seul sur cette planète à utiliser les jeux d’icônes, j’ai l’impression :-) Tu as une préférence pour lequel ?
Je note pour le changement de thème d’admin dans tidyAdmin, ça pourrait être un premier point d’entrée avant d’éventuellement le rendre intégré au core. Bonne idée.
10 De Franck -
Tomek j’ai ouvert mille fois le code du gestionnaire de média en me disant : « Ah y’est, c’est le moment de s’y mettre ! » et puis ensuite, quand tu parcours toute la mécanique, les bras t’en tombent !
Idéalement il faudrait partir sur un plugin « neuf », indépendant, parce que ça va prendre pas mal de temps à coder cette histoire.
Pour ma part, c’est pas du tout un truc sexy à coder, même si je comprends tes attentes à ce sujet. Donc pour être clair, ça n’est pas dans mes priorités.
11 De Philippe -
Franck : j’avais installé icomoon, mais on dirait que c’est devenu le jeu par défaut. Ça date un peu…
12 De biou -
En parlant de packaging de plugins en zip, je vais poser une question très naïve: pourquoi ne pas utiliser composer qui est le système de package natif de php?
Si je me rappelle bien, composer permet de récupérer directement un package depuis un repo git. Ça éviterait de développer qqch de custom, et l’api de composer peut être appelée depuis un script php.
Il y a sûrement de bonnes raisons pour ne pas faire cela, genre les hébergeurs mutualisés n’installent pas composer.
13 De Franck -
C’est vrai que Composer pourrait être une solution, mais pas applicable partout, ça peut être gênant. l’avantage c’est qu’on peut gérer les dépendances — du genre, mon plugin a besoin d’une version du core >= 2.16, par exemple —, ce que je ne sais pas (encore) faire avec un dépôt Github/Gitea.
14 De Tomek -
@Franck : pas de souci, je me doutais que c’était chiant et pas excitant ce gestionnaire de média. J’aurai essayé !
@Mirovinben : ;-)
La dernière version tourne toujours sans problème sur PHP 5.6 (chez free par ex).