Contao 4.6.6, Install Tool, Datenbank aktualisieren Fehler: "Duplicate key name"

Druckbare Version

31.12.2018, 13:05
3dr

Liste der Anhänge anzeigen (Anzahl: 1)

Contao 4.6.6, Install Tool, Datenbank aktualisieren Fehler: "Duplicate key name"

Mit dem Datenübertragungstool bei all-inkl.com habe ich von einer Datenbank die Inhalte in eine neue Datenbank übertragen (beide DB liegen bei all-inkl). Rufe ich nun das Install-Tool auf, möchte dieses Spalten anlegen und löschen was unter var/logs diesen Fehler erzeugt:

Code:

Syntax error or access violation: 1061 Duplicate key name 'path' at /www/htdocs ...

So sieht das aus: Anhang 21749

Leider kenne ich nicht die Befehle wie ich das z.B. direkt in der Datenbank via PHPMyAdmin korrigieren kann. FE und BE scheinen zu funktionieren, vielen Dank für Tipps und Hinweise!

Und allen hier einen guten Rutsch ins neue Jahr! :D
31.12.2018, 13:23
Spooky

Generell gilt: bei Problemen immer zuerst alle Pakete aktualisieren, oder zumindest die Contao Pakete.
31.12.2018, 13:37
Seefahrer

Dieser "Fehler" tritt nach dem Update von Doctrine/Dbal auf die neue Version 2.9.2 auf (Contao 4.6.12) auf.
Nach dem Update soll die DB aktualisiert werden:

Code:

DROP INDEX path ON tl_files Spalten anlegen Alle auswählen CREATE INDEX path ON tl_files ( path(768) )

Das Aktualisieren der DB geht aber offensichtlich ins Leere, das Aktualisieren wird forever angeboten ... FE und BE etc. funktionieren aber dennoch, eine Fehlermeldung wurde bei mir nicht ins Log geschrieben ...
31.12.2018, 14:13
3dr

@Spooky, danke für deinen Support, ich hatte bereits alle Pakete aktualisiert und habe das nun nochmals getan: das Problem besteht danach immer noch.

@Seefahrer, danke für deinen Hinweis; bei mir wurde das Log erst gefüllt mit:

Code:

Syntax error or access violation: 1061 Duplicate key name 'path' at /www/htdocs ...

nachdem ich nur die Checkbox

Code:

CREATE INDEX path ON tl_files ( path(768) )

ausgewählt hatte, was mir logisch erscheint da eine Spalte path in der Datenbanktabelle tl_files vorhanden ist. Hat bereits jemand das Problem lösen können? Danke für Tipps und Hinweise!
31.12.2018, 14:15
Spooky

Das heißt du bist nun auf Contao 4.6.12? Wenn du diesen Fehler in einer frischen Contao 4.6.12 Installation nachvollziehen kannst poste das als Bug auf GitHub (inkl doctrine Versionsangabe).

Hat vermutlich mit dieser Änderung zu tun: https://github.com/doctrine/dbal/pull/3415
31.12.2018, 14:55
3dr

Liste der Anhänge anzeigen (Anzahl: 1)
Okay Spooky, ich versuche mal hier Sinnvolles beizutragen (bin kein Entwickler):
1. Ja, ich bin auf Contao 4.6.12, der Fehler trat auf nach einem Update von Contao 4.6.11 auf Contao 4.6.12, einzige installierte Erweiterung: Isotope, upgrade heute
2. Der Fehler tritt ebenfalls auf nach einem Update von Contao 4.6.5 auf Contao 4.6.12, keine installierte Erweiterung, gerade getestet siehe hier: Anhang 21750
3. Der Fehler tritt nicht auf bei einer Installation von Contao 4.6.12 (Core only), am 29.12.2018 frisch installliert
Für mich daher vorstellbar, dass das mit dieser Änderung zu tun hat: https://github.com/doctrine/dbal/pull/3415 Zwar habe ich einen Github-Account, weiss bisher allerdings nicht wie ich an die

Zitat:

