FAQs

Make sure you are getting the page from the webserver (rather than from your browser cache) by emptying your browser cache and reloading the page. Do this whilst logged out (because the default setting is not to serve cached pages for logged-in users, since logged-in users usually want live content). Then, use the “View Source” function in your web browser to view the page source. Scroll down to the bottom, and you should see a line added by the cache:

However, note that if you are using a further service that minifies HTML (e.g. Cloudflare), then this line may have been removed. Another method is to inspect the contents of the directory wpo-cache inside your wp-content directory.

If your page is not being served from the cache, and you want to find out why not, then firstly – are you sure it is not being so served? As just mentioned, minification will remove HTML comments, like the line above. If you are sure, then you should edit your wp-config.php file, and change the WP_DEBUG setting to true, like so:

define('WP_DEBUG', true);

Then, reload the page, and view the HTML source. The reason will be given at the bottom – if it is not being removed by minification. If you need to first turn off minification, then do so.

No. It’s necessary to have pretty permalinks of the type http://xxxxx.com/my-post/ rather than http://xxxxx.com/?p=1234. Pretty permalinks are the WordPress default setting, and there is no good reason to turn them off, so you should not have a problem with this.

Note that permalinks including /index.php/ are cacheable. It is only those based upon query parameters (?…) that are not.

Full cache purge:

• When changing/updating current themes and parent themes (of child themes)
• When changing/updating current plugins
• When turning off the cache feature in WP-Optimize
• When editing widgets
• When saving the customizer settings
• When updating a menu
• When Autoptimize purges its cache
• When updating permalink structure
• When changing cache settings
• When updating string translations in WPML plugin
• When updating the ‘posts_per_page’ option
• When purging Avada theme’s fusion caches
• When saving any of GetWooPlugins’ settings (Premium)

This can be changed by hooking into the filter wpo_purge_cache_hooks. E.g.

// Add a new action that will trigger a cache purge
add_filter( 'wpo_purge_cache_hooks', function( $actions ) {
    $actions[] = 'my_custom_action';
    return $actions;
} );

Partial cache purge:

• When you publish new content or update/edit existing content, the cache for that post/page will be cleared, as well as associated content (category archives, blog archives)
• When comments are approved, or their status changes
• When terms are created or updated
• When changing/updating stock quantity of WooCommerce product or product variation
• When updating the ‘page_on_front’ option
• When updating ‘page_for_posts’ option
• When updating the ‘URLs to exclude from caching’ WP-Optimize caching configuration
• When trashing a post
• When running importers
• When WooCommerce product is on sale (Premium)

Yes, it is compatible with Gutenberg, the new content editor in WordPress 5.0+.

WP-Optimize is compatible with all web servers, including:

• Apache
• NGINX
• Microsoft IIS
• Litespeed
• Lighttpd

However, only Apache makes it possible for a WordPress plugin to turn on Gzip compression and static caching headers; thus, on other webservers, WP-Optimize can only test and advise whether these beneficial features are active, but cannot itself turn them on.

Add /.+ to the setting “URLs to exclude from cache” on the cache  “Advanced settings” tab.

No, WP dashboard pages are not cached. These usually contain unique content each time they are generated and it is not desirable to show dated content. You may however notice faster loads because the overall load on the site has reduced.

If you cannot see the admin bar on the front-end after enabling cache, you should disable the WP logged-in users cache option.

To use all features in the plugin, a minimum of version WordPress 4 with PHP 5.3 is required.

Go to WP-Optimize -> Cache and enable caching

You’re good to go!

If you run an e-commerce, have a custom login page or any page that has dynamic content, you might want to exclude certain urls from the cache. See Excluding an url from the cache for more details.

Yes. You cannot use two page caches at the same time, and should not try. However, the WP-O page cache will only be switched on if you choose to turn it on; otherwise, it will have no effect on the site (either cacheing or performance). It is not turned on by default. Thus, WP-O can happily co-exist with other plugins.

(N.B. Also, because of how page cacheing works in WordPress, it is not possible to have more than one turned on at the same time; they might both think they’re turned on, but in effect, only the most recently turned-on will be doing anything).

The plugin uses PHP functionality to write to files, it cannot write or modify files it will give you a warning. Typically, you should tell your web host about the permission issue and they should be able to resolve it.

You can however try adding define(‘FS_METHOD’, ‘direct’); to wp-config.php to circumvent the file and folder checks. See this for more information of setting up file and folder permissions for WP

Changing File Permissions

• If a theme or its files use the call php_flush() or function flush() that will interfere with cache, making the plugin send cached files before essential operations have finished. The flush() call is no longer necessary and should be removed.
• Some hosting providers, such as GoDaddy or wordpress.com, provide their own caching solutions. This will often interfere with WP-Optimize’s cache, and could result in those garbage characters.
• Using other speed plugins that force GZIP output can result in this issue. One example is the GZIP compression feature in the plugin “Far Future Expiry Header”, or the setting “enable compression” in the plugin PageSpeed Ninja, which are not compatible with WP-Optimize.

To find out if this is the issue, you can search the code for ob_gzhandler or gzencode. If any of those two strings is found (outside of WP-Optimize), it could be the source of the issue.

