Markitup prenant à peu près en charge les boutons multiligne, on se base maintenant dessus pour les notres : forceMultiline devient multiline dans la déclaration des boutons.
On change de technique pour ce qui est du calcul les sélections (sélectionner toute une ligne, tout un mot, au plus proche d'une sélection ou du curseur) : avec les dernières évolutions de Markitup, seul IE se permet des folies. On ne traite donc que le cas IE spécifiquement, et on laisse Markitup gérer les calculs de position du curseur. Du coup, il y a moins de modifications du code de Markitup.
On n'utilise plus la librairie XRegExp qui ne semble plus utile pour nos calculs d'expressions régulières.
Testé avec : FF6, IE8, Opera11.52, Chromium 12.0
On ajoute pour chaque plugin du core :
- le paquet.xml sous le nom _paquet.xml pour éviter une utilisation par défaut à la place de plugin.xml Il suffira de le renommer pour effectuer les tests.
- les fichiers de langue nécessaire à la description et au slogan.
- un fichier _paquet-migration qui contient les commandes svn pour migrer ou ajouter des fichiers. Ce fichier n'a plus d'autre intérêt que de lister les fichiers à renommer pour retrouver le fonctionnement des balises disparues : install, fonctions et options.
et en particulier de sa valeur 4 qui n'existe plus (feu oo),
l'accessibilite n'etant pas un mode degrade, mais une propriete intrinseque
de l'interface commune a tous.
cela permet
- de cibler .editer au lieu de li ce qui simplifie grandement les css
- de ne pas imposer le balisage html et de faire des formulaires en <p> si on le souhaite
À noter :
* Tab : champ ou lien suivant
* Maj-Tab : précédent
* ctrl-tab et crtl-maj-tab : onglet suivant ou précédent
- Alt-tab et alt-maj-tab : passer d'une application ouverte à une autre
Donc, pour mettre la possibilité de saisir une tab dans le greffon de PP "Code", c'est assez mal parti.
Remarque : que fait un fork de PP dans _galaxie_/forum.spip.org/forum.spip.org_2009/barre_outils/edition.php ?
- deplacer le squelette de preview dans prive/ pour ne pas permettre sa consultation directe
- ajouter un autoriser() dans l'action previsu pour fermer la porte lorsque le porte plume est desactive dans le public
- dans tous les cas faire passer le resultat par safehtml car le texte source peut venir de n'importe qui/n'importe ou et peut servir de support a une attaque type XSS ou vol de cookie (l'utilisation d'un $_POST explicite exclue toutefois le simple lien)
Pas besoin de sécuriser outre mesure ici, on ne réalise donc qu'un recuperer_fond sur les données postées
On passe par cette action pour éviter les redirection et la perte du $_POST de $forcer_lang=true;
cf : ecrire/public.php ligne 80