Wordpress: body_class() im Layoutalltag http://www.highresolution.info/weblog/entry/wordpress_body_class_im_layoutalltag/ Leider ist die Implementation dieser interessanten und nützlichen Funktion in Wordpress eher unglücklich gelöst. Die Jungs von WPEngineer haben bereits im Februar vorbildlich darüber informiert, welche Klassennamen das Tag ins Markup rendert. Darunter befinden sich zahlreiche allgemein gebräuchliche Klassenbezeichnungen wie: archive author blog category date home page search tag Das Problem bei der Verwendung derart gebräuchlichen Bezeichnungen sind fast zwangsläufig Kollisionen bei der Implementation bestehender CSS-Layouts in Wordpress. Gerade heute habe ich eine Mail zu diesem Thema bekommen: Man kann sich ja mittlerweile im BODY-Tag CSS-Klassen einfügen lassen je nachdem welcher Typ von Seite aktuelle von WordPress ausgegeben wird. Dabei gibt es auch die Klasse “page” für die Seiten in WordPress. Resultat ist, dass sich das dann mit der Klasse “page” aus YAML überschneidet. Ich kann im Moment froh sein, dass es nur eine CSS-Klasse von YAML trifft. Schon innerhalb dieses Bloglayouts hier – würde dieses Blog mit Wordpress laufen – würden weitere Klassenbezeichnungen kollidieren, denn ich verwende in meinem Bloglayout auch Klassenbezeichnungen wie “date” oder “category”. Nur sind diese Klassen in meinem Layout nicht dafür gedacht, an das body-Element geheftet zu werden. Nun könnte ich mein CSS-Framework YAML in einer nächsten Version natürlich anpassen, um der Kollision aus dem Wege zu gehen, aber ich halte dies für den falschen Weg, denn die Welt dreht sich nicht um Wordpress und YAML ist nicht allein von diesem Problem betroffen. Wordpress als Blogtool oder CMS sollte eigenständig kein Markup generieren (soweit die graue Theorie) und es sollte ebenso die Implementation bestehender Layouts nicht durch die Kollision von Klassennamen unnötig erschweren. Ein relativ einfacher und unkomplizierter Lösungsweg heisst: Namespacing. Wordpress könnte allen dynamisch ins Markup generierten CSS-Klassen das Kürzel “wp-” voranstellen (oder dieses sogar im Backend konfigurierbar machen). Bei anderen Content Management Systemen (Bsp: TYPO3) kommt dieses Verfahren bei den meisten Extensions zum Einsatz. Auf diese Weise ließen sich die angedeuteten Probleme leicht vermeiden, während die durchaus sinnvolle Funktionalität weiterhin uneingeschränkt verfügbar bleibt. Leider bin ich selbst zu wenig bewandert in PHP und auch nur ein Gelegenheitsnutzer von Wordpress, dennoch hoffe ich, dass diese Idee auf irgendeinem Kanal an das Entwicklerteam herangetragen wird.   de-de Dirk Jesse Copyright 2009 2009-08-25T;12:36:38+00:00 Kommentar von christian http://www.highresolution.info/weblog/entry/wordpress_body_class_im_layoutalltag/ Um kollisionen zu vermeiden und trotzdem den classennamen sinnvoll zu erhalten gibt es die einfache möglichkeit die classnames gross zu schreiben. wenn also alle cms hersteller ihre standard classen gross machen würden gäbe es keine Kollision mit irgendwelchen css framworks oder einenen stylesheets. Um kollisionen zu vermeiden und trotzdem den classennamen sinnvoll zu erhalten gibt es die einfache möglichkeit die classnames gross zu schreiben.

