Speed up your site (BIG time!) — Quick Cache provides reliable page caching for WordPress. Easy-to-use (very simple installation).
?qcAC=0to disable caching when you ARE caching GET Requests. See also: #210.
WP_CONTENT_DIRis now obeyed in the scenario where it's set to a path outside of
ABSPATH. See also: #95
WP_CONTENT_DIRin the "Directory/Expiration Time" options panel. See also: #206
QUICK_CACHE_PROconstant to false. See also: #229
redirect_canonical()bug workaround. See also: #209
character whitespace during CSS compression. See also: #25
http/example-com/sample-page.html). For more details, please see https://github.com/WebSharks/Quick-Cache/wiki/Branched-Cache-Structure
ob_start(). See https://github.com/WebSharks/Quick-Cache/issues/97
status_headerso that Quick Cache can properly detect calls to the WP core function
wp-content/cache/quick-cache/to provide better organization of cache files and avoid interfering with another plugin that may also be writing to the
wp-content/cache/directory. See https://github.com/WebSharks/Quick-Cache/issues/123
WP_CONTENT_URLconstants to point somewhere other than the default, Quick Cache will now obey those and use your custom directory for storing cache files. See https://github.com/WebSharks/Quick-Cache/issues/95
draftwould trigger the Auto-Purge Post routine and clear the cache for that post. Now only purges post status
privateand when transitioning from
privatepost status to
private. See https://github.com/WebSharks/Quick-Cache/issues/43
xmlrpcfile. These are now properly auto-excluded. On Multisite installations,
/files/is also auto-excluded from being cached. This bug required fixing incorrect instances of
[?$]in regex patterns. See: https://github.com/WebSharks/Quick-Cache/issues/41
wp_set_comment_statusto purge the comment cache when a comment status changes.
set_time_limit()errors in case function is disabled in PHP configuration. This is a temporary fix and will be handled more appropriately in a future maintenance release. See also: https://github.com/WebSharks/Quick-Cache/issues/20
advanced-cache.phplevel (e.g. very early-on). For further details on this, please check your Dashboard under:
Quick Cache -› Theme/Plugin Developers. See also: https://github.com/WebSharks/Quick-Cache/issues/17
.htaccessfile from the
/wp-content/plugins/quick-cache/directory that prevented directory indexing, as this is not compatible in all hosting environents. See: https://github.com/WebSharks/Quick-Cache/issues/9
/wp-config.phpfile on sites that move this file up one directory. Fixed in this release. See: https://github.com/WebSharks/Quick-Cache/issues/7
/wp-config.phpfile may become corrupted upon deactivation of the Quick Cache plugin through the WP Dashboard. Fixed in this release. See: https://github.com/WebSharks/Quick-Cache/issues/6
reamde.txtfile regarding "what to do in an emergency scenario".
HTTPSevironment variable in order to prevent cache collisions on sites that serve pages over SSL. Nothing to configure, this is now built into the Quick Cache engine.
ob_gzhandler(); and the like. Quick Cache will now throw PHP exceptions to warn you about this should it be an issue in your hosting environment. If you want to enable GZIP, please follow the instructions provided by Quick Cache and avoid the use of
ob_gzhandler()as this is not a recommended way to enable GZIP on any hosting platform.
__function and a new text domain was added:
quick-cache. PO translation files should be placed in your plugins directory, example:
/wp-content/plugins/quick-cache-en_US.mo; or in
activate_plugins. This is a default Capability that comes with the Administrator Role in WordPress. So, unless you've modified your WordPress Roles/Capabilities in some extremely creative way, this should not impact you; just something to be aware of.
$_SERVER["REQUEST_URI"]inside the comment lines that Quick Cache introduces at the bottom of the source code.
yymmdd. The version for this release is:
is_user_logged_in()in the second phase of
advanced-cache.phphave been resolved in this release of Quick Cache.
header.phpfile, or in other places that may create a problem in the nesting order of output buffers. For instance, this release of Quick Cache resolves some incompatiblities with Headway themes for WordPress®. Please note that GZIP should be enabled at the Apache level ( i.e. with an .htaccess file ), or in PHP using
zlib.output_compression = on. Both of these methods are preferred over
ob_start("ob_gzhandler"). If you must use
ob_start("ob_gzhandler"), please make this declaration inside your
/wp-config.phpfile, and NOT inside
/header.php, as this creates a problem that Quick Cache must work around, and could ultimately prevent GZIP from working at all if you do it this way. For further details on how to enable GZIP with Quick Cache, please see the included
dirname()that were processed by the Quick Cache
/advanced-cache.phphandler should have been using
WP_CONTENT_DIRfor improved compatibility with WordPress® installations that may use non-standardized installation directories and/or symlinks.
add_filter("ws_plugin__qcache_ms_user_can_see_admin_header_controls", "__return_true");. This button is always visible to Super Admins. Adding this Filter makes it visible to all child Blog Owners as well.
5xxerror code. Quick Cache is now capable of disabling the cache engine dynamically on all database connection failures within WordPress®.
5xxerror codes. Quick Cache now monitors the
5xxerror codes. If a
5xxstatus header is detected, caching is automatically disabled, as it should be.
glob()has been added to Quick Cache. In previous versions, it was impossible to pinpoint a specific cache file through Dynamic Pruning routines ( at least, not with 100% accuracy ). This was because an MD5 Version Salt could have been generated; based on arbitrary conditionals, set by the site owner. Quick Cache now stores its cache files with three MD5 hash strings, producing longer file names; but with the added benefit of improved Multisite compatibility, and improvements in optimization overall. Quick Cache can now handle dynamic pruning with 100% accuracy. Even supporting complex Multisite installations, with or without
Clear Quick Cachebutton into the WordPress® Dashboard. This makes it easy to force a "cache reset, via
ajax", without having to navigate through the Quick Cache menu for this simple task. Another great benefit to this new button, is that it works in all Dashboard views, even in a Multisite installation across different backends. If you're running a Multisite installation, you can use this new button to clear the cache for a particular site/blog in your network, without interrupting others.
QUICK_CACHE_ALLOWEDwas being defined too early in the buffering routine. This has been resolved in v2.2.1.
advanced-cache.php. A few things have been streamlined even further.
Status: 503header, or a
$_SERVER["HTTP_HOST"]variable. Quick Cache is now capable of handling this gracefully.
$blog_id = 1in favor of
is_main_site(); providing support for Multisite Mode, where there are multiple sites, instead of just multiple blogs.
ws_plugin__qcache_curl_get(), have been replaced by
c_ws_plugin__qcache_utils_urls::remote(), which makes use of
wp_remote_request()through the WP_Http class. This removes an absolute dependency on the cURL extension for PHP. This also gives Quick Cache/WordPress® the ability to decide with method of communication to use for HTTP requests; based on what the installation server has available. Note: this only affects the Auto-Cache Engine for Quick Cache, which is completely optional.
wp-contentdirectory; Quick Cache can help with this, in a more intuitive fashion.
Single + Front Page. This makes it possible to Create or Edit a Post/Page, and have the cache automatically updated for that specific Post/Page. And.. in addition, your Front Page ( aka: Home Page ) will also be refreshed at the same time.
De-Activation Safeguardsto the Quick Cache options panel.
CGI/FastCGIimplementations. Quick Cache should work fine with any Apache/PHP combination. Please report all bugs through the Support Forum.
/files/being accessed through
htaccess/mod_rewrite. Quick Cache has been updated to exclude all
/files/served under WordPress® MU, which is the way it should be. Requests that contain
/files/are a reference to WordPress® Media, and there is no reason, to cache, or send no-cache headers, for Media. Quick Cache now ignores all references to
/files/under WordPress® MU. This problem was not affecting all installations of WPMU, because there already are/were scans in place for Content-Type headers. However, under some CGI/FastCGI implementations, this was not getting picked on WMPU with
mod_rewriterules. This has been resolved in v2.1.2.
HTTP_HOSTdetection under WordPress® MU installations that were using sub-domains. Please thank
QuickSanderfor reporting this important issue.
Content-Typeheaders through PHP routines. Quick Cache is now smart enough to automatically disable itself whenever a theme or plugin sends a
Content-Typeheader that would be incompatible with Quick Cache. In other words, any
Content-Typeheader that is not a variation of
HTML, XHTML or XML.
header()function in PHP ), those headers will be preserved. They'll be stored along with the cache. This allows them to be sent back to the browser whenever a cached version is served on subsequent visits to the original file.
quick-cache-mu.phpadded specifically for MU installations. WordPress® MU is a special ( multi-user ) version of WordPress®. If you're running WordPress® MU, check the [readme.txt] file for WordPress® MU notations.
flock()mutex. If you're on a Cloud Computing Model ( such as the Rackspace® Cloud ), then you'll want to go with flock() unless they tell you otherwise. In all other cases we recommend the use of Semaphores over Flock because it is generally more reliable. The folks over at Rackspace® have suggested the use of flock() because of the way their Cloud handles multi-threading. In either case, flock() will be fully functional in any hosting environment, so it makes a great fallback in case you experience any problems.
define("QUICK_CACHE_ALLOWED", false). We have also added backward compatibility for WP Super Cache, so that
define("DONOTCACHEPAGE", true)will also be supported by plugins that have previously been written for compatibility with Super Cache. In other words, Quick Cache looks for either of these two Constants.
Requires: 3.7 or higher
Compatible up to: 3.9.1
Last Updated: 2014-7-26
16 of 33 support threads in the last two months have been resolved.
Got something to say? Need help?