Naibabiji Cache Purger for EdgeOne vs SQLite Object Cache

A powerful WordPress plugin that automatically purges Tencent Cloud EdgeOne cache when your posts, pages, or custom post types are published, updated, or deleted. External services This plugin connects to the Tencent Cloud EdgeOne API (https://teo.tencentcloudapi.com) to provide cache purging and prefetching functionality. It sends the Following information to Tencent Cloud when a purge or prefetch operation is triggered (e.g., when a post is updated, or when manual purge is used): * Tencent Cloud API Credentials (SecretId): Used for request authentication and signing. * EdgeOne Zone ID: Used to identify the specific site/zone in EdgeOne. * Target URLs or Paths: The specific resources that need to be cleared or prefetched from the CDN nodes. This service is provided by “Tencent Cloud”: Terms of Service, Privacy Policy. Features Automatic Cache Purge Automatically purges cache when posts are published, updated, or deleted Supports all public post types (posts, pages, and custom post types) Smart purge: automatically refreshes post pages, homepage, category archives, tag archives, author archives, and date archives Comment Integration Automatically purges related post cache when new comments are approved Manual Purge Support for manual purge of specific posts or entire site Quick purge buttons in admin panel for recent posts Flexible Configuration Choose purge method: delete cache (delete) or mark as expired (invalidate) Optional logging of purge operations Secure key configuration via wp-config.php constants Cache Plugin Integration Automatically purges EdgeOne cache when popular WordPress cache plugins clear their cache Supports WP Super Cache, W3 Total Cache, WP Rocket, and LiteSpeed Cache Force mode ensures cache plugin integrations work even when auto purge is disabled Proper timing control ensures compatibility with all cache plugin loading sequences Cache Prefetching Optional cache prefetching after purging (disabled by default) Only prefetches post URLs, not archive pages to conserve EdgeOne prefetch quota Ensures first visitor gets cached content immediately Prefetch results are displayed in the purge logs for easy monitoring Enhanced Logging Detailed logging of all purge operations with success/failure status Manual log clearing functionality for easier debugging Prefetch operation results displayed alongside purge results Job IDs and error messages for easy troubleshooting Advanced Manual Purge Optimized host-specific “Purge All” using the purge_host method Manual purge operations are not affected by auto purge settings Force mode support for cache plugin integrations Comprehensive URL coverage for post-related purges Custom URL Purge Purge cache for specific URLs (CSS, JS, images, etc.) Support for directory prefix purge using trailing slash (/) Batch processing: enter multiple URLs, one per line Automatic URL validation and filtering Smart type detection: files use purge_url, directories use purge_prefix Nginx Cache Integration Optionally clear Nginx server-side page cache (FastCGI cache or Proxy cache) alongside EdgeOne CDN cache Configured separately — most sites using only WordPress cache plugins do not need this Nginx cache and EdgeOne cache are cleared independently; either can succeed even if the other fails Includes path validation with real-time feedback in the settings page Uses ngx_cache_purge module for precise URL-based cache clearing (faster and more efficient) Added “Purge Endpoint Path” option for customizable Nginx purge URL path (e.g., use a random string like /xK9mPurge_q7z for better security) Uses HTTPS requests to your site’s own domain for purge, avoiding HTTP-to-HTTPS redirect issues Friendly error messages in purge logs: clearly explains why a URL wasn’t cached (e.g., “Not cached — the page was returned instead of a purge response”) instead of showing raw HTML Fallback to file deletion for full-site purge operations Detailed per-URL purge logging for Nginx cache operations No SDK Required Direct API calls, no need to install Tencent Cloud SDK Compatible with all WordPress versions 5.5+ Configuration Get Tencent Cloud API Keys Visit Tencent Cloud Console Create or get your SecretId and SecretKey Get EdgeOne Zone ID Visit EdgeOne Console Select your site and find the Zone ID (format: zone-xxxxxx) Configure Plugin There are two configuration methods: Method 1: Using wp-config.php (Recommended) Add these constants to your WordPress wp-config.php file: define( 'NB_CACHE_PURGER_SECRET_ID', 'your-secret-id' ); define( 'NB_CACHE_PURGER_SECRET_KEY', 'your-secret-key' ); Then in WordPress admin: 1. Go to “Settings” → “Naibabiji Cache Purger” 2. Fill in the Zone ID (Secret ID and Secret Key will be automatically loaded from constants) 3. Choose other options and save Method 2: Direct Configuration in Admin Log in to WordPress admin Go to “Settings” → “Naibabiji Cache Purger” Fill in the following information: Secret ID: Tencent Cloud API Secret ID Secret Key: Tencent Cloud API Secret Key Zone ID: EdgeOne Zone ID Choose other options: Enable Auto Purge: Whether to automatically purge cache when posts are updated Purge Method: delete: Directly delete node cache invalidate: Mark as expired, revalidate from origin Enable Logging: Whether to log purge operations Nginx Cache Integration (Optional) Only needed if your server uses Nginx FastCGI cache or Proxy cache (configured via fastcgi_cache_path or proxy_cache_path in nginx.conf). Most sites using WordPress cache plugins do not need this. In “Settings” → “Naibabiji Cache Purger” → scroll to the Nginx Cache Integration section at the bottom Check Enable Nginx Cache Purge Set a Purge Endpoint Path — we recommend using a random string (e.g., /xK9mPurge_q7z) for security, so you can use allow all; in Nginx without exposing the endpoint to attackers Enter the absolute filesystem path to your Nginx cache zone directory (e.g. /var/run/nginx-cache) — this is only used as fallback when purging the entire site The web server process (e.g. www-data) must have write permission to this directory The settings page will validate the path and show whether it is writable Save settings — Nginx cache will now be cleared automatically every time EdgeOne cache is purged Nginx Purge Configuration To use the ngx_cache_purge module integration, you need to configure your Nginx server block with the appropriate purge rules. Replace /xK9mPurge_q7z with your custom purge path: nginx location ~ /xK9mPurge_q7z(/.*) { allow all; deny none; fastcgi_cache_purge YOUR_CACHE_ZONE "https$request_method$host$1"; # Or for proxy cache: # proxy_cache_purge YOUR_CACHE_ZONE "https$request_method$host$1"; } Replace YOUR_CACHE_ZONE with the name of your Nginx cache zone (e.g., wordpress). Important notes: * The fastcgi_cache_purge key ("https$request_method$host$1") must match your fastcgi_cache_key directive exactly, including the https prefix * If you are using BT Panel (宝塔) with an HTTP-to-HTTPS redirect rule, the plugin sends HTTPS requests to your own domain, so no additional exclusion rules are needed * For detailed configuration instructions, see the configuration tutorial

A persistent object cache helps your site perform well. This one uses the widely available SQLite3 extension, and optionally the igbinary and APCu extensions to php. Many hosting services offer those extensions, and they are easy to install on a server you control. What is this about? It’s about making your site’s web server perform better. An object cache does that by reducing the workload on your MariaDB or MySQL database. This is not a page cache; these persistent objects go into a different kind of cache. These objects aren’t chunks of web pages ready for people to view in their browsers, they are data objects for use by the WordPress software. Caches are ubiquitous in computing, and WordPress has its own caching subsystem. Caches contain short-term copies of the results of expensive database lookups or computations, and allow software to use the copy rather than repeating the expensive operation. This plugin (like other object-caching plugins) extends WordPress’s caching subsystem to save those short-term copies from page view to page view. WordPress’s cache happens to be a memoization cache. Without a persistent object cache, every WordPress page view must use your MariaDB or MySQL database server to retrieve everything about your site. When a user requests a page, WordPress starts from scratch and loads everything it needs from your database server. Only then can it deliver content to your user. With a persistent object cache, WordPress immediately loads much of the information it needs. This lightens the load on your database server and delivers content to your users faster. Who should use this? If your site runs on a single web server machine, and that server provides the SQLite3 and igbinary extensions to php, this plugin will almost certainly make your site work faster. And if that server provides the APCu extension, this plugin uses it too. Some hosting providers offer redis cache servers. If your provider offers redis, it may be a good choice. You can use it via the Redis Object Cache plugin. Sites using redis have one SQL database and another non-SQL storage server: redis. Other hosting providers offer memcached, which has the Memcached Object Cache plugin. And some large multipurpose cache plugins, such as the LiteSpeed Cache, also offer object caching based on one of those cache server software packages. The cache-server approach to object caching comes into its own when you have multiple load-balanced web server machines handling your site. SQLite doesn’t work correctly in a multiple-web-server environment. But, for single-server site configurations, SQLite, possibly assisted by APCu, performs well. And the vast majority of sites are single-server. APCu APCu is an in-memory storage medium. It lets php programs, like WordPress, store data in shared memory so it’s very fast to retrieve when needed. If APCu is available on your host server, you can configure this plugin to use it. It reduces the typical cache lookup time to one-fifth or less of the SQLite lookup time, which is itself a few tens of microseconds. Performance counts, especially on busy web sites. Please look at Installation to learn how to configure this plugin to use APCu. The plugin works fast without it, and faster with it. WP-CLI: Even if APCu is in use, caching with SQLite is necessary when your web site uses WP-CLI, because WP-CLI programs do not have access to the APCu cache. This plugin writes all cached data both to APCu and to SQLite and makes sure the two are synchronized. WP-CLI You can control this plugin via WP-CLI once you activate it. Please type this command into your shell for details. wp help sqlite-object-cache Credits Thanks to Till Krüss. His Redis Object Cache plugin serves as a model for this one. And thanks to Ari Stathopoulos and Jonny Harris for reviewing this. Props to Matt Jones for finding and fixing a bug that appeared on a heavily loaded system. Thanks to Massimo Villa for testing help, and to nickchomey for a comprehensive code review. All defects are, of course, entirely the author’s responsibility. And thanks to Jetbrains for the use of their software development tools, especially PhpStorm. It’s hard to imagine how a plugin like this one could be developed without PhpStorm’s tools for exploring epic code bases like WordPress’s. How can I learn more about making my WordPress site more efficient? We offer several plugins to help with your site’s database efficiency. You can read about them here.