Closed BugBuster1701 closed 11 years ago
Nachtrag: Im hatte Peter Müller darauf aufmerksam gemacht.
Ich kann das Problem leider nicht nachvollziehen. Ich habe jetzt mehrfach Updates von 2.11.6 auf 3.0.RC2+ laufen lassen, aber das DB-Update lief immer korrekt durch. Wie genau kann ich das reproduzieren?
Gibt es schon Neues zu diesem Thema?
Ich hatte im Forum gebeten sich hier zu melden, ich frag noch mal.
Bei meinen Versuchen reicht es aus, sich den lts-Branch zu ziehen, die Music Academy zu installieren und dann ein Update zu starten. Nachdem alle Dateien überschrieben waren habe ich noch /system/modules aufgeräumt, so dass dort keine veralteten Module mehr vorhanden sind. Danach das Installtool starten und Schritt 1-3 ausführen. Bei Schritt 3 wird bemängelt, dass die DB nicht aktuell ist. Einfach auf "Datenbank aktualisieren" klicken ohne irgendwelche Checkboxen zu ändern und das Problem wird bei mir sichtbar.
Tut mir leid, aber auch nach dieser Anleitung kann ich es nicht reproduzieren. Irgendwelche Third-Party-Extensions installiert?
Nein, die reine Music Academy. Du nimmst aber kein Live Update oder? Ich teste es nachher nochmal komplett von Hand, bisher habe ich für das Update eigene Shell-Skripte benutzt. Daran kann es aber eigentlich auch nicht liegen, Peter hat ja den gleichen Fehler.
Du nimmst aber kein Live Update oder?
Wieso, tritt das Problem nur beim Live Update auf? Im ganzen bisherigen Ticket ist nirgends vom Live Update die Rede.
Nein, ist kein Live Update Problem. Wollte du sichergehen, dass du es auch "von Hand" probierst. Dann teste ich später nochmal ohne Shell-Skript.
Da GitHub spinnt, komme ich leider gerade an keinen Contao-Check…später/morgen nochmal probieren. Würde dir eigentlich der Zugang zu einer C3 Installation helfen, die das Problem bereits hat?
Nein, denn wenn ich es bei mir nicht reproduzieren kann, bin ich auch nicht zuständig :)
Also ich muss passen, bei mir tritt es immer auf. Vielleicht können @BugBuster1701 und @pmmueller ja nochmal schauen, ob es bei ihnen reproduzierbar ist?
Bei mir ist es definitiv reproduzierbar. Windows 7 - XAMPP 1.8 - iMac mit 10.8.2 und Parallels 7.
In system/modules muss man nach Schritt 2 diverse Ordner löschen, weil es sonst zu diversen Fehlern kommt:
Das Installtool sollte zumindest darauf hinweisen, dass die Existenz dieser Ordner ein ordnungsgemäßes Update verhindert.
Bei mir ist es auch definitiv reproduzierbar. Windows 7 - Contao2go
ALTER TABLE tl_calendar_events
CHANGE startTime
startTime
int(10) unsigned NULL default NULL;
ALTER TABLE tl_calendar_events
CHANGE endTime
endTime
int(10) unsigned NULL default NULL;
ALTER TABLE tl_calendar_events
CHANGE startDate
startDate
int(10) unsigned NULL default NULL;
ALTER TABLE tl_calendar_events
CHANGE endDate
endDate
int(10) unsigned NULL default NULL;
Diese 4 Einträge wollen einfach nicht weg beim updaten der DB.
Ich habe noch mal die 2.11.6 & 3RC2 von Gitthub runter geladen und den Test wiederholt ... selber Effekt!
Dazu mal auf jeden Fall der Hinweis, dass man bei einer bestehenden Installation nicht einfach nur die neuen Dateien hochladen kann und dann erwarten darf, dass damit das Update abgeschlossen ist. Nicht umsonst wird ja in der Doku auf die Möglichkeit der Synchronisation per FTP-Client hingewiesen, bei der nicht nur neue Dateien hochgeladen, sondern auch alte entfernt werden.
Dürfte ich noch um einen weiteren Test bitten: Einmal die 2.11.6 in den Ordner <server>/2.11.6
, Installtool aufrufen und Music Academy installieren. Danach die 3.0.RC2 in den Ordner <server>/3.0.RC2
, im Installtool dieselbe Datenbank auswählen wie bei der 2.11.6er-Installation, das Version 3-Update durchführen und schauen, ob das Problem auftritt.
Test wie von Dir verlangt durchgeführt. Problem ist so nicht mehr vorhanden.
Nur leider wird dieser Test nicht repräsentativ sein für die xig Tausend Contao Installationen die es im Netz nun schon gibt. Einige werden seit 2.9 oder früher existieren und wurden zum Teil aktualisiert von Hand oder mit dem Live Update.
Was Du mit dem Test jetzt bewiesen hast, ist höchstens, dass man Contao 2.11.6 auf Contao 3 Updaten kann, vorausgesetzt Contao 2.11.6 wurde von Grund auf neu installiert.
Anmerkung: Das mit der Synchronisation ist eine gute Idee und ist mir ja auch nicht fremd ... aber wie soll man jetzt herausfinden woher diese 4 Änderungen an den Events herkommen ? Ich habe mich an den Workaround von pmueller gehalten und genau das gelöscht (synchronisiert) wie er es beschrieben hat.
Der von Leo vorgeschlagene Test zeigt im Grunde recht gut, dass beim manuellen Update zuvor irgendwas falsch gemacht wurde. Es reicht halt nicht, einfach nur die neuen Dateien über die alten drüberzukopieren (wie es im Forum manchmal von einigen vorgeschlagen wird), vielmehr müssen - insbesondere bei einem Major Update - selbstverständlich auch verwaiste Dateien und Ordner entfernt werden (war schon immer so und wird auch immer so bleiben). Diese Update-Variante heißt ja nicht umsonst "Manuelles Update"; man muss sich demzufolge auch selbst darum kümmern, dass die Synchronisierung bzw. der Abgleich der Datei- und Verzeichnisstrukturen ordnungsgemäß ausgeführt wird.
Weil z.B. in dem Fall nun 2 SQL Definitionen existieren, einmal im DCA und einmal als database.sql ? Fällt mir grad so ein. Schaut doch mal nach bei den Updates wo es Probleme macht und nehmt die database.sql weg und probiert nochmal das DB Update. (aus system\modules\calendar\config)
@leofeyer und @xchs
Das manuelle Update per FTP
Steht so seit der ersten Auflage in meinem Buch und ihr habt jeder eine Auflage als Fachlektor abgesegnet. Da war keine Rede davon, dass man synchronisieren oder alte Dateien/Ordner entfernen muss. Ich selbst habe das auch noch nie gemacht und es mehr als Option gesehen. Thomas fand das in der dritten Auflage auch okay so.
Sollte ich das in der Korrekturfahne noch schnellstens ändern?
@pmmueller
Also ich würde schon darauf hinweisen. So steht es auch im Contao Benutzerhandbuch: Wie man Contao manuell aktualisiert
Ich kann nur für mich sprechen, aber ich habe das "Manuelle Update" immer so verstanden, dass man verwaiste/obsolete Dateien und Ordner selbstverständlich auch (selbst) entfernen muss. Genau das ist es ja (u.a.), was einem sonst der Live Update Service abnimmt.
Sollte ich das in der Korrekturfahne noch schnellstens ändern (lassen)?
Done.
Super! :+1:
Und gut, dass sich das grad grad noch ausgegangen ist. Satz und Druck stehen sicherlich unmittelbar bevor :)
Also es ist definitiv die database.sql in /system/modules/calendar/config welche diesen Loop verursacht hat. Ich habe sie nach dem Update wieder ins Verzeichnis kopiert und es wurden folgendes hinzugefüg:
DROP TABLE tl_task_status
;
ALTER TABLE tl_calendar
ADD makeFeed
char(1) NOT NULL default '';
ALTER TABLE tl_calendar
ADD format
varchar(32) NOT NULL default '';
ALTER TABLE tl_calendar
ADD language
varchar(32) NOT NULL default '';
ALTER TABLE tl_calendar
ADD source
varchar(32) NOT NULL default '';
ALTER TABLE tl_calendar
ADD maxItems
smallint(5) unsigned NOT NULL default '0';
ALTER TABLE tl_calendar
ADD feedBase
varchar(255) NOT NULL default '';
ALTER TABLE tl_calendar
ADD alias
varbinary(128) NOT NULL default '';
ALTER TABLE tl_calendar
ADD description
text NULL;
ALTER TABLE tl_calendar_events
ADD details
mediumtext NULL;
Select all
ALTER TABLE tl_calendar_events
CHANGE startTime
startTime
int(10) unsigned NULL default NULL;
ALTER TABLE tl_calendar_events
CHANGE endTime
endTime
int(10) unsigned NULL default NULL;
ALTER TABLE tl_calendar_events
CHANGE startDate
startDate
int(10) unsigned NULL default NULL;
ALTER TABLE tl_calendar_events
CHANGE endDate
endDate
int(10) unsigned NULL default
Zuerst löscht es was und und dann will es was hinzufügen was es wohl nicht mehr gibt ...
Freut mich das ich pmueller helfen konnte sein Buch zu verbessern. Das nenne ich gutes Marketing und User Freundlichkeit!
Speziell für das Update auf 3.0: https://github.com/contao/core/issues/4887
Vielen Dank für die diversen Tests und Hinweise. Die sich daraus ergebende Frage ist, ob es eine Möglichkeit gibt, die besagten Ressourcen automatisch zu löschen, wenn die neuen Dateien einfach nur über die bestehende Installation kopiert wurden.
Spontan fiele mir dazu ein, dass man in der Config.php
die alten Core-Module explizit ausschließen könnte. Das einzige Problem dabei ist das Tasks-Modul, weil es das ja auch in Contao 3 weiterhin gibt, wenn man es sich über das ER installiert. Deswegen kann man es nicht generell deaktivieren.
Würde es funktionieren, wenn die Updateroutine im task
-Modulordner eine .skip
-Datei erstellt (so wie von @BugBuster1701 vorgeschlagen)?
Das geht, wenn man zuerst das Installtool aufruft und nicht das Backend. Diese Vorgehensweise wäre aber auch logisch nach einem Update. Die Änderungen sind in 54bfb3febf57631fe93fa2402b56b7723e7766e2 hinzugefügt.
Durch diese Update-Vorgehensweise (3er-Dateien einfach über die 2er-Dateien kopieren) entstehen bei mir jedoch knapp über 1.800 Dateileichen. Als Administrator oder Entwickler möchte ich mit so einem System nicht arbeiten müssen, vor allem nicht, wenn Core-Dateien angepasst werden sollen. Davon gibt es jetzt nämlich sehr viele doppelt, nur eben in unterschiedlichen Verzeichnissen.
Hab mir mal den Spaß gemacht und eine vollständige Liste aller verwaisten Contao 2.11.6-Dateien in Contao 3 erstellt.
# CHANGELOG.md
# GPL.txt
# LGPL.txt
# contao/contao-uncompressed.js
# contao/contao.js
# cron.php
# plugins/
# share.php
# system/config/.htaccess
# system/config/config.php
# system/constants.php
# system/contao.css
# system/drivers/
# system/functions.php
# system/html/
# system/interface.php
# system/libraries/
# system/mbstring.php
# system/modules/backend/
# system/modules/calendar/Calendar.php
# system/modules/calendar/Events.php
# system/modules/calendar/ModuleCalendar.php
# system/modules/calendar/ModuleEventMenu.php
# system/modules/calendar/ModuleEventReader.php
# system/modules/calendar/ModuleEventlist.php
# system/modules/calendar/config/.htaccess
# system/modules/calendar/config/database.sql
# system/modules/calendar/dca/.htaccess
# system/modules/calendar/html/
# system/modules/calendar/languages/de/.htaccess
# system/modules/calendar/languages/en/.htaccess
# system/modules/calendar/templates/.htaccess
# system/modules/comments/Comments.php
# system/modules/comments/ContentComments.php
# system/modules/comments/ModuleComments.php
# system/modules/comments/config/.htaccess
# system/modules/comments/config/database.sql
# system/modules/comments/dca/.htaccess
# system/modules/comments/html/
# system/modules/comments/languages/de/.htaccess
# system/modules/comments/languages/en/.htaccess
# system/modules/comments/templates/.htaccess
# system/modules/faq/ModuleFaq.php
# system/modules/faq/ModuleFaqList.php
# system/modules/faq/ModuleFaqPage.php
# system/modules/faq/ModuleFaqReader.php
# system/modules/faq/config/.htaccess
# system/modules/faq/config/database.sql
# system/modules/faq/dca/.htaccess
# system/modules/faq/html/
# system/modules/faq/languages/de/.htaccess
# system/modules/faq/languages/en/.htaccess
# system/modules/faq/templates/.htaccess
# system/modules/frontend/
# system/modules/listing/ModuleListing.php
# system/modules/listing/config/.htaccess
# system/modules/listing/config/database.sql
# system/modules/listing/dca/.htaccess
# system/modules/listing/html/
# system/modules/listing/languages/de/.htaccess
# system/modules/listing/languages/en/.htaccess
# system/modules/listing/templates/.htaccess
# system/modules/news/ModuleNews.php
# system/modules/news/ModuleNewsArchive.php
# system/modules/news/ModuleNewsList.php
# system/modules/news/ModuleNewsMenu.php
# system/modules/news/ModuleNewsReader.php
# system/modules/news/News.php
# system/modules/news/config/.htaccess
# system/modules/news/config/database.sql
# system/modules/news/dca/.htaccess
# system/modules/news/html/
# system/modules/news/languages/de/.htaccess
# system/modules/news/languages/en/.htaccess
# system/modules/news/templates/.htaccess
# system/modules/newsletter/ModuleNewsletterList.php
# system/modules/newsletter/ModuleNewsletterReader.php
# system/modules/newsletter/ModuleSubscribe.php
# system/modules/newsletter/ModuleUnsubscribe.php
# system/modules/newsletter/Newsletter.php
# system/modules/newsletter/config/.htaccess
# system/modules/newsletter/config/database.sql
# system/modules/newsletter/dca/.htaccess
# system/modules/newsletter/html/
# system/modules/newsletter/languages/de/.htaccess
# system/modules/newsletter/languages/en/.htaccess
# system/modules/newsletter/templates/.htaccess
# system/modules/registration/
# system/modules/rep_base/
# system/modules/rep_client/
# system/modules/rss_reader/
# system/modules/tasks/
# system/modules/tpl_editor/
# system/scripts/
# system/themes/default/images/1c.gif
# system/themes/default/page.css
# system/themes/default/src/page.css
# system/utf8_lookup.php
# tl_files/
# typolight/
Wobei man mit dem Ordner "tl_files" natürlich vorsichtig sein muss. Bei einem Upgrade von der 2.11 wird man diesen in aller Regel weiter benutzen wollen. (Für die Umbenennung des Ordners in "files" muss zwingend das Gist-Skript von Tristan ausgeführt werden!)
Beim Update von 2.11.6 zu 3.0rc2 kommt es zu einem Problem mit der tl_calendar_events. Der DB Update Prozesse will 4 Felder Updaten und kommt da nicht mehr raus.
Erste Analyse ergab: Ein Unterschied ist, dass die 4 Felder unterschiedlich definiert sind zw. Contao 2 und 3. Contao 2:
Contao 3: (aus DCA rauskopiert)
Contao will hier scheinbar die Felder mit einer Default Angabe ändern, bekommt aber ohne Default Angabe den Vergleich zurück, daher die Schleife.
Hinweis noch dazu: Das ist nur bei einem Update der Fall, ein Contao 3 direkt installiert bringt dieses Problem nicht mit.