dynamicinternet Wir machen Ihr Web dynamisch!

WordPress Magazin Themes

geschrieben von Micha am 01. Juli 2008 | 7 Kommentare

Magazin Themes für WordPress sind sehr beliebt, vor allem im internationalen Markt sieht man sehr viele Anbieter sogenannter „Premium Themes“. Sie offerieren sie dem Nutzer mehr oder weniger zusätzliche Optionen bzw. Templates, um eben diesem Magazincharakter gerecht zu werden.
Ich habe mir eine Menge solcher Themes  angeschaut und auch auf den entsprechenden Seiten die Foreneinträge bzw. Tutorials zu den Themes gelesen, um herauszufinden, was diese Themes so toll macht.
In diesem Beitrag soll es nicht darum gehen, andere Arbeit schlecht zu machen. Ich habe mich wirklich intensiv damit auseinandergesetzt und würde ganz gerne Meinungen hören, weil mir Dinge aufgefallen sind, die für mein Verständnis nicht optimal sind. Das heißt natürlich nicht, dass mein Verständnis das Richtige ist.

Schaut man sich die Demos dieser Magazin Themes an, stellt man fest, dass alles Kategorie-basiert aufgebaut ist. Eine Kategorie ist meist ganz oben als „featured“  Kategorie besonders hervorgehoben, gefolgt von mehreren anderen Kategorieansichten in unterschiedlichen Rastern. Auf den Demoseiten sieht auch alles superchic aus. Es sind immer dieselben, gleichlangen Dummytexte mit gleichem Datum und ein paar pixelgenau erzeugten Bildern, die über benutzerdefinierte Felder eingefügt werden. Also wirklich nichts Spannendes.
Nehmen wir das eben Festgestellte mal auseinander.

Kategorie vs. Chronologie

Die kategoriebasierte Anordnung macht die zeitliche Abfolge der Artikel kaputt. Was ist, wenn gerade in der „featured“ Kategorie eine Woche kein neuer Artikel erscheint? Dann sieht die Webseite aus, als wäre sie tot. Anders herum kann ein Artikel aus einer anderen Kategorie vielleicht der Hammer sein, wird aber nicht als Teaser dargestellt, weil er nicht in dieser featured Kategorie ist. Für mein Verständnis ist das nicht optimal.
Der nächste Punkt ist, das eben diese Kategorieansichten alle hardcoded sind, das heißt, der vielleicht programmierunkundige Nutzer muss in zig Templates Kategorie-IDs editieren. Was, wenn er eine neue Kategorie hinzufügt, wo soll er die dann reinschreiben? Hinzu kommt, dass jedes Query, welches eine Kategorie listet, 4 Datenbankabfragen verursacht, egal, ob eine oder 5 Posts geholt werden. Wenn ich also 10 Kategorien auf der Startseite liste, habe ich schon mal 40 Querys zusätzlich. Das sollte man nicht aus den Augen verlieren.
Da diese Themes auch meistens eine Sidebar haben und diese auch gefüllt sein muss, sieht man oft eine Liste mit den „Recent Posts“. Schaut man da etwas genauer hin, sieht man die gleichen Artikel, die schon irgendwie kategoriebasiert auf der Seite zu sehen sind, noch einmal in chronologischer Abfolge gelistet. Daran sieht man sehr schön die Problematik. Würde ich zB. 15 Artikel chronologisch auf der Seite plazieren, könnte ich mit einem Offset von 15 die nachfolgenden  10 „Recent Posts“ listen, was für mich mehr Sinn macht, da einfach mehr Informationen auf der Seite sind. Kategorien sind einfach zu starr.
Das liegt daran, dass eine Post zunächst nichts mit einer Kategorie zu tun hat. Das Post-Objekt von WordPress hat keine Informationen über die Kategorie. In einem 2. Query werden die Terms (Kategorien und Tags) geholt und in einem eigenen Objekt abgelegt, auf das dann zugegriffen werden kann. Jetzt kann ja einer sagen, man könnte ja beide Objekte mergen und sonst was mit anstellen, unterm Strich ändert das nichts an der Tatsachen, das ich entweder kategoriebasiert oder chronologisch sortieren kann, beides zusammen geht nicht.

