SQLite Cache
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.
