kullikulli MitgliedKommentare: 1478 Danke erhalten: 184 Mitglied seit: August 2013 bearbeitet 7. November

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

1 Antwort

  • Moritz NaczenskiMoritz Naczenski AdministratorKommentare: 6045 Danke erhalten: 1781 bearbeitet 9. November Mitglied seit: September 2013

    Nunja, der Kunde ist natürlich bei soetwas der Leidtragende - aber in diesem Fall geht das auch kaum anders. Was hat Shopware hier konkret für euch alles ausprobiert:

    - Mehrere betroffene Shops gedebuggt
    - Lokale Installation mit identischer PHP-Version getestet
    - Installation mit identischer PHP-Version bei anderem Hoster getestet
    - Informationen zur "kaputten" PHP-Version gesammelt und hier veröffentlicht
    - Es haben sich 3 Mitarbeiter an diesem Thread rege beteiligt (@Shyim@AndreHerking‍ und ich)

    Was hat der Hoster bisher getan? Soweit ich sehe, nur beim Hersteller seiner eingesetzten Software nachgefragt. Ihr könnt mir gerne nochmal eine Testinstallation schicken, mit der ich machen kann, was ich will. Dann schaue ich mir das auch nochmal auf einem solchen Server an. Live-Debugging an irgendwelchen Shops macht da aber keinen Sinn.

    Zitieren
    Akzeptierte Antwort
  • Akzeptierte Antwort
«1

