Off Canvas Warenkorb und Accountbereich funktionieren nach Update nicht

Hallo zusammen, 

wir haben ein Update von 5.1.3 auf 5.4.5 gefahren. Dass es besonders nach 5.2.0 und auch bei 5.3.0 noch Änderungen gab und dieser Sprung ein recht großer ist, ist uns bewusst. 

 

Wir haben in einer Staging Umgebung keine Fehler festellen können, bei Inbetriebnahme in die Liveumgebung haben wir aber einige Probleme: 

 

  • Der Off Canvas Warenkorb lädt sich tot

  • Man kann sich zwar anmelden, doch nach der Anmeldung erscheint folgender Fehler, mit dem wir leider nicht viel anfangen können. 

    ps! Ein Fehler ist aufgetreten!
    Die nachfolgenden Hinweise sollten Ihnen weiterhelfen.

    An exception occurred while executing ‚SELECT t0.customernumber AS customernumber_1, t0.id AS id_2, t0.paymentID AS paymentID_3, t0.customergroup AS customergroup_4, t0.subshopID AS subshopID_5, t0.pricegroupID AS pricegroupID_6, t0.encoder AS encoder_7, t0.password AS password_8, t0.active AS active_9, t0.email AS email_10, t0.firstlogin AS firstlogin_11, t0.lastlogin AS lastlogin_12, t0.accountmode AS accountmode_13, t0.confirmationkey AS confirmationkey_14, t0.sessionID AS sessionID_15, t0.newsletter AS newsletter_16, t0.validation AS validation_17, t0.affiliate AS affiliate_18, t0.paymentpreset AS paymentpreset_19, t0.language AS language_20, t0.referer AS referer_21, t0.internalcomment AS internalcomment_22, t0.failedlogins AS failedlogins_23, t0.lockedUntil AS lockedUntil_24, t0.salutation AS salutation_25, t0.title AS title_26, t0.firstname AS firstname_27, t0.lastname AS lastname_28, t0.birthday AS birthday_29, t0.doubleOptinRegister AS doubleOptinRegister_30, t0.doubleOptinEmailSentDate AS doubleOptinEmailSentDate_31, t0.doubleOptinConfirmDate AS doubleOptinConfirmDate_32, t33.id AS id_34, t33.userID AS userID_35, t33.countryID AS countryID_36, t33.stateID AS stateID_37, t33.company AS company_38, t33.department AS department_39, t33.salutation AS salutation_40, t33.title AS title_41, t33.firstname AS firstname_42, t33.lastname AS lastname_43, t33.street AS street_44, t33.zipcode AS zipcode_45, t33.city AS city_46, t33.phone AS phone_47, t33.ustid AS ustid_48, t33.additional_address_line1 AS additional_address_line1_49, t33.additional_address_line2 AS additional_address_line2_50, t33.userID AS userID_51, t52.title AS title_53, t52.stateID AS stateID_54, t52.additional_address_line1 AS additional_address_line1_55, t52.additional_address_line2 AS additional_address_line2_56, t52.id AS id_57, t52.userID AS userID_58, t52.company AS company_59, t52.department AS department_60, t52.salutation AS salutation_61, t52.firstname AS firstname_62, t52.lastname AS lastname_63, t52.street AS street_64, t52.zipcode AS zipcode_65, t52.city AS city_66, t52.countryID AS countryID_67, t52.userID AS userID_68, t0.customergroup AS customergroup_69, t0.subshopID AS subshopID_70, t71.id AS id_72, t71.userID AS userID_73, t71.userID AS userID_74, t0.pricegroupID AS pricegroupID_75, t0.default_billing_address_id AS default_billing_address_id_76, t0.default_shipping_address_id AS default_shipping_address_id_77, t0.language AS language_78 FROM s_user t0 LEFT JOIN s_user_billingaddress t33 ON t33.userID = t0.id LEFT JOIN s_user_shippingaddress t52 ON t52.userID = t0.id LEFT JOIN s_user_attributes t71 ON t71.userID = t0.id WHERE t0.id = ?‘ with params [„11“]: SQLSTATE[42S22]: Column not found: 1054 Unknown column ‚t0.doubleOptinRegister‘ in ‚field list‘ in vendor/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php on line 131

    Stack trace:
    #0 vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(855): Doctrine\DBAL\DBALException::driverExceptionDuringQuery(Object(Doctrine\DBAL\Driver\PDOMySql\Driver), Object(PDOException), ‚SELECT t0.custo…‘, Array)
    #1 engine/Library/Doctrine/ORM/Persisters/Entity/BasicEntityPersister.php(742): Doctrine\DBAL\Connection->executeQuery(‚SELECT t0.custo…‘, Array, Array)
    #2 engine/Library/Doctrine/ORM/Persisters/Entity/BasicEntityPersister.php(760): Doctrine\ORM\Persisters\Entity\BasicEntityPersister->load(Array, NULL)
    #3 vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php(462): Doctrine\ORM\Persisters\Entity\BasicEntityPersister->loadById(Array)
    #4 engine/Shopware/Core/sAdmin.php(3821): Doctrine\ORM\EntityManager->find(‚Shopware\Models…‘, ‚11‘)
    #5 engine/Shopware/Core/sAdmin.php(1472): sAdmin->getUserBillingData(‚11‘, Array)
    #6 engine/Shopware/Controllers/Frontend/Account.php(63): sAdmin->sGetUserData()
    #7 engine/Library/Enlight/Controller/Action.php(184): Shopware_Controllers_Frontend_Account->preDispatch()
    #8 engine/Library/Enlight/Controller/Dispatcher/Default.php(549): Enlight_Controller_Action->dispatch(‚indexAction‘)
    #9 engine/Library/Enlight/Controller/Front.php(222): Enlight_Controller_Dispatcher_Default->dispatch(Object(Enlight_Controller_Request_RequestHttp), Object(Enlight_Controller_Response_ResponseHttp))
    #10 engine/Shopware/Kernel.php(215): Enlight_Controller_Front->dispatch()
    #11 vendor/symfony/http-kernel/HttpCache/HttpCache.php(486): Shopware\Kernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
    #12 engine/Shopware/Components/HttpCache/AppCache.php(268): Symfony\Component\HttpKernel\HttpCache\HttpCache->forward(Object(Symfony\Component\HttpFoundation\Request), true, NULL)
    #13 vendor/symfony/http-kernel/HttpCache/HttpCache.php(443): Shopware\Components\HttpCache\AppCache->forward(Object(Symfony\Component\HttpFoundation\Request), true)
    #14 vendor/symfony/http-kernel/HttpCache/HttpCache.php(339): Symfony\Component\HttpKernel\HttpCache\HttpCache->fetch(Object(Symfony\Component\HttpFoundation\Request), true)
    #15 engine/Shopware/Components/HttpCache/AppCache.php(189): Symfony\Component\HttpKernel\HttpCache\HttpCache->lookup(Object(Symfony\Component\HttpFoundation\Request), true)
    #16 vendor/symfony/http-kernel/HttpCache/HttpCache.php(205): Shopware\Components\HttpCache\AppCache->lookup(Object(Symfony\Component\HttpFoundation\Request), true)
    #17 engine/Shopware/Components/HttpCache/AppCache.php(116): Symfony\Component\HttpKernel\HttpCache\HttpCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
    #18 shopware.php(122): Shopware\Components\HttpCache\AppCache->handle(Object(Symfony\Component\HttpFoundation\Request))
    #19 {main}

 