Das heißt natürlich nicht, dass Kategorien nutzlos sind. Man kann durch Unterteilung in Kategorien den Lesern spezielle Interessenbereiche zur Verfügung stellen, zusätzlich auch mit Kategoriefeed, man kann für jede Kategorie eigene Templates schaffen, was auch immer. Nur auf der Startseite würde ich mir eine chronologische Abfolge vorziehen. Der SPON hat ja auch immer seinen Topartikel oben, egal ob er aus der Kategorie Politik, Sport oder Schlagmichtot ist. Ich finde, der Aufbau der Struktur einer Seite findet beim Nutzer statt, nicht durch das Werkzeug.

Bilder zum Artikel einfügen

Nun zu den Bildern. Die meisten dieser Magazin Themes verwenden benutzerdefinierte Felder, um die Artikel herauszustellen. Ist das jetzt gut oder schlecht? Gehen wir mal alle Möglichkeiten, Bilder zu einem Artikel hinzuzufügen, mit Vor- und Nachteilen durch.

Mit benutzerdefinierten Feldern

Das Einfügen eines Bildes über benutzerdefinierte Felder ist ein Mehraufwand für den Nutzer. Auch muss er genau wissen, was er einzufügen hat, die komplette Url oder nur einen Teil der Url , je nachdem, wie das Theme gecodet wurde. Kann also leicht zu Verwirrungen führen. Ein weiterer Nachteil ist, dass das Bild vielleicht die Größe für den Teaser hat, wenn der Artikel später aber „runterrutscht“, wo eigentlich die Artikel mit einem kleinen Vorschaubild stehen sollen, ist das Bild zu groß. Da hilft Verkleinerung durch CSS meistens auch nicht wirklich. Ein Vorteil ist, das man Bilder mehrfach verwenden kann, zB. ein WordPress Logo kann man in zig Artikel einfügen, ohne jedesmal ein neues hochladen zu müssen. Ein weiterer Vorteil ist, das Auslesen des benutzerdefinierten Feldes verursacht keine zusätzliche Datenbankabfrage, weil die Metas eh bei jeder Post geholt werden.

Durch Einfügen in den Auszug (the excerpt)

Im Grunde das Gleiche wie bei den benutzerdefinierten Feldern. Unflexible Bildgröße, keine zusätzlichen Datenbankabfragen. Möglicherweise verständlicher zu nutzen.

Durch normales Einfügen eines Bildes zum Artikel und automatisches Auslesen des Bildes.

Für mich der interessanteste Part, allerdings auch mit Nachteilen verbunden. WordPress speichert alle Bilder in 3 Größen ab, Originalgröße, Medium und Vorschaubild. Das macht die Geschichte schon flexibler. Der Nutzer braucht nur zu seinem Artikel ein Bild hochladen und ich kann für bestimmte Ansichten die Medium-Auflösung auslesen oder das Vorschaubild. Dafür verursacht WordPress pro Artikel 2 zusätzliche Datenbankverbindungen (Bild holen und Bildmetadaten holen). Ein weiterer Nachteil ist, das Bild muß zum Artikel gehören (direkt zur Post hochgeladen werden), sonst funktioniert es nicht. Das liegt daran, das auch ein Bild eine Post ist und die Post „Bild“ mit dem Artikel, in dem sie sich befindet, nur über das Feld post_parent verbunden ist. Selbst wenn man das Bild über die Url in einen anderen Artikel einfügt, es ist immer mit dem Artikel verknüpft, zu dem es hochgeladen wurde. Der Wert wird nicht updated. Nix mit Mehrfachverwendung von Bildern. Der Nutzer hat allerdings bei dieser Variante die wenigste Arbeit und ich die meiste Freiheit.
Was machen? Alles zusammen geht nicht.
Wie man sieht, ein spannendes Thema. Was ist der beste Weg? Was wollen die Nutzer eines Magazinthemes? Fragen über Fragen. Allen zugleich kann man es eh nicht recht machen, je mehr man aber von der Zielgruppe anspricht, umso größer der Erfolg.