Je commence un peu à saturer côté Javascript, il va falloir que je repasse à autre chose ; la liste des plugins à publier, avec une partie pour la future 2.15, commence à s’alourdir et je reprends du coup mes questionnements sur la gestion de mes dépôts, pour l’instant gérés avec Mercurial, en mode privé sur Bitbucket (et copie locale sur mon Mac).
Un Gitea installé sur mon serveur pourrait faire le job (c’est ce que j’utilise au boulot pour les développements), sauf que ça va me contraindre à basculer quasiment tous mes dépôts sous Git et vu que j’en ai pas loin d’une centaine — 4/6e de plugins, 1/6e de thèmes et le reste de trucs divers et variés —, les bras m’en tombent d’avance !
Reprendre les tests unitaires côté Clearbricks, j’ai senti que ça me manquait côté Dotclear (unitaire/fonctionnel) quand j’ai commencé à basculer sur ES6, j’aurais bien aimé pouvoir lancer les tests pour vérifier que je ne cassais rien ; les compléter côté Dotclear…
Ah mais avant il faut que je termine ce que j’ai entrepris côté Javascript avec la reprise des promesses, mal gérées dans l’ensemble. Ça permettra d’avoir un code plus robuste et au passage plus facile à tester.
Sinon j’adapterais bien un thème, mais je n’en ai trouvé aucun qui ait fait tilt quand je l’ai découvert !
1 De Da Scritch -
Je réfléchis à la possibilité d’utiliser le “index.php” d’un site pour l’appeler à partir du shell afin d’y effectuer des commandes : lister les billets, lister les utilisateurs, changer un mot de passe…
Reste la question de l’authentification via le shell et la gestion des multisites … mais surtout comment construire ce script de manière à ce qu’il ne fragilise pas la sécurité ou alourdisse le code
2 De Franck -
Gnieark avait commencé le développement d’un plugin pour ajouter une API REST à Dotclear, peut-être que tu peux repartir de ça (ou t’en inspirer) ?
3 De Da Scritch -
Pas con !
y’aurait qu’à créer un interpréteur de la ligne de commande, qui le transforme en requête GET.
4 De Da Scritch -
bon, en fait…. ça marche presque d’entrée !!!!
~$ php7.0 site/index.php
PHP Notice: Undefined index: REQUEST_URI in site/inc/libs/clearbricks/common/lib.http.php on line 68
PHP Notice: Undefined index: HTTP_HOST in site/inc/libs/clearbricks/common/lib.http.php on line 27
PHP Notice: Undefined index: SERVER_PORT in site/inc/libs/clearbricks/common/lib.http.php on line 37
PHP Notice: Undefined index: SERVER_PORT in site/inc/libs/clearbricks/common/lib.http.php on line 37
PHP Notice: Undefined index: REQUEST_URI in site/inc/libs/clearbricks/common/lib.http.php on line 69
(suivi de la sortie HTML de la home page)
5 De olivier -
Je vois pas trop pourquoi le fait de passer de mercurial (hg) à git changera quelque chose.
Mercurial gère très bien les tags, les branches (tout comme git), et Bitbucket fournit la possibilité d’avoir des dépôts privés et/ou publics.
Un jour il faudra qu’on m’explique pourquoi git est autant plébiscité.
6 De Franck -
La question n’est pas de choisir entre git ou hg, mais de choisir où et comment sont hébergés les dépôts (autres que ceux que j’ai sur mon Mac).
Côté mercurial, il faut installer hg, un trac ou équivalent, … Pas le plus simple, tandis que côté git, un simple Gitea fait le job.
Au delà de ça je suis d’accord avec toi olivier, hg fait très bien le job et j’en suis satisfait depuis des années !
7 De Franck -
Bonne nouvelle, Gitlab annonce l’intégration de Mercurial dans Gitlab (.com pour l’instant j’ai l’impression).