Über Hilfe wäre ich sehr dankbar. Versandarten habe ich alle einmal deaktiviert, alle externen Plugins sind ebenfalls deaktiviert. 

Hallo zusammen, wir haben es selbst gefixed mit ein bisschen Übertragungsarbeit aus anderen, älteren Forenbeiträgen. Im Endeffekt waren die 3 Spalten 

  • doubleOptinRegister
  • doubleOptinEmailSentDate
  • doubleOptinConfirmDate

nicht in der tabelle s_user angelegt. Durch das Einfügen per SQL Befehl dieser 3 Spalten funktioniert der Shop einwandfrei. 

 

Kann damit als gelöst betrachtet werden. 

1 „Gefällt mir“

Vielen herzlichen Dank für die Lösung dieses Problems. Ich habe tagelang keine Lösung gefunden und der einzige Strohhalm war Ihr Beitrag. Dank diesem funktioniert nun wieder alles. :slight_smile:

LG Mercator

Hallo,

das deutet ja auf ein unvollständiges Update hin. Da ist ja irgendwas schief gelaufen. Da sollte man genau prüfen, ob alle anderen Änderungen und Anpassungen sauber durchgelaufen sind. Wenn sich herausstellt, dass wirklich nur die Änderung fehlt, dann müssen die Felder so angelegt werden, wie es vorgesehen ist.

