Bei Migration Contao 3.5 ? 4.9 SQL-Import-Fehler 1054, Unknown column ...

[Contaona]

Ich versuche derzeit, eine alte Contao-Website 3.5 in eine frische 4.9 zu migrieren.

Ein paar Erweiterungen habe ich über den Contao-Manager installiert, andere mit der von Leo beim Nordtag 2017[*1] vorgestellten direkten Methode. Und bei allen Versuchen zwischendurch immer schön den Cache (bzw. die Caches) und Datenbank aktualisiert. Aber egal, wie und wann ich versuchte, die SQL-Datei zu importieren, kam folgender Fehler:

Der Import konnte nicht abgeschlossen werden! Ist die Datenbank aktuell und die Template-Datei kompatibel mit Ihrer Contao-Version?
SQLSTATE[42S22]: Column not found: 1054 Unknown column 'space' in 'field list'

In der tl_article der alten Datenbank bin ich fündig geworden und habe dann in der neuen Datenbank die Spalte "space" mit den entsprechenden Parametern hinzugefügt.
Die Fehlermeldung ist nun weg. Dafür ist eine neue, nach dem gleichen Schema aufgetaucht.

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'title' in 'field list'

Es gibt aber eine Spalte title in der tl_article...


Sagt jemandem von euch das Ganze etwas? Habt ihr Tips, wie ich gezielt vorgehen kann?



[*1] Leo Feyer - Contao 4 installieren und bestehende Installationen migrieren - Contao Nordtag 2017
https://www.youtube.com/watch?v=rwC8xfdO3Ao

[fiedsch]

Wenn Du mit „die SQL Datei“ einen Dump aus Deiner alten 3er Contao Installation meinst: Du Must diesen zuerst in eine Datenbank importieren, diese dann mit Deiner Contao 4 Installation verbinden und dann die Updates machen.

[Contaona]

Wenn Du mit „die SQL Datei“ einen Dump aus Deiner alten 3er Contao Installation meinst:

Ja.

Du Must diesen zuerst in eine Datenbank importieren,

So hatte ich das noch gar nicht betrachtet ... Okay. Ich hab den Dump jetzt in eine neue Datenbank2 gespeichert. Das hat geklappt.

diese dann mit Deiner Contao 4 Installation verbinden und dann die Updates machen.

Hier kämpfe ich noch... Irgendwie will mir das nicht gelingen.

Sagen wir mal, ich hatte beim Installtool ursprünglich die Datenbank1 angegeben. Wie bringt ihr es jetzt dazu, sozusagen zu resetten und mich erneut nach den Datenbankdaten zu fragen oder sonstwie neu zuzuordnen? Geht das irgendwo im Contao-Manager?
Ich hab versucht, die config/parameters.yml anzupassen, aber es klappt noch nicht ganz. Ob ein bestimmtes Refresh, eine Cache-Aktualisierung fehlt oder das "secret" in der Datei stört, das ich nicht anzupassen wüsste?

[tab]

Nach Änderung in einer Konfigurationsdatei (hier parameters.yml) muss der Anwendungscache neu aufgebaut werden (Contao-Manager, Systemwartung)

[Contaona]

Nach Änderung in einer Konfigurationsdatei (hier parameters.yml) muss der Anwendungscache neu aufgebaut werden (Contao-Manager, Systemwartung)

Danke für die Bestätigung. Das hatte ich gemacht. Aber leider läuft es einfach nicht, immer ist irgendwas. Vielleicht hat die Datenbankgröße von 800 MB etwas damit zu tun; das erforderte schon beim Import Sonderwege.

Nochmal versucht. Ergebnis:

Gateway Timeout. The gateway did not receive a timely response from the upstream server or application.

Und das sagt /var/logs/prod...log dazu:

