Eine neue Seite bauen - Architektur

Beim Bauen einer Seite muss man sich gewissen Dingen bewusst sein. Diese sollen hier kurz erläutert werden. Ziel ist es, dass jeder, der eine neue Seite baut, sich dieses Kapitel noch einmal zu Herz nimmt und dann die Grundlagen der Seite definiert.

Grundsatz: Je mehr Module eingesetzt werden, desto mehr Ressourcen braucht sie und desto schwieriger ist sie zu warten! Daher soll man sich laufend die Frage stellen: "Ist dieses Modul wirklich notwendig und brauche ich es auch wirklich, oder kann ich damit nur gerade 20% von dem Abdecken, was ich mir eigentlich erhofft habe.

Inhaltstypen anlegen und planen

• Was für Inhaltstypen werden benötigt?
• Welche CCK Feld brauchen diese Inhaltstypen? Können Felder mehrfach eingesetzt werden?
• Ja, man darf und soll diese Informationen auch aufschreiben, sprich im Voraus planen.

Es gibt die Möglichkeit, Felder mehrfach zu verwenden. Die Vor- und Nachteile werden auf einer Unterseite näher erläutert. Eine kleine Bemerkung zur Mehrfachverwendung vorweg:
Achtung! Kardinalität und Required (Globale Feldeinstellungen) müssen über alle Felder des gleichen Typs identisch sein, bzw. werden automatisch identisch gehalten

Taxonomy vs. CCK vs Inhaltstypen

Schlussendlich müssen Inhaltstypen bzw. thematisch Unterscheidungen feststellbar sein. Mit Taxonomy, CCK und Inhaltstypen überschneiden sich z.T. in ihrer Funktionalität, bzw. es lassen sich die selben Konzepte abbilden, was aber nicht wirklich die Meinung ist:

Taxonomy: Diese dient der thematischen Klassifizierung: Inhat A gehört in die Kategorie "Politik", Inhalt B in "Sport". Von der Struktur her sind jedoch beide Artikel identisch. Dies liess sich mit CCK Felder abbilden oder auch mit Inhaltstypen (ein Inhaltstyp Sport, einer Politik), was jedoch nicht sinnvoll ist.

CCK: Mittels CCK lassen sich Auswahlfelder machen. Beispiel dafür wäre: "Artikel ist importiert: Ja, Nein". Auch dies liesse sich mit den beiden anderen Konzepten abbilden. CCK ist der Taxonomy dann vorzuziehen, wenn es nicht inhaltliche Angaben eines Nodes sind (z.B. ein Status), nicht aber um eine eigentlich Klassifizierung des.

Inhaltstypen: Immer dann, wenn die gleichen Felder bzw. viele Felder gleich sind, kommen Inhaltstypen zum Zug, z.B.: Ein Inhaltstyp Artikel, welcher aus einem Titel, einem Lead und einem Body besteht, oder ein Inhaltstyp Bild, welcher aus einem Bild sowie einem Titel besteht.

Nodepermissions

Nodepermissions sind nicht als solches in Drupal Core drin. Standardmässig kann ein User Inhalte entweder lesen oder nicht. Mit Modulen, welche Nodepermissions definieren, lässt sich das ändern, so dass festgelegt werden kann, welche Nodes von welchem User gesehen werden kann. Klassisches Beispiel dafür ist das Modul "Organic Groups" (kurz OG)
Der Einsatz dieser Modul hat jedoch zur Folge, dass der Blockcache von Drupal nicht mehr eingesetzt werden kann. Daher: 2x überlegen, ob es das wert ist.

Caching

Cachingoptionen von Beginn auf berücksichtigen und im Hinterkopf behalten. Falls hauptsächlich nicht registrierte Benutzer auf der Webseite sind, müssen die Seite so anlegen werden, dass der Pagecache optimal arbeiten kann. Es gibt einige Elemente, welche nicht mit dem Pagecache harmonieren. Dazu gehören:

• Grundsätzlich alle Elemente, welche für den nicht eingeloggten User verschiedene Zustände annehmen können, wie z.B. eine Umfrage. Daher die Umfrage so bauen, dass sie Cachebar ist (z.B. im Artikel immer die Frage anzeigen und dann nach Abstimmung auf eine neue Seite mit den Resultaten linken)
• Falls viele verschiedene Nodes auf einer Seite sind, dann heisst dass in den meisten Fällen, dass auch entsprechend oft node_load aufgerufen wird, was wiederum heisst, dass die Belastung auf die Datenbank entsprechend gross ist. Lösung: Falls eine Views, dann diese Umbauen (siehe nächster Punk) oder entsprechende Cachingmechanismen einsetzen.

Performante Views bauen