When a user visits your website a call is made to your server to deliver the requested content. Gzip compresses your webpages and style sheets before sending them over to the browser. This drastically reduces transfer time since the files are much smaller.

Gzip compression is really effective because CSS files and HTML files use a lot of repeated text and have plenty of whitespace. Since Gzip compresses common strings, this can reduce the size of pages and style sheets by up to 90%.

For a detailed walk-through on how to use the WP-Optimize caching feature, we put together a video that takes you through all the necessary steps:

WordPress uses nonces as security tokens which are printed in the source code of the page. These nonces cannot be reused and are valid for 12 hours by default, but developers can change that value. The nonce getting invalidated can affect all kinds of functionality on the site like form validation or the visual appearance of a page among others.

Setting a cache lifespan to under 10 hours ensures the cache is flushed automatically once the nonce expires. This way you can use WPO cache on sites which use nonces.

The cache lifespan option is set to 10 hours by default, but you may have go down to 8 or even less. A lower cache lifespan value will result in more frequent cache update activity on your server, and thus more preload processes, if activated. If you notice any issues due to high server load, set a higher interval for the preloader.

Yes! No special configuration is needed. Page cacheing on the WP site (that done by WP-Optimize) is independent of proxy cacheing (e.g. Cloudflare) – you can use both, or neither, and they will complement eachother and not interfere.

Just one thing to note – Cloudflare will strip out the special HTML comment at the bottom of the source of a page that is helpful to confirm that page cacheing is working, so, don’t be confused by that – it’s absence doesn’t indicate it’s not working.

User specific cache is specifically built for your membership site, or any type of site where pages contain user specific content.

Enabling “User specific cache” will create a cache version for each logged-in user, resulting in great performance for your website members.

Note that if you have many users, this could result in a large amount of files.

The website will also be cached for non logged-in users.

Note that the cache preloader will only preload the cache for non logged-in users.

NB: User specific cache is a premium feature

You can use the `wpo_cache_cookies` filter to generate separate cache files. For example, you may want to generate separate cache files for different currencies. You can modify and use the following code snippet to do so:

<?php
add_filter('wpo_cache_cookies', 'myprefix_add_cache_cookies', 20, 2);

function myprefix_add_cache_cookies($cookies) {
if (// Check if some feature exists that needs separate cache) {
$cookie[] = 'cache_key_that_needs_separate_cache';
}
return $cookies;
}

Static content is any content that can be delivered to an end user without having to be generated, modified, or processed. The server delivers the same file to each user, making static content one of the simplest types to cache and transmit over the Internet.

You can tell the browser to reuse a locally cached copy of these static files instead of requesting them from your server each time the page loads. Also if the file changes however the modified time on it changes and the browser is forced to fetch a fresh copy. This will not only save valuable bandwidth but also ensure a faster load time your visitors.

You can set the time for which these files are valid using the static file cache option in WPO. It is set to 28 days by default. Do note that this will work only if the user has a copy of the static file stored in the browser from an earlier visit to your site.

If you activate 2 caching plugins (or at least the functionality) at the same time, this might cause a fatal error and break your site.

Follow these instructions to recover your site:

• Connect to your server via FTP (or an other way if you prefer).
• Browse to the root of the WordPress installation, where you should have a file named wp-config.php.
• Download this file and open it in a text editor, such as notepad (Windows) or textedit (Mac).
• Locate the line define('WP_CACHE', true);, delete it, save the file and upload it back via FTP.
• Then still via FTP, enter the folder wp-content and delete the file advanced-cache.php
• You should now be able to reconnect to your administration.
• Go to one or all of your caching plugins settings, and only keep 1 activated.

If the error comes back before you had a chance to do this:

• Try the first part again, and before going to the admin, do the following:
• Using FTP, browse to the folder wp-content/plugins, and rename the folders of all caching plugins (for example by adding a -).
• Then go to Plugins in your administration, and make sure the cache plugins are deactivated.
• Using FTP, browse to the folder wp-content/plugins, and rename the folders of all caching plugins back to their original names.
• You can now reactivate the caching plugin of your choice.

If you want to check what cache file is being used for displaying a page, then you should edit your wp-config.php file, change the WP_DEBUG setting and the WPO_CACHE_FILENAME_DEBUG to true

define(‘WP_DEBUG’, true);
define(‘WPO_CACHE_FILENAME_DEBUG’, true);

Then, purge the cache, reload the page and view the HTML source. Scroll down to the bottom, and you should see a line added by the cache:

<!-- Cached by WP-Optimize (gzip) - https://getwpo.com - Last modified: Wed, 01 Dec 2021 10:47:38 GMT --><!-- WP Optimize page cache debug information -->
<!-- 
Extension: .html
Filename: index.html
 --->

Users should use a cookie consent plugin which doesn’t generate different pages based on cookie consent. Regardless of the consent state, the generated page should be the same and the consent state should be managed by JavaScript.

One such plugin we can recommend that uses the above suggested method is the CookieYes plugin:

https://wordpress.org/plugins/cookie-law-info/