doctrine Versionsangabe

komme und wie ich den Fehler wo auf Github beschreiben könnte, wozu rätst du mir?
31.12.2018, 17:45
3dr

So, in der composer.lock der Contao 4.6.12 Installation finde ich in Zeile 1505 diesen Eintrag:

Code:

"doctrine/dbal": "^2.9",

ist das die von dir genannte

Zitat:

doctrine Versionsangabe

?
31.12.2018, 18:04
PaddySD

Das ist aber nicht die installierte Version, sondern eine Abhängigkeit (require), in dem Fall vom contao-installation-bundle.

Du musst nach dem Namenseintrag suchen. Gib mal im Suchfeld Deines Editors folgendes ein:

Code:

"name": "doctrine/db

So sollte der Eintrag aussehen, und diese Versionsnummer wäre wichtig:

Code:

{ "name": "doctrine/dbal", "version": "v2.9.2", "source": { "type": "git", "url": "https://github.com/doctrine/dbal.git", "reference": "22800bd651c1d8d2a9719e2a3dc46d5108ebfcc9" }, "dist": { "type": "zip", "url": "https://api.github.com/repos/doctrine/dbal/zipball/22800bd651c1d8d2a9719e2a3dc46d5108ebfcc9", "reference": "22800bd651c1d8d2a9719e2a3dc46d5108ebfcc9", "shasum": "" }, "require": { "doctrine/cache": "^1.0", "doctrine/event-manager": "^1.0", "ext-pdo": "*", "php": "^7.1" }, "require-dev": { "doctrine/coding-standard": "^5.0", "jetbrains/phpstorm-stubs": "^2018.1.2", "phpstan/phpstan": "^0.10.1", "phpunit/phpunit": "^7.4", "symfony/console": "^2.0.5|^3.0|^4.0", "symfony/phpunit-bridge": "^3.4.5|^4.0.5" }, "suggest": { "symfony/console": "For helpful console commands such as SQL execution and import of files." }, "bin": [ "bin/doctrine-dbal" ], "type": "library", "extra": { "branch-alias": { "dev-master": "2.9.x-dev", "dev-develop": "3.0.x-dev" } }, "autoload": { "psr-4": { "Doctrine\\DBAL\\": "lib/Doctrine/DBAL" } }, "notification-url": "https://packagist.org/downloads/", "license": [ "MIT" ], "authors": [ { "name": "Roman Borschel", "email": "roman@code-factory.org" }, { "name": "Benjamin Eberlei", "email": "kontakt@beberlei.de" }, { "name": "Guilherme Blanco", "email": "guilhermeblanco@gmail.com" }, { "name": "Jonathan Wage", "email": "jonwage@gmail.com" } ], "description": "Powerful PHP database abstraction layer (DBAL) with many features for database schema introspection and management.", "homepage": "https://www.doctrine-project.org/projects/dbal.html", "keywords": [ "abstraction", "database", "dbal", "mysql", "persistence", "pgsql", "php", "queryobject" ], "time": "2018-12-31T03:27:51+00:00" },
31.12.2018, 19:05
3dr

@PaddySD, danke für die Info, hier der genannte Ausschnitt aus der composer.lock

Code:

