shop plötzlich zerschossen

Am Shop wurde nichts geändert und auch auf dem server sollten keine Probleme gewesen sein.

Die Einkaufswelten wurden plötzlich zerstört angezeigt, danach war der Shop überhaupt nicht erreichbar;

Die Einkaufswelten lassen sich nicht neu erstellen und auch nicht abspeichern, die Änderungen gehen verloren

[07-Nov-2018 18:32:04 Europe/Berlin] PHP Fatal error: Uncaught Error: Call to a member function renderEsiTag() on null in /home/amafinod/public_html/var/cache/production_201807181357/templates/frontend_Meintheme_de_DE_1_secure/6b/ff/5c/6bff5cd765173b7399a0e0675f22e8eb07295bb4.snippet.index.tpl.php:814
Stack trace:
#0 /home/amafinod/public_html/var/cache/production_201807181357/templates/frontend_Meintheme_de_DE_1_secure/6b/ff/5c/6bff5cd765173b7399a0e0675f22e8eb07295bb4.snippet.index.tpl.php(288): content_5be31435559c07_28030274(Object(Enlight_Template_Default))
#1 /home/amafinod/public_html/engine/Library/Smarty/sysplugins/smarty_internal_templatebase.php(180): content_5be31435c670e4_46433262(Object(Enlight_Template_Default))
#2 /home/amafinod/public_html/engine/Library/Enlight/View/Default.php(300): Smarty_Internal_TemplateBase->fetch()
#3 /home/amafinod/public_html/engine/Library/Enlight/Controller/Plugins/ViewRenderer/Bootstrap.php(216): Enlight_View_Default->render(Object(Enlight_Template_Default))
#4 /home/amafinod/public_html/engine/Library/Enlight/Control in /home/amafinod/public_html/var/cache/production_201807181357/templates/frontend_Meintheme_de_DE_1_secure/6b/ff/5c/6bff5cd765173b7399a0e0675f22e8eb07295bb4.snippet.index.tpl.php on line 814

 

theme kompilieren ist auch nicht möglich

Es ist ein Fehler aufgetreten

Während der Bearbeitung von Shop "Amafino" ist ein Fehler aufgetreten: variable @btn-font-size is undefined in file /home/amafinod/public_html/themes/Frontend/Responsive/frontend/_public/src/less/_components/buttons.less in buttons.less on line 25, column 14 23| .border-radius(3px); 24| .appearance(); 25| .unitize(@btn-font-size, 16, font-size); 26| .linear-gradient(@btn-default-top-bg, @btn-default-bottom-bg); 27| -webkit-font-smoothing: inherit; 28| display: inline-block;

Jemand ne Idee bevor ich datensicherung aufsetze

Spontane Selbstzerstörung klingt eher komisch.

Irgendein Prozess muss ja gelaufen sein. Vielleicht PHP-Version gewechselt? Cronjobs (bspw. Cache leeren) gelaufen? 

Du kannst ja auch mal schauen, ob die btn-font-size in der Theme-Konfiguration hinterlegt ist.

Die Meldung oben (mit ESI) kommt nur aus dem Frontend, nicht aus dem Backend.

Den “@btn-font-size is undefined” hatten wir heute schon mehrfach im Forum. Bei den Betroffenen gab es ein Update von PHP 7 seitens des Hosters (genauere Infos zur Version blieben die Betroffenen ja schuldig). Zurück zu PHP 5.6 hat den Fehler bei den angeblich abgestellt.

https://forum.shopware.com/search?Search=+%40btn-font-size&sLanguage=1

1 „Gefällt mir“

Mich wundert allerdings, was das mit der PHP-Version zu tun hat. Weil es ja auch zahlreiche Shops gibt die PHP7.0/7.1 und 7.2 einsetzen.

Gerne mal etwas mehr Informationen liefern!

PHP-Änderungen gab es hier angeblich leider nicht, ich kann zumindest im cpanel nichts erkennen, aber ich hake da nochmal nach.

shop 5.4.6

PHP 7.0

Dieses Problem hatten wir heute ebenfalls.
Shopversion 5.5.3
PHP Version 7.0

Ein Switch zu PHP 5.6 hat erstmal abhilfe geschaffen.
Ich mach mal ein Ticket bei unserem Provider um nachzufragen was heute in der Nacht genau geschehen ist.

Nur zur Info aus Gegentest: SW 5.5.3 Testshop PHP in FastCGI : 7.0.30 , 7.1.19 & 7.2.7 durchgelaufen.

PHP 7.0.XX => XX = ?? Das wäre ja relevant!

[@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski “Moritz Naczenski”)‍ siehe auch:
https://forum.shopware.com/discussion/57270/online-shop-ueber-nacht-selbst-zerstoert-theme-manager-defekt
 

Die Einkaufswelten im Frontend waren komplett weg, im Backend waren diese zwar sichtbar aber konnten nicht bearbeitet werden.
Weiter waren sämtliche Bestellungen nicht mehr sichtbar.

