Installation legt das Verzeichnis /backend nicht an

Shopware 5 Installation/Einstieg
1

Bei der Installation Shopware wird das Verzeichnis /backend nicht angelegt und somit ist im Anschluss auch kein Zugang zum Backend möglich.

Shopware bewertet den Server bisher als in Ordnung, das Verzeichnis und den Unterverzeichnissen habe ich auch mal mit chmod 777 volle Berechtigungen gegeben, jedoch erfolgtlos. Kein Backend:

Systemvoraussetzungen

Glückwunsch!

Alle Voraussetzungen für eine erfolgreiche Installation sind erfüllt*

* Hinweis: Auf Deinem System ist die Codierungs-Software ionCube nicht installiert. Diese wird nur benötigt, wenn Du Dir später über unseren Shopware Community Store Erweiterungen installieren möchtest, die mit ionCube verschlüsselt sind. Du kannst die Installation von ionCube auch jederzeit nachholen.

Dateien und Verzeichnisse (alles ausblenden)

Die nachfolgenden Dateien und Verzeichnisse müssen vorhanden sein und Schreibrechte besitzen

config.phpvar/log/var/cache/web/cache/files/documents/files/downloads/recovery/custom/pluginsengine/Shopware/Plugins/Community/engine/Shopware/Plugins/Community/Frontendengine/Shopware/Plugins/Community/Coreengine/Shopware/Plugins/Community/Backendengine/Shopware/Plugins/Default/engine/Shopware/Plugins/Default/Frontendengine/Shopware/Plugins/Default/Coreengine/Shopware/Plugins/Default/Backendthemes/Frontendmedia/archive/media/image/media/image/thumbnail/media/music/media/pdf/media/unknown/media/vector/media/video/media/temp/recovery/install/data

System (alles ausblenden)

Dein Server muss die folgenden Systemvoraussetzungen erfüllen, damit Shopware lauffähig ist

VoraussetzungErforderlichDein Systemphp5.6.47.0.28ionCube Loader5.00

The ionCube Loader is only required if you wish to use encrypted third-party plugins.

mod_rewrite10

The Apache Module “mod_rewrite” should be active when using Shopware with the Apache Server.

pdo11pdo_mysql11gd2.0.02.2.5gd_jpg11freetype11libxml2.6.262.9.4curl7.0.07.47.0openssl11session11mbstring11iconv11json11xml11simplexml11ini_set11include_path11session.auto_start00memory_limit256M128Mmax_execution_time30120upload_max_filesize6M2Mpost_max_size8M8Mallow_url_fopen11file_uploads11suhosin.session.cryptua00suhosin.get.max_value_length20002000

When the “suhosin” PHP extension is loaded and the “get.max_value_length” is less than 2000, the Ext JS files cannot be loaded via GET request in the Shopware backend. This means that the Shopware backend can be partially uncached.

parse_ini_file11

The php function “parse_ini_file” must be enabled to use plugins which provide custom snippets.

zip11ftp11

 

Ich müsste auf dem Server mehrere PHP-Versionen verwenden, daher ist der bisher konfiguriert dafür nach dieser Anleitung von Thomas Christlieb: https://www.thomaschristlieb.de/mehrere-php-versionen-auf-einem-linux-server-mit-php-fpm/

Selbsverständlich beabsichtige ich noch das Modul ReWrite zu aktivieren und die memory_limits und max_file_uploads von PHP zu ändern.

Eventuell hängt es auch mit der PHP-Konfiguration zusammen, dass die Installation das Verzeichnis nicht anlegt? Leider ist mir bisher noch unbekannt, wie ich die Parameter bzw. wo ich diese ändern kann, daher habe ich Thomas Cristlieb (den Autor des Artikels zu mehreren PHP-Versionen) angeschrieben.

Unabhägig davon gibt es vielleicht hier einen Hinweis zu dem vermissten Verzeichnis? Ich habe übrigens die derzeit aktuelle stable release (5.4.1) heruntergeladen und entpackt.

DL

2

Hi Dirk,

/backend ist kein real existierendes Verzeichnis - der Aufruf wird über die Shopware .htaccess Datei gesteuert, für welche Du mod_rewrite aktiv haben musst.

VG

 

3

Danke!

Nun muss ich eben mal schauen wie ich das anstelle, auf meinem Server mit den zwei Versionen PHP, das mod_rewrite zu aktivieren. Es ist ein Ubuntu 16.04.4 LTS server mit Apache 2.4 und der genannten PHP-Einstellung für zwei PHP Versionen für verschiedene virtuelle hosts. Kannst Du mir das eventuell schreiben, wo ich was an welcher Datei dazu ändern müsste? Ggf. vielen Dank vorab.

DL

4

Hi,

verschiedene PHP Versionen sollten bei Dir kein Problem darstellen. mod_rewrite ist ja zunächst ein Apache Modul - schau mal, ob das aktiv ist und die .htaccess von Shopware in Deinem vhost existiert.

Anleitung zum aktivieren von mod_rewrite für Deine Distribution:
How To Rewrite URLs with mod_rewrite for Apache on Ubuntu 16.04 | DigitalOcean

VG

5

Ich habe alles so wie in der Anleitung von Digitaocean zu meiner Distribution umgesetzt. Leider bisher ohne gewünschtem Erfolg.

sudo a2enmod rewrite

sudo systemctl restart apache2
  1. die .htaccess mit nano im Verzeichnis bearbeitet bzw. angesehen. Sieht so aus:



RewriteEngine on

#RewriteBase /shopware/

Https config for the backend

#RewriteCond %{HTTPS} !=on
#RewriteRule backend/(.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

