5.x Themes in 6.x konvertieren

Dies ist eine Übersetzung der Seite Converting 5.x themes to 6.x auf drupal.org.
Ein neuer theme developers guide ist spezifisch für Drupal 6 verfügbar.
Modulentwickler, bitte lest die Seite Using the theme layer im module developer guide.

Überblick über die Theme-Änderungen in 6.x

1. Themes haben eine .info- Datei
2. Die Theme Registry
3. Theming durch Template Dateien
4. Template Verwaltung
5. Neue Template Dateien (.tpl.php)
6. Neue Vorschläge für die Namensgebung für Template Dateien
7. Block-Regionen definieren
8. Änderung der Variablennamen für die Block-Regionen
9. Theme-Einstellungen anpassen
10. Neue $signature Variable
11. Die $body_classes variable
12. $language ist jetzt ein Objekt
13. Themes können core- und modulspezifische CSS-Dateien überschreiben
14. Right to left CSS override Dateien unterstützt
15. Submitted by user on date/time ist themable
16. jQuery ist auf 1.2.6 aktualisiert
17. Default JavaScript Datei
18. JavaScript theming

Themes haben eine .info- Datei

In Drupal 5.x Modulen erfolgte die Einführung von .info Dateien, um Metadaten über das Modul (Beispiel, Name, Version, Beschreibung, Abhängigkeiten etc.) zu speichern.
In Drupal 6.x haben auch Drupal Themes eine .info Datei. Siehe vollständige Anleitung writing .info files for themes.

Beispiel themeName.info (Auszug):

Die Theme Registry

Alle Theme-Funktionen müssen jetzt registriert werden. In Drupal 5 wurden alle automatisch gefunden. In 6.x wird neu hook_theme verwendet um alle themebaren Ausgaben zu registrieren.
Die PHPTemplate engine sorgt für diese Registrierung, sodass in den meisten Fällen nicht manuell registriert werden muss.

• Dazu gibt es eine Ausnahme. Forms, die nicht mit dem Standardtheme implementiert sind, werden nicht registriert.
• Siehe Beispiel im Theming Handbuch für mehr Details im Zusammenhang mit dem Form Theming
• Wichtiger Hinweis! Jedesmal, wenn eine neue Theme-Fuktion oder -Template zum Theme hinzugefügt wird, muss die Registry gelöscht werden!

Theming durch Template Dateien

In 5.x konnten themable Funktionen mit dem themeEngine_hook() oder themeName_hook() überschrieben werden. Das ganze Markup wurde in der template.php Datei platziert und mit den Daten zurückgegeben. Oder, um eine separate template Datei zu benutzen (.tpl.php), könnte in 5.x _phptemplate_callback() bentutzt werden.

In 6.x wird _phptemplate_callback() nicht mehr unterstützt, weil es in die main theme() Funktion eingebunden wurde. Aber man braucht sie nicht: So lange der hook als theme Funktion registriert ist (siehe oben), kann man das Standard-Theming überschreiben, indem man entweder eine entsprechend benannte Funktion "themeName_hook" oder eine entsprechend benannte Datei: "hook.tpl.php": erstellt.
Der Hook menu_tree ist zum Beispiel themable. Um ihn zu überschreiben, erstellt man eine Funktion in der template.php mit dem Namen "theme_name_menu_tree()" oder eine Template-Datei im entsprechenden Theme mit dem Namen "menu-tree.tpl.php. Man beachte, dass der Unterstrich _ in einen Bindestrich - geändert wurde.
Die Registry muss gelöscht werden und die Theme-Fuktion oder die Theme-Template-Datei werden das Theming der Menu-Trees übernehmen.

In 5.x, wurde _phptemplate_callback() auch verwendet, um dem hook die Manipulation der Variablen zu erlauben. Folgendes ist nicht mehr erlaubt:

Das Hinzufügen von Variablen in Drupal 6.x ist in der preprocess documentation beschrieben.

• Weitere Details zum Überschreiben ist unter overriding behavior verfügbar
• In diesem Zusammenhang sind auch die Informationen zu den zugrundeliegenden Änderungen zwischen 5 und 6 relevant.

