Basculez librement entre les onglets Visual et HTML

Cette question a donc été soulevée à plusieurs reprises sous différents drapeaux, mais je voudrais présenter un fil unifié pour une solution ultime à ce problème.

Dans WordPress, par défaut, lors du basculement entre les éditeurs HTML et Visual dans TinyMCE, certaines balises sont supprimées du contenu et d'autres fonctionnalités étranges se produisent. Deux solutions de contournement connues pour l'écriture de code HTML plus efficace consistent à supprimer la fonction wp_auto_p à l'aide de filtres et à installer TinyMCE Advanced et à activer l'option «Arrêter la suppression des balises p & br».

Cela ne fonctionne que si bien, malheureusement.

Prenons, par exemple, l'exemple suivant:

<h2>How does it work?</h2>
<p>In order to use jQuery Easy Columns, you must install it as you would any other jQuery plugin.  First, download the zip file using the button above.  After downloading the file, extract it to a location of your choice, and move the extracted folder to your server using your favorite FTP client.  After moving the plugin to your server (and of course calling the jQuery source into your document), call it in on your site using the following snippet of code:</p>
<pre>
&lt;script type=&quot;text/javascript&quot; src=&quot;/path/to/jquery.easycolumns.js&quot;&gt;&lt;/script&gt;
</pre>

Si je tape ce code dans l'éditeur HTML, avec les deux options énumérées ci-dessus déjà activées, alors lorsque je bascule entre les deux éditeurs différents, rien ne se passe, ce qui est attendu. Malheureusement, lors de l'enregistrement, le code se convertit automatiquement en ceci:

<h2>How does it work?</h2>
<p>In order to use jQuery Easy Columns, you must install it as you would any other jQuery plugin.  First, download the zip file using the button above.  After downloading the file, extract it to a location of your choice, and move the extracted folder to your server using your favorite FTP client.  After moving the plugin to your server (and of course calling the jQuery source into your document), call it in on your site using the following snippet of code:</p>
<pre>
<script type="text/javascript" src="/path/to/jquery.easycolumns.js"></script>
</pre>

Comme vous pouvez le voir, toutes les entités à l'intérieur de la balise pre sont reconverties en caractères HTML réels. Ensuite, si je sauvegarde à nouveau ce même message, j'obtiens quelque chose comme ceci:

<h2>How does it work?</h2>
<p>In order to use jQuery Easy Columns, you must install it as you would any other jQuery plugin.  First, download the zip file using the button above.  After downloading the file, extract it to a location of your choice, and move the extracted folder to your server using your favorite FTP client.  After moving the plugin to your server (and of course calling the jQuery source into your document), call it in on your site using the following snippet of code:</p>
<pre><br />
<script type="text/javascript" src="/path/to/jquery.easycolumns.js"></script><br />
</pre>

Notez que Wordpress injectera en fait des balises br dans la publication. Inutile de dire que lorsque ce message a été mis à jour à quelques reprises, lors de sa visualisation sur le frontend, l'affichage est loin de l'affichage prévu.

La seule façon dont j'ai semblé me ​​débarrasser de toutes les «fonctionnalités de formatage» ajoutées a été de désactiver l'éditeur visuel via mon profil.

C'est une bonne solution pour moi, étant donné que je suis un développeur Web professionnel. Pour mes clients, cette solution est loin d'être élégante. Mes clients utiliseront, pour la plupart, l'éditeur visuel. Beaucoup de mes clients ne sont pas très avertis en technologie et ont parfois besoin de moi pour corriger leurs messages lorsque la mise en page se casse. Cela me limite à utiliser l'éditeur visuel, car je ne peux pas passer à l'éditeur HTML sans craindre de casser la mise en page.