{ "name": "doctrine/dbal", "version": "v2.9.2", "source": { "type": "git", "url": "https://github.com/doctrine/dbal.git", "reference": "22800bd651c1d8d2a9719e2a3dc46d5108ebfcc9" }, "dist": { "type": "zip", "url": "https://api.github.com/repos/doctrine/dbal/zipball/22800bd651c1d8d2a9719e2a3dc46d5108ebfcc9", "reference": "22800bd651c1d8d2a9719e2a3dc46d5108ebfcc9", "shasum": "" }, "require": { "doctrine/cache": "^1.0", "doctrine/event-manager": "^1.0", "ext-pdo": "*", "php": "^7.1" }, "require-dev": { "doctrine/coding-standard": "^5.0", "jetbrains/phpstorm-stubs": "^2018.1.2", "phpstan/phpstan": "^0.10.1", "phpunit/phpunit": "^7.4", "symfony/console": "^2.0.5|^3.0|^4.0", "symfony/phpunit-bridge": "^3.4.5|^4.0.5" }, "suggest": { "symfony/console": "For helpful console commands such as SQL execution and import of files." }, "bin": [ "bin/doctrine-dbal" ], "type": "library", "extra": { "branch-alias": { "dev-master": "2.9.x-dev", "dev-develop": "3.0.x-dev" } }, "autoload": { "psr-4": { "Doctrine\\DBAL\\": "lib/Doctrine/DBAL" } }, "notification-url": "https://packagist.org/downloads/", "license": [ "MIT" ], "authors": [ { "name": "Roman Borschel", "email": "roman@code-factory.org" }, { "name": "Benjamin Eberlei", "email": "kontakt@beberlei.de" }, { "name": "Guilherme Blanco", "email": "guilhermeblanco@gmail.com" }, { "name": "Jonathan Wage", "email": "jonwage@gmail.com" } ], "description": "Powerful PHP database abstraction layer (DBAL) with many features for database schema introspection and management.", "homepage": "https://www.doctrine-project.org/projects/dbal.html", "keywords": [ "abstraction", "database", "dbal", "mysql", "persistence", "pgsql", "php", "queryobject" ], "time": "2018-12-31T03:27:51+00:00" },
01.01.2019, 09:45
Spooky

Deine doctrine/dbal Version ist 2.9.2
01.01.2019, 19:00
neelix

Hallo zusammen,

ich hänge an der gleichen Stelle fest. Ich komme auch von einer 4.6.6 auf die 4.6.12.

Ich habe die beiden Queries auch schon zu Fuß per phpMyAdmin gemacht. Nützt aber nicht. Das Install-Tool dreht sich hier im Kreis.

Der Index ist in der DB vorhanden, ich würde die Schleife aber trotzdem gerne durchbrechen.

Neelix
01.01.2019, 19:22
Znrl

Hab das gleiche Problem, auch ein manuelles löschen der gesamten "tl_files" hilft nicht, im Installtool wird dann erst die Tabelle wieder angelegt und danach kommt die gleiche Meldung wie in #3 wieder.

Dieser pull request scheint ja um so was zu gehen?
https://github.com/contao/contao/pull/256
01.01.2019, 19:42
3dr

@Spooky,
dass meine doctrine/dbal Version 2.9.2 ist habe ich jetzt verstanden, da ich das Verhalten im Install-Tool jedoch nicht qualifiziert als Fehler beschreiben kann, werde ich auf Github zunächst nichts tun. Ist die Ursache dieses Verhaltens nicht schon in https://github.com/doctrine/dbal/pull/3415 beschrieben, denn zumindest bei mir ist das nur bei einem Upgrade auf 4.6.12 aufgetreten, nicht bei einer Neuinstallation?

@Neelix,
kannst du hier beschreiben wie solche Queries zu Fuß per phpMyAdmin gemacht werden, vielen Dank!
01.01.2019, 19:45
neelix

Zitat:

Zitat von 3dr

@Neelix,
kannst du hier beschreiben wie solche Queries zu Fuß per phpMyAdmin gemacht werden, vielen Dank!

Geh im phpMyAdmin in die entsprechende Datenbank, dort oben auf SQL und führe die Querie aus, die das Install-Tool machen will:

Code:

DROP INDEX path ON tl_files; CREATE INDEX path ON tl_files ( path(768) );

Wenn Du dann in der Struktur der Tabelle 'tl_files' schaust, siehst Du ganz am Ende die Auflistung der Indizies.
01.01.2019, 21:47
Toubibe

Also wenn ich die Diskussion im Forum und die Einträge unter anderem von Leo im Github betrachte, scheint es nach wie vor ein Problem mit doctrine/dbal und Contao 4.6 zu geben, während das Problem für die Version 4.4 gelöst zu sein scheint.
Siehe dazu Github https://github.com/contao/contao/issues/238 --> offenbar wurden in Contao 4.6.12 die notwendigen Kompatibilitätsänderungen durchgeführt, aber nach wie vor besteht wenn ich das ganze richtig verstanden habe ich Bug in doctrine/dbal (Leo: Note that Doctrine still needs to fix doctrine/dbal#3414 so index length changes are detected correctly).

