Nachdem ich jetzt schon mehrfach etwas unvorsichtig Drupal-8-Contrib-Module installiert habe, die mir im Prinzip die Datenbank geschrottet haben, muss ich eine deutliche Warnung aussprechen: Niemals ein D8-Modul auf der Live-Seite installieren, bevor man es auf einer lokalen Kopie getestet hat. Verschiedene Fälle können auftreten, die einen sonst böse zum Stolpern bringen.
Im ersten Blogpost dieser Mini-Serie hatte ich mich ausführlich über die Segnungen des Configuration Management ausgelassen. Natürlich gibt es im Alltag auch Enttäuschungen. Die erste erlebte ich heute: Custom Blocks, die man in der "Custom Block Library" erstellt, lassen sich nicht mit dem Configuration Management exportieren. Grund: der Inhalt eines Custom Blocks gilt als Content, und CMI (kurz für Content Management Initiative) exportiert nur Konfiguration. Die Konfiguration für den Block (wo er platziert wird etc.) wird jedoch exportiert. Durch den fehlenden Inhalt gibts jedoch statt dem Block nur einen unerfreulichen Hinweis, dass da was fehlt.
Ein Hinweis zum Bearbeiten von Blöcken: Da das Erstellen eines Blockinhaltes und das Platzieren desselben nun auf zwei getrennte Formulare aufgeteilt ist, unterscheidet man in "Block konfigurieren" (Platzieren etc) und "Block bearbeiten" (bei einem Custom Block den Inhalt ändern). Da muss man drauf achten, sonst landet man im falschen Formular und hat ein Fragezeichen (oder unerfreulicheres) im Gesicht.
Jedoch hat man bei der Entwicklung von Drupal 8 schon an das Content Staging gedacht: es wurde das Konzept der UUIDs eingeführt. Alle Content Entities (und damit auch Custom Blöcke) haben UUIDs. Warum das wichtig ist: über eine UUID bekommt eine Content Entity eine eindeutige ID, die unabhängig von der automatisch vergebenen ID ist, die per Auto Increment erstellt (einfach hochgezählt, in der Reihenfolge, wie die Entities erstellt werden) wird. Genau dieses Problem bewirkte in Drupal 7, dass man z.B. Blöcke nicht so einfach synchronisieren konnte. Falls man aus Versehen auf der Live-Seite und auf der lokalen Kopie Blöcke in unterschiedlicher Reihenfolge angelegt hatte, dann waren die unterschiedlichen IDs je nach Setup fatal.
Wir müssen etwas abwarten, dann wird es mit Sicherheit in Contrib Lösungen geben, in Drupal 8 Inhalte zu synchronisieren, die sich die im Core vorhandene Struktur zu Nutze machen wird. Dies wird dann viel weiter gehen als in Drupal 7, auch Nodes und alle anderen Inhalte werden synchronisierbar sein. Ein Feature, das vor allem in größeren Unternehmen mit unfangreichen Websites wichtig ist, und von manchen kommerziellen CMSen geboten wird.
In Drupal 8 wurde das Entity-System deutlich verbessert und Dinge zu Entities gemacht, die vorher keine waren. So auch Blöcke. Während man sich darüber streiten kann, ob das neue Blockinterface wirklich intuitiv ist - es ist eher teilweise komplizierter - sind Blöcke als Entities ungeteilt super.
Grunsätzlich - mit Ausnahmen - sind Entities in Drupal "fieldable", d.h. man kan über die Oberlfläche Felder hinzufügen. Ein besserer Auskenner mit Entities wird mir diese Aussage um die Ohren hauen, aber auch in D7 stellt es sich für den Seiten-Erbauer so da.
Für Blöcke macht die Verwendungsmöglichkeit von Feldern erstaunlich viel Sinn. Typischer Anwendungsfall: Man hat auf der Startseite unter dem Header drei Blöcke nebeneinander, die jeweils ein Bild, eine kurze Überschrift und einen kurzen Text haben. Oft verwendet, um die drei wichtigsten Angebote der Firma oder sonstiges in die "Aktionsfläche" zu stellen. Mit einen Custom Block Typ kann man diese Blöcke für den Endkunden einfach und fast idiotensicher editierbar machen. Vor allem das Bild muss nicht mehr im Haupt-Textfeld sein, was die Bilddarstellund fehleranfällig und das Hochladen komplizierter macht. Auch die Formatierung über Image Styles oder sogar responsive Image Styles wird ermöglicht - oder sagen wir mal erleichtert, mit Hilfe des Media Modules konnte man das vielleicht auch früher hinbekommen.
In Drupal 7 war das mit Erweiterungsmodulen auch möglich, z.B. mit Bean https://drupalize.me/blog/201503/creating-block-types-bean oder man verwendete das Modul "Node Block", dass Nodes als Block verfügbar machte. Es ist jedoch etwas ganz anderes, die Funktionalität im Core zu haben, wo sie hingehört.