Liste mit Drupal 8 Tips

Wenn man mit einer neuen Software-Version arbeitet, hat man allerhand Aha- und Wtf- Erlebnisse. Nie ist es so frisch wie beim ersten Mal... Ich habe hier einige dieser Momente aufgeschrieben. Ich machte das, während ich an einer Seite arbeitete, die Skizzenhaftigkeit sei mir daher hoffentlich verziehen.

Fiese Fallen / Hilfreiche Module

Module deaktivieren Module deinstallieren

Module können nicht mehr einfach deaktiviert werden, sondern müssen deinstalliert werden. Warum? Aus Gründen... Es ist allerdings eine sehr sinnvolle Sicherung eingebaut: Bevor man z.B. das Shortcut-Modul deinstallieren kann, muss man alle Content- oder Config-Entities, die damit erstellt wurden, löschen. Das mag noch unkomfortabler erscheinen. Allerdings sorgt es dafür, dass man nicht aus Versehen die Arbeit von drei Wochen zerstört und ist zu begrüßen.

Admin Menu hat evtl. einen Nachfolger

Zum Zeitpunkt, als ich diese Zeilen schreibe, ist Admin Menu für Drupal 8 noch nicht benutzbar. Vorsicht: wenn man es versucht zu installieren, hat man den Eindruck, dass es einem die ganze Seite kaputtgemacht hat, da nur noch eine Fehlermeldung erscheint und man es nicht mehr deinstallieren kann. Allerdings: Bei mir hat geholfen, einfach den Modulordner zu löschen. Es bleiben wahrscheinlich irgendwo Reste zurück, aber das verbuchen wir im Moment unter Lehrgeld.

Eine attraktive Alternative und mit einer stabilen Version für Drupal 8 ist das Modul Admin Toolbar. Es folgt zudem der Optik der Toolbar, die sich im Core befindet und blendet sich daher nahtlos ein.

Keine "System" Tabelle in der Datenbank

Wenn man nun ein Modul hat, das einem die Seite lahmlegt, konnte man es früher in der System-Tabelle auf Status 0 setzen (vorübergehend abschalten) oder die zugehörige Zeile löschen und damit das Modul richtig deaktivieren. Das geht nicht mehr, und zwar ganz bewusst, siehe Punkt 1 oben. Es gab eine endlose und sehr hitzig geführte Diskussion, dass es eine Möglichkeit geben müsse für Entwickler, zerstörerische Module minimal-invasiv zu deaktivieren. Das wird es bestimmt auch wieder geben in der Zukunft oder wir finden eine andere Möglichkeit, es hinzubekommen. Alte Zöpfe abschneiden tut immer weh, und ich vertraue mal auf die Core-Entwickler, dass wir ihnen später danken werden.
Es geht aber noch weiter: es gibt die ganze System-Tabelle nicht mehr. Eine Art Verzeichnis, welche Module installiert sind, wird es woanders geben, das finden wir schon noch raus.

Little known facts about new features

Die Veränderungen und vor allem vielen kleinen Detailverbesserungen in Drupal 8 sind massiv. MASSIV. Daher entdeckt man immer wieder mal was Neues, wo man sagt: ah! Das hat mich in Drupal 7 immer gestört bzw. hätte man besser machen können.

Benutzerfreundliche Eingabe von Menülinks

In Drupal 7 konnte man einen Menülink entweder zum Alias des Nodes (=unsicher, Alias könnte sich ändern) oder zur Node ID (=nur für Kenner, nichts für den Endkunden) eingeben. In Drupal 8 gibt es jetzt das beste aus beiden Welten: In einem Autocomplete Feld gebe ich den gesuchten Titel des Nodes ein, und er findet einen, wenn es einen ähnlich geschriebenen gibt. Verknüpft wird aber intern die Node ID. Falls man dann unbedingt doch manuell die node ID eingeben will (unnötig), dann muss man einen führenden Slash voranstellen, also /node/1.
Ach ja, erwähnte ich schon, dass Autocomplete-Felder in Drupal 8 von Grund auf überarbeitet wurden? Sie sind jetzt nicht mehr schneckenlangsam, sondern rasend schnell.

Entwickler-Tips

Config Management

Für Entwickler eines der spannendesten neuen Features: die Configurations-Export- und Synchronisierungs-Möglichkeit. Ein _enormer_ Aufwand wurde betrieben, um alle Änderungen an einer Seite, die als Konfiguration angesehen werden können, zwische verschiedenen Instanzen der Seite synchronisieren zu können. Vielen Dank an Greg Dunlap (heyrocker), der sich als Initiativen-Abteilungsleiter mindestens zwei Jahre seines Lebens in diese Geschichte reingekniet hat. Es war wesentlich länger, aber zwei Jahre waren ca. die "heisse Phase". Natürlich haben zahllose Leute geholfen, es ist schwer zu entscheiden, wer die meiste Arbeit gemacht hat. Greg hat jedoch als Gesicht der Initiative bestimmt am meisten der Spannungen und Kritik mitbekommen, die unweigerlich im Projektverlauf auflaufen.

Grob gesagt funktioniert es jetzt so: man kann die komplette Konfiguration der Seite - also alles was nicht als Content gilt - auf Knopfdruck exportieren. Diese vielen .yml-Dateien packt man dann in ein Sync-Verzeichnis, das man vorher in einen von Git erfassten Ordner gepackt hat. Dies pusht man dann normalerweise von lokal oder woanders ins Git. Auf der Seite, die man auf den in der Synchronisation enthaltenen Stand bringen möchte, importiert man dann die ganze Kiste. Darin sind erstaunliche Sachen enthalten: z.B. auch die installierten Module! Das ging zwar im Prinzip auch früher mit Features.

Nun ist es aber tief im Core verankert, und die auftretenden Probleme sind Core-Business. D.h. man kann davon ausgehen, dass mittelfristig einfach alles exportierbar ist. Alle verantwortungsvollen Contrib-Modul-Maintainer werden die Konfiguration ihrer Module ebenfalls gemäss den Standards exportierbar machen. Was das für einen Unterschied vor allem für größere Projekte ausmacht, weiss jeder, der schon an solchen mitgearbeitet hat und sich mit dem Problem des Deployment beschäftigt hat.

Das Features-Modul ist dadurch nicht überflüssig geworden. Im Gegenteil: es kann sich jetzt auf das Wesentliche konzentrieren: für die Core-Configuration Möglichkeiten zu schaffen, die Config-Dateien zu Funktionalitäts-Paketen zusammenzupacken und vielleicht eine bessere UI zur Verfügung zu stellen. Es ist das Feld bereitet für vielerlei Contrib-Module, mit der Basisfunktionalität alle möglichen tollen Sachen anzustellen.

Fortsetzung folgt.