yeswiki
yeswiki copied to clipboard
YesWiki
Aceditor refactor & features Fixs #1023
Yo !
voilà je pense que la PR est prête pour review. Niveau code, il y a beaucoup de commits et changements, donc le ieux est peut être plutot de regarder l'état final : AceditAction.php aceditor.js etc..
Il y aura aussi besoin d'un bonne série de tests ! Candidate potentielle pour la release 4.4
Voilà le contenu
Amélioration de la création de page
Modal de création/édition de lien simplifiée
Nouveau bouton pour créer une page
Petit crayon pour éditer les liens
Ancienne syntaxe de lien de nouveau par default
Lorsque je crée un lien depuis
si le lien s'ouvre dans l'onglet courant alors il utilise la syntaxe classique [[Lien texte]] puisqu'il y a maintenant le lien pour l'éditer
Autocompletion pour les lien et les actions
Plusieurs aceditor par page
Les composants marchent maintenant dans chaque editeur
Refactor Aceditor
J'ai regroupé et converti pas mal de bout de code qui étaient éparpillées et qui fonctionnait indépendamment, rendant assez dur à suivre le fonctionnement de aceditor
Maintenant il y une action AceditorAction (qui s'invoque depuis un twig avec le nouveau helper renderAction)
{{ renderAction('aceditor', { saveButton: true, name: 'body', value: body })|raw }}
Cependant, du au fait que l'on ne peut pas mettre un élément HTML form dans un autre, il faut aussi ne pas oublier d'inclure les différentes modals via un {{ include('@aceditor/aceditor-modals.twig') }}
Ensuite la classe javascript Aceditor va s'initialiser pour chaque éditeur de la page, gérer la toolbar, gérer les aide à la saisie de l'éditeur (autocompletion, petit crayon pour éditer les actions et les liens), et initialiser les différentes modals (actions-builder, files, link...)
Refactor handler edit
Pareil y'avait plusieurs bout de code éparpillé, du à l'utilisation des callback edit__.php. J'en ai regroupé certains, mais pas tous. Il y aura encore les actions relatives aux tags et au selecteur de thème à refactorer pour les inclure directement dans handlers/edit.twig
Super boulot @seballot . Cette phrase est courte bien que je souhaite souligner le gros travail de refactor sur tu as fait et qui respectent nos standards.
Juste parce que tu as oublié de le préciser dans le commentaire de tête, il faudra bien que nous fusionnions les améliorations du thème margot nécessaire pour maintenir l'affichage.
Point d'attention pour @mrflos , la présente branche modifie le contenu de certains handlers __edit.php etc pour déplacer le contenu dans le handler edit.php principal, ce qui fait que contenus concernant des tools officiels ne sont plus maintenant que dans le dossier concerné. Le besoin est une amélioration des performances et de la maintenabilité.
mais je sais que tu m'as déjà fait la remarque pour d'autres PR d'éviter de la faire. Es-tu OK avec ceci cette fois ?
tu veux dire que @seballot introduit des __edit et edit__ dans le coeur de yeswiki?
Ca je ne suis pas tres favorable.
J'ai aussi remarqué un template attach qui trainait dans le coeur ou dans l'extension aceditor, ca non plus j'aime pas trop.
Mais je vais faire une revue méthodique pour faire des retours.
@seballot très bonne idée l'**usage de eslint. Pour aider les développeurs, est-ce que tu pourrais *créer un script dans package.json qui contient la ligne exacte que tu appelles pour faire le eslint pour que nous puissions faire yarn lint ou yarn lint-fix afin de faire le même traitement que les tiens sur nos commits ?
J'ai testé le mécanisme de preview. Super boulot qui fonctionne très bien.
J'ai testé plusieurs champ textelong en mode wiki. Il se trouve que le petit bouton crayon reste actif quand on sélectionne un autre textearea (alors qu'on s'attendrait à ce qu'il disparaisse automatiquement quand on change de textearea) (c'est mineur).
Autre souci, en vue iframe, le petit crayon n'est pas visible pour les champ textearea dans un formulaire de saisie de fiche et il est visible pour la modification d'une page (handler editiframe)
Autre souci, avec les modifications de textarea.twig le paramètre tempTag n'est plus transmis à file-upload-button.
@seballot est-ce que tu pourrais voir comment le passer comme argument de l'action aceditor pour le transmettre ensuite au twig ? Ce paramètre est nécessaire pour le bon fonctionnement de l'ajout de fichiers depuis les champs textelong dans les formulaires des fiches. (correctif nécessaire à mon avis, mais a priori pas compliqué à corriger).
Sinon, je ne vois pas d'autres choses qui ne fonctionnent pas. Vraiment beau travail et le refactor php et js de la partie aceditor et choses associées rend le code vraiment plus facile à maintenir. Merci
Oui @mrflos , @seballot a déplacé des __edit et edit__ des tools pour les intégrer dans le code de edit.php mais il n'a pas créer de nouveau __edit ou edit__ dans le coeur par contre, donc ça n'est peut-être pas aussi critique que ce que tu sembles avoir compris dans ton dernier commentaire
oui, si c'est juste unifié dans edit.php, ca me va, je ne pense pas que beaucoup d'extensions ou custom agissent sur cela.
On le sait que des tools comme aceditor, attach et templates seront un jour (pour ecto) refactorisés et intégrés dans le coeur, ca n'a pas de sens de les avoir en extension
Super, @mrflos ta réponse me permet de lever mon point de vigilance non critique.
coucou !
Merci pour vous retours :)
Pour eslint, j'utlise pas de commande, je l'ai intégré dans vscode. On pourrait d'ailleur lancer un lint général sur tous les fichier js, ça ferait pas de mal ! mais dans une autre PR
Pour l'iframe, chez moi ça fonctionne le petit button. Bizarre... t'as une erreur dans la console? tu peux retester en vidant le cache?
le petit bouton crayon reste actif quand on sélectionne un autre textearea
C'est corrigé
Pour le tempTag, bien vu ! c'est corrigé aussi
@seballot merci pur les améliorations.
Pour eslint: je verrais bien quelques mots dans docs/users/dev.md pour expliquer comment configurer vscode pour utiliser eslint. Comme ceci, je serai en mesure de configurer mon environnement dans le même état que le tien.
En plus, je rajouterais bien ceci dans package.json, afin que les développeurs YesWiki sans EDI (il y en a !!!) puissent faire facilement un lint
"scripts": {
"postinstall": "./javascripts/vendor/extract-files-from-node-modules.sh",
"lint-scan-all": "yarn eslint --fix-dry-run .",
"lint-scan": "yarn eslint --fix-dry-run",
"lint-fix-all": "yarn eslint --fix .",
"lint-fix": "yarn eslint --fix ."
},
en ajoutant .eslintignore avec
# core
/node_modules/
vendor/
# official tools
tools/*
!tools/autoupdate
!tools/aceditor/*
!tools/aceditor
!tools/aceditor/*
!tools/attach
!tools/attach/*
!tools/bazar
!tools/bazar/*
!tools/contact
!tools/contact/*
!tools/despam
!tools/despam/*
!tools/hashcash
!tools/hashcash/*
!tools/lang
!tools/lang/*
!tools/login
!tools/login/*
!tools/nospam
!tools/nospam/*
!tools/progressBar
!tools/progressBar/*
!tools/rss
!tools/rss/*
!tools/security
!tools/security/*
!tools/syndication
!tools/syndication/*
!tools/tableau
!tools/tableau/*
!tools/tags
!tools/tags/*
!tools/templates
!tools/templates/*
!tools/toc
!tools/toc/*
!tools/helloworld
!tools/helloworld/*
Qu'en dis-tu ? (effectivement, mettre en application ces commandes sur tous les fichiers, c'est pour une autre PR, mais au moins, tout le monde aura le même script)
concernant le souci avec iframe:
- si je créé une page:
- avec le code suivant
""<iframe src="https://example.com/?TestEdit/editiframe" width="100%" height="300" class="auto-resize"></iframe>"" - et que j'insère un bouton dans la partie d'édition (
{{button class="btn-primary" link="https://yeswiki.net" text="Mon bouton" }}) - le bouton avec le petit crayon n'est pas joli
- avec le code suivant
- si j'affiche une page en édition
editiframe(https://example.com/?MaPage/editiframe)- et que j'insère un bouton dans la partie d'édition (
{{button class="btn-primary" link="https://yeswiki.net" text="Mon bouton" }}) - le bouton petit crayon n'est toujours pas joli
- et que j'insère un bouton dans la partie d'édition (
- si je crée un formulaire avec un seul champ
textareaField- code du formulaire
texte***bf_titre***Titre de la fiche*** *** *** *** ***text***1*** *** *** * *** * *** *** *** *** textelong***bf_description***Zone de texte*** *** *** *** ***wiki***0*** *** *** * *** * *** *** *** *** - et si j'essaie de saisir une une fiche en mode
iframe(urlhttps://example.com/?BazaR/iframe&vue=saisir&action=saisir_fiche&id=1) - j'insère un bouton dans la partie d'édition (
{{button class="btn-primary" link="https://yeswiki.net" text="Mon bouton" }}) - alors le bouton petit crayon n'est pas visible (alors qu'il existe bien dans le DOM mais il est trop décalé à gauche)
-
- code du formulaire
@seballot Confirmes-tu les mêmes soucis ? (Je suis en Firefxox à jour avec un cache rafraîchi et sur la bonne branche pour le thème margot)
Pour quoi pas contourner le problème et mettre le button sans positionnement négatif à gauche:
L'histoire du padding sur l'éditeur, ca rend moche les formulaires qui ne sont plus alignés, ni avec les autres champs ni avec la barre d'édition, et ce sera toujours problématique avec les iframes..
Si le bouton se met par dessus les numéros de lignes et/ou la marge de l'éditeur, ca le fait, non?
toute solution me conviendra, tant que le bouton reste visible en iframe et tant qu'on ne modifie pas la marge à gauche du formulaire
Wesh !
Pour le eslint, ok pas de soucis pour les commandes dans package.json ! Pour le tuto sur l'éditeur, bah je crois que y'a déjà assez de doc bien faite sur chaque éditeur, j'ai pas trop envie de la ré écrire :)
Pour iframe et crayon, pour moi tout marchait bien (avec les meme exemples que tu donnes jérémy, sur chromium et firefox), mais j'ai fait des modifs voir si maintenant c'est pas plus stable? Faut aussi puller sur margot. Mais en fait je vois que sur tes screenshots tu n'a aucun padding dans ta page en iframe. Moi j'en avais deux des padding (un sur la classe .container et un sur la classe ..yeswiki-page-widget). J'ai viré celui sur .container, du coup y'en a toujours un de 15px en mode iframe ce qui me parait bon non? pourquoi toi tu n'as aucun padding? t'as du code custom qui traine? le padding est déifnit ici Car effectivement si y'a plus de padding c'est pas la meme histoire faut plus qu'il dépasse le bouton !
Ah j'ai compris, j'ai l'extension lms pour laquelle il y a une modification du padding (besoin de @acheype ).https://github.com/YesWiki/yeswiki-extension-lms/blob/f5a9927b5711fdf8fe66b49fe836762472f79098/presentation/styles/lms.css#L57-L59
Donc quand lms est installé, ça pose des soucis.
Il faut donc faire le point avec @acheype pour savoir ce qu'il est possible de faire.
car effectivement, sans lms il y a un petit padding qui permet de voir le bouton, avec lms, le padding disparait.
En tout cas, avec le correctif que tu as fait, le bouton est joli pour un fonctionnement sans lms et il est fonctionnel mais un peu coupé pour un fonctionnement avec lms.
En l'état, ça me va, je valide la PR (si jamais tu peut rajouter les scripts dans packages.json, ce serait un plus, mais bon on pourra le faire plus tard).
ll reste de faire le point avec @acheype pour la position du bouton avec lms.
Peut-être une règle spécifique à ajouter dans lms.css
Merci Jerem !
Allez en petit bonus pour ce soir, special dedicassse @mrflos, la prise en charge des liens markdowns dans l'éditeur !
Pour info j'ai fait en sorte que si on édite un ancien lien syntaxe wiki, ça conserve cette syntaxe. Je sais pas ce qui est le mieux, peut être que c'est ok si on le bascule en markdown automatiquement?
et pour l'iframe, perso j'en utilise jamais, mais c'est peut être effectivement plus pratique si y'a aucune marge? si oui on pourrait faire la modif dans le coeur, et faudra que je change les boutons pour s'y adapter
En y réflchissant, je pense qu'il vaut mieux supprimer tous les padding dans l'iframe, comme l'a fait le LMS. Si besoin de padding, tu peux toujours le rajouter autour de l'iframe. J'ai donc ajuster le bouton pour qu'il soit dedans ça vous va si je vire le padding par défault des iframes?
Yes trop cool, merci pour la spéciale dédicace! Ca va être bon tout ca! Pour moi c'est ok pour les histoire de padding, puisqu'en effet, on peut le gérer spécifiquement sur le wiki. Pour les liens, si ca transforme en MD ca me parait pas mal, on aurait en 4.3 la syntaxe dans les titres et formatage de base, 4.4 les liens éditables/transformables en MD, et donc ensuite plus que des petits ajustements et le script de migration à prévoir pour la suite!
Merci en tout cas, très bonne PR!
ça vous va si je vire le padding par défault des iframes?
Oui, c'est plus logique de laisser le site qui l'intègre gérer comment il veut l'intégrer. J'avais ce besoin en effet pour le LMS et avais défini un padding null.
Je n'ai pas testé, ni regardé en détail mais le reste a l'air très chouette :+1:
pour ma part, je vous laisse voir pour le css des iframes tant que les boutons restent visibles, ce qui e semble le cas dans tout ce qui est proposé
~~Est-ce que vous avez aussi un souci de positionnement du nom du champ texte long par rapport à la barre d'édition d'un champ texte long ?~~
=> corrigé si thème margot à jour
ah j'ai peut etre oublié de dire faut puller margot !
------- Original Message ------- On Tuesday, October 11th, 2022 at 10:30, Jérémy Dufraisse @.***> wrote:
Est-ce que vous avez aussi un souci de positionnement du nom du champ texte long par rapport à la barre d'édition d'un champ texte long ? image
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
Ah oui effectivement, je n'avais pas vu le commit d'hier soir.
Je retire mon commentaire précédent, si on a la dernière version de la branche aceditor sur margot, tout est bon. Merci @seballot
Hello, on a passé 2h avec @seballot à tenter de trouver une syntaxe pas éloigné du markdown pur, pour quand meme pouvoir en particulier sur les liens et images markdown, passer des attributs et autres pour gerer id, class modales, etc
Voici nos tests https://md.yeswiki.net/qKSgijJyTTyRakVGHbQmeQ?both
On était d'abord sur la syntaxe kramdown proposée par @acheype {#id .class} en dehors du lien, hélas ca serait compliqué de gérer cela avec l'éditeur à pinceau, et sur hedgedoc et github, ca ne marche pas et se voie bien...
Notre conclusion serait de partir sur
pour les liens
[lien](https://domaine.ext "Mon titre{modal}")
[lien](https://domaine.ext "Mon titre{.main #toto lang=fr prout}")
pour les images
et pour les redimensionnements
Ca passe en markdown classique (avec juste du déchet en fin de titre au survol, facilement identifiable), et c'est relativement facile à implémenter dans yeswiki actuel.
On part du principe qu'il faudrait pour les exports md de yeswiki vers d'autres editeurs md, il faudra un handler /md , qui complétera les url relatives pour en faire des urls complètes, et qui pourra virer les {foo=bar} des titres.
Qu'en pensez vous?
Slt ! Si je comprends bien vous préférez coder l'interprétation du markdown plutôt qu'utiliser une librairie existante comme php-markdown. Quelle est la raison ?
Pour la syntaxe, vous avez l'air d'y avoir déjà bien réfléchi, top ! Je préfère pour ma part toujours la syntaxe markdown-extra vu que c'est un standard et que certains logiciels l'implémentent.
Ca me paraît plus logique que le {...} soit écrit après le lien ou l'image, plutôt qu'associé au titre. Cela permet également de rajouter des classes aux titres tel Mon titre {.ma-classe}.
Pour les outils qui font du markdown simple, ça ne me choque pas plus d'avoir un {...} à la fin qu'un titre biaisé. Et c'est d'ailleurs une super idée ce handler /md, il faudra de toute façon passer par lui ! (d'ailleurs il pourra dans le même temps supprimer les actions yeswiki {{...}}).
Après vous semblez dire que c'est compliqué à gérer pour l'éditeur à pinceau, donc à vous de voir... L'idéal serait d'avoir une syntaxe reconnue dès le départ... mais nous ne sommes loin d'être dans un monde idéal ;)
Si je comprends bien vous préférez coder l'interprétation du markdown plutôt qu'utiliser une librairie existante comme php-markdown. Quelle est la raison ?
Non c'est juste pendant qu'on reste sur doryphore, il faut garder le formatter wakka, pour ectoplasme, on le fera avec une librairie php (reste à savoir laquelle : https://github.com/cebe/Markbench#markdown-benchmarks-php )
J'avoues @acheype que tu me fais douter avec ta réflexion sur se caler sur une syntaxe standardisée, juste le soucis c'est laquelle? markdown extra est sympa mais peu commune par rapport à la syntaxe initiale et celle de Github Flavored Markdown...
Et le cas d'usage courant, c'est de passer depuis une page wiki à un éditeur collaboratif en ligne type hedgedoc, il faut tenter de le faire sans douleur...
Je propose d'expérimenter avec la syntaxe la plus facile à implémenter pour @seballot dans l'éditeur actuel, puisque pour choisir le parser md d'ectoplasme, il y aura peut etre des nouveaux standards et librairies et que le travail sur la traduction wakka vers le md choisit permettra d'introduire des changements dans la syntaxe si besoin!
Coucou !
C'est bon j'ai eu une idée, j'ai réussi à parsé le md-extra sans encombre, avec le pinceau & co
Donc les deux sont techniquement possible maintenant. Y'a plus qu'à choisir lol
J'avoue que, même si ça nous as semblé mieux à Flo et moi de mettre la partie extra à l'intérieur du titre, comme ça ça passe quand meme à peu près dans des interpreteur normaux, je me dis que ceux qui ont pondu le markdown extra étaient peut être un peu plus calé que nous lol donc autant les suivre non?
plus calé que nous, n'exagérons rien, mais oui, c'est bien de rester dans les trucs déja faits!
Ca me donnera peut etre l'occasion (dans longtemps, hein) de faire un plugin hedgedoc pour gérer les {newtab target=blank}
Ah okk... vous êtes chaud les gars de coder une première fois le truc puis de recommencer avec une librairie pour ectoplasme ! :) Je me demandais s'il n'y avait pas possibilité de lancer d'abord le formatter wakka puis une lib markdown ensuite pour vous éviter cela, mais à vous de voir ce qui est le plus simple pour vous.
C'est bon j'ai eu une idée, j'ai réussi à parsé le md-extra sans encombre, avec le pinceau & co
Top !
L'intérêt que j'y vois c'est que si on passe ensuite à une lib markdown, il n'y aura pas besoin de modifier le code des pages pour ces classes/attributs.
reste à savoir laquelle : https://github.com/cebe/Markbench#markdown-benchmarks-php
Je ne connaissais pas Cebe-markdown, ça peut être un bon candidat ! Markdown-extra n'est pas encore complètement géré mais y'a déjà les "attributs spéciaux" !
Ca me donnera peut etre l'occasion (dans longtemps, hein) de faire un plugin hedgedoc pour gérer les {newtab target=blank}
... ou plus simple de passer par le handler /md ;)
Ah okk... vous êtes chaud les gars de coder une première fois le truc puis de recommencer avec une librairie pour ectoplasme
En fait moi je m'occupe que du aceditor là, et à cet endroit on ne peut pas utiliser de lib.
Pour faire le rendu avec wakka oui t'as raison faudrait se pencher sur l'utilisation d'une lib. Après je connais pas du tout ce fichier formatters/wakka, @mrflos t'en penses quoi? tu voudras t'occuper de gérer la syntaxe md et extra-md dans le formatter?
Du coup on par sur extra-md on est d'accord? Pour les options des liens (ouvrir dans un nouvel onglet ou ouvrir dans une modal), y'a plusieurs options
// Choix 1: On se fait des raccourci spécifique pour wiki
// avantage: c'est bien lisible/compréhensible
// inconvénient: ça marchera pas avec une lib de parsage md classique
[test](MaPage){newtab}
[test](MaPage){modal}
// Choix 2: On utilise le extra-md tel quel
// avantage: c'est compatible, et un dev va direct comprendre que en fait on peut mettre ce qu'on
// veut comme attribut html dans le {}
// inconvénient: c'est pas très fengshui pour les non geeks
[test](MaPage){target=_blank}
[test](MaPage){.modalbox}
// Choix 3: l'entre deux: extra-md pur, mais on bidouille les lien dans un nouvel onglet avec une classe
// (on rajoutera le code js adapté)
// avantage: compatible et lisible
// inconvenient: c'est moins propre niveau structure du html pour les nouvel onglet, mais bon osef je crois
[test](MaPage){.newtab}
[test](MaPage){.modalbox}
Perso j'irai pour choix 3, mais je suis aussi ok avec le 2. et vous?
Pour faire le rendu avec wakka oui t'as raison faudrait se pencher sur l'utilisation d'une lib. Après je connais pas du tout ce fichier
formatters/wakka, @mrflos t'en penses quoi? tu voudras t'occuper de gérer la syntaxe md et extra-md dans le formatter?
J'avais fait des essais (ya 5 ans) sur https://github.com/YesWiki/yeswiki-extension-markdown mais c'est pas si facile de faire cohabiter wakka et markdown, a cause des <br> de wakka et <p> de markdown, entre autres.
Pour moi, jusqu'a ectoplasme, on allait survivre avec le formatter wakka augmenté de regex pour le markdown (et je veux bien voir pour rajouter les trucs de bases manquants). Et pour ecto, virer les formatters et passer par un parsing direct de markdown avec la lib qui va bien, et pour les actions à voir, peut etre laisser twig gérer, ou avoir le parser des actions seulement.
Perso j'irai pour choix 3, mais je suis aussi ok avec le 2. et vous?
pareil, je me dis que les 2 fonctionnent de toute façon..