Ich denke, im Moment gibt es nur den Weg, dass in der composer.json die dbal Version 2.9 als Konflikt aufgeführt wird:
"conflict": {
"doctrine/dbal": "^2.9"
},
Damit läuft das ganze wieder korrekt, allerdings wird gleichzeitig auf die Contao-Version 4.6.11 runtergestuft - aber immerhin läuft es so, jedoch bei meinen Versuchen weder mit dbal 2.9.1 noch mit 2.9.2.
Und der Versuch, die Contao-Version 4.6.12 durch einen entsprechenden Eintrag in der composer.json zu "erzwingen" unter oben eingetragenem Konflikt, ergibt die Fehlermeldung im Contao-Manager: "Console task terminated" ... "- contao/installation-bundle 4.6.12 requires doctrine/dbal ^2.9 -> satisfiable by doctrine/dbal[v2.9.0, v2.9.1, v2.9.2]"

Kurz: bei mir läuft es nur mit dbal 2.8.1 und Contao 4.6.11 und jetzt warte ich auf Doctrine, dass die ihre Hausaufgaben machen ;-) Wenn ich dort richtig interpretiert habe, ist dies als Milestone für dbal 2.10 notiert.
01.01.2019, 21:55
Spooky

Zitat:

Zitat von 3dr

@Spooky,
dass meine doctrine/dbal Version 2.9.2 ist habe ich jetzt verstanden, da ich das Verhalten im Install-Tool jedoch nicht qualifiziert als Fehler beschreiben kann, werde ich auf Github zunächst nichts tun. Ist die Ursache dieses Verhaltens nicht schon in https://github.com/doctrine/dbal/pull/3415 beschrieben, denn zumindest bei mir ist das nur bei einem Upgrade auf 4.6.12 aufgetreten, nicht bei einer Neuinstallation?

Tritt vermutlich nur auf, wenn die Tabelle schon zuvor existiert und vor doctrine/dbal 2.9.2 erzeugt wurde.

Poste wie gesagt den Bug Report.
01.01.2019, 21:56
neelix

Es ist aber anscheinend auch abhängig davon von welcher Version man beim Update kommt.

Ich habe eine Installation, die ich regelmäßig und oft auf die jeweils aktuelle Version ziehe und andere Installationen, die auch mal mehrere Wochen bis Monate kein Update sehen.

Der Sprung von 4.6.11 auf 4.6.12 war kein Problem und bei dieser Installation bin ich auch vorher nie in dieser Schleife hängen geblieben (k.A. wann diese Indexänderung erstmals durchgeführt wird).

Beim Sprung von 4.6.6 auf 4.6.12 bei einer der anderen Installationen aber jetzt bin ich jetzt in den Fehler gelaufen.
01.01.2019, 22:02
PaddySD

@Toubibe

Hast Du schonmal versucht, die doctrine/dbal 2.9.0 zu nehmen? Also so:

Code:

"conflict": { "doctrine/dbal": ">=2.9.1" },
01.01.2019, 22:05
neelix

Ich habe gerade mal bei einer andern 4.6.6 geguckt.

Wenn ich dort einen Testlauf mache, dann will er folgende Updates laden:

Code:

- Updating doctrine/doctrine-cache-bundle (1.3.3) to doctrine/doctrine-cache-bundle (1.3.5) - Updating doctrine/dbal (v2.8.0) to doctrine/dbal (v2.9.2) - Updating doctrine/doctrine-bundle (1.9.1) to doctrine/doctrine-bundle (1.10.0)

Installationsstand: 21.9.2018, 17:33:19
01.01.2019, 23:36
Znrl

Zitat:

Zitat von neelix

