Daher wurde diese Frage oft unter verschiedenen Markierungen aufgeworfen. Ich möchte jedoch einen einheitlichen Thread für eine endgültige Lösung dieses Problems vorstellen.
Standardmäßig werden in WordPress beim Hin- und Herwechseln zwischen dem HTML- und dem Visual-Editor in TinyMCE bestimmte Tags aus dem Inhalt entfernt, und es treten andere seltsame Funktionen auf. Zwei bekannte Problemumgehungen für das Schreiben von effizienterem HTML-Code sind das Entfernen der Funktion wp_auto_p mithilfe von Filtern und das Installieren von TinyMCE Advanced sowie das Aktivieren der Option "Entfernen von p & br-Tags beenden".
Das funktioniert leider nur so gut.
Nehmen Sie zum Beispiel das folgende Beispiel:
<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>
Wenn ich diesen Code in den HTML-Editor eingebe, wobei beide oben aufgeführten Optionen bereits aktiviert sind, passiert beim Wechsel zwischen den beiden verschiedenen Editoren nichts, was zu erwarten ist. Leider wird der Code beim Speichern automatisch in folgenden Code konvertiert:
<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>
Wie Sie sehen, werden alle Entitäten im Pre-Tag wieder in tatsächliche HTML-Zeichen konvertiert. Wenn ich dann denselben Beitrag erneut speichere, erhalte ich etwa Folgendes:
<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>
Beachten Sie, dass Wordpress tatsächlich br-Tags in den Beitrag einfügt. Es erübrigt sich zu erwähnen, dass nach einigen Aktualisierungen dieses Beitrags beim Anzeigen im Frontend die beabsichtigte Anzeige bei weitem nicht erreicht wird.
Die einzige Möglichkeit, die hinzugefügte "Formatierungsfunktionalität" loszuwerden, bestand darin, den visuellen Editor über mein Profil zu deaktivieren.
Dies ist eine gute Lösung für mich, wenn man bedenkt, dass ich ein professioneller Webentwickler bin. Für meine Kunden ist diese Lösung alles andere als elegant. Meine Kunden werden größtenteils den visuellen Editor verwenden. Viele meiner Kunden sind nicht sehr technisch versiert und manchmal muss ich ihre Beiträge korrigieren, wenn das Layout kaputt geht. Dies beschränkt mich auf die Verwendung des visuellen Editors, da ich nicht in den HTML-Editor wechseln kann, ohne das Layout zu beschädigen.
Hauptsächlich (und ich denke, es gibt eine große Community, die von dieser Antwort profitieren könnte), welche expliziten Schritte kann ich ausführen, um Folgendes sicherzustellen:
- Ein Beitrag kann im visuellen oder HTML-Editor bearbeitet werden.
- Der Inhalt eines Posts wird beim Wechseln zwischen den beiden Registerkarten in keiner Weise geändert.
- Beim Speichern eines Posts aus dem HTML-Editor wird kein zusätzlicher Inhalt hinzugefügt.
- Beim Speichern eines Posts aus dem HTML-Editor werden keine Entitäten konvertiert.
- BONUS: Wenn Sie einen Beitrag im HTML-Editor speichern, wird jeder Code (z. B. HTML), der in ein Pre-Tag eingeschlossen ist und noch nicht in Entitäten konvertiert wurde, automatisch in Entitäten konvertiert.
Wenn wir das oben genannte Verhalten in TinyMCE durch die Verwendung eines Plugins eines Drittanbieters erzeugen können, können wir im Wesentlichen alle anderen Fragen bezüglich falscher Formatierung durch die Verwendung von TinyMCE beantworten. Ich bin der Meinung, dass viele Menschen davon profitieren könnten.
Es scheint nur logisch, dass es eine bestimmte Funktionalität gibt, die man von einem WYSIWIG-Editor erwarten würde, und das widerspricht dem. Laut aller Logik und Vernunft sind die in Wordpress eingebauten Formatierungsfunktionen mit ihrem aktuellen Setup ziemlich nutzlos. Ich denke, wenn sie diese Formatierungsoptionen verwenden möchten, ist es am besten, den einen oder den anderen Editor zu aktivieren, nicht beide.
UND BITTE: Beantworten Sie diesen Thread nicht mit Problemumgehungen und Downloads für andere WYSIWIG-Editoren, die das Problem beheben. Dies ist ein zugrunde liegendes Problem (obwohl nicht wirklich ein Fehler) mit dem Wordpress-Kern, das behoben werden muss.
EDIT : Okay, ich habe daran gearbeitet und ich denke, Reverse Engineering wird der beste Weg sein, um dieses Problem zu lösen. Im Moment habe ich wpautop deaktiviert (dies ist nur aus Gründen der Übersichtlichkeit eine Funktion, die sich in den Filter "the_content" einfügt, um p- und br-Tags hinzuzufügen, bevor der Text angezeigt wird , und nicht, wenn der Text gespeichert wird. Ich glaube, es besteht Verwirrung Was die Funktionsweise dieser Funktion betrifft, ist wpautop nicht für die Änderungen verantwortlich, die beim Wechseln zwischen den Editor-Registerkarten auftreten.
Wie auch immer, ich habe wpautop deaktiviert, wie es sich für die Verwendung des HTML-Editors gehört. Von diesem Punkt an habe ich den visuellen Editor deaktiviert, um zuerst mit den HTML-Entitätsfehlern zu beginnen, die beim Speichern eines Posts auftreten. Dank der Hilfe von C. Bavota habe ich ein Snippet gefunden, um alle Tags im HTML-Editor in entsprechende Entitäten zu konvertieren, bevor sie im Frontend der Site angezeigt wurden (Quelle: http://bavotasan.com/2012/convert) -vor-tag-inhalt-zu-html-entitäten-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 );
Auf diese Weise werden Probleme mit Wordpress, bei denen alle Entitäten beim Speichern in Tags konvertiert werden, wirksam beseitigt, indem sie umgangen werden. Jetzt können Sie den HTML-Editor verwenden und Standardcode zwischen "pre" -Tags schreiben, ohne die Entitätskonvertierung selbst vorzunehmen. Dadurch werden alle Probleme bei der Entitätskonvertierung in Wordpress behoben und sichergestellt, dass im Front-End alles korrekt angezeigt wird. Jetzt müssen wir herausfinden, woran wir uns anschließen müssen, um das Verhalten beim Hin- und Herklicken zwischen Registerkarten zu ändern. Momentan scheint es so zu sein, dass beim Übergang vom HTML-Code zum visuellen Tab der Inhalt des HTML-Tabs durch Javascript oder etwas anderes interpretiert wird, um ein Live-Update dessen bereitzustellen, wie der Inhalt aussehen soll. Dadurch werden die Tags (die auf der Registerkarte HTML in Form von Nicht-Entitäten angezeigt werden) nicht angezeigt, sondern verarbeitet. Dann, Beim Zurückschalten auf die Registerkarte HTML sieht es so aus, als würde TinyMCE die aktuellen Daten weiterleiten. Dies bedeutet, dass Sie beim Zurückschalten Ihre HTML-Struktur verlieren. Wir müssen einen Weg finden, TinyMCE anzuweisen, alles in Pre-Tags in entsprechende Entities umzuwandeln, bevor wir es in das Fenster laden (im Wesentlichen die Backend-Version dessen, was wir auf dem Frontend getan haben, aber mit Tinymce und Javascript anstelle von PHP und Hooks). damit es angezeigt anstatt verarbeitet wird. Vorschläge? Entspricht Entities, bevor sie in das Fenster geladen werden (im Wesentlichen die Backend-Version von dem, was wir auf dem Frontend gemacht haben, aber mit Tinymce und Javascript anstelle von PHP und Hooks), so dass sie angezeigt statt verarbeitet werden. Vorschläge? Entspricht Entities, bevor sie in das Fenster geladen werden (im Wesentlichen die Backend-Version von dem, was wir auf dem Frontend gemacht haben, aber mit Tinymce und Javascript anstelle von PHP und Hooks), so dass sie angezeigt statt verarbeitet werden. Vorschläge?
EDIT 2 :
Nach einigen Nachforschungen funktioniert das Konvertieren der Entitäten im Pre-Tag, wenn sie angezeigt werden, einwandfrei für den Inhalt im Pre-Tag. Angenommen, ich habe einen Blog-Beitrag mit einer Zeile wie der folgenden:
"Als Nächstes müssen wir diese Zeile zu unserer HTML-Datei hinzufügen: <p> Hallo, Welt! </ P>"
Wenn Sie sich diese Zeile ansehen, können Sie erkennen, dass der Code auf der Site angezeigt und nicht analysiert werden soll. Wenn der Beitrag gespeichert wird, werden diese Entitäten jedoch beim nächsten Ladevorgang für die Bearbeitung des Beitrags dekodiert und bei jedem nachfolgenden Speichervorgang gespeichert als rohe HTML-Tags, die dazu führen, dass sie am Frontend analysiert werden. Die einzige Lösung, die ich mir bisher vorstellen kann, wäre, für das "Code" -Tag, das ich für das Pre-Tag verwende, ähnlichen Code zu schreiben und dann kleine Zeilen in das "Code" -Tag und große Blöcke in das "pre" -Tag. Hat jemand noch andere Ideen?