Cartoons, Comics, Illustrationen, Doodles und Auftragsarbeiten

WordPress verbieten HTML zu verändern

Ist echt unmöglich. Wenn man versucht reines HTML in einem WordPress Artikel oder einer Seite zu schreiben, kommt der interne WordPress-Filter daher und meint er müsse unbedingt Zeilenumbrüche und Paragraphen einfügen und sonst welche Änderungen an dem sorgsamst vorpräparierten HTML-Code tätigen. Pfui ist das, echt frustrierend.

Nachdem ich also eine ganze Weile lang meine Haare am raufen war und alle Tricks aus der Community nichts geholfen haben, wurde ich endlich fündig.

Es musste wieder mal ein Plugin her. So langsam werden es ziemlich viele 😉 aber mit diesem hat der Besucher nichts am Hut. Es tut nichts anderes als zu verhindern, dass WordPress den HTML-Code filtert.

Das schöne dabei ist, dass dieses Plugin nicht global wirkt, weder für alle Artikel und Seiten und auch nicht pauschal für jeweils einen Beitrag.

Durch die Shortcode-Tags

[...] HTML-Code [/...] (die ... durch raw ersetzen.)

können ganz gezielt die Bereiche gesteuert werden.

Das schöne daran ist auch, dass man sogar zwischen visuellem und HTML-Editor wechseln kann. WordPress packt zwar die Shortcodes in Paragraphen-Tags ein, aber das ändert nichts an der Funktionalität. Cool was?

Beispiel:

Für meine zukünftige BlogWall (BlogWall = Linkliste von Bloggern ), muss ich zwingend ’sauberen‘ HTML-Code haben. Was ihr unten seht, ist das fertige Ergebnis (im visuellen Editor sieht es noch etwas anders aus, weil das CSS noch nicht eingebunden ist).

  • W3Filter

    ComicArt und Fundstücke.

 

HTML-Code:

Und das ist der Code im HTML-Editor nach dem Speichern und Filtern UND -ganz wichtig- nach dem hin- und herwechseln zwischen visuellem Editor und HTML-Editor.

laut Aussage des Entwicklers, sollte das eigentlich nur mit der Premium-Version funktionieren. Tut es aber auch so. Vielleicht sieht es dann noch schöner aus? Keine Ahnung.

wordpress-html-raw-format-unfiltered

Wie ihr seht, bis auf ein paar künstliche Leerstellen und Leerzeilen, die aber ohne HTML-Tags geschaffen sind, ist der Code wie ursprünglich.

Fehlt noch was? Ach klar, den Namen des Plugins hätte ich Schussel fast vergessen 😳

Das Plugin nennt sich Raw-Html, und ist sehr aktuell, was ich immer sehr wichtig finde.

Viel Spaß damit und hoffen wir, dass zukünftig diese Basis-Funktionalität in den WordPress-Core Einzug finden wird.

Nachtrag:

Eben entdeckt, im Editor-Modus gibt es sogar noch ein Menü mit Optionen. Was macht denn dann noch die Premium-Version von Raw HTML?

wordpress-plugin-raw-html-options

