Robert Soare
Forum Replies Created
-
Hello,
This feed address is return HTTP Error 503: https://www.pmsm.fr/category/actions-preventions/feed/, so it is not accessible.
http https://www.pmsm.fr/category/actions-preventions/feed/
HTTP/1.1 503 Service Unavailable
age: 0
cache-control: no-cache
content-length: 107
content-type: text/html
date: Thu, 09 Apr 2026 12:34:15 GMT
set-cookie: WEBMO-VNU=3|adecy|adecy; path=/; HttpOnly; SameSite=Strict
strict-transport-security: max-age=86400; preload;
via: 1.1 varnish (Varnish/7.1)
x-cache: MISS
x-cacheable: NO:HTTPerror
x-varnish: 136120336
x-varnutype: 5
<html><body><h1>503 Service Unavailable</h1>
No server is available to handle this request.
</body></html>You need a working feed link. A working link looks like this: https://themeisle.com/blog/feed/
Hi,
You can try to re-add your accounts since there is a possibility that services like Facebook have changed their requirements and might need a new authorization key.
Also, if it is still not working, you can check your WordPress debug logs to see if there might be a reported problem that may prevent the plugin from running the sharing workflow.
Hi,
In our isolated cases, the issue does not manifest; we suspected that our old CSS minifier might be the problem, but it does not modify new modern CSS code. Besides Otter, do you have any other plugins that may manipulate the CSS (like optimizers that rewrite the CSS to be compatible with older browsers)? Also, can you share an example of how you used it (in case we might be an edge case that we are not aware of)?
Thank you!
- This reply was modified 1 month, 2 weeks ago by Robert Soare.
Hello,
Currently, there is UI option to disable this behaviour. And, as a hook, you can use this as a reference to disable the hooks that are working with global options:
<?php
/**
* Plugin Name: SWCFPC - Disable Full Purge on Theme/Menu Edits
* Description: Prevents Super Page Cache for Cloudflare from purging the entire
* cache when menus, theme options, or customizer settings are saved.
* Manual purge via the plugin dashboard still works.
*/
add_action( 'init', function () {
if ( ! isset( $GLOBALS['sw_cloudflare_pagecache'] ) ) {
return;
}
$cache_controller = $GLOBALS['sw_cloudflare_pagecache']->get_cache_controller();
if ( ! $cache_controller ) {
return;
}
// Remove the hooks that trigger a full cache purge on global changes.
// Per-post auto-purge (edit_post, clean_post_cache, etc.) is unaffected.
$purge_actions = [
'wp_update_nav_menu', // Menu create/update/delete
'update_option_theme_mods_' . get_option( 'stylesheet' ), // Theme customizer options (e.g. header, footer, colors)
'switch_theme', // Active theme switch
'customize_save_after', // Theme customizer save (live preview → publish)
];
foreach ( $purge_actions as $action ) {
remove_action( $action, [ $cache_controller, 'purge_cache_on_theme_edit' ], PHP_INT_MAX );
}
}, 0 ); // Priority 0 on init — runs after the plugin registers its hooksHello,
If “Purge HTML pages only” is enabled, the plugin will only clear the cached HTML pages from Cloudflare. It will not clear images or other static files like CSS or JS.
So if you update an image and want Cloudflare to fetch the new version, you would need to either:
- purge that specific image URL
- use Force purge everything
- or upload/use a new image URL so Cloudflare sees it as a new file
As for the difference between the two purge options:
- Purge whole cache follows your current plugin settings
- Force purge everything ignores that setting and clears everything from Cloudflare, including images and other static assets
So with “Purge HTML pages only” turned on, Purge whole cache would still leave images alone, while Force purge everything would remove everything.
About “Ignore marketing parameters”: yes, it can help improve cache hit rate, especially if you get traffic from Google Ads, Facebook ads, email campaigns, etc., where URLs often include things like gclid, fbclid, or utm_*.
In normal use, that should not break Google Ads tracking or conversion tracking, because those parameters are still in the visitor’s browser URL. The plugin is basically just ignoring them for cache purposes, so Cloudflare can serve the same cached page instead of creating a separate cache entry for every tracked URL variation.
The only time you’d want to be careful is if your site changes page content on the server side based on those parameters. In that case, ignoring them for caching could cause problems.
Hello,
Could please enable the debug logs (in Settings > Error log) and share it on this thread when the problem arise?
A 422 means that the server could not process the content of that image so we need to check the image and see why the server reject its.
Hello
So it seems that the rules in the Cloudflare Cache are not working very well.
λ http GET https://www.adnperformances.com/wp-json/ --headers
HTTP/1.1 200 OK
Age: 118
CF-RAY: 9bef03e3de8de429-OTP
Cache-Control: max-age=16070400
Connection: keep-alive
Content-Encoding: zstd
Content-Type: application/json; charset=UTF-8
Date: Fri, 16 Jan 2026 16:33:32 GMT
Nel: {"report_to":"cf-nel","success_fraction":0.0,"max_age":604800}
Report-To: {"group":"cf-nel","max_age":604800,"endpoints":[{"url":"https://a.nel.cloudflare.com/report/v4?s=nWI8WYuaAriS6nuimDK7HaDUSIW6biShTvSBhqwG%2B3R43Su%2FtPbupSorQbeDS35GDj9nq08vGLBcQp9tvUkyQ1%2B3%2BUR8NsJbKYTa2mGz9yfaC2F3SATW"}]}
Server: cloudflare
Transfer-Encoding: chunked
access-control-allow-headers: Authorization, X-WP-Nonce, Content-Disposition, Content-MD5, Content-Type
access-control-expose-headers: X-WP-Total, X-WP-TotalPages, Link
allow: GET
alt-svc: h3=":443"; ma=86400
cf-cache-status: HIT
last-modified: Fri, 16 Jan 2026 16:31:34 GMT
link: https://www.adnperformances.com/wp-json/; rel="https://api.w.org/"
vary: Origin,Accept-Encoding,User-Agent
x-content-type-options: nosniff
x-robots-tag: noindex
x-turbo-charged-by: LiteSpeed
x-xss-protection: 1; mode=blockPer your posted rules, the
wp-jsonpath should be excluded from caching. You can try uninstalling the plugin, deleting the existing rule from the Cloudflare dashboard, then reinstalling and reconnecting.Hello,
For Cloudflare integration, we require:
'#waf:read',
'#waf:edit',
'#dns_records:read',
'#dns_records:edit',
'#page_shield:read',
'#ssl:read',
'#page_shield:edit',
'#zone:edit',
'#zone:read',
'#zone_settings:read',
'#zone_settings:edit',
'#cache_purge:edit',
'#analytics:read',And from your response it seams that those 3 are missing:
"#waf:read",
"#waf:edit",
"#analytics:read"Hello,
You might want to deactivate the “Automatically purge Cloudflare’s cache when something changes on the website” option that triggers the purge when a post type changes. This is a general setting; we do not have one yet that disables on specific post types.
When enabling it, you might also want to check if you have frequent updates to your pages since without the auto-purge some old content might be served.
Hello,
Thanks for reporting, the issue might have been caused by
location /wp-cron.php { add_header Cache-Control "no-cache, no-store, must-revalidate, max-age=0"; expires -1; }, but if it works fine without any modification on the.nginxyou can ignore that advice.Hello,
If you are using only the Disk Cache, it helps only on serving the web page faster. It is unrelated to concurrent visitors since even if we increase the response speed, the traffic can be way too high if it is the case.
If your website is completely static, it might be worth integrating Cloudflare as a proxy since they will cache most of your resources and serve them from their servers without users hitting your server.
- This reply was modified 4 months, 1 week ago by Robert Soare.
In the Browser Console, what errors do you see? And if it is possible to send a screenshot and link for a manual check.
Also, the plugin might be not aware of all Elementor cases of save. Our automatic purge cache is linked to WordPress native hooks for saving posts and pages. Anything else might need a manual purge.
Also, if you can, you can also post the settings via Export Settings (sensitive data will not included) – it will be a .json file to which you can copy the content and paste it here.
Cache Lifespan (seconds)you can can also set it under 12 hours. This one determine how much it can keep the saved HTML file on the disk (it does not affect Cloudflare).Hello,
We confirmed the bug and a report has been send to the developers.
Thank your for reporting this!
Hello,
One thing you can try is to set
Cache-Control max-age(onAdvanced > Cache Lifetime Settings) to value lower than or equal to 12 hours (like 43200). For e-commerce sites, the default value of 1 year might be too much since the website has a lot of dynamic content along with CSS snippets via WPCode.The Disk Cache save a copy of the HTML page on the disk, thus any change might not be immediately reflected. With a lower cache age, the cache will refresh more often.
Do I keep it to related pages only or should Purge whole cache be enabled too?
You should keep them both.
Glad to hear that the problem was solved.
Incidentally, I see nothing in the Page Rules section about any deprecation, which is very unusual for CF when they’re deprecating something.
The deprecation that I was talking was this (in case of the old users): https://developers.cloudflare.com/rules/reference/page-rules-migration/