wenn also alle cms hersteller ihre standard classen gross machen würden gäbe es keine Kollision mit irgendwelchen css framworks oder einenen stylesheets.

]]> 2012-04-13T;14:58:31+00:00 Kommentar von Sven http://www.highresolution.info/weblog/entry/wordpress_body_class_im_layoutalltag/ Interessant ist an dieser Stelle, dass Wordpress wohl unterschiedliche Wege nutzt um Klassen mit ihren Klassennamen auszugeben. Ein Beispiel sind bei Wordpress die Widgets der Sidebar, wenn ich mir dort die automatisch gerenderten Klassennamen anschaue sehe dort ein namespacing-Verfahren. Beispiel: “widget_tag_cloud, widget_text, widget_search, widget_pages”. Warum denn dann nicht auch bei dem neuen Template-Tag?! Interessant ist an dieser Stelle, dass Wordpress wohl unterschiedliche Wege nutzt um Klassen mit ihren Klassennamen auszugeben.
Ein Beispiel sind bei Wordpress die Widgets der Sidebar, wenn ich mir dort die automatisch gerenderten Klassennamen anschaue sehe dort ein namespacing-Verfahren.
Beispiel: “widget_tag_cloud, widget_text, widget_search, widget_pages”.

Warum denn dann nicht auch bei dem neuen Template-Tag?!

]]> 2012-04-13T;14:58:31+00:00 Kommentar von Michael http://www.highresolution.info/weblog/entry/wordpress_body_class_im_layoutalltag/ Ich finde es ja auch nicht toll, was WordPress bei body_class() und post_class() für einen Horror rausbläst. post_class() liefert auf einer Seite ebenfalls die Klasse page. Aber ich muß diese Funktionen nicht verwenden oder ich modifiziere sie. Ich finde es ja auch nicht toll, was WordPress bei body_class() und post_class() für einen Horror rausbläst. post_class() liefert auf einer Seite ebenfalls die Klasse page. Aber ich muß diese Funktionen nicht verwenden oder ich modifiziere sie.

]]> 2012-04-13T;14:58:31+00:00 Kommentar von Roland http://www.highresolution.info/weblog/entry/wordpress_body_class_im_layoutalltag/ body_class() sollte meines Achtens konfigurierbar sein. :) Aber ich nutze schon keine Wortpresse mehr, sondern bald ein eigenes System - mit YAML. :) body_class() sollte meines Achtens konfigurierbar sein. :) Aber ich nutze schon keine Wortpresse mehr, sondern bald ein eigenes System - mit YAML. :)

]]> 2012-04-13T;14:58:31+00:00 Kommentar von Thomas Scholz http://www.highresolution.info/weblog/entry/wordpress_body_class_im_layoutalltag/ Wer YAML mit Wordpress benutzt, wird doch sicher schlau genug sein, einfach get_body_class() zu nehmen. Die Funktion mit der direkten Ausgabe ist für Leute gedacht, die sich sonst nicht weiter mit PHP beschäftigen wollen; niemand muß sie verwenden. Dann kann man wegwerfen, was man nicht braucht, und umbenennen, was stört. Alternativ setzt man auf den Hook body_class in der functions.php einen Filter. Wer YAML mit Wordpress benutzt, wird doch sicher schlau genug sein, einfach get_body_class() zu nehmen.
Die Funktion mit der direkten Ausgabe ist für Leute gedacht, die sich sonst nicht weiter mit PHP beschäftigen wollen; niemand muß sie verwenden.
Dann kann man wegwerfen, was man nicht braucht, und umbenennen, was stört.

