SQLite Object Cache

A persistent object cache helps your site perform well. This one uses the widely available SQLite3 extension to php. Many hosting services offer it. If your hosting service does not provide memcached or redis, you may be able to use this plugin instead and get the benefit of object caching. 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. 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. (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.

Installing "SQLite Object Cache" can be done either by searching for "SQLite Object Cache" via the "Plugins > Add New" screen in your WordPress dashboard, or by using the following steps:

1. Download the plugin via WordPress.org
2. Upload the ZIP file through the 'Plugins > Add New > Upload' screen in your WordPress dashboard
3. Activate the plugin through the 'Plugins' menu in WordPress

The plugin offers optional settings for your wp-config.php file. If you change them, deactivate the plugin first, then change them, then reactivate the plugin.

1. WP_SQLITE_OBJECT_CACHE_DB_FILE. This is the SQLite file pathname. The default is …/wp-content/.ht.object_cache.sqlite. Use this if you want to place the SQLite cache file outside your document root.
2. WP_SQLITE_OBJECT_CACHE_TIMEOUT. This is the SQLite timeout in milliseconds. Default: 5000.
3. WP_SQLITE_OBJECT_CACHE_JOURNAL_MODE This is the SQLite journal mode. Default: ‘WAL’. Possible values DELETE | TRUNCATE | PERSIST | MEMORY | WAL | WAL2 | NONE. (Not all SQLite3 implementations handle WAL2.)

1.3.8 Add some support for new SQLite WAL2 write-ahead logging. Support WordPress 6.5. 1.3.7 Bug fix: Not all versions of SQLite can do DELETE ... LIMIT, so do transaction-size-limited DELETEs a different way. 1.3.6

• Clean up in chunks in an attempt to reduce contention delays and timeouts.
• Do PRAGMA wal_checkpoint(RESTART) when cleaning up, and also occasionally, to prevent the write-ahead log from growing without bound on busy systems.
• Retry three times if cache updates time out.
• Increase default cache size to 16MiB for new users.

1.3.5

• php 8.1, php 8.2 compatibility.
• Support for WordFence and other code using the object cache after shutdown.

1.3.4

• Support SQLite Memory-Mapped I/O.
• Reduce contention delays by limiting the number of get_multiple, set_multiple, add_multiple, and delete_multiple items in each transaction.
• Reduce index page fragmentation by using key order for set_multiple and add_multiple operations.
• Fix initialization defect in cache deletion. Props to @gRoberts84.

1.3.2

• Avoid VACUUM except on cache flush, and do it only with maintenance mode enabled.