Views ist eine Query Engine für die Datenbank und lässt sich sehr vielseitig einsetzen. Dabei gibt es grundsätzlich zwei Möglichkeiten: 1) Die Nodeanzeige und 2) die Feldanzeige. Je nach dem ist das eine oder das andere besser geeignet. Performancetechnisch ist die Feldanzeige jedoch massiv performanter, da in der Feldanzeige ein Query gebaut wird, welcher alle Informationen holt. In der Nodeanzeige werden die Nodeids geholt und dann für jeden Node ein node_load aufgerufen. Hier ein kleiner Benchmark:

• Inhaltstype "Page" - Standard Drupal (ohne Zusätzliche Feld)
• Views mit 10 items, bestehend aus Titel und Body

Es handelt sich hier um sehr einfache Queries und trotzdem ist der Unterschied signifikant!! Zudem, je komplexer ein Node wird, desto grösser wird die Belastung in der Nodeanzeige. In der Feldanzeige, werden die Queries ein wenig komplexer. Also: Falls performante Views gebaut werden sollen: Feldanzeige (Row Style: Fields) verwenden. Views haben zudem eine Cachingmöglichkeit. Dies kann und soll eingesetzt werden.

Das Templating System

Das Templating System von Drupal ist nicht dazu da, missbraucht zu werden! Ein .tpl File soll von einem Nicht-Entwickler (sprich Designer) verstanden und manipuliert werden können. Daher: jegliche Funktionen, PHP Manipulationen, node_load usw. gehören nicht da rein! Ausnahmen: einfach if Abfragen und einfache for Schleifen.

Display Suite, Panels

Beide Module sind mächtige Werkzeuge für das strukturieren von Inhalt und können verhindern, dass viele .tpl Files geschrieben werden, was wiederum dazu führt, dass die Seite nicht mehr ganz so flexibel ist wie sie sein sollte. Also: Vorher überlegen, ob nicht eines der beiden Module dazu geeignet ist, um zum gewünschten Ziel zu kommen.
Mit Display Suite lässt sich folgendes Usecase sehr gut abbilden: Nodetype "story". Wird auf der Startseite als Teaser angezeigt, zusätzlich in einem Block in einer Views, als kleine Minivorschau, dann natürlich auch noch als Vollansicht. Für alle drei Fälle wird eine andere Ansicht benötigt: node-story.tpl.php wird entsprechend aufgeblasen. Mittels Display Suite, lassen sich Kontexte definieren, z.B. Teaser, Full, Mini. Und dann kann man sagen, wo die Elemente des Nodes (CCK Felder, Body, Title, Links, Autor usw.) platziert werden sollen (links, rechts, oben usw.). Dadurch kann erreicht werden, dass der Node 3x unterschiedlich ausschaut, ohne dass man dafür ein aufgeblasenes (oderen mehrere) tpl anlegen muss, was wiederum den Vorteil hat, dass man es sehr schnell verändern kann.

Context

Context ist ein mächtiges Werkzeug, um unter anderem Blöcke zu verteilen. Das normale Blocksystem lässt sich nur über Pfade regeln. Mittels Context lassen sich Kontext definieren (z.B. Nodetypen, Benutzer, Pfade), worauf eine bestimmte Aktion erfolgen kann (z.B. Block xyz anzeigen).

Benutzerrollen

Genau wie die Inhaltstypen müssen auch die Rollen geplant werden. Wer interagiert mit dem System? Auch hier schadet ein Dokument nicht, um das ganze zu dokumentieren. Grundsätzlich gibt es zwei Vorgehensweisen.

1. Jeder Benutzer hat genau 1 Rolle. Jede Rolle muss mit den entsprechenden Berechtigungen konfiguriert werden. Diese Methode ist sehr einfach zu verstehen und erfordert wenig Planung im Voraus, dafür ist sie auch aufwändiger zu warten, da wenn ein neues Modul installiert wird, die Berechtigungen bei jeder Rolle entsprechend aktualisiert werden müssen.
2. Jeder Benutzer hat mehrere Rollen. Die Rollen sind hierarchisch aufgebaut, also eine Rolle Redaktor hat Berechtigung A und B, eine weitere Rolle Chefredaktor hat die Berechtigung C. Ein Benutzer, welcher Chefredaktor ist, hat dann die Rolle Redaktor und Chefredaktor. Diese Methode erfordert ein wenig Geschickt und sorgfältige Planung und Dokumentation, dafür ist sie massiv einfacher zu warten.

SEO

Von Anfang an daran denken. Ist SEO wichtig für die Seite? Falls ja, dann mit einplanen. Dazu gehören Punkte wie:

• Pathauto einsetzen. Wie sollen die Aliase aussehen? Für jeden Inhaltstyp definieren und dokumentieren. Hier kann man ruhig ein wenig Hirnschmalz reinlegen, denn das gewählte Konzept sollte im Nachhinein nicht mehr geändert werden.
• Zusatzmodule: Werden weitere Module benötigt? Nodewords, Pagetitle usw.
• Semantischen Markup für das Theme verwenden

Eine kluge Regel könnte sein [taxonomy-term]/[title].