À ce propos, j'ai commencé à regarder comment on pouvait faire ça via
un plugin, et je joins un patch permettant de le faire (un patch à
appliquer sur exec/articles_edit.php et un exec/affiche_articles_edit.php
à poser à coté).
L'idée, c'est de séparer exec/articles_edit.php en 2 : dans ce script,
la fonction exec_articles_edit_dist récupère les infos de l'article à
éditer puis appelle explicitement exec_affiche_articles_edit_dist.
Si on place cette fonction dans un fichier exec/affiche_articles_edit.php
et qu'on appelle include_fonction('affiche_articles_edit', 'exec') à la
place, il devient alors possible de faire un plugin définissant la
fonction exec_affiche_articles_edit, point de départ idéal pour une
variante ...
Ça me paraîtrait pas déconnant d'intégrer ça dans le core ...
Mrs les devs ajax et autre wywywygers,
j'attire votre attention sur le fait qu'un bon éditeur
(cf... même le notepad !)
intègre une fonctionnalité de recherche et remplacement.
Cordialement,
JLuc
Mrs les devs ajax et autre wywywygers,
j'attire votre attention sur le fait qu'un bon éditeur
(cf... même le notepad !)
intègre une fonctionnalité de recherche et remplacement.
et tinyMCE aussi.
une autre question
Oui, mêmes plusieurs !
=> Tu envisages de spipifier TinyMCE pour que le code produit corresponde au code spip ou bien envisages tu de modifier le moteur de rendu pour gérer le code de tinymce (ou autre) ET/OU les raccourcis spip ?
=> Si le choix est exclusif (soit mode wysiwyg soit raccourcis spip), comment envisages tu la migration/conversion d'un site existant en mode wysiwyg ?
=> Si on peut utiliser les 2, est-ce à dire qu'on pourra choisir par auteur ou pour chaque article son mode d'édition ?
=> Si le choix s'est arrêté sur TinyMCE, qu'est ce qui a motivé ton choix / autres éditeurs existants ?
Je suis plus qu'intéressé par tes réponses vu que je mène une réflexion similaire en ce moment mais pour agora (pas de troll svp) et on pourrait peut être mutualiser tout ou partie de la réflexion et/ou de la réalisation...
=> Tu envisages de spipifier TinyMCE pour que le code produit
corresponde au code spip ou bien envisages tu de modifier le moteur de
rendu pour gérer le code de tinymce (ou autre) ET/OU les raccourcis spip ?
html-isation lors de l'envoi dans tinyMCE et opération inverse au retour.
je sais pas du tout ce que ça va donner, pour l'instant, j'essaye juste
de voir à quoi ça resseble, pour savoir s'il y a des points bloquants
=> Si le choix est exclusif (soit mode wysiwyg soit raccourcis spip),
comment envisages tu la migration/conversion d'un site existant en mode
wysiwyg ?
aucun changement dans les articles => n.a.
=> Si on peut utiliser les 2, est-ce à dire qu'on pourra choisir par
auteur ou pour chaque article son mode d'édition ?
Idéalement, on pourrait choisir comme entre interface complete ou simplifiés
mais ça, pour l'instant, c'est pas accessible par plugin. Quoique, faut
voir
=> Si le choix s'est arrêté sur TinyMCE, qu'est ce qui a motivé ton
choix / autres éditeurs existants ?
C'est pas arréte, mais Jacques à l'air de dire que seuls dojo et mce
sont libre ET multi browsers
En plus, MCE à une notion de plugins qui pourra servir quand il faudra
s'attaquer à la notion de liens vers des entités spip, ou attachement
d'images ou docs spip.
Je suis plus qu'intéressé par tes réponses vu que je mène une réflexion
similaire en ce moment mais pour agora (pas de troll svp) et on pourrait
peut être mutualiser tout ou partie de la réflexion et/ou de la
réalisation...
ça dépend : agora est toujours 1.7-like ? coté plugins et compagnie y'a
pas grand chose à mutualiser dans ce cas ?
y'a jamais que la perso du mce qui serait commune.
ça dépend : agora est toujours 1.7-like ? coté plugins et compagnie y'a
pas grand chose à mutualiser dans ce cas ?
y'a jamais que la perso du mce qui serait commune.
Globalement, on a pris des voies différentes sur l'implémentation ; je ferais une synthèse de notre position vendredi je pense sur le wiki.
Agora est toujours 1.7-like, donc c'est vrai que ca va limiter la mutualisation à la réflexion et la personnalisation de TinyMCE si tout le monde retient celui-là.
Eh Eh, comme quoi mes besoins ne me sont pas particuliers.
Si cette fonction porte ce nom alors que l'API ne l'exige pas (et elle a d'autres bizarreries) c'est que j'ai besoin de la surcharger moi aussi sur certains sites.
Il faut en effet couper ce script en 2, mais le découpage fonctionnel consiste à mon avis à dire qu'il y a la partie SQL à mettre dans un fichier, et la partie HTML dans un autre. Après, libre à chacun de s'écrire un exec/article_wysiwig_edit.php chargeant le fichier commun s'occupant de la partie SQL, et du coup on a accès à tout moment aux deux modes d'édition, sans forcer personne.
> la fonction exec_articles_edit_dist récupère les infos de l'article à
> éditer puis appelle explicitement exec_affiche_articles_edit_dist.
Eh Eh, comme quoi mes besoins ne me sont pas particuliers.
Si cette fonction porte ce nom alors que l'API ne l'exige pas (et
elle a d'autres bizarreries) c'est que j'ai besoin de la surcharger
moi aussi sur certains sites.
mais comment peux tu la surcharger si elle est appelée explicitement ?
Il faut en effet couper ce script en 2, mais le découpage fonctionnel
consiste à mon avis à dire qu'il y a la partie SQL à mettre dans un
fichier, et la partie HTML dans un autre. Après, libre à chacun de
s'écrire un exec/article_wysiwig_edit.php chargeant le fichier commun
s'occupant de la partie SQL,
effectivement, c'est l'idée, sauf que dans mon cas, j'ai juste à
insérer quelques bricoles entre debut_cadre_formulaire() et
formulaire_articles_edit().
c'est dommage de copier/coller toute la fonction juste pour ça déjà,
mais là, faut aussi copier/coller la fonction appelante
et du coup on a accès à tout moment aux
deux modes d'édition, sans forcer personne.
Ca s'appelle svn [6088].
heu ... article_update qui sert à faire un select, c'est moyen ! nan ?
Bon, y'a donc des gros copier/coller, mais ça marche.
Sur spip-zone, dans plugins/_amelioration_admin_/tinymce, ça
marche sur le dernier svn, et ça met tinyMCE sur les zones texte et
chapo de l'édition d'articles.
Pour l'instant, c'est plutôt un "proof of concept", car il faut
chiader l'aller retour, qui utilise les fonctions propre et sale, mais
qui doit louper un paquet de truc. Je vais potasser ça asap.
Par contre, quelqu'un a dit ce matin "Les wysiwyg sont d'une manière
générale des scripts que j'arrive assez bien à maitriser" : il faut
adapter la personnalisation de la barre de menu pour gérer les
raccourcis spip et uniquement ceux là.
Là, j'ai une perso batarde qui accepte de mettre des properties dans
les tableaux alors qu'on ne sait rien en faire en spip, et j'ai pas les
raccourcis intertitre, puce (le "-", pas le "-*"), code, poesie et ...
html
Faut également décliner une autre perso plus simple pour les blocs
courts (titre, surtitre ...) dans lesquels on peut se permettre de
n'autoriser que em, strong, et code par exemple.
Ensuite faudra cogiter sur les aspects liens internes, images et
documents.
mais comment peux tu la surcharger si elle est appelée explicitement ?
Comme tu le proposais dans ton mail précédent. Mais ce n'est pas satisfaisant, c'est pourquoi on a rien dit là-dessus.
j'ai juste à
insérer quelques bricoles entre debut_cadre_formulaire() et
formulaire_articles_edit().
c'est dommage de copier/coller toute la fonction juste pour ça déjà,
mais là, faut aussi copier/coller la fonction appelante
Chaque besoin est particulier, ca parait difficile d'éviter ça.
C'est mon cas aussi, mais sur d'autre parties.
heu ... article_update qui sert à faire un select, c'est moyen ! nan ?
Ca se termine par un update, justement. Mais c'est vrai que justement on déplorait qu'il soit là, c'est à améliorer.
Bon, y'a donc des gros copier/coller, mais ça marche.
Sur spip-zone, dans plugins/_amelioration_admin_/tinymce, ça
marche sur le dernier svn, et ça met tinyMCE sur les zones texte et
chapo de l'édition d'articles.
Je viens d'essayer, il faut bidouiller le chemin d'accès au fichier .js et
ça marche (Safari, avec les bugs de tinymce sur ce système [les boutons ne
marchent pas, mais les raccourcis clavier oui]).
Pour l'instant, c'est plutôt un "proof of concept", car il faut
chiader l'aller retour, qui utilise les fonctions propre et sale, mais
qui doit louper un paquet de truc. Je vais potasser ça asap.
Pour moi, si on active ce plugin, on peut coller le texte dans le champ avec
<html>...</html> autour. Ca peut être très sympa pour les forums, par
exemple (enfin, avec moins de boutons tout de même :))
Faut également décliner une autre perso plus simple pour les blocs
courts (titre, surtitre ...) dans lesquels on peut se permettre de
n'autoriser que em, strong, et code par exemple.
Surtout, avant de continuer dans cette voie, il faudrait réfléchir à
organiser différemment ces pages de formulaire. Chaque "champ" d'édition
devrait être défini par un widget. Ensuite, une fois qu'on a une petite
collection de widgets passe-partout (éditer une ligne, éditer un gros champ,
editer un petit champ, éditer une date etc), on pourra les surcharger comme
on voudra.
Ca rejoindrait le chantier "actions" que j'avais démarré sur spip-lab, et
aussi ce qu'on bidouille actuellement sur irc, à propos des interfaces de
tags..