Template Verwaltung

Template Dateien(.tpl.php) können nun besser verwaltet werden, in dem man sie in Unterordnern organisiert.
DIe PHPTemplate engine wird alle im Theme finden und ihren Ort registrieren. Es gibt keine Beschränkung bezüglich der Tiefe dieser Ordnerstruktur.

Neue Template Dateien (.tpl.php)

In der Version 5.x wurden folgende templates durch die phptemplate.engine (im theme enginge Ordner) implementiert:

• page.tpl.php
• node.tpl.php
• comment.tpl.php
• block.tpl.php
• box.tpl.php

Mit den neuen Änderungen im Untergrund, werden mehr Standardtemplates zur verfügung gestellt. In zukünftigen Versionen wird es noch mehr geben. Die templates der Version 5.x wurden auch verschoben.Im Kommentar dieser Dateien steht, wo sie verwendet werden welche Variablen verfügbar sind.

Um diese Templates zu überschreiben, müssen sie in den Theme-Ordner kopiert und die Registry gelöscht werden.

Sie auch complete list of new templates im Theming Handbuch.

Die selten verwendeten standard core Funktionen für die obigen Templates sind nicht mehr vorhanden. So existiert zum Beispiel theme_page nicht mehr. Dies betrifft alle themebaren Ausgaben, die in Templates konvertiert wurden. (?). Diese Funktionen sind nicht länger nötig. Diese Änderung sollte niemanden betreffen. Die entfernten Funktionen sind nicht zu verwechseln mit ähnlich klingenden Funktionen: theme ('page') ist immer noch in Betrieb! Nur die Default-Implementierung hat sich verändert.

Neue Vorschläge für die Namensgebung für Template Dateien

Es gab bisher Empfehlungen für page.tpl.php- basierend auf dem Pfad, node.tpl.php- basierend auf dem Inhaltstyp und block.tpl.php- basierend auf den Regiionen und Modulen.
Im Rahmen der oben genannten Template-Konvertierungen, wurden auch neue Empfehlungen erstellt.
Siehe complete list of new template suggestions im Theming Handbuch.

Block-Regionen definieren

hook_regions ist veraltet. Regionen werden jetzt durch die .info-Dateien definiert. Weitere Details sind auf der entsprechenden Handbuchseite zu finden.

Änderung der Variablennamen für die Block-Regionen

Die Variablennamen für die side bar block regions und footer haben geändert.

In der Version 5.x nutzten die Regionen "left", "right" und "footer" die Variablen $sidebar_left, $sidebar_right und $footer_message in der page.tpl.php. Das war ein Überbleibsel aus den Verisonen 4.6 und noch früher.

Um es sauberer und direkter zu machen, erstellen die drei Regionen die Variablen $left, $right und $footer- genau wie alle anderen Regionen. $footer_message ist immer noch in Gebrauch, aber diese wird für die Footer-Message, die auf der site information administration Seite aus gesetzt wird..

Theme-Einstellungen anpassen

Theme Autoren können jetzt ihr Theme durch den Site Administrator kofigurierbar machen.
In der neuen Version hat jedes Theme seine Einstellungsseiten im Verwaltungsbereich: admin/build/themes/settings/themeName. Diese Seite enthält die Standardeinstellungen wie “Logo image settings” und “Shortcut icon settings”. Um weitere Einstellungsmöglichkeiten hinzuzufügen, kreiert man einfach eine theme-settings.php Datei im eigenen Theme-Ordner und fügt eine themeName_settings() oder themeEngineName_settings() Funktion hinzu. Um weitere Formularelemente hinzuzufügen, sollte diese Funktion die Forms API benutzen.
Mehr Details sihe Custom theme settings im Theme Developer Handbuch.

Neue $signature Variable

In Drupal 6.x wurden die Signaturen dynamisch gemacht. Das heisst, sie erscheinen, wenn ein Kommentar angezeigt wird und sind nicht mehr ein Teil des Kommentars selbst. Deshalb muss eine $signature variable zur comment.tpl.php Datei hinzugefügt werden.
In 5.x:

In 6.x:

Hinweis:folgender Code kann benutzt werden, um eine doppelte Anzeige von Signaturen in alten Posts zu verhindern.

