Tommy
Forum Replies Created
-
Forum: Plugins
In reply to: [W3 Total Cache] Bug Nginx rules & Yoast SEO sitemap.@vmarko Will turning off the “Verify rewrite rules” setting stop W3TC from updating the rule back into the nginx.conf?
It’s the only solution I’ve found so far is to remove “xml” from the rule, but it keeps getting added back automatically.Forum: Plugins
In reply to: [W3 Total Cache] Bug Nginx rules & Yoast SEO sitemap.This block changed with the last update but my problem still happen.
location ~ \.(html|htm|rtf|rtx|txt|xsd|xsl|xml)$ { etag on; if_modified_since exact; add_header Pragma "no-cache"; add_header Cache-Control "private, no-cache"; add_header Referrer-Policy "strict-origin-when-cross-origin"; try_files $uri $uri/ /index.php?$args; }I have to remove “xml” and restart nginx to make my sitemap available. I’m using CloudPanel.
Forum: Plugins
In reply to: [W3 Total Cache] Bug Nginx rules & Yoast SEO sitemap.This is what ChatGPT told me.
This is usually fine, but with Yoast SEO sitemaps, which are served dynamically via PHP (not as static .xml files), this can cause issues. Here's what might be happening: ❌ Why It's Redirecting (301) to Homepage When someone requests /sitemap_index.xml (a typical Yoast sitemap URL), NGINX applies this rule because .xml matches the regex. The file /sitemap_index.xml does not exist physically, so: NGINX tries /sitemap_index.xml/ (a directory) — doesn't exist. Then it tries /index.php?$args — this triggers WordPress routing. If W3TC caching or redirects are misconfigured, or if WordPress fails to resolve that route, it falls back to the homepage and issues a 301 redirect.Forum: Plugins
In reply to: [W3 Total Cache] Bug Nginx rules & Yoast SEO sitemap.The sitemap redirect to the index page. (301)
try_files $uri $uri/ /index.php?$args; is causing the issue.
I’m using Yoast SEO sitemap.
Forum: Plugins
In reply to: [W3 Total Cache] Bug Nginx rules & Yoast SEO sitemap.@vmarko Any updates on this? It’s annoying because W3TC overwrites the nginx config edits I make each time, making the sitemap unavailable again.
Forum: Plugins
In reply to: [W3 Total Cache] Blank page on Chrome incognito mode@vmarko I’ve found the issue, it’s related to Brotli.
If Brotli is enabled on the origin server, it causes a conflict with Cloudflare and W3TC, resulting in the blank page.
Forum: Plugins
In reply to: [W3 Total Cache] Blank page on Chrome incognito modeThe issue occur when page cache is enabled and Cloudflare is also enabled (orange cloud) and when you access the site in a new incognito tab.
Disabling W3tc or page cache fix it. I think this is an issue between CF and W3tc.
Forum: Plugins
In reply to: [W3 Total Cache] Blank page on Chrome incognito modeDisabling Cloudflare (Grey cloud) also fix the issue, is that an issue between CF and W3tc? I don’t have other WP site on CF to test.
I’m unable to find the “link to the media files” option anymore, I cannot use the lightbox with Gutenberg single image.
@vupdraft I found the issue, it was caused by W3 Total Cache Object Cache
Clearing the object cache fix the issue.
Thank you.
There are errors in the console.
No php errors.
POST /wp-admin/admin-ajax.php?_fs_blog_admin=true 400Forum: Plugins
In reply to: [W3 Total Cache] 404 errors causing website crash.I wasn’t aware this option existed. It was not enabled, but enabling this option actually fix my issue.
Thank you.
Forum: Plugins
In reply to: [W3 Total Cache] 404 errors causing website crash.Hello,
Yes, the issue is caused by ““try_files $uri $uri/ /index.php?$args;” added to static files. When you have a lot of traffic and 404 errors it will cause some memory issue.
I have disabled Browser Caching from W3 and added my own NGINX rules without this line.
I think W3 should not add this line to static files. It’s bad for performance, NGINX should handle the 404 errors and NOT WordPress.
This blog post explain my issue.
https://wphelp.blog/manage-404-errors-static-files-from-the-server/
Just a suggestion.
Thanks.
Forum: Plugins
In reply to: [W3 Total Cache] Cache control header no longer workingI have fixed my issue by simply enabling page caching, when page cache is enabled the cache control header is working.
I couldn’t enable Page Cache before because I was using another caching plugin that have a feature than W3TC doesn’t have. But I have removed this plugin now.
Forum: Plugins
In reply to: [Remoji - Post/Comment Reaction and Enhancement] Mobile responsiveI agree, I managed to fix mine with this custom CSS.
@media only screen and (max-width: 600px) { #remoji_panel { left: 0px!important; } }