[gelöst]Fehler im Database-Updateskript D8.7

Ich habe jetzt zweimal auf Drupal 8.6.12 downgegradet und wieder upgegradet. Zwei meiner Sites gehen unter D 8.7.1. nicht mehr, also bleibe ich jetzt bei 8.6.
Ich weiß nicht mehr, was ich tun kann. Etliche Dinge sind jetzt in einem unklaren Zustand. Ein Node, der mit einem Menüpunkt verbunden ist, lässt sich nicht mehr bearbeiten und neu speichern.
Ich rätsle, wie ich da jetzt weiterkommen kann. Kann ich irgendwas von Hand verändern? Eventuell direkt in der Datenbank? Aufwendig, aber vielleicht möglich. Seufz.
Die meisten Websites sind noch nicht so wahnsinnig umfangreich, aber eine wurde vor über 10 Jahren unter D6 erstellt und beinhaltet doch ein paar tausend Nodes.

Eventuell spiele ich nochmal alte Database-Backups von vor dem 8.7.0-Update ein. Gehen halt ein paar Nodes verloren.

Von welcher Drupal 8 Version hattest Du auf 8.7 upgedated?
Fehlten evt. Zwischenschritte?
Habe gemerkt, dass man wirklich jede Version einzeln updaten sollte, also ohne Versionssprünge.
Allerdings beruhen meine Erfahrungen auf Update mit Composer. Wie hast Du es gemacht?
Von Drupal 8.7 habe ich instinktiv erst mal noch die Finger gelassen, vielleicht besser so. ;-)

Ich habe eigentlich immer die aktuellste Drupal-Version. Es war also eine 8.6.x - ich glaube, die jetzige Sicherheitsupdate-Version ist erst später erschienen.
Da ich natürlich immer ein Backup der Datenbank habe, setze ich jetzt nach und nach alle Websites auf den Stand von vor dem Update zurück, füge die dadurch verlorengegangenen Artikel und sonstigen Änderungen wieder ein und versuche das Update dann nochmal neu. Leider ist in den zwei Wochen einiges passiert auf den Sites.

Updates mache ich übrigens mit composer. Ich habe mir ein kleines Skript geschrieben, das alle Websites offline setzt, die Datenbanken sichert, Drupal und alle Module updatet, drush updb und drush cr ausführt und dann die Sites wieder online stellt und Backups älter als ein halbes Jahr löscht. Das hat sonst immer super funktioniert.

Wenn ich schon mal Kaffee schlürfe und im Drupalcenter unterwegs bin, kann ich dir hier auch gleich eine Erklärung mit auf den Weg geben. Des Rätsels Schweizer Taschenmesser ist in deinem Fall folgender drush Befehl

https://drushcommands.com/drush-8x/core/entity-updates/

drush entity-updates ist ein Entwicklerwerkzeug. Wenn die Entitäts-/Felddefinitionen eines Moduls geändert werden, können diese Änderungen mit diesem Befehl schnell und einfach übernommen werden.

In einer normalen Produktionsumgebung sollte das nicht passieren..Wird ein Modul aktualisiert, sollte das Modul diese Änderungen berücksichtigen..

Im Fall des Updates auf 8.7 wurden beispielsweise die Taxonomiebegriffe überarbeitet. Das führt dazu, dass die Definitionen für diese Funktion aktualisiert werden müssen.

In der Pressemitteilung zu Drupal 8.7 klingt, dass dann so:

Natürlich wurde noch mehr geändert, aber die Taxonomiebegriffe sind mir in deiner Fehlermeldung direkt aufgefallen. Darum habe ich dieses Beispiel rausgegriffen.

Werner, ich hatte es so verstanden, dass das Schweizer Taschenmesser
drush entup
in dem Fall nicht funktioniert hat.
Oder verstehe ich was bei Dir oder kniekel@drupal.org falsch?

