Es gibt ein merkwürdiges Verhalten, wenn man in Views Inhaltstypen nach Sprache filtern möchte.
Intuitiv würde man den Sprachfilter auf den Inhalt setzen. Dies zeigt nur in der Standardsprache eine Ausgabe.
Das SQL der Abfrage zeigt den Unterschied schon in der ersten Zeile:
für die Standardsprache (hier Deutsch) sieht die Zeile so aus:
SELECT node_field_data.created AS node_field_data_created, node_field_data.nid AS nid ...
für Englisch:
Nach dem Hinzufügen neuer Wertpaare (key|label) zu einem bestehenden Drupal-8-field vom Typ "List (text)" mit bereits übersetzten Wertpaaren stimmen die Übersetzungen nicht mehr?
Sondern sind "verrutscht"?
Immer dran denken, auch die "Allowed values list" neu zu übersetzen!
Ausgangssituation:
Meine Kolleg*innen haben mich öfter mal auf composer schimpfen gehört ... ;)
Insbesondere für dev-Module bin ich zum Schluß gekommen, dass ich updaten lieber per Hand mache (tar.gz runterladen und entpacken) als per composer update/require.
Das bietet aus meiner Sicht entscheidende Vorteile:
Unsere aktuelle Lieblings-Fehlermeldung:
Object of class
Drupal\\Core\\Field\\Plugin\\Field\\FieldType\\StringItem
could not be converted to string
Sehr schön - ein StringItem kann nicht in einen PHP-String verwandelt werden.
Bei einem Drupal-8-View, der nodes als display-suite-view-mode darstellt erhielt ich vor jeder Zeile die unerwünschte Ausgabe
< data-history-node-id="56" data-quickedit-entity-id="node/56" class="contextual-region node node--type-XY node--view-mode-ABC ds-1col clearfix">
Das wird bereits beim Bearbeiten des Views in der Vorschau angezeigt:
Also Ergänzung zu .git Dateien aus Modulen nicht ins eigene Git! hier eine schnelle Methode, sie wieder loswerden.
Weil es uns leider selber passiert ist...
.git-Verzeichnisse in Modul-Verzeichnis zu liegenAlso vor den add'en nach .git-Verzeichnisse suchen, z.B. mit find modules/contrib/ -name '.git*'
Auch kleine Dinge sind anders in D8. Aber auch schön, wie z.B. bei Field formatter. Ein einfacher ist schnell gestrickt und kommt mit einer kleinen Datei, einer Klasse, einer annotation und einer Funktion aus.
Vorausgesetzt wir haben bereits ein Modul MY-MODULE, brauchen wir nicht viel:
Um in Drupal 8 per Code einen Block zu erschaffen wird im wesentlichen
BlockBase erweitertbuild() überschrieben.Zu beachten ist die übliche PSR-4 Struktur, damit Drupal den Block auch findet.
Für ein Module my_module (üblichweise in modules/custom/my_module/) braucht es dann src/Plugin/Block/MyBlock.php:
Nicht überraschend, aber auch nicht nach langer Krankheit, sondern in ergrauten Ehren von uns gegangen ist
Drupal 6
13.02.2008 - 24.02.2016
Die trauernde Community wird dein Andenken in Ehren halten.
Und welche kämpft angesicht solcher Screens nicht mit den Tränen?
So oder so ähnlich könnten Nachrufe auf Drupal 6 lauten.
Oder nicht?
Hm.
Von uns gegangen...?
Da bemühet man sich, immer alle Settings (und erschaffene DB-Tabellen und ...) ordentlich im .install File per hook_update_N() anzulegen... und dann bemerkt man nach dem Einspielen (drush updatedb), dass eine Variable vergessen oder ein Fehler gemacht wurde.
Einen neuen hook_update_N+1() anlegen ist nicht wirklich elegant.
Das Wissen um die richtige Stelle in der Datenbank führt zur geeigneten Methode um die Infos zurückzusetzen:
UPDATE system SET schema_version=N-1 where name = 'MYMODULE';