J’aime SPIP ; : une fois installé, sa syntaxe comprise, il est facile de publier et de l’étendre. Je n’aime pas trop Joomla ou WordPress. En effet, si le cœur est soigné, il faut des compétences PHP pour étendre correctement le CMS, tandis qu’avec SPIP, la lecture de la doc sur les boucles et squelettes suffit à faire pas mal de choses.
Résultat : Joomla, WordPress ont des sites dédiés aux extensions, une pléthore, mais combien de qualité ? Confer MISC, où un article de 2014 parlait justement de revue de code et des requêtes non vérifiées dans des extensions pour WordPress...
Tandis qu’avec SPIP et son langage, soit on développe un truc qui fonctionne, soit un truc qui ne fonctionne pas ; mais c’est beaucoup plus difficile de compromettre la sécurité de son hébergement.
Maintenant, SPIP est fait pour des gens qui savent publier. Tandis que Joomla, WordPress, ... s’adressent aussi bien à des néophytes. L’éditeur TinyMCE de WordPress est à ce sujet un atout très apprécié de certains clients !
J’ai donc eu pour mission de passer d’un site SPIP à un site plus WYSIWG... J’ai retenu WordPress. Et cet article va présenter les difficultés à retrouver l’équivalent du plugin « crayons » de SPIP, car ne pas offrir l’équivalent de « crayons » serait considéré à juste titre comme une grosse régression.
C’est une extension de SPIP qui permet de corriger des petites choses (fautes de frappes...) depuis l’espace public du site, une fois connecté.
Pour activer ça, rien de plus simple : aller dans les extensions de SPIP, cliquer sur « crayons » et activer la chose : SPIP s’occupe des dépendances... Modifier les squelettes au besoin pour mettre des #EDITtexte ici où là. Un double clic sur l’élément (ou un clic sur une petite icône qui apparaît au survol) le remplace par un éditeur. Tout simple, tout pratique.
En fouillant sur le site des extensions de WordPress (à l’heure de l’écriture de cet article, nous en sommes à « 34,660 PLUGINS », je n’ai rien trouvé de concluant. Sans doute existe-t-il là-dedans ce que je cherche, mais je passe certainement moins de temps à développer ce qui me convient qu’à fouiller un tel bazar !
J’ai trouvé TinyMCE Advanced qui me plait bien pour sa possibilité d’insérer des tables dans l’éditeur TinyMCE de WordPress.
J’ai trouvé Pst from Front-End mais il n’est pas francisé et comporte des options inutiles pour moi... et ne pallie pas le problème de la non apparition des galeries sur l’espace public !
Un truc qui a priori semblait pas mal c’était https://wordpress.org/plugins/ultim... mais depuis la version 3.9 de WordPress, ce n’est plus valable... Eh oui, sur les 34660, combien vont fonctionner avec MA version de WordPress, combien sont maintenus ?
Mon problème est d’utiliser le même éditeur en partie privée qu’en partie publique (une fois connecté avec les bonnes autorisations), en particulier avoir un aperçu des galeries photos (le SPIP à reprendre était étendu avecun modèle de galeries photos, natives dans WordPress).
Or ... comme le fait remarquer dtbaker :
The documentation is rather lacking : http://codex.wordpress.org/wp-views
Donc j’ai cherché et j’ai trouvé le wp_editor : je pensais bêtement utiliser ce wp_editor dans une ressource à laquelle on accède en ajax. Apparemment c’est une mauvaise idée car les scripts mis en queue ne exécutent pas et le résultat est nul.
À défaut, je me suis dit « donc on va permettre d’éditer un article ou un post sur sa page publique uniquement (pas depuis une archive ou un résultat de recherche : ça limite un peu mais c’est tolérable). Là, l’éditeur semble fonctionner (images qui s’affichent bien dans l’éditeur visuel, mise en forme pas mal...). Mais : les galeries sont remplacées par un carré tout gris. c’est là que je suis tombé sur le filtre « tiny_mce_before_init ». Bon, ça va aller avec ça que je me suis dit.
Donc je teste, si is_single() je mets un wp_editor caché et j’encapsule le $post->post_content dans un div avec un petit crayon. Lors d’un clic sur le petit crayon ou un double-clic sur le div englobant, je cache ce bloc pour afficher l’éditeur (que j’ai pris soin d’instancier dans un div caché).
Et là, zut ! Les shortcodes sont interprétés... Alors dans l’init je désactive l’évaluation des shortcode et j’installe un hook pour restaurer l’interprétation des shortcodes pour le post_content.
Là, ça commence par aller pas mal. Mais ... les galeries sont remplacées par un gros bloc gris. Je m’excite pas mal sur tiny_mce_before_init... avec des résultats mitigés :
– soit le [gallery] n’est pas interprété ;
– soit il est remplacé par ... rien du tout !
Pour finalement trouver la cause du problème : wpview/plugin.js vérifie que
// Check if the <span class="base64" title="PGNvZGUgY2xhc3M9J3NwaXBfY29kZSBzcGlwX2NvZGVfaW5saW5lJyBkaXI9J2x0cic+d3AubWNlPC9jb2RlPg=="></span> API exists.
if ( typeof wp === 'undefined' || ! wp.mce ) {Dans la négative, on n’a plus rien :
return {
getViewText: _noop,
setViewText: _noop,
getView: _noop
};Reste à trouver comment avoir un objet wp.mce dans la page. Un coup de find me premet de trouver l’insertion du script :
wp_enqueue_script( 'mce-view' );
Enfin, j’y suis !
Presque ... maintenant, reste à étudier si c’est dans les bonnes fonctions de rappel que j’appelle mon code, contrôler le respect des autorisations d’accès ... On est tellement content quand on a réussi à greffer nos fonctions là-dedans qu’on aurait tendance à utiliser ça sans vérifier les effets de bord. WordPress, c’est le royaume de l’effet de bord ;-)