[2022-08-07 06:34:25] request.INFO: Matched route "contao_install". {"route":"contao_install","route_parameters":{"_ro ute":"contao_install","_scope":"backend","_token_c heck":true,"_controller":"Contao\\InstallationBund le\\Controller\\InstallationController::installAct ion"},"request_uri":"https://www.example.org/contao/install","method":"POST"} []
[2022-08-07 06:36:25] request.CRITICAL: Uncaught PHP Exception Doctrine\DBAL\Exception\DriverException: "An exception occurred while executing 'CREATE INDEX leadenabled ON tl_form (leadenabled)': SQLSTATE[42000]: Syntax error or access violation: 1072 Key column 'leadenabled' doesn't exist in table" at /serverpfad/www/example.org/webs/contao-4-9/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php line 128 {"exception":"[object] (Doctrine\\DBAL\\Exception\\DriverException(code: 0): An exception occurred while executing 'CREATE INDEX leadenabled ON tl_form (leadenabled)':\n\nSQLSTATE[42000]: Syntax error or access violation: 1072 Key column 'leadenabled' doesn't exist in table at /serverpfad/www/example.org/webs/contao-4-9/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php:128, Doctrine\\DBAL\\Driver\\PDO\\Exception(code: 42000): SQLSTATE[42000]: Syntax error or access violation: 1072 Key column 'leadenabled' doesn't exist in table at /serverpfad/www/example.org/webs/contao-4-9/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDO/Exception.php:18, PDOException(code: 42000): SQLSTATE[42000]: Syntax error or access violation: 1072 Key column 'leadenabled' doesn't exist in table at /serverpfad/www/example.org/webs/contao-4-9/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:141)"} []

[mlweb]

Erst mal folgende Fragen:

• Welche Version von Contao war das ursprünglich?
  Es ist dringend zu empfehlen auf die letzte Version von Contao 3.5 (3.5.40) zu aktualisieren und erst dann auf Contao 4 upzudaten.
• Wie genau bist Du beim im gesamten Updateprozess vorgegangen?
• Hast Du beim Export der DB von Contao 3 alle Tabellen gesichert?

Es ist zu empfehlen beim Export der DB aus der alten Installation folgende Tabellen nicht mit zu sichern:
tl_search
tl_search_index
tl_undo
tl_version
tl_session
tl_log
Sie werden neu erstellt bei Aufruf des Installtools und Du veringerst dabei ggf. die Größe des DB-Dumps enorm.

• Was genau meinst Du mit " Das erforderte beim Import Sonderwege"
• Bist Du sicher das der Export Deiner Datenbank komplett war?
• Bist Du sicher, dass der Import Deiner Datenbank komplett durchgeführt wurde?
• Welche Erweiterungen sind in der Contao 3.5 Installation installiert gewesen?

Es sollte heute eigentlich nicht mehr notwendig sein eine Erweiterung manuell zu installieren oder andersherum gesagt: eine Erweiterung die noch manuell zu installieren ist, wurde sicher seit einiger Zeit nicht mehr gepflegt. Es ist also fraglich ob die Erweiterung überhaupt mit Contao 4.9 bzw. 4.13 kompatibel ist

[Contaona]

Erst mal folgende Fragen:

• Welche Version von Contao war das ursprünglich?
  Es ist dringend zu empfehlen auf die letzte Version von Contao 3.5 (3.5.40) zu aktualisieren und erst dann auf Contao 4 upzudaten.

Es ist die 3.5.2 und aus bestimmten Teufelskreisgründen kann ich sie da an der Stelle auch nicht aktualisieren. Daher der Versuch, sie auf einen anderen Server zu holen.

Die Frage ist, wie ich das am besten anstelle.

Ich dachte mir, einen Versuch (mit mehreren Anläufen), es auf eine neue LTS-Version zu holen, ist es wert. Dabei habe ich nicht die 4.13 genommen, weil sich da wohl etwas Grundlegendes mit CSS geändert hat. Wie es mit den anderen Versionen aussieht, weiß ich nicht.

Inzwischen habe ich es außerdem auf einer anderen Subdomain mit Contao 3 versucht. Zuerst mit der 3.5.40 und nach Problemen damit, dann mehrere Schritte rückwärts. Aktuell bin ich bei der 3.5.2, also der exakt gleichen Contao-Version wie die vom alten Server, mit dem ältesten auf dem Server verfügbaren PHP, der Version 5.5, und das lief besser als mit PHP 7.

Hürde hier, Hürde da überwunden, aber immer wieder komme ich an den gleichen Punkt wie in #5: Fehlermeldungen mit tl_form.

Bei der Installation klappt der Import der Datenbank (mysql -u benutzer3 -p datenbank3 < Database_datenbankname1_datum.sql). Das Installtool contao/install.php möchte dann die Datenbank aktualisieren, und zwar beginnend mit folgenden Zeilen:

CREATE INDEX leadenabled ON tl_form (leadenabled)
CREATE INDEX leadmaster ON tl_form (leadmaster)
CREATE INDEX leadenabled_leadmaster ON tl_form (leadenabled, leadmaster)
ALTER TABLE tl_form ADD leadEnabled CHAR(1) DEFAULT '' NOT NULL
ALTER TABLE tl_form_field ADD leadStore VARCHAR(10) DEFAULT '' NOT NULL
ALTER TABLE tl_form_field ADD step VARCHAR(10) DEFAULT '' NOT NULL
ALTER TABLE tl_form_field ADD maxval VARCHAR(10) DEFAULT '' NOT NULL
ALTER TABLE tl_form_field ADD minval VARCHAR(10) DEFAULT '' NOT NULL
[...]

Es läuft aber nicht durch.

Wenn ich mich dann mit meinem alten User, der in der importierten Datenbank steht, anmelden will, erscheint folgende Meldung:

An exception has been thrown during the rendering of a template ("An exception occurred while executing 'SELECT id, title, leadMenuLabel FROM tl_form WHERE leadEnabled='1' AND leadMaster=0': SQLSTATE[42S22]: Column not found: 1054 Unknown column 'leadEnabled' in 'where clause'").

Was ich auffällig finde, ist die unterschiedliche Groß- und Kleinschreibung von leadEnabled & Co.
Ist das normal? Mir ist gerade nur noch schwindelig.
Oder war es normal bzw. nicht so schlimm und wird jetzt strenger gehandhabt? Könnte das ein Problem sein? Wenn Letzteres: Wie bügele ich das am geschicktesten wieder aus, ohne etwas zu zerschießen? (Es handelt sich bei beiden Servern um Linux, also von daher zumindest case-sensitiv.)

• Wie genau bist Du beim im gesamten Updateprozess vorgegangen?

Oh je, ich hab so viel ausprobiert ... Das kann ich gar nicht alles beschreiben. Aber ich komme ggf. nochmal darauf zurück.

Mit dabei Sicherung über die Erweiterung DBBackup, über MyPHPAdmin - mit allen Tabellen und ohne deinen "Exludes", über mysqldump auf der Konsole. Da kommen einige GB zusammen ;-)
Import geht am besten mit mysql auf der Konsole (siehe oben).

• Hast Du beim Export der DB von Contao 3 alle Tabellen gesichert?

Bei manchen Exemplaren auf jeden Fall.

Es ist zu empfehlen beim Export der DB aus der alten Installation folgende Tabellen nicht mit zu sichern:
tl_search
tl_search_index
tl_undo
tl_version
tl_session
tl_log
Sie werden neu erstellt bei Aufruf des Installtools und Du veringerst dabei ggf. die Größe des DB-Dumps enorm.

Sehr gut. Damit ist der Dump immerhin von über 800 MB auf unter 500 MB heruntergegangen.
Leider stockt es in diesem Fall damit genauso.

• Was genau meinst Du mit " Das erforderte beim Import Sonderwege"
• Bist Du sicher das der Export Deiner Datenbank komplett war?
• Bist Du sicher, dass der Import Deiner Datenbank komplett durchgeführt wurde?
• Welche Erweiterungen sind in der Contao 3.5 Installation installiert gewesen?

Es sollte heute eigentlich nicht mehr notwendig sein eine Erweiterung manuell zu installieren oder andersherum gesagt: eine Erweiterung die noch manuell zu installieren ist, wurde sicher seit einiger Zeit nicht mehr gepflegt. Es ist also fraglich ob die Erweiterung überhaupt mit Contao 4.9 bzw. 4.13 kompatibel ist

Um die Inkompatibilität der Erweiterungen auszuschließen, habe ich inzwischen exakt die Gleiche (3.5.2) genommen, Ergebnis siehe oben. (Wobei ich bei der Contao 3 noch gar keine Erweiterungen installiert habe...)
In die neuen Contao 4 hatte ich sie zum Teil kopiert, damit möglichst nichts fehlt und alte Strukturen ihr "Futter" finden - wenn es im Video schon so schön glatt 1:1 klingt. Es war bzw. ist halt eine Hoffnung.

[tab]