15 Kommentare

  1. hmm…. ich arbeite ja sehr viel mit HTML, bin damit aber noch nie auf irgendwelche Probleme gestoßen in WordPress. Plugins etc. nutze ich dafür auch nicht 😉

  2. Immer diese frühaktiven Menschen :-)

    Die Foren sind voll von Anfragen und ich hatte ja auch das Problem.

    Also, was ist bei dir anders? Hast du den Advanced Visual Editor installiert? Hast du mal meinen Html-Code ausprobiert? WordPress macht ja nicht bei jedem Html-Tag Mist und auch nicht immer stören diese Änderungen.

    Wie gesagt, viele haben diese unerwünschte Funktionalität, sonst gäbe es dafür auch kein passendes Plugin.

    Aber ist doch schön, wenn du noch keinen Ärger damit hattest :-) .

  3. Nein, ich habe gar nichts zusätzliches installiert, was hier greifen würde, weder Plugins noch Features. Vielleicht code ich einfach nur anders in HTML und weiß mir via dem entsprechenden CSS zu helfen 😉

  4. Hmm, das hat mit Html- und Css-Kenntnissen wenig zu tun, wenn WordPress den Code ändert.

    Wenn ich den Code so haben möchte wie vorher aufgesetzt, dann hat WordPress davon die Finger zu lassen. Meine Meinung.

  5. Mir hat WordPress noch nie was verändert 😉

  6. Dann hast du entweder nie richtig hingesehen, oder du hast bisher nur Basis-Html verwendet 😉

    Fällt es dir tatsächlich so schwer zu akzeptieren, dass genügend Leute das Problem haben und es nicht an mangelnden Html-Kentnissen hapert, sondern dass WordPress ganz objektiv und nachvollziehbar den ursprünglichen Code in manchen Fällen so verändert, dass nicht mehr dass gewünschte Ergebnis geliefert wird?

    Tippe doch einfach mein Beispiel ab und gut ist.

  7. Nö, schwer von Begriff bin ich nicht. Ich wollte eben nur mitteilen, dass ich sehr sehr viel mit HTML und CSS in WordPress arbeite und mir das noch nie passiert ist.

    Dein Beispiel kann und möchte ich nicht abtippen, denn a) fehlt das gesamte CSS dazu, b) habe ich keine Ahnung wie das Endergebnis aussehen sollte und c) ist es mir definitiv viel zu verschachtelt. Ich löse aufwendigeren Dinge immer gerne weniger verschachtelt, dafür mit mehr CSS 😉

  8. Das du nicht schwer von Begriff bist ist mir schon klar, nur ein wenig kampfeslustig momentan 😉

    Es ist ja auch nicht so, dass WordPress immer und grundsätzlich den Quelltext verändert und es auch nicht immer tragisch ist. Aber manchmal möchte man halt, dass WordPress komplett die Finger von dem Quelltext lässt. Eine neue Zeile oder ein Absatz gehören nun mal nicht einfach so rein gepflanzt.

    Ich finde es ja auch schön, dass du dieses Verhalten niemals beobachtet hast, ehrlich, aber genügend Leute haben es leider schon erlebt. Mehr kann ich dazu nicht sagen.

    Und dass du die paar Zeilen nicht abtippern möchtest (hat ja mit CSS nichts zu tun) zeigt mir ja auch, dass es dir ziemlich egal ist, was WordPress tut, Hauptsache du bist davon ’noch‘ nicht betroffen.

    Schön für dich, für die anderen gibt es ja noch ein Plugin 😉

  9. Also WordPress macht mir da auch gerne Probleme. Schon alleine dass der HTML-Editor nicht alle HTML Tags anzeigt ist ein wenig blöd, z.B. und
    Beim hin- und herwechseln zwischen visual und html werden einfach s gesetzt und gelöscht.

  10. „z.B. br und p“
    „p-Tags gesetzt und gelöscht“

    scheinbar werden die kommentare nicht richtig escaped? ist das standard?

  11. Entschuldige bitte die späte Freigabe, war zu sehr mit Abschlussprojekt, G+ und neuem Comic beschäftigt.

    Das mit dem Strippen der Tags innerhalb von Kommentaren habe ich auch festgestellt :-) in Drupal weiß ich, dass man genau angeben konnte, welche Tags erlaubt sind. Das müsste in WordPress eigentlich auch möglich sein. Ich werde mal nachforschen wo und wie das geht, denn br p und pre sollten schon gehen dürfen.

    Ich finde es zwar auch micht so prickelnd noch ein weiteres Plugin installiert zu haben, aber speziell für die BlogWall möchte ich keine Code-Ergänzungen seitens WordPress haben.

  12. <?php echo allowed_tags(); ?> ist die Lösung, damit kannst Du im Kommentarbereich des Themes die erlaubten Tags für die Kommentare anzeigen.

    Ich weiß jetzt wohl auch warum ich dieses von Dir beschriebene Verhalten von WordPress nie erlebe: Ich schreibe ausschließlich nur im HTML Editor, den visuellen nutze ich nie (auch kein Wechseln hin und her) 😉

  13. Das ist ja super! Danke :-) Weißt du auch, wie man die Liste der erlaubten Tags erweitern kann?

    Gut, dass das Thema endlich geklärt ist. Ich hatte schon das Gefühl, wir würden nie auf einen gemeinsamen Nener kommen 😉

    Hast du denn den TinyM Advanced gar nicht installiert oder nur nie verwendet? Weil ich mir dann ernsthaft überlege, den wieder zu deinstallieren. Zwingend brauche ich den nicht.

  14. Ne, weiß ich leider nicht.
    Und Tiny… für was sollte ich das brauchen? Ich schreibe immer nur im HTML Modus, genauso wie ich immer nur im Notepad progge 😉

  15. Das erklärte ja so einiges an dem unterschiedlichen WordPress-Verhalten.

    So langsam gelange ich auch zur der Einsicht, dass ich mir für ein paar mehr Annehmlichkeiten eine Menge mehr Ärger einhandle.
    Ich werde das Tiny… Plugin mal deaktivieren und mal schauen, wie sich das sonst auswirkt.

\\n