WordPress: W3 Total Cache conflict

[kallehauge]

Howdy,

I have found a conflict between Wodby and W3 Total Cache which I believe is due to a rewrite that needs a condition in the nginx WordPress preset.
Nginx will throw a 404 when a user tries to access an HTML file that do not exist when "Browser cache" is enabled in W3 Total Cache.

It is the following configuration, added in W3's Nginx configuration, that will start the problem:

location ~ \.(html|htm|rtf|rtx|svg|txt|xsd|xsl|xml)$ {
    expires 3600s;
    etag on;
    if_modified_since exact;
    add_header Pragma "public";
    add_header Cache-Control "public";
    add_header X-Powered-By "W3 Total Cache/0.9.7.3";
}

This configuration will cause an error giving a 404 response in Nginx instead of passing the URL to the web app when a user tries to access a static html file that do not exist. See the error message below.

nginx_1    | 2019/05/10 13:18:07 [notice] 42#42: *8 "/wp-admin$" does not match "/test-test.html", client: 172.18.0.2, server: default, request: "GET /test-test.html HTTP/1.1", host: "nginx-test.localhost"
nginx_1    | 2019/05/10 13:18:07 [notice] 42#42: *8 "^/[_0-9a-zA-Z-]+(/wp-.*)" does not match "/test-test.html", client: 172.18.0.2, server: default, request: "GET /test-test.html HTTP/1.1", host: "nginx-test.localhost"
nginx_1    | 2019/05/10 13:18:07 [notice] 42#42: *8 "^/[_0-9a-zA-Z-]+(/.*\.php)$" does not match "/test-test.html", client: 172.18.0.2, server: default, request: "GET /test-test.html HTTP/1.1", host: "nginx-test.localhost"
nginx_1    | 2019/05/10 13:18:07 [notice] 42#42: *8 "/wp-admin$" does not match "/test-test.html", client: 172.18.0.2, server: default, request: "GET /test-test.html HTTP/1.1", host: "nginx-test.localhost"
nginx_1    | 2019/05/10 13:18:07 [error] 42#42: *8 open() "/var/www/html/test-test.html" failed (2: No such file or directory), client: 172.18.0.2, server: default, request: "GET /test-test.html HTTP/1.1", host: "nginx-test.localhost"
nginx_1    | 172.18.0.2 - - [10/May/2019:13:18:07 +0000] "GET /test-test.html HTTP/1.1" 404 193 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36"

I'm guessing it's this rewrite rule that's the cause of the conflict: https://github.com/wodby/nginx/blob/master/templates/presets/wordpress.conf.tmpl#L109

How to reproduce:

• Create a fresh install of WordPress with the docker4wordpress Docker stack.
• Install W3 Total Cache plugin
• Enable Browser cache in W3 Total Cache (or import this json settings file )
• Add the new nginx.conf file in the root of the WordPress site (NGINX_SERVER_EXTRA_CONF_FILEPATH: /var/www/html/dev.nginx.conf)
• Try to access a random path ending with .html (example: http://vanilla-install.localhost/unknown-path.html)
• Nginx will now throw a 404 page without passing the URL to WordPress.

What was expected?

I expected the URL to be passed to WordPress so WordPress would be able to determine if it was an actual error or not. Right now Nginx just throws a 404 without hitting the web app.

Edit: Updated line-number in WordPress preset template.

[csandanov]

Most likely it doesn't work because W3TC requires certain additions to nginx config. I've added experimental support of W3TC to the latest version, can be enabled via $NGINX_WP_W3TC=1.

Could you please confirm that the change helps. See referenced commit for more details.

[kallehauge]

First off; thank you for improving the W3 Total Cache experience with the Nginx image @csandanov!

Secondly; I only see references to the Enhanced page cache in the experimental configuration. Is it on purpose that this logic is not applied to the "Basic" page cache option as well? (they use two different pathes: wp-content/cache/page/... and wp-content/cache/page_enhanced/...)

Lastly; apparently the solution to the specific issue was pretty easy. While testing your latest configuration, I found an option that's actually the cause of the issue (see attached screenshot). I simply didn't think this was an option based on the messages received in the Nginx log.

I think we get the notice below because the condition for # Admin for subdir multisite. is a bit too broad so it just tries to match everything with a filename that have not yet been matched?

nginx_1 | 2019/05/10 13:18:07 [notice] 42#42: *8 "/wp-admin$" does not match "/test-test.html", client: 172.18.0.2, server: default, request: "GET /test-test.html HTTP/1.1", host: "nginx-test.localhost"

[csandanov]

Could you please clarify why would you need all 404 .html requests being redirected to index.php? What are these .html files? Just static files or is this a tricky approach W3TC uses for caching dynamic page (weird)?