Geh im phpMyAdmin in die entsprechende Datenbank, dort oben auf SQL und führe die Querie aus, die das Install-Tool machen will:

Code:

DROP INDEX path ON tl_files; CREATE INDEX path ON tl_files ( path(768) );

...

Wenn ich das direkt (mit Adminer) durchführe steht dort jeweils:
Abfrage ausgeführt, 0 Datensätze betroffen

Im Installtool ändert sich dadurch erwartungsgemäß nichts.

Wie gesagt hilft es aber auch nicht die die Tabelle tl_files komplett zu löschen.
Wäre jetzt nur mal interessant zu sehen, was an der Tabelle anders ist, wenn man die 4.6.12 direkt installiert?
Oder liegt das vtl. nur daran, dass Contao irgendein updatescript dort einfach gar nicht erst ausführt?
02.01.2019, 03:03
Toubibe

Zitat:

Zitat von PaddySD

@Toubibe

Hast Du schonmal versucht, die doctrine/dbal 2.9.0 zu nehmen? Also so:

Code:

"conflict": { "doctrine/dbal": ">=2.9.1" },

Funktioniert! und damit wird auch das Update auf Contao 4.6.12 eingespielt.
Das heisst also, die bisherigen Updates funktionieren, wenn doctrine/dbal 2.9.0 installiert ist, nicht aber mit 2.9.1 und 2.9.2
02.01.2019, 06:54
bizon

Zitat:

Zitat von Toubibe

"conflict": {
"doctrine/dbal": ">=2.9.1"
},

Damit werden aber sämtliche kommenden Updates von doctrine/dbal ausgeschlossen.

Besser wäre also dieser Eintrag, der nur die nicht laufenden Versionen ausschließt:

Code:

"conflict": { "doctrine/dbal": "2.9.1|2.9.2" },
02.01.2019, 08:56
PaddySD

Ich hab den Eintrag absichtlich so gewählt, da ich im Moment lieber eine funktionierende Contao Version habe, als beim nächsten Update vorher schauen zu müssen.

Deshalb lieber "ab jetzt" ausschliessen, und den Eintrag dann entsprechend entfernen, wenn die dbal-Version wieder passt, als andersrum. Better safe than sorry :D
02.01.2019, 09:13
Spooky

Der Fehler muss vermutlich in Contao selbst behoben werden, daher wäre es wichtig einen entsprechenden Bug Report zu machen. Bisher wurde das noch nicht gemacht.
02.01.2019, 10:45
3dr

@Spooky,
gerade habe ich versucht das Verhalten auf Github zu melden, dies wäre dann mein erstes Issue gewesen. Wie ich lese, müssen dazu wohl die betroffenen Contao-Versionen und die Wege zur Reproduzierbarkeit angegeben werden. Beide Fragen kann ich jedoch nicht beantworten da ich z.B. keine Contao 4.4.*-Version habe und auch keine ältere Contao 4.6-Version die ich updaten könnte (bei einer Neuinstallation von 4.6.12 hatte ich dieses Verhalten nicht).
02.01.2019, 10:47
intradesign

Hallo zusammen!

Ich werde das gleich auch mal testen.

Ich finde es ziemlich doof, dass überhaupt ungetestete Updates der Drittanbieter-Pakete eingespielt werden. Ich sehe das so wie PaddySD. Was ist denn aus "never change a running system" geworden?
Nicht dass ich keine Updates installieren möchte, aber es gibt bei den vielen Abhängigkeiten andauernd Updates und immer wieder führen die zu Problemen, die zwar meistens durch downgrade behebbar sind, aber die Suche nach einer Problemlösung kostet oft recht viel Zeit.

Aus meiner Sicht müssten die Versionen der Abhängigkeiten je Contao-Version festgeschrieben werden und neuere Versionen der Abhängigkeiten nur auf expliziten Wunsch hin manuell aktualisieren lassen - sprich: Die müssten auch im Contao Manager erscheinen und dort manuell zum Update markiert werden können, nicht nur bei einem Update automatisch mit aktualisiert werden.