Alternativ setzt man auf den Hook body_class in der functions.php einen Filter.

]]> 2012-04-13T;14:58:31+00:00 Kommentar von micha149 http://www.highresolution.info/weblog/entry/wordpress_body_class_im_layoutalltag/ Das neue Template-Tag ist absoluter Mumpitz! Wordpress sollte sich mal ein vernünftiges Template-System anschaffen. Wenn ich PHP-Methoden aufrufen muss, welche direkt ein HTML zurück- oder gar ausgeben, hat irgendwer was falsch verstanden. Damit bin ich bei WP schon einige Male auf die Nase gefallen. Das neue Template-Tag ist absoluter Mumpitz! Wordpress sollte sich mal ein vernünftiges Template-System anschaffen. Wenn ich PHP-Methoden aufrufen muss, welche direkt ein HTML zurück- oder gar ausgeben, hat irgendwer was falsch verstanden. Damit bin ich bei WP schon einige Male auf die Nase gefallen.

]]> 2012-04-13T;14:58:31+00:00 Kommentar von Frank http://www.highresolution.info/weblog/entry/wordpress_body_class_im_layoutalltag/ @Eric: Auch wenn ich Dirk hier recht gebe, so holst du doch weit aus; es ist nicht nur in WordPress ein Problem; außerdem kann man die Funktion von WordPress einfach ersetzen, was aber YAML nicht hilft und zusätzlich kann man die Funktion um eigene Klassen erweitern. Alternativ kann man via Hook auch noch auf die Funktion einfluss nehmen. Also ganz so typisch WP ist es nicht, denn andere Systeme geben diese Möglichkeiten nicht. Trotzdem ist das sicher via Standard Namespacing besser zu lösen. Aber die Idee von WP war hier zusätzlich noch Strings zu nutzen, die immer gleich sind und man so eventuell offen benutzerdef. Stylesheets vereinfachen kann. @Eric: Auch wenn ich Dirk hier recht gebe, so holst du doch weit aus; es ist nicht nur in WordPress ein Problem; außerdem kann man die Funktion von WordPress einfach ersetzen, was aber YAML nicht hilft und zusätzlich kann man die Funktion um eigene Klassen erweitern. Alternativ kann man via Hook auch noch auf die Funktion einfluss nehmen. Also ganz so typisch WP ist es nicht, denn andere Systeme geben diese Möglichkeiten nicht.

Trotzdem ist das sicher via Standard Namespacing besser zu lösen. Aber die Idee von WP war hier zusätzlich noch Strings zu nutzen, die immer gleich sind und man so eventuell offen benutzerdef. Stylesheets vereinfachen kann.

]]> 2012-04-13T;14:58:31+00:00 Kommentar von Dirk Jesse http://www.highresolution.info/weblog/entry/wordpress_body_class_im_layoutalltag/ @Eric So isses. Und Du lieferst gleich einen weiteren Lösungsansatz, Wordpress könnte sich auf das Rendern der Klassennamen beschränken, ohne das class-Attribut mit auszugeben. @Eric

So isses. Und Du lieferst gleich einen weiteren Lösungsansatz, Wordpress könnte sich auf das Rendern der Klassennamen beschränken, ohne das class-Attribut mit auszugeben.

]]> 2012-04-13T;14:58:31+00:00 Kommentar von Eric Eggert http://www.highresolution.info/weblog/entry/wordpress_body_class_im_layoutalltag/ Das ist das typische Wordpress-Problem, es scheint als dächten sie man ist ganz alleine auf der Welt und sie müssten sich um niemand kümmern. Alleine schon, dass es class=”“ mitrendert zeugt schon davon, ich will eventuell ja auch noch eine andere Klasse an meinen Body anhängen. In meinem Textpattern-blog benutze ich als Klasse die Sektion, so: &lt;body class=”&lt;txp:section /&gt;”&gt; würde meine Sektion jetzt page heißen uns sich daher mit YAML (das ich nicht nutze, aber wir simulieren jetzt mal) ins Gehege kommen, ist es ein einfaches daraus &lt;body class=“sect-&lt;txp:section /&gt;”&gt; zu machen und dann im CSS per sect-page darauf zuzugreifen. Das ist das typische Wordpress-Problem, es scheint als dächten sie man ist ganz alleine auf der Welt und sie müssten sich um niemand kümmern. Alleine schon, dass es class=”“ mitrendert zeugt schon davon, ich will eventuell ja auch noch eine andere Klasse an meinen Body anhängen. In meinem Textpattern-blog benutze ich als Klasse die Sektion, so: <body class=”<txp:section />”> würde meine Sektion jetzt page heißen uns sich daher mit YAML (das ich nicht nutze, aber wir simulieren jetzt mal) ins Gehege kommen, ist es ein einfaches daraus <body class=“sect-<txp:section />”> zu machen und dann im CSS per sect-page darauf zuzugreifen.

]]> 2012-04-13T;14:58:31+00:00 Kommentar von xwolf http://www.highresolution.info/weblog/entry/wordpress_body_class_im_layoutalltag/ Betrifft in der Tat ja nicht nur YAML. Mir sind auch gleich die Microformate eingefallen, derren Parser mit einigen der Klassennamen Probleme haben könnten… Betrifft in der Tat ja nicht nur YAML.
Mir sind auch gleich die Microformate eingefallen, derren Parser mit einigen der Klassennamen Probleme haben könnten…

]]> 2012-04-13T;14:58:31+00:00 Kommentar von Dirk Jesse http://www.highresolution.info/weblog/entry/wordpress_body_class_im_layoutalltag/ Das ist zwar eine Überlegung gewesen - siehe Beitrag - aber das bekämpft auch nur die Symptome, aber nicht die Ursache. Zudem würde ich eine über Jahre gewachsene Kompatibilität von YAML zerstören - nur weil ein CMS bei einem optionalen Template-Tag ein bisschen aus der Reihe tanzt. Nein, das ist es mir momentan nicht wert. Für Wordpress-User gibt es mehrere Wege, das “Problem” zu umgehen. Die einfachste wäre, auf den Template-Tag zu verzichten. Wenn das nicht geht, dann kann man innerhalb des YAML-Layouts mit dem Selektor “div.page” störungsfrei arbeiten oder man setzt man setzt die für “.page” definierten Eigenschaften für “body.page” wieder zurück. Dennoch wäre es mittelfristig das Beste, wenn Wordpress hier nachbessern würde. Das ist zwar eine Überlegung gewesen - siehe Beitrag - aber das bekämpft auch nur die Symptome, aber nicht die Ursache.

