Contao 4.4 oder 4.6. Installtool Meldung: Es ist ein Fehler aufgetreten (evtl. auch 4.9.)

NACHTRAG - Alternative Lösung, Vorabtest:

Da der bisherige Lösungsansatz nur in bestimmten Konstellationen hilft, ist es unter Umständen ratsam zuerst einmal den folgenden Schritt auszuführen:

Contao-Manager starten und oben auf "Systemwartung". Dann bei "Composer Abhängigkeiten" hinten das Pfeilchen klicken und "Composer Update ausführen" anklicken.

Dieses Update alleine genügt oft schon den korrekten Aufruf des Install-Tools zu bewirken.

 

NACHTRAG2 - Alternative Lösung, Vorabtest Nr. 2:

Der Fehler kann auch vorkommen, wenn eine oder mehrere Tabellen aus dem Dump nicht wirklich in Ordnung sind. Gerade bei großen MySQL-Dumps gab es einmal das Problem, das eine erzeugte Dump-Datei (im .zip Format) fehlerhaft war. Erkennbar war der Fehler durch eine tl_xxxxxx (Tabelle) Fehlermeldung im Log-File in vars/logs (in meinem Fall das es die tl_newsletter_recipients welche einen Fehler meldete). Eine unkomprimierte Datei lies sich wegen der Größe nicht ohen weiters nutzen (dazu hätte der MySQL Dumper herhalten müssen).

Die Lösung war einen neuen Dump zu erzeugen und einzuspielen, aber in diesem Fall über eine GZ Kompression zu gehen. Nach dem Import der GZ Datei lies sich das Installtoll wieder fehlerlos starten.

 

Ursprünglicher Artikeltext, bezogen auf die spezielle Konstallation:

Dieser Fehler ist meist sehr frustrierend und vor allem wenig Ausagekräftig. Ein Blick in das Logfile im Ordner /var/logs bringt derzeit unter Umständen den Ausdruck:

app.CRITICAL: An exception occurred. {"exception":"[object] (Doctrine\\DBAL\\Schema\\SchemaException(code: 30): There is no column with name 'path(333)' on table 'tl_files'. at usw.

Eine Recherche im Web bringt einem dann vielleicht zu diesen beiden Beiträgen: https://github.com/contao/contao/issues/238 oder https://github.com/doctrine/dbal/issues/3409.

Das Problem ist wohl durch ein Update von doctrine/dbal 2.9.0 auf 2.9.1 entstanden und wurde durch ein Contaoupdate z.B. von 4.4.30 to 4.4.31 quasi implementiert. Auch ein Contaoupdate von 4.6.8 auf 4.6.10 oder 4.6.11 erzeugt scheinbar diesen Fehler.

Eine nachvollziehbare Lösung des Problems findet sich im ersten github-Beitrag und hat nach meinen Tests zumindest gut funktioniert, solange es kein neues Updates gibt die den Fehler beheben:

Ergänze im Rootverzeichnis in der Datei composer.json manuell die Zeile:

"conflict": { 

		"doctrine/dbal": "2.9.1" 
},

Wichtig ist das Komma am Ende wenn man den Baustein dazwischen einfügt (meine komplette Datei führe ich unten auf).

Hat man es korrekt eingefügt kann man den Contao-Manager starten und geht oben auf "Systemwartung". Dann bei "Composer Abhängigkeiten" hinten das Pfeilchen klicken und "Composer Update ausführen" anklicken.

Nach dem Update kann man das Contao-Installtool starten und dann sollte es wieder funktionieren. Für mich zählte an dieser Stelle dass die Lösung schnell und unkompliziert funktioniert, solange bis ein neues Update bereit gestellt wird und dieses Problem behoben ist.

{
    "type": "project",
    "require": {
        "contao/calendar-bundle": "^4.4",
        "contao/comments-bundle": "^4.4",
        "contao/faq-bundle": "^4.4",
        "contao/listing-bundle": "^4.4",
        "contao/manager-bundle": "4.4.*",
        "contao/news-bundle": "^4.4",
        "contao/newsletter-bundle": "^4.4"
    },
    "extra": {
        "contao-component-dir": "assets"
    },
	"conflict": {
        "doctrine/dbal": "2.9.1"
 },
    "scripts": {
        "post-install-cmd": [
            "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
        ],
        "post-update-cmd": [
            "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
        ]
    }
}