Transient Cleaner vs SQLite Cache

Clean expired transients from your options table. The original and best! Transient housekeeping was added to the core of WordPress after version 5.8. However, I have decided to open up this plugin to all versions to allow for manual transient cleaning. Longer term I am working on a new version of the plugin, designed specifically for all WordPress releases. Tested up to PHP 8.2 Fully complies with WordPress coding standards Compliant with the stronger WordPress VIP coding standards, as well as compatibility with their platform Community plugin – visit the Github page to get involved with the latest code development, request enhancements and report issues “Transients are a simple and standardized way of storing cached data in the WordPress database temporarily by giving it a custom name and a timeframe after which it will expire and be deleted.” Unfortunately, expired transients only get deleted when you attempt to access them. If you don’t access the transient then, even though it’s expired, WordPress will not remove it. This is a known “issue” but due to reasons, which are explained in the FAQ, this has not been adequately resolved. Why is this a problem? Transients are often used by plugins to “cache” data (my own plugins included). Because of this it means that expired data can be left and build up, resulting in a bloated database table. Meantime, this plugin is the hero that you’ve been waiting for. Simply activate the plugin, sit back and enjoy a much cleaner, smaller options table. It also adds the additional recommendation that after a database upgrade all transients will be cleared down. The Settings Screen Within Administration -> Tools -> Transients an options screen exists allowing you to tweak when you’d like cleaning to happen, including the ability to perform an ad-hoc run, and when you’d like the to be automatically scheduled. You can even request an optimization of the options table to give your system a real “pep”! Running in Lite mode A “lite” mode is available. By activating this the options screen will no longer appear and default settings will be used. The advantage? Improved performance to Admin and, especially if you’re running multi-site, no chance of anybody “tinkering” with the settings. To activate, use the following… define( 'TC_LITE', true ); This should be added to your wp-config.php file. Using hooks If you’re the type of odd person who likes to code for WordPress (really?) then I’ve added a couple of hooks so you can call our rather neat cleaning functions… housekeep_transients – this will clear down any expired transients clear_all_transients – this will remove any and all transients, expired or otherwise Acknowledgements I’d like to thank WordPress Developer Andrew Nacin for his early discussion on this. Also, I’d like to acknowledge the useful article at Everybody Staze for ensuring the proposed solution made sense, and W-Shadow.com for the cleaning code. Iconography is courtesy of the very talented Janki Rathod.

On first request to a given URL whole html code of a page is being stored in the SQLite database. On next requests to the same page WordPress core will not be loaded at all but the content of a page will be retrieved from the the SQLite storage therefore duration of PHP execution decreases in dozen of times. Many sites on the same webserver may use common SQLite storage. Compatible with WordPress Multisite. Requires PHP SQLite PDO. In comparison with plugins generating static html pages this plugin does not create multiple directories and html files but stores all generated pages in one file. Moreover, many wordpress sites on the same webserver may use common SQLite storage. Keeps 404, 301, 302, 304 HTTP statuses, optionally supports ETag, Expires, Content-Length, Content-Type (with charset) headers. As the cache script doesn’t load the WordPress core where does it save it’s settings? To get the plugin working you need to define the SQLite storage location in the index.php of the wordpress installation directory (note, not in wp-config.php but index.php). Besides of the SQLite file, this directory contains general settings file (compression setting) and a subfolder for per domain settings. In the admin area (plugin setting page) and to remember after deactivation where the cache located, litecache_path WordPress option is used. How the plugin handles URLs with and without `www.` prefix? The presence of www. prefix is defined in Settings – General. The plugin stores with_www parameter in domains/yourdomain.ini file in the cache directory and redirects requests correspondingly; these redirects are being processed before cache usage. Is it WordPress Multisite compatible? Yes, but for subdomains mode only (blogname.example.com), not for example.com/blogname. A superadmin of a multisite network has access to the first setting form (cache location), blog admins have access to the second form and purge form.