Une semaine que je tourne en rond. non pas que je m'ennuie, loin de là, mais plutôt que je n'y arrive pas.
Dans mon jeu de Dotclear version namespace, j'avance sur plusieurs chantiers en même temps, histoire que ce soit moins rébarbatif. Je n'ai toujours pas fini le typage des méthodes mais ça avance bien et je vais bientôt pouvoir faire une deuxième passe pour modifier, uniformiser, simplifier ces types. Par contre j'ai passé la semaine sur deux autres (voir trois) modifications que je voulais apporter avec comme résultat un échec total.
Je n'arrive pas modifier, le lancement de l'application, et l'accès au singleton, je lance trop de classe et fonction pour lancer le core, ça ne me plait pas, mais impossible de simplifier.
Je n'arrive pas à faire une jolie classe de container qui puisse rendre toujours le bon type sur ses propriétés. Je pense qu'il faut que je pousse un peu plus, voir élargir le champs du Curseur.
Et toujours en fil rouge, je n'arrive pas à simplifier les Modules (plugin, et thème), sur ce point j'attend un peu que le reste avance pour pouvoir envahir Dotclear avec des tas de plugins et constater la charge.
J'ai commencé ces jours tranquillement à compléter le typage des méthodes dans le code de Dotclear. C'est assez fastidieux et cela m'a même réservé quelques surprises et casse-tête. Et je suis tombé sur des méthodes magiques de PHP (__get, __set, __call, etc...) qui m'ont fait poser quelques questions. D'habitude j'adore ces méthodes, cela permet d'écrire plus rapidement avec des codes courts, mais d'un autre coté, cela va à l'encontre de ma recherche de code en béton armé. J'ai donc profité du fait que phpstan ronchonnait sur certaines méthodes magiques pour décider d'en supprimer une bonne partie. Quelle idée ! Me voila avec plus de 10000 occurences à modifier !
Lenny - La veze - 04/2022Dans un premier temps je vais faire un premier passage pour tout modifier version brut, puis je modifierais peut-être quelques noms de méthodes. Au final, j'aurai un code plus lourd, pas spécialement plus lisible au premier regard, mais qui aura du sens et on saura de quoi on parle. (Quand à la vitesse de traitement, je ne devrait gagner qu'un millième de milliseconde.)
Au passage, j'ai échangé quelques mots avec le grand gourou ce matin au sujet des différentes méthodes existantes dans Dotclear pour créer le code HTML des formulaires, je vais avoir un gros chantier en perspective.
Quelle désagréable sensation que celle d'un code qui ne te plait pas mais que tu souhaites garder !
Voila maintenant plus de 3 mois que j'ai entamer mes essais d'une version chamboulée du moteur de blog Dotclear avec notamment quelques impératifs que je m'étais fixé dès le départ. Parmi ceux-ci, il y avait une meilleur gestion des modules tels que les thèmes et plugins, surtout du coté des répertoires. Pour le code même des modules, il y a encore du travail et c'est encore très lent aujourd'hui, j'en suis conscient et j'espère améliorer la moulinette, mais pour le second effet kiss-kool, ça ne me plait pas du tout. Mais de quoi je parle ? Petite explication. Premièrement dans cette version revue de Dotclear, Je propose plusieurs répertoires pour stocker les thèmes, comme ce qui existe aujourd'hui dans Dotclear 2.x sur les plugins, avec en plus un répertoire supplémentaire par blog (pour les thèmes et pour les plugins). Et deuxièmement, j'autorise à stocker certains de ces répertoires n'importe ou. (et je n'utilise pas de liens symboliques, je suis du monde Windows je ne sais pas ce que c'est :o )
Ambre et Oriane - La Panicière - 03/2021 "Et?" me direz vous. Et du coup je dois fournir tous les fichiers tels que les feuilles de style, les javascripts, les images, etc. à travers un gestionnaire du fichier. Pour ce faire, ce gestionnaire doit connaitre tous les répertoires de thèmes et plugins ainsi que le blog courant et sa configuration, ça prend du temps. Ce qui n'est pas grave pour un fichier peu vite devenir une catastrophe pour 40 fichiers à fournir pour une page web… Du coup par exemple sur l'interface d'administration on a cette désagréable sensation que ça rame, que tout ne s'affiche pas d'un coup. Je n'aime pas ça et je ne peux rien y faire.
Depuis fin décembre, je travaille sur une branche Namespace de Dotclear et autant le dire tout de suite, il n'y a plus aucune chance que je réussisse à rendre ce code compatible avec la branche master (les versions actuelles).
Et je commençais même à baisser les bras à cause de la lenteur extrême de mon code, et aidé par le passage du COVID qui m'a ruiné une semaine… Jusqu'à ce que j'en trouve la raison et revienne à une vitesse d'exécution un peu plus normale (autant le code que moi!). Bref, le mal de crâne passant je vais bientôt pouvoir me replonger dedans et continuer à tout casser car même si le fait est que ce code est incompatible avec l'existant, il y a pleins de bonnes choses dedans. Pour parler technique, voila quelques exemple :
Gestion de l'arborescence façon PSR-4 et donc normalement composer compliant,
Plus de clearbricks, qui est engloutie par Dotclear,
Plus d'appelle à des global sortie du chapeau, tout passe par l'application (super nom fourre tout),
Plus de constante de configuration, idem tout est dans l'appli,
Le truc qu'on appelle application est accessible n'importe ou n'importe quand dans le code,
Refonte totale façon modules des plugins et thèmes qui deviennent des types de modules,
Multi répertoire de thèmes avec possibilité de répertoire par blog,
Pour ça, passage de toutes les requetes (page,img,css,js,etc) par un gestionnaire d'URL (lourd mais souple)
Et j'en oublie pleins…
Donc même si cette branche ne sort jamais, je m'amuse bien et il y a pleins de bonnes idées dedans, ça servira toujours.
Coté planning, je m'était donné 1 an pour rendre un verdict, j'en suis à deux mois, see you later.
La prochaine version de Dotclear requiert PHP > 7.4, hors chez moi j'avais une 7.3.xx. C'est l'occasion de faire un petit pense bête sur la manière de faire l'upgrade.
Oriane - La panicière - 12/2021
On part d'une installation Debian avec un serveur Apache2 et on se connecte au surveur web en SSH avec un utilisateur sudo. On commence par mettre à jour la distribution avec la commande :
sudo apt update & upgrade -y
Ensuite on regarde ce qui est installé actuellement et on récupère cette liste :
sudo dpkg -l | grep php
ii libapache2-mod-php 2:7.3+69 all server-side, HTML-embedded scripting language (Apache 2 module) (default)
ii libapache2-mod-php7.3 7.3.31-1~deb10u1 amd64 server-side, HTML-embedded scripting language (Apache 2 module)
ii php 2:7.3+69 all server-side, HTML-embedded scripting language (default)
ii php-cli 2:7.3+69 all command-line interpreter for the PHP scripting language (default)
ii php-common 2:69 all Common files for PHP packages
ii php-curl 2:7.3+69 all CURL module for PHP [default]
ii php-gd 2:7.3+69 all GD module for PHP [default]
ii php-gmp 2:7.3+69 all GMP module for PHP [default]
ii php-intl 2:7.3+69 all Internationalisation module for PHP [default]
ii php-mbstring 2:7.3+69 all MBSTRING module for PHP [default]
ii php-mysql 2:7.3+69 all MySQL module for PHP [default]
ii php-xml 2:7.3+69 all DOM, SimpleXML, WDDX, XML, and XSL module for PHP [default]
ii php-xmlrpc 2:7.3+69 all XMLRPC-EPI module for PHP [default]
ii php-zip 2:7.3+69 all Zip module for PHP [default]
ii php7.3 7.3.31-1~deb10u1 all server-side, HTML-embedded scripting language (metapackage)
ii php7.3-cli 7.3.31-1~deb10u1 amd64 command-line interpreter for the PHP scripting language
ii php7.3-common 7.3.31-1~deb10u1 amd64 documentation, examples and common module for PHP
ii php7.3-curl 7.3.31-1~deb10u1 amd64 CURL module for PHP
ii php7.3-gd 7.3.31-1~deb10u1 amd64 GD module for PHP
ii php7.3-gmp 7.3.31-1~deb10u1 amd64 GMP module for PHP
ii php7.3-intl 7.3.31-1~deb10u1 amd64 Internationalisation module for PHP
ii php7.3-json 7.3.31-1~deb10u1 amd64 JSON module for PHP
ii php7.3-mbstring 7.3.31-1~deb10u1 amd64 MBSTRING module for PHP
ii php7.3-mysql 7.3.31-1~deb10u1 amd64 MySQL module for PHP
ii php7.3-opcache 7.3.31-1~deb10u1 amd64 Zend OpCache module for PHP
ii php7.3-readline 7.3.31-1~deb10u1 amd64 readline module for PHP
ii php7.3-xml 7.3.31-1~deb10u1 amd64 DOM, SimpleXML, WDDX, XML, and XSL module for PHP
ii php7.3-xmlrpc 7.3.31-1~deb10u1 amd64 XMLRPC-EPI module for PHP
ii php7.3-zip 7.3.31-1~deb10u1 amd64 Zip module for PHP
On voit qu'on a effectivement la version 7.3 de PHP. IL va falloir la mettre à jour vers la version suivante. Pour cela il faut récupérer une liste de paquetages que le système saura installer. Ici on enchaine plusieurs commandes qui installent de quoi récupérer la liste des paquetages php disponible pour le serveur, on ajoute le lien dans le gestionnaire de paquetages et on met à jour la liste :
Voila, le système de paquetages du serveur va svoir installer ce qu'on veut. On commence par PHP lui même :
sudo apt install php7.4 php7.4-common php7.4-cli
D'après la liste de ce qu'on avait d'installer sur le serveur au début de ce billet, on installe les paquetages correspondant : Attention la liste ici est juste pour l'exemple, votre serveur n'a pas forcément ces paquetage et en a peut-être d'autres en plus.
Enfin on installe le module PHP d'apache2 : Normalement il va être automatiquement installer en dépendance des paquetages précédents.
sudo apt install libapache2-mod-php7.4
On nettoie les paquetages qui sont désormais inutiles :
sudo apt purge php7.3 php7.3-common
On désactive l'ancien module et on active le nouveau : Normalement l'ancien devrait déjà avoir disparu avec la commande purge.
sudo a2dismod php7.3
sudo a2enmod php7.4
Enfin on redémarre Apache :
sudo service apache2 restart
Voila un beau serveur en php 7.4.
Les commandes restent les mêmes pour monter jusqu'à la dernière version (actuellement 8.1) de php. A ceci près qu'il faudra peut-être reconfigurer le fichier ini de php (/etc/php/x.x/apache2/php.ini) Il a également fallu que je désactive l'extension php xmlrpc (ajouter ; au début de la ligne du fichier /etc/php/8.1/apache2/conf.d/20-xmlrpc.ini) pour la version actuelle de Dotclear qui contient déjà des classes faisant la même chose.
Comme d'habitude, il suffit d'une idée qui me passe par la tête pour me lancer à corps perdu dans une aventure bien trop périlleuse pour moi.
Il y a quelques temps, j'ai commencé à regarder le fonctionnement des espaces de noms dans PHP, avec 10 ans de retard et l'impasse que j'avais fait sur ce système de gestion de classe, l'affaire n'était pas gagnée. Dès le premier aspect ça ma titillé et j'ai, comme toujours, mis mon cerveau en ébullition: Les espaces de noms de PHP permettent une gestion ultra simple de l'auto-chargement des classes depuis leurs différents dossiers. Il n'en fallait pas plus pour que j'attaque à recoder mon moteur de blog préféré en suivant ce principe. (En vrai je me suis fait la main sur des plugins qui tournent chez moi avec ces fameux namespaces) Et voila, je n'ai pas réfléchie, ça engendre des milliers de problèmes et d'incompatibilités avec le code actuel et je suis donc en train d'adapter et de bricoler pour que ça passe. Et comme il y a un moment ou évidement ça ne passe plus, je recommence en modifiant en conséquence. Je suis borné, j'ai déjà recommencé 3 ou 4 fois.
Il serait bon que pour une fois, vu que ça à l'air de me plaire, je prenne le problème dans son ensemble et que je pose les bases d'une réécriture propre. Je sais faire ça moi ?
Ambre et Oriane - La Panicière - 12/2021
Pour la petite histoire, je suis partie sur du 100% classe, plus de fichiers avec des bouts de code, plus de fichier avec 5 ou 6 classes dedans. Cette structure m'oblige donc à revoir certains aspects et rendent le code absolument incompatible (pour le moment) avec l'existant. Par exemple, les pages de la partie administration seront servies depuis un seul point d'entrée et non plus une page/fichier par lieu. Les plugins ne seront plus non plus géré comme aujourd'hui par fichier (_define.php, _admin.php, etc) mais pas classe. Tous les passage pirouettes du core de Dotclear à des méthodes statiques à travers des globales seront à proscrire. (J'ai même envie de passer en dynamique pas mal de classes) J'ai donc pas mal de soucis en perspective. Mais c'est ce qui fait la beauté du jeu. Et puis Dotclear est assez solide aujourd'hui pour que ce ne soit pas une nécessité avant longtemps. Ouf. Ah, et au passage, clearbricks serait engloutie par Dotclear. Voila.
J'ai voulu faire simple et je suis tombé sur plus tordu que moi...
Toujours dans mon optique de lier mes blogs Dotclear à d'autres choses à travers l'authentification OAuth2, je me voyais déjà réussir dans un avenir proche proposer un plugin permettant de s'authentifier sur Github, Facebook ou je ne sais quelle plateforme de contenu en deux clic de souris. Suis-je bête ?
Ambre, Evan, Lenny, Oriane - La panicière - 10/2021
En théorie j'ai déjà réussi, chez moi ce plugin fonctionne. Une fois qu'on a indiqué la clé associant une plateforme de blogs à un fournisseur de contenu, il suffit à un utilisateur du blog de cliquer pour autoriser ce blog à échanger dans son dos avec la dite plateforme. Simple vue d'ici. Mais non. En effet les premiers mots de ma phrase précédente vont apporter un mal de crane incommensurable au super-admin de multiblogs. Je recommence doucement.
Donc pour utiliser mon plugin sur une plateforme de blogs, il faut d'abords entrer une clé permettant d'accéder au fournisseur de contenu.
Ah ? Et je la trouve ou cette clé ?
Ben facile, il faut créer une application chez le fournisseur et il te donnera une clé.
Créer une application ? kesako ? des exemples ?
On va commencer doucement, prenons l'exemple de Github, tu te connectes sur le site, tu vas dans l'espace developers et tu créer une nouvelle application simplement en entrant un nom et l'url de ton admin de blogs. Et il te file une clé.
Ah ouai ça va c'est pas la mort.
Attend j'ai un autre exemple un poil plus costaud.
Je vais surement rater des étapes car je ne suis pas arrivé au bout, je vais parler de l'usine à gaz Facebook Developers. Je voulais donc proposer dans mon petit plugin de se connecter à Instagram, chez moi quelques ligne de code pour accorder les requetes OAuth2 aux spécifications de la plateforme Instagram et zou, je file sur Insta pour créer une application... Ah merde, c'est sur Facebook, pas grave j'ai déjà un compte dev chez eux qui date de la bonne époque. Pour créer une application Instagram il faut donc commencer par avoir un compte dev Facebook, puis créer une application Facebook dans laquelle on créer une sous application Instagram. Pas simple, ce n'est que le début. Faut dire à quoi sert l'application, à quoi je sers, leur filer une copie de ma carte d'identité (oui oui), si mon logo est bien (ah non ça c'est eux qui me le disent, j'ai recommencé 10 fois avant d'être accpeté.) faire valider l'application. Ouf. Ah non faut recommencer pour ajouter les droits Instagram à mon application... Je pleure. Ce n'est pas fini, il faut que je fasse une vidéo de 5 minutes leur présentant comment fonctionne mon application et à quoi elle sert, ou faire une dissertation de 10 pages... Ok la j'ai abandonné. Mais en lot de consolation j'ai eu le droit d'avoir un accès testeur sur mon aplication youpi ! Bref, mon code fonctionne, mais je pense que personne ne se cassera la tête à créer une application Facebook pour son multi-blogs. Fail pour bibi.
Si j'étais une standard, je serais celui de l'echec de standardisation de standard.
J'essai depuis quelques jours, voir semaines, d'écrire un bout de code qui me permette d'utiliser les API tiers dans le moteur de blog Dotclear. Je pense qu'il serait sympa d'apporter ça à Dotclear, que ce soit pour de l'identification, pour les commentaires, pour de l'auto promotion sur des réseaux, pour de l'action bidirectionnelles (j'ai bien quelques idées en tête avec Github). Ce n'est pas la première fois que je me penche sur le sujet, il y a une dizaine d'années j'avais déjà concocté un plugin mais la lourdeur du code et la non standardisation des API tiers m'avaient fait non seulement abandonner le plugin mais carrément l'envie de coder !
Lenny - Saint-Germain - 09/2021
Et surement parce que l'effet de cet épisode s'est estompé, pour la énième fois, j'ai retenté l'expérience. Après dix ans, j'avais espoir que les choses se soient améliorées, avec de vrais standards que tout le monde (toutes les API) respectait. Je suis naif. Non seulement il n'y a pas un standard qui s'est dégagé des autres, mais de nouveaux sont apparus, et ceux existant ne sont toujours pas plus respectés. Donc outre les soucis techniques (gestion d'un point d'arriver coté admin de Dotclear), il faut gérer les multiples standards, et il faut gérer les multiples exceptions à ces multiples standards. Bref je suis naïf.
Cette fois j'ai pris mon temps, avançant à tout petit pas, me posant des questions et lisant des pages et des pages de documents, à chaque étapes, à chaque fonction. J'ai avancé et alors que je suis proche des premiers échanges avec des API, voila que la lassitude revient. Comment peut-on utiliser une vingtaine de class et je ne sais combien de méthodes juste pour fabriquer un lien ! C'est juste aberrant et ça me dépasse. Quand je vois la simplicité du moteur de blog Dotclear, je ne peux pas lui apporter cette lourdeur juste pour une featurette... Je pourrais peut-être me limiter à un standard comme OAuth2 qui me parait le plus complet, mais également le moins respecté, donc au final je ne suis pas sure que ça change grand chose. Je pourrais également utiliser une bibliothèque toute faite, j'en ai étudié quelques unes, mais c'est encore pire, car il faudra intercaler une surcouche entre Dotclear et ces bibliothèques... Au secours.
Bref il est temps de faire une pause dans cette démarche et de me replonger dans les entrailles plaisantes de Dotclear.
Ce n'est toujours pas mon métier, du tout, mais après 10 ans d'absence j'ai remis le nez dans une de mes passions : la programmation web. A l'ancienne avec PHP et mon moteur de blog préféré : Dotclear.
A l'époque j'avais fait quelques plugins plus ou moins programmés avec les pieds mais qu'importe, je m'amusais bien. Puis il y a 3 mois, une mise à jour de Dotclear et le temps passant, mes plugins finirent par être obsolète. Que nenni ! Un petit tour dans le code, et les revoila, pour certains, à jour. J'aurai pu m'arrêter là, mais le virus déjà avait repris le dessus.
Il a fallu que je m'adapte aux changements opérés dans le langage PHP pendant ces 10 ans d'absence mais ça va, je ne suis pas encore trop vieux et j'ai réussi à emmagasiner tout ça, s'en suivent des dizaines de commits sur Dotclear.
Orchestré de main de maitre, j'adore ce moteur de blog qui ne s'intéresse nullement à sa popularité mais plutôt au respect des standards et de l'accessibilité. J'en parle aujourd'hui ici car une nouvelle version est sortie et je suis heureux d'y avoir participé, très modestement, après tout ce temps.
A l'époque j'avais fait