Entup funktioniert noch nicht in Drupal 8.7, weil Drupal gerade neuer ist als drush, aber das wird schon wieder gehen, nach der nächsten Release. Du hast schon recht. Er schreibt ja, dass es nicht klappt. Aber dieses Problem kriegen wir noch öfter und wenn es so weit ist, dann kann ich dieses Thema einfach verlinken :-D

Wenn ihr das Problem in mehreren Instanzen habt, dann sei so gut und versuche stattdessen mal

drush updb --entity-updates und sag uns bitte, ob's funktioniert.

Regina, ich hatte in diesem Thread noch nichts geschrieben. Ich bin allerdings, wie Joachim, der Meinung, daß dieser Befehl hier gar nicht erforderlich war. Wichtig ist beim Update von D8.6.15 auf D8.7.1, daß vor dem Ausführen von "composer update" das Vendor-Verzeichnis sowie die composer.lock-Datei gelöscht werden. Andernfalls läuft das Update nicht richtig. Die Updates der Entities passieren in den ganz normalen Update-Funktionen der Core-Module. Die wurden bei mir über "drush updb" alle ordnungsgemäß durchlaufen. Ich vermute also, daß bei composer update Fehler aufgetreten sind, die man erst mal beheben müßte, damit der Rest funktioniert.

Hä??? Wie kam ich da drauf, dass Du das warst, Werner? Sorry...
Ich denke, ich sollte gaaaaanz langsam aus dem Urlaub zurück kommen und heute noch nicht alles auf einmal nachholen wollen. ;-)
Ist ja jetzt auch geklärt.
Vermutlich kam ich wegen dem anderen Post auf die Idee, wo wir uns einig waren, dass es eine gute Idee ist, das Vendor-Verzeichnis sowie die composer.lock-Datei zu löschen.

Vielen Dank für den Hinweis aufs Löschen des Vendor-Verzeichnisses usw.
Ich bin gerade dabei, den Zustand von D8.6 wiederherzustellen. Bis auf eine Website, bei der ich einiges an Inhalt sichern und dann wiederherstellen muss - da ist in zwei Wochen leider etliches dazugekommen - bin ich durch.
Ich werde dann berichten, kann aber sein, dass ich erst nächste Woche einen neuen Versuch starten kann.
Ja, und drush entup funktioniert ja leider unter D8.7 nicht. Das steht sogar bei den release notes oder irgendwo, weiß nicht mehr genau wo.
Ist halt leider eine Multisite-Installation mit 11 Sites ... meistens sehr praktisch, aber wehe, es geht was schief.

Hast Du Multi-Sites mit Domain Access Modul oder händisch gemacht?
Ich frage, weil ich eine Webseite unter D7 mit acht Domains habe und gespannt bin, wie stabil Domain Access schon läuft.
Angeblich soll es funktionieren.
Aber scharf bin ich noch nicht auf die Umstellung.
Dort werden viele Einstellungen Domainabhängig von den Redakteuren gepflegt und deswegen braucht es das Modul inklusive Bereitstellung von Menü-Links pro domain u.s.w.

Ich mache das schon seit Drupal 6 und kenne das Modul "Domain Access" überhaupt nicht.
Es funktioniert ganz wunderbar mit verschiedenen Ordnern im Ordner sites. Früher musste man den Namen des Ordners sehr gut überlegen, aber jetzt geht das ja alles über sites.php
Damit sind alle Sites völlig unabhängig voneinander, außer dass ihnen immer das gleiche Set an Modulen und Themes zur Verfügung steht, wobei man ja unterschiedliche davon aktivieren kann und theoretisch auch welche im Sites-Unterordner installieren kann, so dass sie für die anderen nicht sichtbar sind. Das ist genau das, was ich brauche. Technisch weitgehend identisch, inhaltlich komplett getrennt.
Muss ich mir Domain Access anschauen? Kommt da was, was ich nicht auf dem Schirm habe?

