Bevor Du aber nun mit der Installation beginnst, solltest Du dich vergewissern, dass Dein System die Systemvoraussetzungen für Shopware 6 erfüllt.
Darüber hinaus empfiehlt es sich die Routing-Einstellungen Deines Webservers ggf. anzupassen.
Ein entsprechendes Beispiel anhand von Apache haben wir Dir hier unten aufgeführt.
ServerName "_HOST_NAME_"
DocumentRoot _SHOPWARE_DIR_/public
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
ErrorLog ${APACHE_LOG_DIR}/shopware-platform.error.log
CustomLog ${APACHE_LOG_DIR}/shopware-platform.access.log combined
LogLevel debug
doch was genau soll das sein? Wo muss ich das einstellen? In eine htaccess kann ich es ja nicht packen, da die selbst im /public liegt …
habe versucht die Domain direkt auf /public zu rooten, dann werde ich beim Aufruf meiner Domain zumindest weitergeleitet auf /recovery/install/ … dann bekomme ich aber folgenden Fehler
Fatal error: Uncaught Symfony\Component\Dotenv\Exception\PathException: Unable to read the "/meinhosting/shop/shopware6/test/public/../.env" environment file. in /meinhosting/shop/shopware6/test/vendor/symfony/dotenv/Dotenv.php:484 Stack trace: #0 /meinhosting/shop/shopware6/test/vendor/symfony/dotenv/Dotenv.php(65): Symfony\Component\Dotenv\Dotenv->doLoad(false, Array) #1 /meinhosting/shop/shopware6/test/public/index.php(41): Symfony\Component\Dotenv\Dotenv->load('/meinhosting/shop/...') #2 {main} thrown in /meinhosting/shop/shopware6/test/vendor/symfony/dotenv/Dotenv.php on line 484
Berechtitungen habe ich via CHMOD auf 777 gesetzt (rekursiv natürlich)
Beim Routing muss der VHost nur auf /public zeigen. Mehr muss man da nicht machen. Dein Fehler hat eher nichts mit dem routing zu tun. Ansonsten muss man die URL halt immer mit /public aufrufen wenn man das nicht hat.
Der Fehler klingt eher so, als ob Dateien fehlen. Alles direkt auf dem Server entpackt?
was ist denn dieses /shopware6/test/public/…/.env environment file und wo sollte es liegen? Muss ich das selbst anlegen?
es wird ja offenbar versucht das File in /vendor/symfony/dotenv/Dotenv.php:484 zu laden…
auffällig ist am Pfad ja der doppelte Punkt /public/ …/.env … die Datei hab ich überhaupt nicht, die sollte ja dann wohl außerhalb von /public liegen oder?
hab die Datei .env mit der Hand leer angelegt, dann komm ich zwar einen Schritt weiter aber zum nächsten Fehler
Warning: require(/meinhosting/shop/shopware6/test/vendor/composer/../symfony/polyfill-ctype/bootstrap.php): failed to open stream: No such file or directory in /meinhosting/shop/shopware6/test/vendor/composer/autoload_real.php on line 66
Fatal error: require(): Failed opening required '/meinhosting/shop/shopware6/test/vendor/composer/../symfony/polyfill-ctype/bootstrap.php' (include_path='.:/usr/local/lib/php') in /meinhosting/shop/shopware6/test/vendor/composer/autoload_real.php on line 66
irgendwie ist das unbefriedigend… kann die Installation nicht einfach funktioniern ohne Probleme, so wie es bei SW5 der Fall war?
Warum muss ich überhaupt eine Datei mit der Hand anlegen?
Muss man ja garnicht, funktioniert bei anderen ja auch so
Schmeiß die Installation mal weg und beginne von vorne. Kenne dein System jetzt nicht, aber bei unseren zertifizierten Hostern läuft das out of the Box. Lokal mit Standard Lamp unter Ubuntu auch. Php7.2 auch aktiv?
Verzeichnisrechte pauschal auf 0777 setzen ist auch ein eigenartiger Schritt. Stelle mal sicher, dass der Prozess der den Webserver betreibt auch Besitzer der Dateien ist. Dann braucht man auch kein 0777. Wenn das nötige ist, liegt ja generell was im Argen auf dem Server. Wie gesagt, dass env File musst du nicht erstellen, war eben nur ein Test.
entpacken auf dem Server
Verzeichnisrechte anpassen, wie es der Server benötigt (nicht 0777, ist im Web immer eine schlechte Idee)
Domain/recovery/install/index.php aufrufen
Wenn das nicht klappt, musst du mal debuggen woran es liegt, sind ja nur php Dateien. Generell hat es hier ja bei Profihost, All-Inkl., Timme, lokal usw. schon hundertfach funktioniert. Der Installer basiert auf dem SW5 installer, da hat sich nicht groß etwas verändert.
tut mir leid, aber ich debugge doch nicht einen Installer von dem ich erwarte, dass er auf jedem Hosting einwandfrei funktioniert.
das ist dann wohl das Todesurteil für uns in Sachen Shopware 6, für sowas hat niemand Zeit. Ein neuer Shop muss in 5min installiert sein… ging ja bei SW5 auch einwandfrei.
ob das setzen von 777 gut oder schlecht ist, ist ja erstmal egal. Ich wollte halt auf Nummer sicher gehen um das Problem so evtl. zu beseitigen.
“Prozess der den Webserver betreibt auch Besitzer der Dateien ist” --> wie stellst du dir das vor, wie ich das machen soll?
EDIT:
wenn ich direkt /recovery/install/index.php aufrufe, komme ich zu einem Installer. Mal sehen ob das durch geht… wieso leitet mich die BaseURL dann nicht auf /recovery/install/index.php weiter sondern auf /recovery/install ?
Wenn du einen Webserver betreibst solltest du dich auch mit Linux auseinander setzen, ansonsten den Hoster fragen. Besitz- und Zugriffsrechte sind sehr komplex und müssen auf den Betrieb der Seite abgestimmt werden. Alles für alle freigeben (0777) öffnet nur Haus und Hof für mögliche Angriffe durch dritte. Das hat auch nichts mit Shopware zu tun. Das ist für jede Art von Webserver immer eine schlechte Idee.
Und der Installer leitet korrekt weiter. Wahrscheinlich ignoriert dein Webserver hier die Konfiguration, dass die index.php angesprochen werden soll, wenn keine Datei übermittelt wird. Aber auch das ist Konfigurationssache auf dem Server.
Der Installer wird nicht überall funktionieren. Das gibt es schlichtweg nicht. Dafür gibt es Hoster die sich mit den Betrieb von Webservern auseinander setzen und die korrekt konfigurieren. Wobei das nun wirklich noch eine Kleinigkeit ist.
Domainfactory und Shopware war und ist immer ein Gefrickel. (liegt an dem speziellen Setup, den dF abweichend zu anderen Hostern hat). Wenn es dann funktioniert, ist es im Vergleich zu Angeboten von Hostern, die spezielle Shopware-Angebote in der selben Preisklasse haben, recht langsam. Das war einer, aber nicht der einzige Grund, warum ich vor ein paar Jahren von dF weg bin.
Und da dF zumindest in der Vergangenheit sehr „konservativ“ beim Umsetzen von Technologie(Updates|Neuheiten|Sprüngen) war, ist davon auszugehen, dass auch die MySQL 5.7. eher erst in Monaten oder Jahren eingeführt wird.
Das soll kein Bashing sein, muss man aber als (pot.) Kunde wissen.