Also was an den Updateversuchen von tl_form auffällt ist, dass hier ein Index erzeugt werden soll, bevor die Spalten hinzugefügt werden. Das dürfte so natürlich nicht klappen und prompt kommt ja auch der Fehler, dass die Spalte nicht vorhanden ist. Kann man im Installtool nicht auswählen, welche Änderungen ausgeführt werden sollen? Denke schon, habe ich ja letztens auch gemacht. Dann würde ich einfach mal die Erzeugung der drei Indizes nicht auswählen und erst mal die dafür notwendigen Spalten hinzufügen lassen. Wenn die dann drin sind, die Indizes versuchen. Welche Erweiterung bringt die Spalten eigentlich mit? Ist das contao_leads (oder so ähnlich, habe es noch nie benutzt)? Oder wurden die drei Indizes vielleicht nachträglich irgendwie eingefügt, um die Performance zu verbessern? Jedenfalls stimmt da was mit der Reihenfolge der vorgeschlagenen Datenbankänderungen nicht.

Ich denke auch, Contao 3.5.2 war noch nicht voll kompatibel zu PHP 7, die 3.5.40 wäre es.

[Contaona]

*Trommelwirbel* Dank euch ist die alte Contao-3.5.2-Website nun (noch mit ein paar Macken) direkt in Contao 4.9! Übrigens vorher auch in Contao 3 auf dem neuen Server, wurde dann aber außer für logische Folgerungen nicht mehr gebraucht. :-)

Neulich (#7) war bei dem ganzen Hin und Her plus Müdigkeit etwas durcheinandergeraten, aber zum Glück hat es dennoch die entscheidenen Punkte enthalten und eure Antworten haben verhindert, dass ich mich verrenne.

Wie es schließlich geklappt hat:

1) Export über MyPHPAdmin ohne die Tabellen tl_search, tl_search_index, tl_undo, tl_version, tl_session, tl_log und ansonsten voreingestellten Optionen.
Das hat nicht nur den Dump von über 800 MB auf unter 5 MB - mit 2 Nullen weniger, sic! - reduziert, sondern wohl auch folgende "Duplikate" aus dem Suchverlauf verhindert.

[2022-08-09 16:20:24] request.CRITICAL: Uncaught PHP Exception Doctrine\DBAL\Exception\UniqueConstraintViolationE xception: "An exception occurred while executing 'CREATE UNIQUE INDEX url ON tl_search (url)': SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'foo/bar' for key 'url'" at /pfad/contao-4-9/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php line 74 {"exception":"[object] (Doctrine\\DBAL\\Exception\\UniqueConstraintViolat ionException(code: 0): An exception occurred while executing 'CREATE UNIQUE INDEX url ON tl_search (url)':\n\nSQLSTATE[23000]: Integrity constraint violation: 1062

Import über die Konsole: mysql -u benutzer3 -p datenbank3 < Database_datenbankname1_datum.sql. (Andere Methoden habe ich nicht mehr ausprobiert, wäre aber sicherlich auch gegangen.)


2) Durch Abwählen der SQL-Index-Befehle bei der Aktualisierung der Datenbank im Installtool lief es endlich; dann stufenweise erneut die Datenbank mit den restlichen Befehlen aktualisieren lassen. Bei Contao 4.9 kommt kein Weg dran vorbei, auch mit der wie oben beschrieben bereinigten Datenbank nicht. Bin gespannt, wie es bei anderen bevorstehenden Migrationen aussieht. (Bei Contao 3 erschien es bei korrektem Vorgehen doch nicht.)

Euch nochmal ein riesendickes Dankeschön! Inzwischen habe ich auch die ersten "Macken" beheben können, aber einiges hakt noch ...

Gibt es irgendwo eine Übersicht mit den typischen Änderungen, die vorzunehmen sind, wenn man von Contao 3 auf 4 umsteigt?

Ein Beispiel wäre folgendes:

Wenn man in Contao 3 URLs ohne jeglichen Zusatz haben wollte, also auch ohne ".html" am Ende, musste man ein Häkchen in den Einstellungen beachten und die .htaccess bearbeiten. Und in Contao 4? Da finde ich die Einstellung bisher gar nicht.

[tab]

Zwecks URL Suffix: https://contao-academy.de/blog/url-s...ntao4-anpassen
Ansonsten zwei Dinge die ich anpassen musste:

• In der Navigation ist der aktive Eintrag jetzt ein strong-Tag, bisher span. -> CSS anpassen, in einigen Regeln musste span durch strong ersetzt werden.
• Bei den Nachrichtenlisten hat sich die HTML-Struktur etwas geändert, was bei mir wiederum Anpassungen am CSS notwendig machte

Ansonsten die eigenen Templates auf den neuen Stand bringen, also die Änderungen im Vergleich zum Standardtemplate auf das jeweilige neue Standardtemplate übertragen. Auch wenn das in vielen Fällen optisch nicht unbedingt sichtbar ist, sind doch Verbesserungen im Detail enthalten.

Edit: In den Seitenlayouts werden jetzt teils native JS Templates eingebunden anstatt jQuery. Das wird auch soweit passend ersetzt, braucht aber gelegentlich einfach ein Abspeichern des Layouts, bis es greift. Auch wenn du nichts drin geändert hast. Auch ystemwartung mal drüberlaufen lassen kann nichts schaden. Suchindex neu aufbauen. Caching-Einstellungen für den Servercache (public) eventuell auf längere Zeiten setzen wie bisher, da bei den allermeisten Änderungen im Backend die betroffenen Cacheseite automatisch invalidiert und somit beim nächsten Aufruf neu erzeugt werden. Kann man also ohne Weiteres auch auf einige Monate einstellen, was früher in 3.x dann gelegentlich ein komplettes Löschen des Caches erforderlich machte.

Neue .htaccess verwenden und die eigenen Anpassungen an der alten .htaccess nach Bedarf übernehmen.

Naja, gibt sicher noch einiges, was ich bereits wieder vergessen habe.

[Contaona]

Zwecks URL Suffix: https://contao-academy.de/blog/url-s...ntao4-anpassen

Damit hat es auf Anhieb geklappt.

Ansonsten zwei Dinge die ich anpassen musste:

• In der Navigation ist der aktive Eintrag jetzt ein strong-Tag, bisher span. -> CSS anpassen, in einigen Regeln musste span durch strong ersetzt werden.

Was bin ich froh, dass du mir diesen konkreten Hinweis gegeben hast! Mit dem Hinweis habe ich Stunden gebraucht; ohne wäre ich wohl einfach nur noch verrückt geworden. Es klingt so einfach, mal eben das CSS anzupassen. Es war auch gar nicht viel. Nur die Navigation(en) und zwei, drei weitere problemlose Kleinigkeiten. Wenn da nicht die ganzen Nebeneffekte von Caches und Mischungen von verschiedenen Quellen usw. wären ... Aber auch das ist nun geschafft. :-)

• Bei den Nachrichtenlisten hat sich die HTML-Struktur etwas geändert, was bei mir wiederum Anpassungen am CSS notwendig machte

Ansonsten die eigenen Templates auf den neuen Stand bringen, also die Änderungen im Vergleich zum Standardtemplate auf das jeweilige neue Standardtemplate übertragen. Auch wenn das in vielen Fällen optisch nicht unbedingt sichtbar ist, sind doch Verbesserungen im Detail enthalten.

Hm.

Edit: In den Seitenlayouts werden jetzt teils native JS Templates eingebunden anstatt jQuery. Das wird auch soweit passend ersetzt, braucht aber gelegentlich einfach ein Abspeichern des Layouts, bis es greift. Auch wenn du nichts drin geändert hast. Auch ystemwartung mal drüberlaufen lassen kann nichts schaden. Suchindex neu aufbauen. Caching-Einstellungen für den Servercache (public) eventuell auf längere Zeiten setzen wie bisher, da bei den allermeisten Änderungen im Backend die betroffenen Cacheseite automatisch invalidiert und somit beim nächsten Aufruf neu erzeugt werden. Kann man also ohne Weiteres auch auf einige Monate einstellen, was früher in 3.x dann gelegentlich ein komplettes Löschen des Caches erforderlich machte.

Oha... Ich werde gleich darauf zurückkommen ... Ob mein Problemchen mit einer Wortwolke, die nicht richtig weiterleitet, vielleicht hiermit zu tun hat?

Neue .htaccess verwenden und die eigenen Anpassungen an der alten .htaccess nach Bedarf übernehmen.