Ja, die Methode via sites.php kenne ich auch.
Das ist super, wenn man sehr unterschiedliche inhalte hat.
Aber in meinem Fall (bzw. mehreren Fällen) geht es eben darum, dass weite Teile der Inhalte gleich sind.
Und es gibt zu dem Domain Access viele weitere Module, die Zusatzfunktionen bringen, wie z.B. die bereits erwähnten Menüpunkte je nach Domain.
Oder Ansprache des Domainnamens in Views.

Auch Blöcke können Domainabhängig eingebunden werden.
Also auch für Redakteure ohne tiefere Drupal-Kenntnisse zu bedienen.
Sehr hilfreiches Modul, dessen Grenzen eher im Hirn des Administrators liegen, weil es schnell unübersichtlich wird.
Mein letzter Stand war, dass es für D8 zwar noch Alpha, aber schon recht gut zu verwalten ist:
https://www.drupal.org/project/domain
Ist also weniger, dass was kommt, was Du nicht auf dem Schirm hast, sondern geht, falls es auf D9 nicht weiter gepflegt wird. ;-)

Wenn Du mit Deiner Methode zufrieden bist, dann bleib besser dabei.
Man kann vermutlich nur nach genauer Einsicht in die Projektstruktur entscheiden, ob das Modul einen Mehrwert gegenüber Deiner Methode hat.

Ich habe es bei diesem Kunden im Einsatz:
https://www.anukan.de/
Gibt noch eine Partnerseite mit ebenfalls mehreren Domains, die neulich aus bürokratischen Gründen auf eine eigenständige Installation gebracht wurde.

Meine eigene Webseite
https://www.gartenstauden.de/
hat auch noch zwei weitere Domains auf der gleichen Installation, die einige Inhalts-Blöcke teilen.

Danke für die Ausführungen. Nee, das brauche ich dann nicht.

Bei mir sind es mehrere Kirchengemeinden, die naturgemäß ähnliche technische Anforderungen haben (bzw. von mir so aufgedrückt bekommen ;-) ), aber dann eben doch inhaltlich völlig getrennt sind. Einzig den gemeinsamen Stadt-Gemeindebrief hab ich halt über RSS gelöst, dafür brauche ich kein so umfangreiches Modul.

Wenn ich mich recht erinnere, gab es unter D6 auch das Konzept, eine Datenbank pro Website mit unterschiedlichen Prefixes für jede Tabelle zu bespielen und dann z.B. die Benutzer-Datenbank gemeinsam zu haben. Das fand ich ganz spannend, habe ich aber nie gemacht. Und mir sind mehrere kleine Datenbanken (die größte hat auch schon 400MB) dann doch lieber als ein riesiges Ding, mit dem ich nicht mehr umgehen kann. Weiß nicht, ich glaube, das wäre theoretisch immer noch möglich.

Ach wusste gar nicht, dass es das nicht mehr gibt.
Aber würde ich auch nicht nutzen wollen.

Das Konzept der Prefixes gibt es noch immer. Da man heute aber mit der Zahl der Datenbanken nicht mehr so eingeengt ist wie früher, hat es sich etwas überlebt. Einzelne kleinere Datenbanken sind einfach besser zu handeln, besonders bei Problemen.

Der Thread hier ist ja etwas abgedriftet, aber ich hatte dort die Lösung gefunden:
https://www.drupal.org/project/drupal/issues/3040129#comment-13103380

So, ich habe jetzt erst mal einen Update-Versuch gestartet, bei dem ich das vendor-Verzeichnis und composer.lock gelöscht hatte. Die Datenbank-Updates sind wieder schiefgegangen.
Für heute lasse ich das jetzt mal bei 8.6.x Dann starte ich nochmal einen Versuch mit Auskommentieren dieser einen Zeile.
Vielleicht sollte mich mir mal ein Skript schreiben, das die letzten Datenbank-Backups wieder zurückschreibt. Das ist nämlich ziemlich nervig. :-)

Manchmal hilft Warten: Das Update von 8.6.x auf 8.7.2 lief ohne Probleme.
Danke für alles mit Überlegen.