Principalement, (et je pense qu'il y a une grande communauté qui pourrait bénéficier de cette réponse), quelles étapes explicites puis-je suivre pour assurer ce qui suit:

1. Un article peut être édité à partir de l'éditeur visuel ou HTML.
2. Le contenu d'un article n'est en aucun cas modifié lors du basculement entre les deux onglets.
3. Lors de l'enregistrement d'une publication à partir de l'éditeur HTML, aucun contenu supplémentaire n'est ajouté.
4. Lors de l'enregistrement d'un article à partir de l'éditeur HTML, aucune entité n'est convertie.
5. BONUS: Lorsque vous enregistrez une publication à partir de l'éditeur HTML, tout code (HTML par exemple) qui est enveloppé dans une balise pré et qui n'est pas déjà converti en entités sera automatiquement converti en entités.

Essentiellement, si nous pouvons créer le comportement susmentionné dans TinyMCE grâce à l'utilisation d'un plugin tiers, nous pouvons étouffer toutes les autres questions concernant le faux formatage grâce à l'utilisation de TinyMCE. Je pense que beaucoup de gens pourraient en bénéficier.

Il semble logique qu'il y ait une certaine fonctionnalité que l'on peut attendre d'un éditeur WYSIWIG, et cela va à l'encontre de cela. Selon toute logique et raison, les fonctions de formatage intégrées de Wordpress sont assez inutiles avec leur configuration actuelle. Il me semble que s'ils veulent utiliser ces options de formatage, leur meilleur pari serait d'activer un éditeur ou l'autre, pas les deux.

ET S'IL VOUS PLAÎT: Ne répondez pas à ce fil avec des solutions de contournement et des téléchargements pour d'autres éditeurs WYSIWIG qui «résolvent» le problème. Il s'agit d'un problème sous-jacent (mais pas vraiment un bug) avec le noyau Wordpress qui doit être corrigé.

EDIT : Très bien, j'ai travaillé sur cela et je pense que la rétro-ingénierie sera le meilleur moyen de résoudre ce problème. Donc pour l'instant, j'ai désactivé wpautop (qui, pour plus de clarté, est une fonction qui se connecte au filtre "the_content" pour ajouter des balises p et br avant que le texte ne soit affiché , pas lorsque le texte est enregistré. Je pense qu'il existe une certaine confusion quant au fonctionnement de cette fonction. wpautop n'est pas responsable des changements que vous voyez se produire lorsque vous basculez entre les onglets de l'éditeur. C'est quelque chose de complètement différent.

Quoi qu'il en soit, j'ai désactivé wpautop, conformément aux bonnes pratiques lorsque vous utilisez l'éditeur HTML. À partir de ce moment, j'ai désactivé l'éditeur visuel pour commencer par les erreurs d'entité html présentes lors de l'enregistrement d'une publication. Grâce à l'aide d'un C. Bavota, j'ai trouvé un extrait pour convertir toutes les balises de l'éditeur HTML en leurs entités équivalentes avant de les afficher sur le front-end du site (crédit: http://bavotasan.com/2012/convert -pre-tag-contents-to-html-entity-in-wordpress / ).

#add_filter( 'the_content', 'pre_content_filter', 0 );
/**
 * Converts pre tag contents to HTML entities 
 *
 * This function is attached to the 'the_content' filter hook.
 *
 * @author c.bavota
 */

function pre_content_filter( $content ) {
        return preg_replace_callback( '|<pre.*>(.*)</pre|isU' , 'convert_pre_entities', $content );
}


function convert_pre_entities( $matches ) {
        return str_replace( $matches[1], htmlentities($matches[1] ), $matches[0] );
}

add_filter( 'the_content', 'pre_content_filter', 10, 2 ); 

Cela élimine efficacement les problèmes de conversion de toutes les entités en balises par Wordpress lors de l'enregistrement en le contournant. Maintenant, vous pouvez utiliser l'éditeur HTML et écrire du code standard entre les balises "pre" sans faire la conversion d'entité vous-même. Cela prend en charge tous les problèmes de conversion d'entités dans Wordpress et garantit que tout s'affiche correctement sur le front-end. Maintenant, nous devons comprendre quoi accrocher pour modifier le comportement rencontré lors d'un clic d'avant en arrière entre les onglets. À l'heure actuelle, il semblerait que lorsque vous passez du HTML à l'onglet visuel, le contenu de l'onglet HTML soit interprété par javascript ou quelque chose pour essayer de fournir une mise à jour en direct de ce à quoi le contenu devrait ressembler. Cela provoque le traitement des balises (qui sont affichées sous forme non d'entité dans l'onglet HTML) au lieu d'être affichées. Alors, lors du retour à l'onglet HTML, il semblerait que TinyMCE transmette les données actuelles. Cela signifie que lorsque vous revenez en arrière, vous perdez votre structure HTML. Nous devons trouver un moyen de dire à TinyMCE de tout convertir dans les balises pre en entités équivalentes avant de le charger dans la fenêtre (essentiellement la version backend de ce que nous avons fait sur le frontend mais avec tinymce et javascript au lieu de php et hooks), afin qu'il soit affiché au lieu d'être traité. Suggestions? s entités équivalentes avant de le charger dans la fenêtre (essentiellement la version backend de ce que nous avons fait sur le frontend mais avec tinymce et javascript au lieu de php et hooks), afin qu'il soit affiché au lieu d'être traité. Suggestions? s entités équivalentes avant de le charger dans la fenêtre (essentiellement la version backend de ce que nous avons fait sur le frontend mais avec tinymce et javascript au lieu de php et hooks), afin qu'il soit affiché au lieu d'être traité. Suggestions?

EDIT 2 :

Après quelques recherches supplémentaires, la conversion des entités dans la balise pre lorsqu'elles sont affichées fonctionne bien pour le contenu dans la balise pre, mais disons que j'ai un article de blog avec une ligne comme celle-ci:

"Ensuite, nous devons ajouter cette ligne à notre fichier HTML: <p> Bonjour tout le monde! </p>"

En regardant cette ligne, vous pouvez dire que le code est censé être affiché sur le site et non analysé, mais lorsque le message est enregistré, ces entités sont décodées lors du prochain chargement de modification du post et à chaque enregistrement suivant, elles sont enregistrées en tant que balises html brutes, ce qui les amène à être analysées en amont. La seule solution à laquelle je peux penser jusqu'à présent serait d'écrire dans un code similaire pour la balise "code" que j'utilise pour la pré, puis de simplement envelopper de petites lignes dans la balise "code" et de gros morceaux dans le tag "pré". Quelqu'un a d'autres idées?

Très bien, donc j'ai déjà mis à jour cette question une tonne et ça commence à être surchargé, alors j'ai pensé que j'écrirais cela comme une réponse même si elle n'est pas complète.

Extrapolant de la réponse de @ bueltge, je suis en fait retourné et j'ai trouvé son précédent post en question. Dans ce post, il y avait un plugin répertorié que je n'avais jamais vu auparavant: "Balisage HTML Editor préservé". Ce plugin n'a pas été mis à jour depuis longtemps, mais je viens de le tester avec WP 3.6.1 et il est entièrement fonctionnel. Ce plugin prend automatiquement en charge wpautop, fournit un format unifié pour l'insertion des balises br et p dans l'éditeur visuel et préserve votre balisage lors du basculement entre les onglets.

Pour mes propres besoins, j'ai développé ce plugin avec mes propres fonctionnalités: conversion automatique de toutes les balises html dans les balises "<code>" en leurs entités respectives lors de la sauvegarde. Cela signifie que vous pouvez écrire du code HTML standard dans des balises de code dans l'onglet texte, puis l'enregistrer, et tout le contenu des balises pré sera converti en entités pour un affichage correct sur le front-end du site et l'éditeur visuel. Ce n'est pas la solution la plus élégante que j'ai trouvée à ce jour, mais elle semble fonctionner. Ajoutez cette ligne à votre functions.php après avoir activé le plugin:

function code_content_conversion_filter( $content ) {
        return preg_replace_callback( '|<code.*>(.*)</code|isU' , 'convert_entities', $content );
}

function convert_entities( $matches ) {
        return str_replace( $matches[1], htmlspecialchars($matches[1], ENT_QUOTES | ENT_HTML5, 'UTF-8', FALSE ), $matches[0] );
}

add_filter( 'content_save_pre', 'code_content_conversion_filter', 0);

Maintenant, tapez simplement n'importe quel code HTML valide entre les balises de code, et lorsque vous enregistrez, lorsque l'éditeur revient, ils seront tous convertis en entités. Cela vous permet d'écrire du code plus rapidement. Maintenant, la seule chose qui est toujours un problème est que si vous avez un champ "pré" avec une balise de code imbriquée et du HTML, et que vous allez dans l'onglet visuel et essayez d'insérer une nouvelle ligne dans le code, une balise br est injecté dans votre balise de code dans le HTML. Il doit y avoir une option pour désactiver cela dans TinyMCE. Quoi qu'il en soit, tant que vous modifiez vos pré-champs à partir de l'onglet texte, vous pouvez vous sentir libre de basculer librement entre les onglets, ajouter du contenu sous n'importe quel onglet, enregistrer à partir de l'un ou l'autre onglet, et ne pas avoir à vous soucier du formatage gâché!

Cela résout en fait les 5 points de ma question initiale. Le point 2 est encore un peu floconneux, mais je crois que pour la plupart des gens, cela règle le problème. J'ai l'intention de passer au crible ce plugin à un moment donné et d'extraire les parties nécessaires, de le combiner avec mes découvertes et de le reconditionner pour le téléchargement public. Mon objectif ici est de créer un plugin d'installation simple en un clic qui écrit comme prévu.

J'espère que cela aide tout le monde!

Au début, je pense que ce problème a été résolu depuis WP version 3.5; voir ticket 19666 à trac . Mais le tinyMCE a un crochet là-bas nous donne la chance de changer le contenu à l'intérieur de l'éditeur et vous ne devez pas analyser la sortie sur le frontend.

Un petit script source. Je n'ai aucun test avec une version WP actuelle, c'était une ancienne solution pour un client.

Ajoutez cette source via le plugin et améliorez le balisage. La fonction vérifie la balise html <preet si elle existe, elle sera remplacée par du balisage.

add_filter( 'tiny_mce_before_init', 'fb_correction_content_tiny_mce' );

function fb_correction_content_tiny_mce( $init ) {

    $init['setup'] = "function(ed) {
        ed.onBeforeSetContent.add( function(ed, o) {

            if ( o.content.indexOf('<pre') != -1 ) {
                o.content = o.content.replace(
                    /<pre[^>]*>[\\s\\S]+?<\\/pre>/g,
                    function(a) {
                        return a.replace(/(\\r\\n|\\n)/g, '<br />');
                    }
                );
            }
        } );
    }";

    return $init;
}

J'ai eu un problème similaire à l' OP, mais pour moi il y avait un problème avec le maintien <h1>en <div>. Voici ce que je voulais garder lors du basculement entre les onglets Texte et Visuel:

Chaque fois que je changeais d'onglet, il <h1>disparaissait. J'ai fait beaucoup de recherches et pour Wordpress 4.7.3, j'ai découvert qu'il existe de nombreuses corrections obsolètes. Il y a eu une mise à niveau du maire de TinyMCE de la version 3 à 4. Les solutions pour la v.3 n'ont pas fonctionné pour la v.4. Après plus de recherche sur Google et la lecture de la documentation originale de TinyMCE version 4, j'ai trouvé la solution pour mon cas en particulier:

1. Installer le plug-in de configuration avancée TinyMCE
2. définissez le valid_childrenparamètre TinyMCE sur+div[h1],h1[div]
3. J'ai également configuré indent=true, forced_root_block=falseet schema=html5(quand j'ai lu la forced_root_blockdescription, je l'ai compris comme un wpautopsubstitut)

En conséquence, je reçois cela (et il résiste au changement de tabulation)