Support » Allgemeine Fragen » Verhindern, daß WordPress Microdata in Beiträgen löscht

  • Gelöst wordptester

    (@wordptester)


    Hallo zusammen,

    kann mir jemand bitte verraten, wie Microdata (nach schema.org), die im Text-Modus in Beiträge eingefügt wurden, nicht umgehend von WordPress wieder gelöscht werden?
    O.K., es gibt Plugins wie Ravens Schema Creator aber letzteres z.B. schreibt nicht:

    <div itemscope itemtype="http://schema.org/Person">
    	<span itemprop="name">[MeinName] ...</span>

    sondern
    [schema type="person" ...

    BTW: Warum wird der vom Plugin eingefügte String _nicht_ von WordPress gelöscht? Und: kann ich das für die gewollte Syntax irgendwie nutzen?

Ansicht von 11 Antworten - 1 bis 11 (von insgesamt 11)
  • Wenn ich das hier richtig verstehe, schreibt das Plugin nicht [schema type="person" ... in den Output. Es handelt sich vielmehr um die Shortcode-Syntax, welche für den Editor verwendet wird. Der Shortcode wird dann beim Zusammenbauen der Seite geparst und vermutlich wird dabei auch die von Dir erwartete Struktur erstellt.

    Cheers,
    Dennis.

    Du könntest (hoffentlich) Recht haben.
    Als das Ergebnis im html-Editor so gänzlich anders war als die bei schema.org beschriebene Syntax, habe ich das nicht geprüft.
    Ich bin wohl etwas schnell davon ausgegangen, daß das Plugin da eine einfach eine andere Syntax produziert.
    So wie der Text-Editor ja sowieso ’ne ziemlich eigene Sache ist.
    Mich nervt schon immer, daß der Text-Editor von WordPress kein richtiger html-Editor ist,
    – eine eigene Eingabe der Syntax entsprechend schema.org wurde nach Switch in visuell und zurück nach text von WordPress gelöscht
    – das <hr />-Tag im visuellen Editor nicht sichtbar
    – im visuellen Editor eingefügte Linebreaks oder Absatzmarken <p> sind im Text-Editor unterschiedslos, manchmal ein &nbsp
    – … und und und
    Komisch nur, daß das sonst niemanden zu stören scheint.

    Danke für die Antwort und
    beste Grüße

    So wie der Text-Editor ja sowieso ’ne ziemlich eigene Sache ist.

    It’s not a bug, it’s a feature. – Die meisten Blogger möchten eben nicht HTML programmieren, sondern sich auf Inhalte konzentrieren. Alles, was auch nur ansatzweise mit Programmierung zu tun hat, wird über Plugins erledigt. Damit der Nutzer Plugins direkt in seinen Beiträgen anwenden kann, werden Shortcodes (eine Art Textbaustein) angeboten, in denen man Parameter übermitteln kann. Alles in eckigen Klammern ist ein Shortcode, Attribute und Eigenschaften sind Parameter, die an das Plugin übermittelt werden.

    Es gibt übrigens auch Plugins, mit denen sich die Umwandlung von Zeilenschlägen in Absätze (durch Hinzufügen des Paragraph-Tags <p>) abschalten lässt.

    Interessanter Ansatz. Sich nicht um HTML kümmern zu wollen, sei den ‚meisten Bloggern‘ gerne gegönnt. Aber ist dafür nicht der visuelle Editor gedacht?
    Wenn es schon ‚Text‘ heißt, dann doch bitte richtig und nicht diese Mischung. So manches direkte html-Editing bleibt ja durchaus von der Löschung verschont. Das ist nicht Fisch und nicht Fleisch.

    RawHTML oder PostSnippets sind ja Ansätze, um in reinem HTML arbeiten zu können. Leider wird alles von/in RawHTML Geschriebene sofort durch den Wolf des visuellen Editors gedreht, sobald man den Post (versehentlich) im Modus des visuellen Editors öffnet. Ich habe auch eine Möglichkeit gesehen, den visuellen Editor abzuschalten und nur mit „Allways Edit in HTML“ zu arbeiten. Das wiederum geht nur für alle User/Redakteure ==> schade.

    Die Umwandlung von Zeilenschlägen in Absätzen (<p>) kann man durch ein Plugin verhindern? Das wäre ja ein Ansatz, wenn auch nur ein Teil. Welches Plugin wäre das?

    Beste Grüße

    Zu dem Thema kannst Du gern einen eigenen Thread starten, @wordptester.

    Ist Dein Microdata-Problem nun gelöst? Dann markiere es bitte auch als solches. Bitte immer auch an User denken, die eventuell das gleiche Problem haben, eine Lösung suchen und mit dem Off-Topic dann nichts anfangen können.

    Cheers,
    Dennis.

    Naja – gelöst … schaun wir mal 😉 auf jeden Fall werde ich den Thread als „gelöst“ markieren.
    Euch beiden natürlich großen Dank, daß Ihr Euch die Zeit genommen habt, Euch mit meinen Problemchen auseinander zu setzen.
    Beste Grüße

    Moderator Torsten Landsiedel

    (@zodiac1978)

    Gelöst ist es ja nicht wirklich, oder?

    Das sieht ja weniger nach einem WordPress-Problem aus, sondern nach einem TinyMCE-Problem.

    Du könntest bei deren Bugtracker mal ein Ticket erstellen:
    http://www.tinymce.com/develop/bugtracker_bugs.php

    WordPress/TinyMCE versucht halt den HTML-Text um falsches HTML zu bereinigen. Dadurch werden „bleeding edge“ Funktionen gerne mal ausgefiltert.

    Um das zu verhindern kannst Du auf die Konfiguration des TinyMCE per Filter zugreifen:
    http://codex.wordpress.org/TinyMCE#Customize_TinyMCE_with_Filters

    So lassen sich zusätzlich erlaubte Tags/Attribute hinzufügen:
    https://snipt.net/jamesw/prevent-tinymce-from-stripping-schemaorg-attributes-in-wordpress/

    Gruß, Torsten

    Torsten, hier ging es darum, dass nicht verstanden worden war, dass der Shortcode beim Rendern der Seiten erst in HTML umgewandelt wird. Der Teil mit den Rants war nach meinem Empfinden Offtopic…

    Moderator Torsten Landsiedel

    (@zodiac1978)

    Ja, richtig, aber ich dachte, das würde hier ganz gut passen …

    Gruß, Torsten

    War auch neu für mich, was Du da mit eingebracht hast. Hab ich mir gleich gebookmarked. 😉

    Danke Torsten für die Links und das konstruktive Wieder-Aufgreifen meines Problems.
    Genau genommen hat Dennis natürlich Recht und das war eine Abschweifung meinerseits.

    Tatsächlich muß es möglich sein, reines HTML mit dem TinyMCE zu schreiben. Er wird ja noch in einigen anderen CMS eingesetzt und dort ist reines HTML möglich. Es ist also WordPress, das filtert, was aber in der WordPress-Philosophie konsequent ist.

    Wenn man – wie WordPress – versucht, es den Redakteuren/Usern so leicht wie möglich zu machen (z.B. durch Ausfiltern jedes falschen HTMLs), dann ist es natürlich unvermeidbar, daß _jeder_ Code bei einmaligem Ansehen durch den visuellen Editor wieder durch die Mühle gedreht wird.
    Insofern macht es nur Sinn, einen reinen HTML-Editor (wie ich es mir wünsche) anzubieten, wenn man damit gestaltete Beiträge/Posts für den visuellen sperren könnte.
    Und letztlich bin ich ja nicht gegen das Ausfiltern falschen HTMLs. Es stört mich, daß ich Tags, die WP ja im visuellen Editor einsetzt, im Texteditor nicht sehen kann (dort nur Leerzeile oder &nbsp – war das eigentlich ein Absatz oder ein
    ? Und es stört mich, daß auch korrektes HTML ausradiert wird.
    Ich werde mir auf jeden Fall Deine Links ansehen, vielen Dank.
    Beste Grüße

Ansicht von 11 Antworten - 1 bis 11 (von insgesamt 11)
  • Das Thema „Verhindern, daß WordPress Microdata in Beiträgen löscht“ ist für neue Antworten geschlossen.