Shopware 6 auf Webhosting 8000

  • Hallo,

    ich wollte gerade Shopware 6 auf unserem Webhosting 8000 installieren.

    Jedes Mal bei der Datenbank-Installation gibt es einen Error mit folgender Meldung:

    Ich habe den Support bereits kontaktiert, leider ohne Hilfe, da es sich um ein externes Skript handelt...


    Ich hoffe es findet sich jemand, der eine Lösung hat.

    Danke!

  • Vielen Dank für deine Antwort. Wenn ich die Installation mit Shopware 5.5.10 probiere, bekomme ich leider auch eine Fehlermeldung:


    Error

    Please try to fix this error and restart the update.

    Response

    Code
    "
    \nNotice:  session_start(): ps_files_cleanup_dir: opendir(/var/lib/php5/sessions) failed: Permission denied (13) in /var/www/vhosts/hosting108787.a2f33.netcup.net/httpdocs/shop-test5.de/recovery/install/src/app.php on line 59
    \n{\"valid\":true,\"offset\":850,\"totalCount\":1551,\"success\":true}"


    Ich finde es kann doch eigentlich nicht sein, dass entweder Shopware eine Software rausbringt, die viele nicht installieren können, oder netcup keine Lösung zu einer so weit verbreiteten Software anbieten kann.


    Vielleicht hat ja noch jemand eine Idee.

  • Offenbar ist das Verzeichnis, in dem die Session gespeichert werden soll (session.save_path, /var/lib/php5/sessions) nicht zugreifbar. Das ist m.E. ein Fehler in der Konfiguration und kam letztens bereits einige Male vor und wurde dann vom Support behoben.

  • Offenbar ist das Verzeichnis, in dem die Session gespeichert werden soll (session.save_path, /var/lib/php5/sessions) nicht zugreifbar. Das ist m.E. ein Fehler in der Konfiguration und kam letztens bereits einige Male vor und wurde dann vom Support behoben.

    Zumal php5 doch eh bald auf den Webhosting abgeschaltet wird.

  • Zumal php5 doch eh bald auf den Webhosting abgeschaltet wird.

    Er benutzt ja auch php7.2, hat aber als session.save_path (siehe screenshot) eben noch /var/lib/php5/sessions) stehen. Habe kein Webhosting, aber es sieht für mich so aus, als könnte man das umstellen und es sollte dann laufen.

    Wenn das die Standardkonfiguration ist, dann sieht das schon sehr nach einem Fehler aus.


    Klar ist Netcup so günstig, weil der Support sich nicht um jeden DAU kümmert und erst mal alles, abwiegelt mit "kein Support für Nutzersoftware". Aber es ist andererseits auch irgendwie ärgerlich, dass man immer erst mal nachweisen muss, dass der Fehler (und eine nicht funktionierende Standardkonfiguration sehe ich als sowas an) bei Netcup liegt bevor sich das mal jemand anschaut.

  • Das ist bei mir aber auch so und funktioniert. Eine andere Auswahl habe ich da auch gar nicht. Der Pfad ist seit Jahren so, zwischenzeitlich gab es mal /var/lib/php/sessions zur Auswahl, jetzt nicht mehr. Ich denke es ist einfach ein Rechteproblem, der Name des Verzeichnisses ist zwar irreführend, aber letztlich egal.Insgesamt muss ich aber leider auch sagen, bei meinen ersten gebuchten Webhostings hier gab es keinerlei Probleme, in letzter Zeit schleichen sich mehr Fehler ein, als netcup lieb sein kann.

    Also falls der Support die obige Fehlermeldung zugeschickt bekam, hätte man dort eigentlich wissen müssen, dass es damit in letzter Zeit öfter Probleme gab. Externes Skript hin oder her, ein Fehler beim Starten der Session muss das doch eigentlich wieder in Erinnerung bringen. PHP-Fehler treten natürlich auch bei externen Skripten auf, die wenigsten Kunden werden sich wohl auf interne Skripte von netcup beschränken. Und nur weil das Skript extern ist heisst ja nicht, dass ein auftretender Fehler nicht trotzdem auf die Konfiguration des Servers zurückzuführen sein kann. Falls die Fehlermeldung nicht mitgeschickt wurde, würde ich mir wünschen, dass der Support nach der Fehlermeldung fragt.

    • Offizieller Beitrag

    Guten Abend zusammen,



    danke für eure Unterstützung.


    Bei den zwei Meldungen ganz oben (im Bezug auf das session_dir) handelt es sich um eine Notice und eine Warning. Die erste Meldung deutet lediglich darauf hin, dass der Garbage Cleaner von PHP die Session Files nicht löschen konnte. Das ist korrekt so, da wir die Löschung automatisiert vornehmen. Dieses Feature sollte eigentlich in den PHP-Settings unsererseits deaktiviert sein. Ich werde prüfen, warum das nicht der Fall ist und es ggf. korrigieren. Diese Meldung ist aber definitiv nicht ursächlich und erzeugt auch keinerlei Probleme bei der Nutzung von PHP-Sessions. Zahlreiche Kunden auf dem gleichen Server nutzen PHP-Sessions erfolgreich. Der session_path ist korrekt so, dieser wird erst in der Zukunft (bei einem Upgrade des Betriebssystems) verändert.


    Die zweite Meldung dürfte eher im Programmcode der verwendeten Software zu verorten sein, evtl. durch die vorangegangene Meldung. Aber auch diese stellt nicht das eigentliche Problem dar.


    Der eigentliche Fehler lautet: "Identifier DB not initialized yet"


    Dieser Fehler deutet laut einer Internetrecherche z.B. auf einen Fehler bei der Datenbankverbindung hin, auf ein zu niedriges Memory Limit, eine zu niedrige Max Execution Time, usw.


    Hier empfiehlt sich auch ein Blick in das error log, nachdem die entsprechende Option ("log_errors") in den PHP-Einstellungen der Domain aktiviert wurde. Dort finden sich evtl. weitere nützliche Hinweise, die bei der Fehlersuche helfen können.


    Ich habe mit dem betroffenen Kunden Kontakt per E-Mail aufgenommen, damit wir uns den Fehler gemeinsam nochmal ansehen können. Eventuell gibt es aber ja hier auch Shopware-Anwender, die ein ähnliches Problem hatten und weiterhelfen können.

  • Vielen Dank für alle Antworten und natürlich auch dem Support für die erneute Aufnahme des Tickets!


    Sobald eine Lösung gefunden wurde, werden wir diese natürlich hier veröffentlichen um anderen Usern einen Lösungsansatz für eventuelle Propbleme zu geben. Aber vielleicht gibt es ja aber auch andere Shopware-User, die das gleiche Problem hatten und es lösen konnten?


    Nur so viel, ich habe es gestern mit älteren Showware-Versionen probiert, die 5.5.10 und 5.5.9 gingen auch nicht zu installieren, die 5.4.6 hat die Installation geklappt.

  • Shopware6 läuft!!!!


    Der Support hat sich wirklich schnell gekümmert und auch die Lösung gefunden. Es lag wohl an einem Notice, der als Fehler ausgelesen wurde und somit die Installation verhindert hat. Genaueres kann ich leider auch nicht sagen...

    An unserem Hosting wurde etwas verändert, um zu testen ob es läuft. Scheinbar tut es das und nun wird dieser Fehler in Kürze auf allen Webhosting Paketen behoben. Danke an alle, die dazu beigetragen haben!!!!

  • Hallo cw_pn,


    Wir betreiben einen Magento 1.924 Store und überlegen, auf Shopware 6 zu wechseln. Natürlich würde ich mir das vorab gerne mal ansehen, ohne allzu viel Installationsaufwand betreiben zu müssen.


    Wie hast Du Shopware 6 denn installiert? Per SSH 'zu Fuss'? Es wird im CCP unter den 1-click Anwendungen nicht angeboten.

    Danke für eine Antwort im voraus.

  • Aber keine 1-click installation in den Netcup Anwendungen, oder hab ich da was übersehen? Bin noch neu hier und das CCP ist recht unübersichtlich.

    Also bei mir finde ich das auch nicht bei den Anwendungen im Plesk. Aber man kann sich den Installer runterladen und benutzen.

  • Die 1-Klick-Installationen sind eh größtenteils veraltet, teilweise Jahre alt (WP mal ausgenommen, das hat ja eine direkte Integration in Plesk). Daher ist der Weg über den offiziellen Installer stets vorzuziehen. Auf den Herstellerseiten gibt es dafür meist ausführliche Anleitungen. :)

  • Nich ganz ^^ Mit WP meine ich Wordpress - das ist in Plesk (bei Netcup unter WCP bekannt) direkt integriert und besitzt daher eine bessere Unterstützung. Die restlichen 1-Click-Installationen kann man vergessen und sollte bei denen daher auf die Installer der jeweiligen Hersteller ausweichen. :)


    Die IT bedient sich eindeutig zu vieler Abkürzungen... xD