Die Mirgation steht ja hier shopware/1225-add-double-opt-in-register.php at aac0e5c964ac58b33cb95a6583285df2042d2ade · shopware/shopware · GitHub

Da hängen also weitere Änderungen dran, wie Einstellungen in den Grundeinstellungen, E-Mail-Vorlagen usw.

Da sollte man also sehr vorsichtig sein und genau prüfen, was da passiert ist und was genau fehlt. Sonst wird es zukünftig mit hoher Wahrscheinlichkeit weitere Probleme und Fehler geben, wenn die Umgebung keinen korrekten/sauberen Versionsstand hat

VG
Sebastian

@SebastianKlöpper schrieb:

Hallo,

das deutet ja auf ein unvollständiges Update hin. Da ist ja irgendwas schief gelaufen. Da sollte man genau prüfen, ob alle anderen Änderungen und Anpassungen sauber durchgelaufen sind. […]

Wie kann denn eigentlich so etwas passieren!? Entweder läuft ein Update durch oder es hängt sich auf. Aber so halb halb finde ich - gelinde gesagt - schon eine starkes Stück! Woher soll man danach bitte wissen, ob alles ok ist!?!?! Shopware sollte so eine Art ein LOG File oder ähnliches ausgeben, in dem der Update Fortschritt protokoliert wurde und man klar sieht, das alle Dateien korrekt oder eben nicht korrekt übertragen wurden.

Wird ja protokolliert. Steht in der Datenbank! (Alle Datenbank-Anpassungen werden hier gelistet https://community.shopware.com/Shopware-Updates-Debuggen-von-Fehlern-und-FAQ_detail_1378.html)

Häufigstes Problem ist bisher, dass die Version zurückgesetzt oder ein Backup eingespielt wird. Das dann aber über eine vorhandene Instanz, ohne diese vorher zu säubern. (Gibt es etliche Fälle hier im Forum. Das können wir Software-seitig dann gar nicht ändern oder abfangen)

Mir ist bisher noch kein Fall bekannt, wo das Update sauber durchläuft und dann was fehlt. Bisher waren immer andere Pobleme ausschlaggebend :frowning:

Aha, in der Datenbank! Könnte man das nicht auch evtl. noch am Ende des Updateprozesses ausgeben!?

Und klar, wenn einer seinen Server nicht ausmistet und dann alles einfach drüber semmelt, selber schuld, klar.

Ich geh mittlerweile immer nach drücken des Updateknopfs in Deckung! Wer weiß was mich Sekunden später dort erwartet! Wink

Also die Fehlermeldung bekommst du sogar direkt im Updateprozess angezeigt, auch welcher Prozess mit welchem Schritt (Nummer) fehlgeschlagen ist. In die Datenbank kann man zusätzlich schauen bzw. ist das für die Spurensuche und Korrektur dann wichtig in die Datenbank zu schauen.

Daher kann ich nur empfehlen, da bei sowas im Detail draufzuschauen. Denn ist ein Problem einmal drin, dann kann sich das gut durch alle weiteren Updates durchziehen bzw. immer weitere Probleme verursachen. Shopware muss sich ja auf bestimmte Dinge verlassen bzw. verlassen können. Manchmal treten die Probleme dann erst Monate oder Jahre später auf und das ist ja dann erst recht total ärgerlich :wink:

Danke für die Infos. Da hab ich wohl noch nie so richtig hingeschaut. Klar, bin ja auch immer in Deckung unterm Tisch! Aber ich glaube, ich weiß was Du meinst…

Wenn ich z.B. für Joomla oder Wordpress so etwas mache, weiß ich einfach, das es funzt, zumindest so wie ich das immer mache. Und wenn nicht habe ich dann noch mein Backup Tool, was alles wieder fixen kann. Solche Tools stehen mir halt bei Showpare nicht zur Verfügung, leider. Deshalb spiele ich z.B. meine Shopware DB Dumps nur via Heidi SQL ein. Da sehe ich dann genau, wenn was schief gegangen ist.

Und ja, Du hast recht, solche Probleme können sich erst nach Monaten oder auch Jahren zeigen. Genau das ist nämlich auch immer meine größte Sorge beim Update einspielen, zumindest bei Shopware. Aber vielleicht ist es ja möglich, so eine Art Script zu entwickeln, welches sämtliche Files auf dem Server auf deren Existenz prüft!?