Nur mit neuen Contao-Versionen dürften die Abhängigkeiten auch in neuer Version verwendet werden – und auch nur, wenn die wirklich funktionieren und das getestet wurde.
02.01.2019, 11:57
PaddySD

Das ist ein eher generelles Problem bei heutiger Software. Jeder arbeitet mit Bibliotheken, die von irgendwoher kommen. Die Idee dahinter ist ja auch gut, denn so konzentriert sich jeder auf das, was er kann. Für ein "normales" Contao werden im Moment so um die 130 "Einzelprogramme" installiert...

Das ist ja aber auch so gedacht, denn dafür gibt es ja den LTS-Strang (4.4.x), bei dem genau solche Sachen vermieden werden. Ich hab im Moment nur zwei echte Projekte auf 4.6.x laufen, der Rest ist noch 4.4.x.

Es ist ja auch gut, denn ohne testen finden sich keine Fehler. Vielleicht sollte man solche Unterschiede klarer kommunizieren, damit die entsprechende Version genommen wird. Wenn Du mal schaust, allle diese Fehler sind in der 4.4.x nicht vorhanden (von Einzelfällen mal abgesehen).

Ich stelle zB bei einem Kunden mit 4.6.x (war nötig zw DSGVO) nur den halben Supportpreis in Rechnung, weil ich weiss, da wird definitiv mehr Arbeit kommen, weil "Testversion".
08.01.2019, 10:45
3dr

Sorry für die späte Rückmeldung und danke @Seefahrer, dass du das Problem auf Github gemeldet hast. Mit dem von @bizon genannten Eintrag in der composer.json

Code:

"conflict": { "doctrine/dbal": "2.9.1|2.9.2" },

läuft bei mir nun das Install-Tool sauber durch. Muss dieser conflict-Eintrag ab einem gewissen Punkt wieder entfernt werden oder kann der so stehen bleiben?
08.01.2019, 11:24
bizon

Kannst den Eintrag so stehen lassen, stört nicht. Der schließt ja nur die doctrine/dbal Versionen 2.9.1 und 2.9.2 aus. Die nächste (z.B. 2.9.3), dann hoffentlich wieder funktionierende Version wird automatisch installiert.
08.01.2019, 13:31
kubjo

Was ich nicht so richtig kapiert habe ist:
Wird das in der nächsten Contao Version 4.6.13 gefixed, oder in der nächsten doctrine/dbal 2.9.3, oder muß das immer über die composer.json laufen?

Grüße
JK
08.01.2019, 13:35
lucina

Es scheint so als würde das mit dbal 2.9.3 gefixt. Ticket ist schon zu.
08.01.2019, 19:01
intradesign

Also ich weiß auch nicht... ich habe die exclusion Einträge in der composer.json eingetragen und trotzdem bekomme ich noch die Fehlermeldung und die gleichen Einträge System-Log. Bei der anderen Installation hat es funktioniert (identische konfiguration auf demselben Server).

Das Frontend läuft.

Hat noch jemand eine Idee?

Vielen Dank und viele Grüße
Timo
08.01.2019, 19:07
xchs

Du könntest ggf. versuchen, die composer.lock in composer.lock.bak umzubenennen und anschließend erneut eine vollständige Paketaktualisierung auszuführen.
10.01.2019, 11:01
bird

Ich erhalte bei der Neuinstallation einer V 4.6.12 inkl. der Core Standarderweiterungen ebenfalls einen Fehler im Install-Tool. Das Log-File meldet, dass einen Konflikt bei der Erstellung der "tl_newsletter_recipients" besteht:

SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes" at /.../vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php line 106

