Clears the page cache on your own server first, then the copy Cloudflare holds at the edge. One\nplugin, one list of URLs, so the two cannot disagree about what was cleared.<\/p>\n\n
The plugin talks to one outside service, the Cloudflare API. It clears the copy of your pages\nCloudflare holds at the edge, and, if you run the wizard's optional steps, reads and writes the\ncaching configuration of your own zone. Nothing else leaves your server: no update checker, no\nlicence check, no analytics.<\/p>\n\n
Only contacted once you have configured a Cloudflare API token. Without one the plugin refuses\nthe request before anything leaves your server.<\/p>\n\n
What it sends, and when:<\/p>\n\n
It never sends visitor data, personal data or post content.<\/p>\n\n
Once a week WP-Cron fetches Cloudflare's published list of its own IP ranges. The plugin checks\nthat list to confirm a request really arrived through Cloudflare before it trusts the visitor\naddress in the CF-Connecting-IP header. The fetch carries no authentication and nothing about\nyour site beyond the user agent WordPress puts on any HTTP request. Until it first succeeds, the\nplugin falls back to a copy of the list shipped with it.<\/p>\n\n
This one runs whenever the plugin is active, including on sites that never configured Cloudflare.<\/p>\n\n
Cloudflare, Inc. provides the service. Their terms and privacy policy:<\/p>\n\n
The plugin's other network requests never leave your own infrastructure and involve no third\nparty: clearing NGINX through ngx_cache_purge, reading your sitemap index, warming pages with the\npreloader, and reaching the Redis server whose address you configure yourself.<\/p>\n\n
One custom table, Licensed GPL-3.0-or-later, because it derives from two GPL projects and one of them is GPLv3.<\/p>\n\n Nginx Helper by rtCamp, GPL-2.0-or-later, https:\/\/github.com\/rtCamp\/nginx-helper. Source of the\napproach to clearing a local page cache: the nginx cache file path derivation, the ngx_cache_purge\nalternative, the Redis key shape, and which WordPress events invalidate which URLs.<\/p>\n\n App for Cloudflare by Digital Point, GPL-3.0, https:\/\/wordpress.org\/plugins\/app-for-cf\/. Source of\nthe approach to Cloudflare: the API client, resolving a zone from the hostname, the URLs a post\nchange invalidates, the guest-HTML cache rule and its s-maxage header, the static-content\nextension list, and the recommended zone settings.<\/p>\n\n Both were reimplemented rather than copied. No code from App for Cloudflare Pro was used; it is\nproprietary, and has no cache clearing logic in any case. Nothing third party is bundled.<\/p>\n\n\n Add this to or set Queued retries need something to run them:<\/p>\n\n Without a cron entry, anything that falls back to the queue never runs. The dashboard warns you\nwhen that happens.<\/p>\n\n\n Only if you turn the Redis driver on. It needs phpredis 6.0 or newer and does not bundle a\npure-PHP replacement. When phpredis is missing, the driver says so instead of failing quietly.<\/p><\/dd>\n Up to about a minute. WordPress will not spawn cron more than once every 60 seconds, so a queued\njob is never instant. Local cache clearing always runs immediately for that reason; only\nCloudflare gets deferred.<\/p><\/dd>\n Whichever your site publishes. Core, Yoast SEO, Rank Math, All in One SEO and SEOPress are\ndetected, and the index is read twice a day for the file names, so a news sitemap, a taxonomy one\nor page two of a paginated one need no configuring. Editing a post clears its post type's files,\nits taxonomies, the author file and the news sitemap, and leaves the other types alone.<\/p>\n\n The dashboard lists what was found. For anything undetected, put its index URL in the paths field\nunder When to purge, or use the Yes. WooCommerce writes stock, prices and variations straight to the database without saving the\npost, so the plugin listens to WooCommerce's own hooks: a price change or the last item selling\nout clears the product page, the shop page and the category archives.<\/p>\n\n The cart, checkout and account pages never reach the edge, and neither do cart fragments. Twice\nover: the origin refuses to mark them cacheable, and the Cloudflare rule excludes their paths,\ntaken from your store's settings rather than the English defaults.<\/p><\/dd>\n Only once clearing demonstrably works, which is why the wizard refuses a non-zero edge TTL until\na test purge has actually succeeded. Pages held at the edge while clearing is broken stay stale\nfor the whole TTL, and a visitor cannot get past them.<\/p><\/dd>\n\n<\/dl>\n\n\n{prefix}oh_my_cache_jobs<\/code>, holds the queue of jobs waiting to run or retry.\nSettings live in the options table. WP-Cron runs the queue and cleans it up; the jobs that refresh\nthe sitemap list and the Cloudflare IP ranges are scheduled only while the features that need them\nare on, and removed when you switch them off. Turning on \"delete data on uninstall\" removes all of\nit when you delete the plugin. Leave it off and nothing is removed, so deactivating to debug a\nconflict does not cost you your configuration.<\/p>\n\nCredits<\/h3>\n\n
\n
Keeping your Cloudflare token out of the database<\/h4>\n\n
wp-config.php<\/code>:<\/p>\n\ndefine( 'OH_MY_CACHE_CF_API_TOKEN', 'your-token' );\n<\/code><\/pre>\n\nOH_MY_CACHE_CF_API_TOKEN<\/code> in the environment. The token is then never written to the\ndatabase, so it stays out of backups and staging copies, and the settings screen stops offering\na field for it.<\/p>\n\nIf DISABLE_WP_CRON is set<\/h4>\n\n
* * * * * wp oh-my-cache queue run --all --quiet\n<\/code><\/pre>\n\n\n
Does it need the Redis extension?<\/h3><\/dt>\n
How long can a queued purge take?<\/h3><\/dt>\n
Which sitemaps does it clear?<\/h3><\/dt>\n
oh_my_cache_sitemap_urls<\/code> filter.<\/p><\/dd>\nDoes it work with WooCommerce?<\/h3><\/dt>\n
Is it safe to cache HTML at the edge?<\/h3><\/dt>\n
1.0.0<\/h4>\n\n
\n