…sowas sollte nicht sein. 
Hi Sonic,
stimmt - checken wir
Danke für die Info
Sebastian
Hi,
das haben wir extra gemacht um mehr RC Tester zu bekommen 
Nein war ein Bug. Geht jetzt wieder.
Viele Grüße,
Marcel
2 „Gefällt mir“
Die Changelog sieht gut aus. Ich teste gerade.
@derkosta super.
Wenn euch was auffält gerne einfach über https://issues.shopware.com/ ein Ticket anlegen.
VG
Marcel
Schön dass das Artikelspeichern endlich schnell geht 
Schön dass das Artikelspeichern endlich schnell geht
Finde ich auch cool, war ja auch direktes Feedback aus dem Forum, da ist das letzte Zeit ja wieder ein paar Mal aufgeschlagen - da haben wir das Ticket nochmal ausgegraben :)
Testet ihr das eigentlich in einem laufenden Shop? Ist das nicht gefährlich?
Liebe Grüße
Kerstin
Testet ihr das eigentlich in einem laufenden Shop? Ist das nicht gefährlich?
Liebe Grüße
Kerstin
Testen würde ich niemals in produktiven Shop, aber fast jeder hat oder sollte ein Testsystem haben, schon zu Testen für die Update der Plugins und zum nachträglichen Stylen des Shops, eine Kleinigkeit gibt es ja immer zu ändern.
Gruß Uwe
[@Daniel Nögel](http://forum.shopware.com/profile/4010/Daniel Nögel “Daniel Nögel”),
ich habe mir mal die UPGRADE.md übersetzen lassen und durchgelesen, aber mit einigen Sachen kann ich nichts anfangen:
- Fixed
ANDsearch logic for search terms which not exist in the s_articles table. - Added the possibility to configure the file and directory permissions for the
LocalCDN adapter. - change email validation to a simple regex:
/^.+\@\S+\.\S+$/. You can implement your own email validation by implementing theEmailValidatorInterface. - Added order and payment state constants in
\Shopware\Models\Order\Status
Es wäre von Vorteil das auch nicht Profis (Shopbetreiber) ohne Englischkenntnisse wissen was da gemeint ist, sonst weiß man ja nicht auf was man beim Test besonders achten sollte.
Gruß Uwe
Hallo,
die md richtet sich auch eher direkt an Entwickler und ist auf github daher auch nur auf Englisch.
In der allgemeinen Doku findest du alle Tickets auch auf Deutsch http://community.shopware.com/Downloads_cat_448.html#5.1.4RC1
Dort ist Sean und DE und auch das jeweilige Ticket verlinkt mit genaueren Details. Denke das sollte weiterhelfen
Sebastian
Tuts bei mir im Testshop nicht…
Error
Received the following error message:
Could not apply migration: SQLSTATE[42000]: Syntax error or access violation: 1061 Duplicate key name 'mapping_id'
Please try to fix this error and restart the update.
Response
{"valid":false,"errorMsg":"Could not apply migration: SQLSTATE[42000]: Syntax error or access violation: 1061 Duplicate key name 'mapping_id'"}
@sonic
Bei mir ist das Update sauber durchgelaufen.
da scheint es ja irgendwo einen doppelten Eintrag der “mapping_id” zu geben.
da gibt es eigentlich nur zwei Tabellen in der Datenbank, die die Spalte “mapping_id” haben, jedenfalls bei mir.
SQL-Befehl:
SELECT TABLE_NAME, COLUMN_NAME
FROM INFORMATION_SCHEMA.COLUMNS
WHERE column_name LIKE 'mapping_id'
Tabelle : s_article_img_mapping_rules und s_cms_static_groups
Da musst du mal schauen ob es da eine doppelte mapping_id gibt.
Gruß Uwe
2 „Gefällt mir“
Ich vermute, es kommt aus 633-add-index-for-image-mappings.php
addSql($sql);
}
}
Nur ist diese Tabelle in meinem Testshop leer!
[Edit]
Nach dem Löschen der 633-add-index-for-image-mappings.php ist das Update nun durchgelaufen.
Die Tabelle ist aber leer! Offensichtlich führt das Hinzufügen von einem index in eine leere Tabelle zu einen Fehler !?!
Hallo,
du kannst doch den SQL-Befehl mal manuell ausführen, mehr ist das ja nicht.
Einen Fehler kann ich hier nicht erkennen. Habe gerade mal 5.0.4 und 5.1.2 -> 5.1.4RC getestet.
Hattest du ggf. den Index schon selbst gesetzt?
Moritz
[@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski “Moritz Naczenski”) Das habe ich gleich noch nach dem Update direkt in der DB gemacht. “option_id” lief durch, aber “mapping_id” ging nicht, da der index schon gesetzt war. Ich selber hatte aber da wirklich garnichts vorher gemacht! Leider weiss ich nicht mehr, ob vorher 5.1.2 oder 5.1.3 der letzte Stand war, aber da ich in dem Testshop eher selten etwas mache, gehe ich von 5.1.2 aus. Es gibt auch keine Plugins etc. die schon vorher etwas gemacht haben könnten.
Was mir daran aufstösst: Vorher ausgeführte DB-Änderung werden - nehme ich mal an - nach einem Abbruch nicht mehr zurück gesetzt? Dann würde ich bei einem neuen Durchlauf ja u.U. schon früher auf einen solchen Fehler stossen, wenn bis zum Abbruch bereits vorher an anderer Stelle ein Index gesetzt wurde???
So - ich habe ja noch eine Kopie als “Test-Shop” von meinem zweiten Shop - der mit Kauffunktion. Der Stand: 5.1.2 -> Update auf 5.1.4-RC1
GLEICHER FEHLER!
Jetzt habe ich erstmal keine Lust mehr auf 5.1.4
“mapping_id” aus 633-add-index-for-image-mappings.php entfernt, /recovery/update manuell aufgerufen und das DB-Update läuft durch. Aber bei “/done” kommt nun das. Ich gehe dann mal ins Wochenende - so werde ich 5.1.4 jedenfalls nicht auf die “echten” Installationen los lassen. *Komisch* bisher damit noch nie Probleme gehabt. 
Fatal error: Uncaught Error: Call to a member function addElement() on null in /www/htdocs/######/other-domains/###########/themes/Frontend/QuickTest/Theme.php:32 Stack trace: #0 /www/htdocs/######/other-domains/###########/engine/Shopware/Components/Theme/Configurator.php(121): Shopware\Themes\QuickTest\Theme->createConfig(Object(Shopware\Components\Form\Container\TabContainer)) #1 /www/htdocs/######/other-domains/###########/engine/Shopware/Components/Theme/Installer.php(156): Shopware\Components\Theme\Configurator->synchronize(Object(Shopware\Themes\QuickTest\Theme)) #2 /www/htdocs/######/other-domains/###########/engine/Shopware/Components/Theme/Installer.php(117): Shopware\Components\Theme\Installer->synchronizeThemes() #3 /www/htdocs/######/other-domains/###########/recovery/update/src/app.php(165): Shopware\Components\Theme\Installer->synchronize() #4 [internal function]: {closure}() #5 /www/htdocs/######/other-domains/###########/recovery/common/vendor/slim/slim/Slim/Route.php(462): c in /www/htdocs/######/other-domains/###########/themes/Frontend/QuickTest/Theme.php on line 32
Hallo,
man müsste jetzt wissen wie der Stand der Datenbank vorher war. Die Migrations werden ja alle in der s_schema_version festgehalten. Der Index ist komplett neu, den gab es vor 5.1.4 noch nicht. Daher sollte es hier auch keine Probleme geben.
Du kannst mir gerne mal die Datenbank vor dem Update schicken, dann schau ich da mal rein. Die aktuelle hat ja keinen Stand mehr, den man auf irgendeine Art und Weise zur Fehleranalyse nehmen könnte.
Moritz
Beide Testshops basieren auf 4.3.x und wurden durch-upgedatet. Der zweite „heute“ ist ein Clone vom echten und wurde als Kopie vor dem Update von 4.3.6 auf 5.0.0 erstellt. Beim „ersten“ von gestern weiss ich jetzt nicht mehr, ob es eine echte Installation war, oder auch in Clone ist. Der von „heute“ hatte vorher Stand 5.1.2 via Backend-Updates.
Clone: DB-Backup vom „echten“ via HeidiSQl und Einspielen via HeidiSQL in eine leere Datenbank. Eigentlich sollte hierbei doch kein index von alleine erstellt worden sein.
Jetzt kann ich erst mal gucken, wie ich den Error weg bekomme und aus den Wartungsmodus raus komme. 