If Shopware is configured to include a .html suffix on product urls, they will not be accessible, because this configuration assumes that urls ending on .html are static files. Therefore it might make sense to remove the html part from https://github.com/bcremer/shopware-with-nginx/blob/master/global/shopware.conf#L100

Wenn Ich in SEO/Router Einstellungen für Artikel folgende Template benutze - {sCategoryPath articleID=$sArticle.id}/{$sArticle.name}.html, nginx zeigt immer 404 Fehler. Das selbe mit Categorie-Template. Ohne .html funktioniert seo-rewrite ohne Probleme.

At some point we experienced nginx timeouts, for example during product imports oder exports.
I've added fastcgi_read_timeout 300 into the global nginx config, which is enough for now.

As PHP itself handles the timeouts while the import/export scripts, what would be the best way for nginx to "listen" to the php timeouts instead of cutting it off?

Hi all,

with this config, i'm not able to update Shopware.

I tried to reproduce this problem with a clean and fresh install (v 5.1.6) and want to update to 5.2.6 (also tried a while ago to update to 5.2.1).

The update stops at http://domain.com/recovery/update/index.php/dbmigration
Showing:

Error
Received an error message.
URL: unpack?offset=0&total=0
Message: Not Found

Please try to fix this error and restart the update.
Response
404 Page Not Found
The page you are looking for could not be found. Check the address bar to ensure your URL is spelled correctly. If all else fails, you can visit our home page at the link below.

I think its because the nginx config does not take the following URLs into account:
http://domain.com/recovery/update/index.php/unpack?offset=0&total=0

I tried to change the jquery update script to get URLs like this (removed the "index.php"):
http://domain.com/recovery/update/unpack?offset=0&total=0

But this also does not work. I think its because the PHP Update Script uses app.map("/unpack").

I also tried several nginx changes but none of them works. Any help is greatly appreciate!

Greets,

Chris

I am using auto-renewal certificates from Let's encrypt for my shopware installations. The problem with this config is that it somehow blocks the access to the let's encrypt files. Any idea how to bypass this issue?

Thanks in advance

Es gibt aktuell ein Problem mit Plugins wie z.B. Actindo WaWi.
http://wiki.actindo.de/index.php?title=Shopware_4

Normal spricht man das Plugin mit www.domain.tdl/Actindo/ an.
Das Plugin kann man manuell unter www.domain.tdl/Actindo/xmlrpc_server.php?get_cryptmode=1&username=test bzw. www.domain.tdl/shopware.php/Actindo/xmlrpc_server.php?get_cryptmode=1&username=test aufrufen und hier kommt dann eine Antwort.

Bei Apache funktioniert dies problemlos, bei NGINX mit der .conf leider aktuell nicht.
Es kommt eine 404 ERROR.

Ich habe schon viel rumprobiert, leider komme ich nicht drauf woran es hier hängt.

// UPDATE:
Ich habe nun das Problem gefunden.
Da hier eine PHP Datei direkt aufgerufen werden muss, funktioniert location ~ .php$ { natürlich nicht,
weil er nun direkt die PHP Datei xmlrpc..... aufrufen will und deshalb der 404 kommt.
Wenn ich location ~ shopware.php$ { schreibe funktioniert es nun korrekt.
Die Frage ist ob diese Korrektur nicht negative Auswirkungen auf die Basis Shopware Funktionen hat.

Wenn ich in den Artikeleinstellungen unter ESD die gewünschte Datei auswähle und dann oben auf Datei herunterladen klicke werde ich auf folgende URL weitergeleitet und bekomme einen 404 not found:

https://SHOPURL/backend/Article/getEsdDownload/filename/testfile.png

Normalerweise sollte in der shopware.conf ja ein rewrite dafür geben aber bei mir geht es aus dem Admin Interface heraus nicht.
Wie muss ich meine config ergänzen damit dies funktioniert?

this entry works not with robots.txt --> error 404 with nginx.

robots.txt support.

location = /robots.txt {
log_not_found off;
access_log off;
}

change it with...

location = /robots.txt {
log_not_found off;
access_log off;
try_files $uri @shopware;
}

it works. ;-)

We usually add the following location block for Let's Encrypt verification:

    location '/.well-known/acme-challenge' {
        default_type "text/plain";
        root /var/www/letsencrypt;
    }

Trying to add a new certificate we get a 403 error from

Removing that line still results in a 404 error.

I had the idea of a Hardened Configuration what covers things like

• Remove access to all folders except folders: themes, media, web
• Add ip based whitelist to /backend and optional /api, otherwise rewrite to error controller
• Remove all return 404 and rewrite to error controller, to have the same look and feel on blocked resources

What do you think about that? :)

Ich glaube sollte robot.txt location in shopware.conf auskommentiert sein, weil es ab Shopware 4 robot.txt über template erstellt wird. Oder entsprechende Hinweis dazu einfügen?

location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}

Hi @bcremer,

nice to find an unofficial repository of configurations for nginx from an official Shopware Tech member.

My question is, even so, do you (or is it) still recommended to use Shopware on Nginx, regardless of the official support? Is it reliable? What are the most common examples of something that can go wrong?

Thanks.

global/shopware.conf is brilliant. Worked much better than my first attempt at a Shopware snippet!

We would prefer to have different PHP-FPM upstreams for different servers. I implemented this on our server by changing fastcgi_pass to:

fastcgi_pass $fpm_upstream;

and in the server { ... } block setting the variable along with the environment key:

set $fpm_upstream php-staging;
set $shopware_env 'staging';

Ahoi,

wo würde man hier am geschicktesten die Übergabe im Stil eines

fastcgi_params ENV staging;

einbauen, um das Staging Plugin nutzen zu können - bzw. ist das über obiges Kommando problemlos möglich? Da Apache nur

SetEnvIf Host "staging.ihrshop.com" ENV=staging

benötigt, hätte ich vermutet ein zweiter VHost à la example.com.conf mit einer fastcgi_params Zeile VOR dem Include der global/shopware.conf würde das ggf. lösen.

Ist das machbar bzw. könnte man das als Beispiel inkludieren?

Dank und Gruß
Jens

I have trouble witch Item export (Produktexporte) urls https://domain/backend/export/index/feed.xml
I get 404 error and redirect to backend.
Can anyone confirm?

XML SitemapMobile support.

location = /sitemapMobile.xml {
log_not_found off;
access_log off;
try_files $uri @shopware;
}

Hey,
thank u very much for your work. It works good but the routing for the subshops is not working.

For example:
https://{domain}.com/{subpage} is working!
https://{domain}.com/{subshop}/{subpage} is not working (e. g. https://{domain}.com/en/imprint).

Do you have any ideas why this is not working?

Thank u!

If shopware is installed in a subfolder (as suggested by the shopware support for testing/help) a config for this scenario would be great. I think there are some pitfalls and a bit more work than just prepending the subfolder path is required.

After merging PR #8 I was thinking about creating a variable for the esd key to get rid of the hardcoded value in global/shopware.con.

# sites-available/example.com.conf
set $shopware_esd_key '552211cce724117c3178e3d22bec532ec';`

# global/shopware.con
location ^~ /files/$shopware_esd_key/ {
    internal;
}

Unfortunately that seems not possible with plain Nginx config.