Die $body_classes variable

Innerhalb der page.tpl.php war es folgendermassen den Zustand des Layouts auszugeben:

In 5.x gab <?php print $layout; ?> left, right, oder beides aus, je nach dem welche Sidebars im Einsatz waren.

In 6.x sind $body_classes auch verfügbar. <?php print $body_classes; ?> gibt in etwa folgendes aus:

front logged-in node-type-page no-sidebars

- eine Zusammenstellung von spezialisierten Klassen, wie die oben aufgeführten. Mehr dazu hier.

$language ist jetzt ein Objekt

Die $language Variable, die für PHPTemplate zugänglich war ist nun nicht nur ein einfacher String, der den Sprachcode der aktuell aufgerufenen Seite beinhaltet, sondern ein Objekt, welches verschiedene Eigenschaften der aktuellen Sprache repräsentiert.
Das eigene Theme kann nun "rechts nach links"-kompatibel gemacht werden, sodass es von Leuten verwendet werden kann, die in "rechts nach links" geschriebene Inhalte (wie zum Beispiel Hebräisch, z.B. http://www.drupal.org.il/ ) veröffentlichen.

Themes können core- und modulspezifische CSS-Dateien überschreiben

Themes können neu CSS-Dateien ersetzen, die von einem Modul definiert wurden, in dem sie mit drupal_add_css() ein Stylesheet mit dem selben Dateinamen hinzufügen. Themes können so, wenn nötig, ganze CSS Dateien überschreiben und nicht nur spezifische Selektoren.

Wenn zum Beispiel folgender Code in Garland's template.php Datei platziert wird, ersetzt themes/garland/system-menus.css modules/system/system-menus.css:

Right to left CSS override Dateien unterstützt

Submitted by user on date/time ist themable

Das "submitted" Element in Nodes und Kommentaren ist nun wie jedes andere Element themable. Das heisst, man kann überschreiben, welche Informationen wie angezeigt werden.

Es können beliebige Ids oder Klassen hinzugefügt werden, mehr oder weniger Informationen angezeigt werden oder sogar das ganze "submitted" in unterschiedlichem Erscheinungsbild angezeigt werden, je nach dem, ob es sich um das "submitted" eines Kommentars, eines Nodes oder eines bestimmten Typs handelt.

Hier ein Beispiel aus der template.php Datei des Garland Themes:

jQuery ist auf 1.2.6 aktualisiert

Default JavaScript Datei

Ähnlich wie style.css wird neu automatisch eine Datei namens script.js eingefügt, um dem Theme JavaScript hinzufügen zu können. Diese Datei sollte im Home-Verzeichnis des Themes platziert werden. Der Dateiname kann geändert werden. Weitere Dateien können via .info-Datei hinzugefügt werden.

JavaScript theming

Es gibt neu auch einen Theming Mechanismus für JavaScript Code. Gemeinsam mit dem ajtomatisch eingefügten script.js, erlaubt dies Theme Entwicklern mehr Freiheiten im Bereich des Scripten von Ereignissen auf Drupal Seiten. Oft erstellt JavaScript Code Markup, das in die Seite eingefügt wird. Dieser HTML Code wurde normalerweise hartkodiert in das Script eingefügt, das die Änderung des eingefügten Codes verunmöglichte.

Module bieten nun Funktionen im Drupal.theme.prototype neamespace an. Themes sollten ihre überschreibenden Funktionen direkt in den Drupal.theme namespace. Skripte rufen Drupal.theme ('function_name'; ...)auf, welche umgehend entscheiden, ob der Aufruf der Funktion durch das Theme (wenn vorhanden) oder durch die default Funktion bedient wird.
JavaScript Theme Funktionen sind vollkommen frei bezüglich ihrem Rückgabewert. Dieser kann von einfachen Strings bis zu komplexen Datentypen varieren, wie zum Beispiel Objekten, die ihrerseits wiederum JQuery Objekte enthalten, die DOM Elemente wrappen..Hier ist die ursprüngliche (default) Theme Funktion zu beachten: sie zeigt, welcher Wert zurückgegeben werden soll.