RewriteRule shopware.dll shopware.php
RewriteRule files/documents/.* engine [NC,L]
RewriteRule backend/media/(.*) media/$1 [NC,L]

RewriteCond %{REQUEST_URI} !(/(engine|files|templates|themes|web)/)
RewriteCond %{REQUEST_URI} !(/media/(archive|banner|image|music|pdf|unknown|v$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ shopware.php [PT,L,QSA]

 

Die Installation von Shopware zeigt leider weiterhin an:

mod_rewrite10

The Apache Module “mod_rewrite” should be active when using Shopware with the Apache Server.

Noch ein Tipp?

DL

6

Prüfe mal, ob das Modul wirklich geladen wird:

apache2ctl -M
7

Also geladen scheint es zu sein, jedoch zeigt die Installation von Shopware an, dass es nicht geladen sei:

root@ubuntu:/home/dirk# apache2ctl -M
AH00558: apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.1.1. Set the ‚ServerName‘ directive globally to suppress this message
Loaded Modules:
 core_module (static)
 so_module (static)
 watchdog_module (static)
 http_module (static)
 log_config_module (static)
 logio_module (static)
 version_module (static)
 unixd_module (static)
 access_compat_module (shared)
 actions_module (shared)
 alias_module (shared)
 auth_basic_module (shared)
 authn_core_module (shared)
 authn_file_module (shared)
 authz_core_module (shared)
 authz_host_module (shared)
 authz_user_module (shared)
 autoindex_module (shared)
 deflate_module (shared)
 dir_module (shared)
 env_module (shared)
 fastcgi_module (shared)
 filter_module (shared)
 mime_module (shared)
 mpm_prefork_module (shared)
 negotiation_module (shared)
 php7_module (shared)
 rewrite_module (shared)
 setenvif_module (shared)
 socache_shmcb_module (shared)
 ssl_module (shared)
 status_module (shared)

Hier steht zumindest  rewrite_module (shared)

Die .htaccess hat den Inhalt wie bereits gepostet.

DL

8

Stimmen die Rechte / Besitzer der .htaccess Datei ?

VG

9

Ist der Virtual-Host so angelegt, dass er die .htaccess auch interpretiert?

https://httpd.apache.org/docs/2.4/de/mod/core.html#allowoverride

10

Ja, in der .conf für den virtuellen host steht u.A. AllowOverride All

11

Die .conf mit AllowOverride All in /sites-available wurde von mir auch mit a2enssite aktiviert. Noch jemand einen Hinweis wo ich noch suchen kann?

12

Also auf PHP 5.7.4 zeigt die Installationsroutine zwar auch an, dass u.A. mod_rewrite nicht aktiviert sei, aber läuft durch und bricht am Ende ab, weil curl nicht auf dem Server installiert ist. Der Zugriff auf das Backend funktioniert dann.

13

Ich möchte noch mal konkret fragen warum es wohl so ist das die .htaccess nicht berücksichtigt wird.

Die Konfigurationsdatei für den virtuellen host (vhost.conf) von Apache 2.4 sieht so aus:

<ifmodule mod_fastcgi.c>
  AddHandler php56-fcgi-www .php
  Action php56-fcgi-www /php56-fcgi-www
  Alias /php56-fcgi-www /usr/lib/cgi-bin/php56-fcgi-www
  FastCgiExternalServer /usr/lib/cgi-bin/php56-fcgi-www -socket /run/php/php5.6-fpm.sock -pass-header Authorization

  <directory>
     Require all granted
  </directory>
</ifmodule><ifmodule mod_fastcgi.c>
   AddHandler php70-fcgi-www .php
   Action php70-fcgi-www /php70-fcgi-www
   Alias /php70-fcgi-www /usr/lib/cgi-bin/php70-fcgi-www
   FastCgiExternalServer /usr/lib/cgi-bin/php70-fcgi-www -socket /run/php/php7.0-fpm.sock -pass-header Authorization

   <directory>
      Require all granted
   </directory>
</ifmodule><ifmodule mod_fastcgi.c>
   <filesmatch>
      SetHandler php70-fcgi-www
   </filesmatch>
</ifmodule><virtualhost>
        # The ServerName directive sets the request scheme, hostname and port that
        # the server uses to identify itself. This is used when creating
        # redirection URLs. In the context of virtual hosts, the ServerName
        # specifies what hostname must appear in the request's Host: header to
        # match this virtual host. For the default virtual host (this file) this
        # value is not decisive as it is used as a last resort host regardless.
        # However, you must set it for any further virtual host explicitly.
        ServerName shop.so-geht-es.org
        ServerAdmin <a href="mailto:dirk.lehmann@so-geht-es.org">dirk.lehmann@so-geht-es.org</a>
        DocumentRoot /var/www/shopware
        <directory>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                allow from all
        </directory>
        # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
        # error, crit, alert, emerg.
        # It is also possible to configure the loglevel for particular
        # modules, e.g.
        #LogLevel info ssl:warn

        ErrorLog ${APACHE_LOG_DIR}/errors-shop-so-geht-es.log
        CustomLog ${APACHE_LOG_DIR}/access-shop-so-geht-es.log combined

        # For most configuration files from conf-available/, which are
        # enabled or disabled at a global level, it is possible to
        # include a line for only one particular virtual host. For example the
        # following line enables the CGI configuration for this host only
        # after it has been globally disabled with "a2disconf".
        #Include conf-available/serve-cgi-bin.conf
</virtualhost>

Wie man u.A. sieht. AllowOverride All

Die Berechtigungsmatrix ist derzeit 777.