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>
<script type="text/javascript" src="/path/to/jquery.easycolumns.js"></script>
</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:
- Un article peut être édité à partir de l'éditeur visuel ou HTML.
- Le contenu d'un article n'est en aucun cas modifié lors du basculement entre les deux onglets.
- Lors de l'enregistrement d'une publication à partir de l'éditeur HTML, aucun contenu supplémentaire n'est ajouté.
- Lors de l'enregistrement d'un article à partir de l'éditeur HTML, aucune entité n'est convertie.
- 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?