Zudem würde ich eine über Jahre gewachsene Kompatibilität von YAML zerstören - nur weil ein CMS bei einem optionalen Template-Tag ein bisschen aus der Reihe tanzt. Nein, das ist es mir momentan nicht wert.

Für Wordpress-User gibt es mehrere Wege, das “Problem” zu umgehen. Die einfachste wäre, auf den Template-Tag zu verzichten. Wenn das nicht geht, dann kann man innerhalb des YAML-Layouts mit dem Selektor “div.page” störungsfrei arbeiten oder man setzt man setzt die für “.page” definierten Eigenschaften für “body.page” wieder zurück.

Dennoch wäre es mittelfristig das Beste, wenn Wordpress hier nachbessern würde.

]]> 2012-04-13T;14:58:31+00:00 Kommentar von David Maciejewski http://www.highresolution.info/weblog/entry/wordpress_body_class_im_layoutalltag/ Dann solltest du vielleicht über YAML-Namespaces nachdenken, wenn es WordPress schon nicht macht. Dann solltest du vielleicht über YAML-Namespaces nachdenken, wenn es WordPress schon nicht macht.

]]> 2012-04-13T;14:58:31+00:00 Kommentar von Dirk Jesse http://www.highresolution.info/weblog/entry/wordpress_body_class_im_layoutalltag/ @David, das ist für mich keine echte Lösung, da ich keine Wordpress-Baustelle aufmachen und zukünftig Patches für jede einzelne WP-Version pflegen will. Bei anderen CMS ist Namespacing selbstverständlich. @David,

das ist für mich keine echte Lösung, da ich keine Wordpress-Baustelle aufmachen und zukünftig Patches für jede einzelne WP-Version pflegen will. Bei anderen CMS ist Namespacing selbstverständlich.

]]> 2012-04-13T;14:58:31+00:00 Kommentar von David Maciejewski http://www.highresolution.info/weblog/entry/wordpress_body_class_im_layoutalltag/ Du kannst die Funktion body_class() auch in der Datei funktions.php (liegt bei dir im Template-Verzeichnis) überschreiben. So könntest du diese dann YAML mitgeben. Du kannst die Funktion body_class() auch in der Datei funktions.php (liegt bei dir im Template-Verzeichnis) überschreiben. So könntest du diese dann YAML mitgeben.

]]> 2012-04-13T;14:58:31+00:00