Wann schließt Wordpress Inline-Skripte in CDATA ein?

Ich debugge ein Problem mit einem Skript von Drittanbietern, das WordPress-Benutzer verwenden, indem sie einen Ausschnitt aus Skript und HTML in die Körper ihres Posts kopieren / einfügen, wie (natürlich ein Beispiel aus der realen Welt):

<script>
window.foobar = window.foobar || { hello: function(){ console.log('Hello World'); } };
window.foobar.hello();
</script>

Ich habe festgestellt, dass einige WordPress-Installationen dies in CDATA einschließen, andere nicht (wahrscheinlich durch eine Art DOCTYPE-Überprüfung - obwohl alle Themen, an denen ich dies getestet habe, einen HTML5-Doctype verwendeten).

Beim Umschließen des Skripts in CDATA werden die Benutzer jedoch von dem folgenden Fehler gebissen: https://core.trac.wordpress.org/ticket/3670 (das Schließen >wird fälschlicherweise durch ersetzt >), was dazu führt, dass der Browser den Skriptinhalt ignoriert ::

<script>// <![CDATA[  window.foobar = window.foobar || { hello: function(){ console.log('Hello World'); } }; window.foobar.hello();  // ]]&gt;</script>

Ich besitze selbst nicht zu viel WP-Fu und das Googeln hat mich nur dazu gebracht, das Problem so zu identifizieren, wie es ist. Meine Frage wäre also: Wann genau packt WordPress Inline-Skripte in CDATA-Abschnitte? Kann der Benutzer dieses Verhalten irgendwie verhindern? Kann der Benutzer den oben genannten Fehler irgendwie umgehen, ohne den WP-Kern zu ändern?

themes javascript

— m90
quelle

Beim Einfügen von Inline-JS in den Editor sollte WP dieses Verhalten ausführen. Ich schlage vor, die JS mit wp_head oder wp_enqueue_script in die Warteschlange zu stellen.

— Samuel Elh

Meinen Sie "Post's Body" wie im WYSIWYG-Editor? Soweit ich sehen kann, wird JS beim Drucken von Skripten in CDATA-Tags eingeschlossen (die auf verschiedene Arten aufgerufen werden können), sind jedoch nicht filterbar. Ich könnte mir vorstellen, wenn Sie tun das WYSIWYG eines Post bedeuten, könnte es durch das Thema erledigt einige Filterung auf den Inhalt sein.

— Doug Belchamber

Es wird nicht empfohlen, Javascript im WYSIWYG-Editor zu veröffentlichen. Der Editor verfügt über eine Reihe von Filtern, mit denen Sie Ihre Inhalte bereinigen können, die schlecht mit Inline-JS interagieren. Es gibt Plugins, die in dieser Art von Szenario helfen.

— MikeNGarrett

Eigentlich ist es nicht WordPress, das die CDATATags einfügt , sondern der visuelle Editor TinyMCE. Details zu TinyMCE sind hier offtopic, aber Sie können eine Lösung dafür auf Stackoverflow lesen .

Das Stoppen von TinyMCE ist jedoch möglicherweise nicht die vollständige Lösung, die Sie möchten. WordPress selbst hat auch eine Funktion zum Hinzufügen von CDATATags, wxr_cdatadie bei der Ausgabe einer gültigen XML-Datei verwendet wird, beispielsweise wenn Sie die Datei exportieren möchten, um den Inhalt in einen RSS-Feed zu verwenden. Themen und / oder Plugins können diesen Filter an den Inhalt anhängen, wenn das Dokument eine gültige XML-Datei sein soll.

Hier stoßen Sie dann auf den Fehler , der vor zwölf Jahren erstmals dokumentiert wurde und ungelöst bleibt. Es geht um diese drei Zeilen in the_content:

$content = apply_filters( 'the_content', $content );
$content = str_replace( ']]>', ']]&gt;', $content );
echo $content;

Wie Sie sehen können, str_replaceist das fest codiert, unmittelbar gefolgt vom Echo. Es gibt keine Möglichkeit, diesen Ersatz abzufangen.

Wenn Sie jedoch Ihr Thema steuern, können Sie die Ersetzung puffern the_content und rückgängig machen. So was:

ob_start();
the_content();
$content = ob_get_clean();
$content = str_replace( ']]&gt', ']]>', $content ); 
echo $content;

— cjbj
quelle