Antworten

  • Moritz NaczenskiMoritz Naczenski AdministratorKommentare: 6045 Danke erhalten: 1781 Mitglied seit: September 2013

    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.

  • sonicsonic MitgliedKommentare: 1871 Danke erhalten: 511 bearbeitet 7. November Mitglied seit: Januar 2014

    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=+@btn-font-size&sLanguage=1

    Danke von 1Moritz Naczenski
  • Moritz NaczenskiMoritz Naczenski AdministratorKommentare: 6045 Danke erhalten: 1781 Mitglied seit: September 2013

    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!

  • kullikulli MitgliedKommentare: 1478 Danke erhalten: 184 Mitglied seit: August 2013

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

  • kullikulli MitgliedKommentare: 1478 Danke erhalten: 184 Mitglied seit: August 2013

    shop 5.4.6

    PHP 7.0

  • fm1985fm1985 MitgliedKommentare: 9 Danke erhalten: 3 Mitglied seit: Januar 2017

    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.

  • sonicsonic MitgliedKommentare: 1871 Danke erhalten: 511 Mitglied seit: Januar 2014

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

  • sonicsonic MitgliedKommentare: 1871 Danke erhalten: 511 Mitglied seit: Januar 2014

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

  • fm1985fm1985 MitgliedKommentare: 9 Danke erhalten: 3 Mitglied seit: Januar 2017

    @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.

    Danke von 1kulli
  • kullikulli MitgliedKommentare: 1478 Danke erhalten: 184 Mitglied seit: August 2013

    @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.

  • kullikulli MitgliedKommentare: 1478 Danke erhalten: 184 Mitglied seit: August 2013

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

     

  • ToricToric MitgliedKommentare: 865 Danke erhalten: 35 bearbeitet 7. November Mitglied seit: Oktober 2015

    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.

  • Moritz NaczenskiMoritz Naczenski AdministratorKommentare: 6045 Danke erhalten: 1781 Mitglied seit: September 2013

    Mal alle Plugins ausgemacht?

    Klingt ja schon ziemlich skurril.

    Seid ihr denn alle beim gleichen Hoster?

  • fm1985fm1985 MitgliedKommentare: 9 Danke erhalten: 3 Mitglied seit: Januar 2017

    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.

  • kanumakanuma MitgliedKommentare: 206 Danke erhalten: 47 Mitglied seit: Mai 2014

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

    marc

  • SBSB MitgliedKommentare: 175 Danke erhalten: 50 Mitglied seit: April 2015

    @kanuma - welcher hoster ?

  • kullikulli MitgliedKommentare: 1478 Danke erhalten: 184 bearbeitet 8. November Mitglied seit: August 2013

    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 :

    <h2><span class="frontend_error_exception">Ups! Ein Fehler ist aufgetreten!</span></h2>
    <p>
    <span class="frontend_error_exception">Die nachfolgenden Hinweise sollten Ihnen weiterhelfen.</span>
    </p>
    <h3>Unauthorized in engine/Shopware/Controllers/Backend/Index.php on line 223</h3>
    <h3>Stack trace:</h3>
    <div style="overflow:auto;">
    <pre>#0 engine/Library/Enlight/Controller/Action.php(193): Shopware_Controllers_Backend_Index-&gt;loadAction()
    #1 engine/Library/Enlight/Controller/Dispatcher/Default.php(549): Enlight_Controller_Action-&gt;dispatch(&#039;loadAction&#039;)
    #2 engine/Library/Enlight/Controller/Front.php(222): Enlight_Controller_Dispatcher_Default-&gt;dispatch(Object(Enlight_Controller_Request_RequestHttp), Object(Enlight_Controller_Response_ResponseHttp))
    #3 engine/Shopware/Kernel.php(215): Enlight_Controller_Front-&gt;dispatch()
    #4 vendor/symfony/http-kernel/HttpCache/HttpCache.php(486): Shopware\Kernel-&gt;handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
    #5 engine/Shopware/Components/HttpCache/AppCache.php(268): Symfony\Component\HttpKernel\HttpCache\HttpCache-&gt;forward(Object(Symfony\Component\HttpFoundation\Request), true, NULL)
    #6 vendor/symfony/http-kernel/HttpCache/HttpCache.php(253): Shopware\Components\HttpCache\AppCache-&gt;forward(Object(Symfony\Component\HttpFoundation\Request), true)
    #7 engine/Shopware/Components/HttpCache/AppCache.php(105): Symfony\Component\HttpKernel\HttpCache\HttpCache-&gt;pass(Object(Symfony\Component\HttpFoundation\Request), true)
    #8 shopware.php(122): Shopware\Components\HttpCache\AppCache-&gt;handle(Object(Symfony\Component\HttpFoundation\Request))
    #9 {main}</pre>
    </div>
    <div class="doublespace">&nbsp;</div>

    Das:

    https://community.shopware.com/_detail_1984.html?_ga=2.200274926.1796252612.1536475239-529901812.1536475239#Nicht_standardm.C3.A4.C3.9Fig_vorhandene_Plugins_deaktivieren

    bringt leider auch nichts.

    Jetzt bin ich wieder ratlos und warte auf Ideen.

    Am besten ich setze den Shop neu auf...

  • ToricToric MitgliedKommentare: 865 Danke erhalten: 35 bearbeitet 8. November Mitglied seit: Oktober 2015

    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.

  • kanumakanuma MitgliedKommentare: 206 Danke erhalten: 47 Mitglied seit: Mai 2014

    @kanuma - welcher hoster ?

    Aixpro 

  • fm1985fm1985 MitgliedKommentare: 9 Danke erhalten: 3 Mitglied seit: Januar 2017

    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

  • QwertyQwerty MitgliedKommentare: 14 Danke erhalten: 2 Mitglied seit: Januar 2016

    Hallo,

    auch wir wurden gestern in der Nacht böse überrascht von diesem Problem und haben alle Shopware-Shops aktuell auf PHP 5.6 umstellen müssen.

    Auf unserem Server sind die selben PHP Versionen (alt-php70-7.0.32-1) aktiv. Diese Version wurde jedoch bereits automatisiert am 30.10.2018 installiert und ist als kritisches Sicherheitsupdate vom PHP Hersteller gekennzeichnet.

    Es sieht alles danach aus, dass Shopware ein Problem mit dieser PHP Version hat. Dies ist aber die aktuelle PHP7 Version, welche direkt vom PHP Hersteller stammt.

    Was wir persönlich nicht verstehen ist, warum sich dieses Problem dann erst so erheblich zeitversetzt bemerkbar gemacht hat. Denn zwischen dem 30.10. und 7.11. liegen immerhin 8 Tage. Und in diesen 8 Tagen gab es keinerlei Veränderungen am Server.

    Was jedoch einen Tag vorher tagsüber installiert wurde, war entweder das Update auf  Version 5.5.3 bzw. der aktuellsten Version des Shopware Sicherheits-Plugin. Die üblichen Cronjob laufen immer in der Nacht ab und ab genau dann begannen diese Probleme.

  • fm1985fm1985 MitgliedKommentare: 9 Danke erhalten: 3 Mitglied seit: Januar 2017
     

    Was jedoch einen Tag vorher tagsüber installiert wurde, war entweder das Update auf  Version 5.5.3 bzw. der aktuellsten Version des Shopware Sicherheits-Plugin. Die üblichen Cronjob laufen immer in der Nacht ab und ab genau dann begannen diese Probleme.

    Ich hatte das Problem gleich bei mehreren Kunden. Und da waren bis gestern unterschiedliche Versionen im Einsatz.
    5.4.6 war die älteste Version und 5.5.3 die neuste.

  • kullikulli MitgliedKommentare: 1478 Danke erhalten: 184 Mitglied seit: August 2013

    Das Frontend habe ich mit einer aktuellen Datensicherung zum Laufen bekommen.

    Ins backend komme ich komischerweise immer noch nicht rein:

    The provided CSRF-Token is invalid. If you're sure that the request to path "/backend/Login/load/?f=m/Locale|v/Main|v/main/Form|store/Locale|c/Main&no-cache=1541694429" should be valid, the called controller action needs to be whitelisted using the CSRFWhitelistAware interface.
    
    Time: 	
    
    2018-11-08T17:27:12.441480+0100
    
    Channel: 	
    
    core
    
    request: 	
    
    {
        "uri": "/backend/Login/load/?f=m/Locale|v/Main|v/main/Form|store/Locale|c/Main&no-cache=1541694429",
        "method": "GET",
        "query": {
            "f": "m/Locale|v/Main|v/main/Form|store/Locale|c/Main",
            "no-cache": "1541694429",
            "module": "backend",
            "controller": "Login",
            "action": "load"
        },
        "post": []
    }
    
    shop: 	
    
    No shop data available
    
    session: 	
    
    No session data available
    
    CRITICAL
    Message: 	
    
    The provided CSRF-Token is invalid. If you're sure that the request to path "/backend/Login/load/?f=m/Locale|v/Main|v/main/Form|store/Locale|c/Main&no-cache=1541694429" should be valid, the called controller action needs to be whitelisted using the CSRFWhitelistAware interface.
    
    Time: 	
    
    2018-11-08T17:27:12.459490+0100
    
    Channel: 	
    
    core
    
    request: 	
    
    {
        "uri": "/backend/Login/load/?f=m/Locale|v/Main|v/main/Form|store/Locale|c/Main&no-cache=1541694429",
        "method": "GET",
        "query": {
            "f": "m/Locale|v/Main|v/main/Form|store/Locale|c/Main",
            "no-cache": "1541694429",
            "module": "backend",
            "controller": "Login",
            "action": "load"
        },
        "post": []
    }
    
    shop: 	
    
    No shop data available
    
    session: 	
    
    No session data available
    
    ERROR
    Message: 	
    
    Shopware\Components\CSRFTokenValidationException: The provided CSRF-Token is invalid. If you're sure that the request to path "/backend/Login/load/?f=m/Locale|v/Main|v/main/Form|store/Locale|c/Main&no-cache=1541694429" should be valid, the called controller action needs to be whitelisted using the CSRFWhitelistAware interface. in /home/amafinod/public_html/engine/Shopware/Components/CSRFTokenValidator.php:109
    Stack trace:
    #0 /home/amafinod/public_html/engine/Library/Enlight/Event/Handler/Default.php(91): Shopware\Components\CSRFTokenValidator->checkBackendTokenValidation(Object(Enlight_Controller_ActionEventArgs))
    #1 /home/amafinod/public_html/engine/Library/Enlight/Event/EventManager.php(220): Enlight_Event_Handler_Default->execute(Object(Enlight_Controller_ActionEventArgs))
    #2 /home/amafinod/public_html/engine/Library/Enlight/Controller/Action.php(176): Enlight_Event_EventManager->notify('Enlight_Control...', Object(Enlight_Controller_ActionEventArgs))
    #3 /home/amafinod/public_html/engine/Library/Enlight/Controller/Dispatcher/Default.php(549): Enlight_Controller_Action->dispatch('loadAction')
    #4 /home/amafinod/public_html/engine/Library/Enlight/Controller/Front.php(222): Enlight_Controller_Dispatcher_Default->dispatch(Object(Enlight_Controller_Request_RequestHttp), Object(Enlight_Controller_Response_ResponseHttp))
    #5 /home/amafinod/public_html/engine/Shopware/Kernel.php(215): Enlight_Controller_Front->dispatch()
    #6 /home/amafinod/public_html/vendor/symfony/http-kernel/HttpCache/HttpCache.php(486): Shopware\Kernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
    #7 /home/amafinod/public_html/engine/Shopware/Components/HttpCache/AppCache.php(268): Symfony\Component\HttpKernel\HttpCache\HttpCache->forward(Object(Symfony\Component\HttpFoundation\Request), true, NULL)
    #8 /home/amafinod/public_html/vendor/symfony/http-kernel/HttpCache/HttpCache.php(253): Shopware\Components\HttpCache\AppCache->forward(Object(Symfony\Component\HttpFoundation\Request), true)
    #9 /home/amafinod/public_html/engine/Shopware/Components/HttpCache/AppCache.php(105): Symfony\Component\HttpKernel\HttpCache\HttpCache->pass(Object(Symfony\Component\HttpFoundation\Request), true)
    #10 /home/amafinod/public_html/shopware.php(122): Shopware\Components\HttpCache\AppCache->handle(Object(Symfony\Component\HttpFoundation\Request))
    #11 {main}
    
    Time: 	
    
    2018-11-08T17:27:12.460435+0100
    
    Channel: 	
    
    core
    
    request: 	
    
    {
        "uri": "/backend/Login/load/?f=m/Locale|v/Main|v/main/Form|store/Locale|c/Main&no-cache=1541694429",
        "method": "GET",
        "query": {
            "f": "m/Locale|v/Main|v/main/Form|store/Locale|c/Main",
            "no-cache": "1541694429",
            "module": "backend",
            "controller": "Login",
            "action": "load"
        },
        "post": []
    }
    
    shop: 	
    
    No shop data available
    
    session: 	
    
    No session data available

     

    Die Fehlermeldung und der Ladebalken sind imm er noch gleich, cache und cookies sind gelöscht:

    image

  • AndreHerkingAndreHerking MitarbeiterKommentare: 419 Danke erhalten: 103 Mitglied seit: März 2016

    Mal einen anderen Browser probiert, bzw. den Inkognito Modus? Dies ist sehr häufig der Fall, wenn ein alter CSRF Session Cookie noch vorhanden ist. 

    LG Andre

  • kullikulli MitgliedKommentare: 1478 Danke erhalten: 184 Mitglied seit: August 2013

    nein, die kommt überall gleich...

  • AndreHerkingAndreHerking MitarbeiterKommentare: 419 Danke erhalten: 103 Mitglied seit: März 2016

    Cookies werden auch akzeptiert vom Browser? Probiere mal die CSRF Protection temporär zu deaktivieren, vielleicht wird hier ein Fehler verschleiert:

    https://community.shopware.com/FAQ-Fehlermeldungen-und-deren-Ursachen_detail_2001.html#Deaktivieren_des_X-CSRF-Token 

  • QwertyQwerty MitgliedKommentare: 14 Danke erhalten: 2 bearbeitet 8. November Mitglied seit: Januar 2016

    Mal einen anderen Browser probiert, bzw. den Inkognito Modus? Dies ist sehr häufig der Fall, wenn ein alter CSRF Session Cookie noch vorhanden ist. 

    LG Andre

    Hallo Andre,

    darf ich mal fragen, was denn nun passiert um das eigentliche Problem mit dieser PHP 7 Version zu lösen? 

  • AndreHerkingAndreHerking MitarbeiterKommentare: 419 Danke erhalten: 103 Mitglied seit: März 2016

    Mal einen anderen Browser probiert, bzw. den Inkognito Modus? Dies ist sehr häufig der Fall, wenn ein alter CSRF Session Cookie noch vorhanden ist. 

    LG Andre

    Hallo Andre,

    darf ich mal fragen, was denn nun passiert um das eigentliche Problem mit dieser PHP 7 Version zu lösen? 

    Ich hatte mir das auf meiner Testumgebung mit indentischer PHP Version aus dem offiziellen Ubuntu-Repo angeschaut und konnte das nicht nachstellen. Gleiche gilt für eine Debian-Umgebung. Aktuell vermute ich eher, dass es hier an die verwendete Distribution liegt, da augenscheinlich alle CloudLinux einsetzen. Wir werden uns das aber morgen nochmal genauer anschauen.

    LG andre  

  • kullikulli MitgliedKommentare: 1478 Danke erhalten: 184 bearbeitet 8. November Mitglied seit: August 2013

    Cookies werden auch akzeptiert vom Browser? Probiere mal die CSRF Protection temporär zu deaktivieren, vielleicht wird hier ein Fehler verschleiert:

    https://community.shopware.com/FAQ-Fehlermeldungen-und-deren-Ursachen_detail_2001.html#Deaktivieren_des_X-CSRF-Token 

    leider auch nicht

    ich verwende kein cloud-linux ! dachte ich zumindest bis zur Aussage des Providers:  "es wird HardenedPHP verwendet" : also doch cloudlinux !

    Edit: ich bleib auf php 5.6 - da komme ich rein !

  • fm1985fm1985 MitgliedKommentare: 9 Danke erhalten: 3 bearbeitet 8. November Mitglied seit: Januar 2017

    @AndreHerking‍ ich hab dir eine PN gemacht mit dem Link zu der PHPInfo

    Es liegt im übrigen nicht am CloudLinux sondern am HardendedPHP. Bei einem anderer Hoster der CloudLinux im Einsatz hat aber kein HardendedPHP läuft alles normal.

Anmelden oder Registrieren, um zu kommentieren.