Inhaltsverzeichnis
Es ist doch immer wieder erstaunlich, dass 70% aller Websites auf einem CMS basieren, das irgendwie nicht für das Erstellen von Websites geeignet ist. Sehen Sie heute aus der Reihe Werbe-Markt.de ❤ WordPress: Mikrodaten.
Das schema.org ImageObject
Das Beispiel ist relativ willkürlich gewählt, zeigt aber sehr prägnant, wie man mühevoll erstelltes Markup binnen 2 Sekunden zerstören kann. Das ImageObject dient der maschinenlesbaren Auszeichnung von Bildern und ist unter anderem in Zusammenhang mit AMP und Google’s Carousel unabdingbar.
Genauso könnte ich zeigen, wie Sie die Auszeichnung von Adressdaten mit Telefon, Fax und Geodaten am besten direkt über die Datenbank-Tabelle wp_posts statt über das WordPress-Admin vornehmen. Oder wie man ein Video in einen Post einbettet, mit Markup versieht und den Beitrag dann niemals wieder bearbeitet. Auch die Syntax-Highlighter für die Gestaltung der Codebeispiele bereiten ein ums andere Mal wieder große Freude.
Der Code
Wenn Ihnen das im Video zu schnell ging – das hier ist der ursprüngliche HTML-Code:
<figure itemtype="//schema.org/ImageObject" itemscope itemprop="image"> <img src="https://s.w.org/about/images/logos/wordpress-logo-notext-rgb.png" alt="I love WordPress"> <figcaption itemprop="caption">Love it!</figcaption> <meta content="300" itemprop="width"> <meta content="300" itemprop="height"> </figure>
Das Problem
Zu einer sachlichen Problemanalyse würde nun gehören, zu ergründen, warum der gute WYSI… WTF? Editor den Code so dermaßen verunstaltet. Im nächsten Schritt würde man sich versuchen, in TinyMCE einzuhaken, die Konfiguration zu verändern etc. Davon abgesehen, dass dies unerwünschte Nebeneffekte zur Folge hätte: Ist es nicht Sinn von WordPress, sich genau damit nicht beschäftigen zu müssen, sondern ganz einfach Inhalte veröffentlichen zu können? Stattdessen sieht der Code dann so aus:
<figure> <figure><img src="https://s.w.org/about/images/logos/wordpress-logo-notext-rgb.png" alt="I love WordPress" /><figcaption>Love it!</figcaption> </figure> </figure> <meta itemprop="width" content="300" /> <figure> <figure> </figure> </figure> <meta itemprop="height" content="300" /> <figure> </figure>
Die Lösung
Einerseits gibt es Plugins und einfache Codeschnipsel, die TinyMCE dahingehend manipulieren, den Code nicht zu zerstören bzw. versuchen, ihm Attribute wie itemscope etc. beizubringen. Ich habe damit leider durchweg negative Erfahrungen gemacht.
Mein Lösungsansatz für das vorliegende Problem beim ImageObject ist daher, die native WordPress-Funktionalität beizubehalten und sich in den Filter zur Ausgabe einzuhaken. Der beispielsweise in die functions.php des verwendeten Themes einzufügende PHP-Code versteht sich lediglich als Beispiel und ist ggf. den individuellen Bedürfnissen anzupassen.
add_filter('img_caption_shortcode', function ($figure, $args, $content) {
$atts = shortcode_atts(array('id' => '', 'align' => 'alignnone', 'width' => '', 'caption' => '', 'class' => '',), $args, 'caption');
$height = preg_replace('/.*height="?(\d+).*/', '$1', $content);
$figure = '<figure class="' . $atts['class'] . '" itemprop=image itemscope itemtype="//schema.org/ImageObject">' . $content . '<figcaption itemprop=caption>' . $atts['caption'] . '</figcaption><meta itemprop=width content=' . $atts['width'] . '><meta itemprop=height content=' . $height . '></figure>';
return $figure;
}, 99, 3);
Statt des HTML-Codes füge ich die gewünschte Bilddatei einfach über den Medien hinzufügen-Button von WordPress in den Beitrag oder verwende direkt den nativen Shortcode. So oder so sieht der eingefügte Shortcode für das ursprüngliche Beispiel dann etwa so aus und ist vor TinyMCEs Zerstörungswut sicher:
[caption width="300"]<img src="https://s.w.org/about/images/logos/wordpress-logo-notext-rgb.png" alt="I love WordPress"> Love it![/caption]