Erster Verdacht war ein Problem mit der DB (zu dem Zeitpunkt war uns der 503 Fehler noch nicht bekannt.
Also kurzerhand ein Fullbackup gemacht.
Restore der DB von Gestern und vorgestern - ohne Erfolg
Restore der Files von Gestern und vorgestern - ebenfalls ohne Erfolg

Nach dem ich durch Google auf oben genannten Post gestossen bin, habe ich den Wechsel auf PHP 5.6 gemacht und mein manuelles Full-Backup von heute wiederhergestellt und siehe da es funktioniert alles wieder einwandfrei.

1 „Gefällt mir“

@fm1985 schrieb:

[@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski „Moritz Naczenski“)‍ siehe auch:
https://forum.shopware.com/discussion/57270/online-shop-ueber-nacht-selbst-zerstoert-theme-manager-defekt
 

Die Einkaufswelten im Frontend waren komplett weg, im Backend waren diese zwar sichtbar aber konnten nicht bearbeitet werden.
Weiter waren sämtliche Bestellungen nicht mehr sichtbar.

genauso bei uns auch.

mit php5.6 kann ich jetzt auch die EKWs wieder speichern. Feierabend - keine Lust mehr.

 

Nach meinen diversen Problemen, die ich hier geschildert habe https://forum.shopware.com/discussion/57294/update-von-5-5-1-auf-5-5-3-bricht-bei-datenbank-ab

Habe ich auch mal nach der php-Version geschaut.

Ich hatte tatsächlich dem Testshop noch php 5.6.38 und SW 5.5.1. Nach mehrmaligem Updateabbruch zu V 5.5.3 habe ich jetzt auf php 7.0.32 umgestellt und das update lief problemlos durch.

Problem: Das Backend war danach weiß.

Wieder zurück auf 5.6.38 gestellt, Backend wieder da.

Dann habe ich die drei möglichen 7er Versionen nacheinander getestet. BE wieder weiß. Jetzt wieder 5.6.38 = BE wieder da

 

Mein Liveshop läuft allerdings schon länger unter 7.0.32 ohne Probleme bisher. Seit einigen Tagen zwar immer mal etwas sehr langsam im BE aber immer noch erreichbar.

Mal alle Plugins ausgemacht?

Klingt ja schon ziemlich skurril.

Seid ihr denn alle beim gleichen Hoster?

@Moritz Naczenski schrieb:

Mal alle Plugins ausgemacht?

Klingt ja schon ziemlich skurril.

Seid ihr denn alle beim gleichen Hoster?

Ich habe es gerade bei 5 verschiedenen Shops bei 3 Webhoster getestet.
Bei 2 von 3 Webhostern besteht das Problem.
Beide haben Cloud Linux und cPanel im Einsatz.
Der dritte wo alles noch funktioniert hat CentOS mit PLESK im Einsatz

Ein Shop ist ein reiner Testshop und ist eine Nakte SW 5.4.6 Installation nur mit den Demo Daten befüllt.
Auch hier war das Problem vorhanden.

Ich warte noch auf Antwort vom Webhoster, sobald ich diese habe kann ich hoffentlich auch etwas mehr Details posten.

Wir nutzen php 7.1 und plesk… keine Probleme. Das unterstützt die cPanel Theorie 

marc

Es gab einen Bug beim php 7.0 update. Der Bug soll nun behoben sein.

Leider komme ich nicht mehr ins backend. Auch cache und cookies löschen nutzt nichts, ebenso das Einspielen einer Datensicherung nicht :

Ups! Ein Fehler ist aufgetreten!

Die nachfolgenden Hinweise sollten Ihnen weiterhelfen.

Unauthorized in engine/Shopware/Controllers/Backend/Index.php on line 223
Stack trace:

#0 engine/Library/Enlight/Controller/Action.php(193): Shopware_Controllers_Backend_Index->loadAction()
#1 engine/Library/Enlight/Controller/Dispatcher/Default.php(549): Enlight_Controller_Action->dispatch('loadAction')
#2 engine/Library/Enlight/Controller/Front.php(222): Enlight_Controller_Dispatcher_Default->dispatch(Object(Enlight_Controller_Request_RequestHttp), Object(Enlight_Controller_Response_ResponseHttp))
#3 engine/Shopware/Kernel.php(215): Enlight_Controller_Front->dispatch()
#4 vendor/symfony/http-kernel/HttpCache/HttpCache.php(486): Shopware\Kernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#5 engine/Shopware/Components/HttpCache/AppCache.php(268): Symfony\Component\HttpKernel\HttpCache\HttpCache->forward(Object(Symfony\Component\HttpFoundation\Request), true, NULL)
#6 vendor/symfony/http-kernel/HttpCache/HttpCache.php(253): Shopware\Components\HttpCache\AppCache->forward(Object(Symfony\Component\HttpFoundation\Request), true)
#7 engine/Shopware/Components/HttpCache/AppCache.php(105): Symfony\Component\HttpKernel\HttpCache\HttpCache->pass(Object(Symfony\Component\HttpFoundation\Request), true)
#8 shopware.php(122): Shopware\Components\HttpCache\AppCache->handle(Object(Symfony\Component\HttpFoundation\Request))
#9 {main}

Das:

bringt leider auch nichts.

Jetzt bin ich wieder ratlos und warte auf Ideen.

Am besten ich setze den Shop neu auf…

Bin bei Aixpro, da wird Plesk 17.8.11 verwendet. Ich würde da eine Anfrage stellen, wenn ich das Problem irgendwie lokalisieren könnte.

Ich habe in einem Paket 3 Installationen und versuche die Unterschiede mal zusammenzufassen:

  1. Installation
    Live-Shop 5.5.1 schon lange auf 7.0.23
    komplett SSL
    ein paar Plugins
    ist erreichbar,
    Lizenzmanager 1.4.2 aktualisiert 19.10.18

  2. Installation
    kleiner Shop 5.5.2, noch bestückt,
    wenige Plugins
    von der Startseite wird auf den Liveshop umleitet.
    kein SSL
    bis gestern php 5.6.38, seit gestern 7.0.32 - läuft
    Lizenzmanager 1.3.0 neu installiert 7.11.18

  3. Installation
    Eine abgespeckte Version von dem kleinen Shop als Testshop ohne Bilder mit nur einer Hand voll Artikel.
    kein SSL
    Plugins:
    Lizenzmanager 1.3.0
    Googleservices 3.0.0 (s.u.)

Probleme hier:
bis gestern sw 5.5.2, php 5.6.38 - Update auf 5.5.3 immer wieder bei der Datenbankmigration abgebrochen
Umstellung auf php 7.0.32: Update lief durch, BE weiß
zurück auf 5.6.38: BE wieder erreichbar

 

Was bei allen Installationen auffällig ist:
Die Softwareaktualisierung verlangt ein update beim Lizenzmanager, das im Pluginmanager nicht angezeigt wird.
Eine Neuinstallation des Lizenzmanagers ändert nichts daran. Insbesondere bei den Shops mit Version 1.3.0 wird immer 1.3.0 installiert und nicht
1.4.2. Wobei bei 1.4.2 auch eine aktualisierung verlang wird. Soweit ich gelesen habe, braucht man den Lizenzmanager nicht mehr unbedingt, er stört aber auch nicht. Dürfte auch kein Update verhindern.

Im Liveshop habe ich zusätzlich seit einiger Zeit Fehlermeldungen durch swaggoogle, die scheinbar beim Aufruf bestimmter Artikel ausgelöst wird. Die Änderung der config.php wie im Forum beschrieben, hat nichts gebracht. Bei den inaktiven Shops lässt sich das nicht prüfen.

Das ist alles, was ich an möglichen Zusammenhängen beisteuern kann. Ob es welche gibt, kann ich nicht beurteilen.

Mir ist völlig schleierhaft, wieso 3 Installationen im gleichen Paket so unterschiedlich laufen/reagieren.

Ein Update im Liveshop werde ich im Moment auf jeden Fall nicht machen.

@SB schrieb:

@kanuma - welcher hoster ?

Aixpro 

Hier die Antwort von unserem Webhoster Novatrend:

Wir verwenden Cloudlinux mit HardendedPHP welches täglich die Software aktualisiert. Letzte Nacht wurde PHP auf die Version 7.0.32 aktualisiert und folgende Pakete wurden installiert:

alt-php70-7.0.32-1.el7.x86_64
alt-php70-bcmath-7.0.32-1.el7.x86_64
alt-php70-cli-7.0.32-1.el7.x86_64
alt-php70-common-7.0.32-1.el7.x86_64
alt-php70-dba-7.0.32-1.el7.x86_64
alt-php70-devel-7.0.32-1.el7.x86_64
alt-php70-enchant-7.0.32-1.el7.x86_64
alt-php70-firebird-7.0.32-1.el7.x86_64
alt-php70-gd-7.0.32-1.el7.x86_64
alt-php70-imap-7.0.32-1.el7.x86_64
alt-php70-intl-7.0.32-1.el7.x86_64
alt-php70-ldap-7.0.32-1.el7.x86_64
alt-php70-mbstring-7.0.32-1.el7.x86_64
alt-php70-mcrypt-7.0.32-1.el7.x86_64
alt-php70-mysqlnd-7.0.32-1.el7.x86_64
alt-php70-odbc-7.0.32-1.el7.x86_64
alt-php70-opcache-7.0.32-1.el7.x86_64
alt-php70-pdo-7.0.32-1.el7.x86_64
alt-php70-pgsql-7.0.32-1.el7.x86_64
alt-php70-process-7.0.32-1.el7.x86_64
alt-php70-pspell-7.0.32-1.el7.x86_64
alt-php70-snmp-7.0.32-1.el7.x86_64
alt-php70-soap-7.0.32-1.el7.x86_64
alt-php70-tidy-7.0.32-1.el7.x86_64
alt-php70-xml-7.0.32-1.el7.x86_64
alt-php70-xmlrpc-7.0.32-1.el7.x86_64