Sehr wichtig, ja. Das hatte ich gleich zu Beginn gemacht. Und ich glaube nach näherem Hinsehen auch eher nicht, dass die fehlerhafte Weiterleitung etwas damit zu haben könnte.

Naja, gibt sicher noch einiges, was ich bereits wieder vergessen habe.

Falls es dir irgendwann mal einfällt, gern auch noch später ergänzen. Kann immer noch mal helfen.


Hier nun die Beschreibung des erwähnten offenen Problemchens:

Bei der neuen Website leitet die Wortwolke nicht mehr auf verlinkte Ergebnisliste.

Contao-3-Website auf dem alten Server, die gleiche auf Contao 4 migrierte Website auf dem neuen Server, sodass ich beide an sich gut vergleichen kann.
Schritt für Schritt bin ich jedes Modul usw. durchgegangen und alles sieht gleich aus.

Das Ergebnis ist es aber leider nicht: Die Tagwolke ist bei beiden auf Seite A, mit den gleichen Stichwörtern. Aber die Zielstruktur der Links passt bei Contao 4 nicht mehr.
Denn statt auf die Ergebnisseite zu führen (example.org/ergebnisseite/tag/foo)
bleibt es auf der Seite A (example.org/seiteA/tag/foo)
Gebe ich die URL example.org/ergebnisseite/tag/foo per Hand in den Browser, ist diese <strike>korrekt<strike>[*1] vorhanden.
Es geht also <strike>nur</strike>[*1] um diese verflixten Links, die anders zusammengesetzt werden. Als wär der Default einer Variable im Link die aktuelle Seite, die nicht mit dem Eintrag der Weiterleitung überschrieben wird, oder was weiß ich.

Im Tagwolken-Modul ist der Modultyp "Tag Cloud", Tag-Cloud-Template "mod_tagcloud", Weiterleitung zu "ergebnisseite".
Ein Diff der beiden Dateien mod_tagcloud ergibt, dass sie identisch sind.

Dann habe ich noch die Mootools aktiviert, weil das in der Doku als Voraussetzung stand. Das hat die ganze Website lahmgelegt, wegen
'request.CRITICAL: Uncaught PHP Exception Exception: "Could not find template "moo_slider""'
Ich hab gar nicht mehr ausprobiert, die Einzeloption abzuwählen, weil ich festgestellt habe, dass ich die Mootools in der alten Version gar nicht aktiviert hatte. Daran dürfte es also eh nicht liegen.

Stundenlang suche ich nach dem Unterschied in der Ursache und finde ihn nicht.

Hier und da habe ich etwas geändert (und rückgängig gemacht), um zu sehen, was sich tut und ob es dann "greift". Die Systemwartung habe ich zigmal laufen lassen. Nichts.
Die Änderungen haben sich schon ausgewirkt, zum Beispiel das mit den Top 10, was ich vorher nicht hatte. Was zeigt, dass nicht alles völlig gleich ist. Funktioniert auch alles - bis auf die Links.

Nun frage ich mich eben, ob sich irgendwo etwas versteckt, was mit "deinem Edit" zu haben könnte. Allerdings weiß ich damit immer noch nicht, wie ich gezielt vorgehen müsste...

[*1] EDIT: *seufz* Nein, es läuft nicht korrekt, denn es zeigt nicht nur die Ergebnisse zu diesem Stichwort an. :-( Also ist der Fall doch noch mal anders gelagert. Weiter bin ich damit allerdings nicht.

[Contaona]

Möglicherweise liegt das Problem wo ganz anders und betrifft nicht nur die Tags-Erweiterung. Denn jetzt gibt es auch Probleme mit der Standard-Eventliste.

Auf der Website gibt es eine Kalenderseite, auf der alle Termine angezeigt werden. Auf der Startseite soll dagegen nur eine aktuelle Auswahl davon angezeigt werden.
Beides klappt auf der alten Website, auf der neuen werden stattdessen auch auf der Startseite alle angezeigt. Das bedeutet, dass wie bei der Tags-Ergebnisseite die Eingrenzung nicht wirkt.

Modultyp "Eventliste", Anzeigeformat "Alle künftigen Events",
Eventleser "Calendar Event Reader" von der Contao-Official-Demo,
Auszeichnungsfilter "topaktuell" (als Beispiel),
Event-Template "event_upcoming", Modul-Template "mod_eventlist (Standard)"