Der Conflict-Eintrag (doctrine/dbal": "2.9.1|2.9.2") in der composer.json wurde bereits gesetzt und die doctrine/dbal ist 2.9.0. Die Pakete wurden nochmals vollständig aktualisiert.

EDIT: Der beschriebene Konflikt kann nur vermieden werden, indem man auch Version 2.9.0 ausschließt.
14.01.2019, 11:57
Tschuliaaa

Vollständige Paketaktualisierung ausführen?

Zitat:

Zitat von xchs

anschließend erneut eine vollständige Paketaktualisierung auszuführen.

ok und wie mache ich diese Paketaktualisierung?
14.01.2019, 12:00
Spooky

Den entsprechenden Button im Contao Manager klicken.
14.01.2019, 12:03
Tschuliaaa

Liste der Anhänge anzeigen (Anzahl: 2)

auch Version 2.9.0 ausschließen

EDIT: Der beschriebene Konflikt kann nur vermieden werden, indem man auch Version 2.9.0 ausschließt.[/QUOTE]

In der composer.json in meinem Root Verzeichnis?

Der Code um alle drei Versionen auszuschließen, wäre dann entsprechend so?

HTML-Code:

"conflict": { "doctrine/dbal": "2.9.0|2.9.1|2.9.2" },

Ich hocke da jetzt seit 3 Tagen dran und bin echt langsam maximal genervt...

Contao 4.6.12 - Immer wieder der Error beim Aktualisieren der DB: SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes at /is/htdocs/.../www/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:88
14.01.2019, 12:08
Spooky

Der richtige Eintrag lautet

Code:

"conflict": { "doctrine/dbal": "2.9.1 || 2.9.2" }
14.01.2019, 14:42
xchs

Zitat:

Zitat von Tschuliaaa

EDIT: Der beschriebene Konflikt kann nur vermieden werden, indem man auch Version 2.9.0 ausschließt.

Das ist nicht notwendig.

Zitat:

Zitat von Tschuliaaa

In der composer.json in meinem Root Verzeichnis?

Ja.
14.01.2019, 15:51
iuna123

Zitat:

Zitat von Spooky

Der richtige Eintrag lautet

Code:

"conflict": { "doctrine/dbal": "2.9.1 || 2.9.2" }

Falls das irgendwie für euch wichtig ist:
Bei mir tauchte der Fehler nach einer Neuinstallation auf.

Da ich noch nie etwas in die composer.lock Datei geschrieben habe - wo genau muss ich diese Zeile einfügen?
und mit einem abschließendem Beistrich? oder ohne?
Danke für eure Hilfe!
Liebe Grüße
Daiela
14.01.2019, 15:52
Spooky

In die composer.lock sollst du nichts schreiben. Dieser Eintrag gehört in die composer.json.
14.01.2019, 15:56
3dr

Hi, das schreibst du nicht in die composer.lock sondern in die composer.json

Code:

"conflict": { "doctrine/dbal": "2.9.1 || 2.9.2" },

und nicht das abschliessende Komma vergessen!
14.01.2019, 16:09
iuna123

Zitat:

Zitat von 3dr

Hi, das schreibst du nicht in die composer.lock sondern in die composer.json

Code:

"conflict": { "doctrine/dbal": "2.9.1 || 2.9.2" },

und nicht das abschliessende Komma vergessen!

Oh! Danke!
Hab es jetzt in die composer.json ans Ende gesetzt - noch vor der letzten abschliessenden Klammer.

HTML-Code:

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

Dann den Manager nochmals aufgerufen - dann die install Seite - Der Fehler ist nach wie vor da.
Hab ich was falsch gemacht?
Liebe Grüße
Daniela
14.01.2019, 16:12
3dr

Ich musste auch den Cache im Manager löschen und dort alle Pakete aktualisieren.
14.01.2019, 16:13
xchs

Zitat:

Zitat von iuna123

Dann den Manager nochmals aufgerufen

Im Contao Manager hast Du aber schon auch eine vollständige Paketaktualisierung gemacht oder?
14.01.2019, 16:22
iuna123

Zitat:

Zitat von xchs

Im Contao Manager hast Du aber schon auch eine vollständige Paketaktualisierung gemacht oder?

Tataaaaaaa!
Nein hatte ich nicht und siehe da - jetzt hat es geklappt!

Danke vielmals! :)

Alle Zeitangaben in WEZ +1. Es ist jetzt 00:16 Uhr.