Some FAQs about WP Super Cache
Some FAQs about WP Super Cache
Belonging to the project: WordPress User Guide (for newbies)
The WP Super Cache plugin generates static html files from dynamic WordPress blogs. Once the html file is generated, the web server will use it instead of processing heavier and more expensive PHP (WordPress) scripts.
Static html files will be served to the majority of users:
- Users who are not logged in.
- Users who do not leave comments on the blog.
- Or users who don't see password protected posts ( password protected post ).
99% of website visitors will be served by static html files. A cache file can be used thousands of times. Other visitors may be served by a custom cache file designed specifically for them. If they log in or leave a comment, those details will be displayed and cached for them.
The plugin provides cache files in 3 ways (ranked by speed ranking):
- Expert . The fastest method is to use Apache's mod_rewrite (or whatever similar module your web server supports) to serve "supercached/superloaded" static html files. It completely surpasses PHP and is super fast. If your server is affected by traffic, this method is likely to deal with "lighter" queries. This requires the Apache mod_rewrite module (if you can use custom static links it's probably already installed) and some tweaks to the .htaccess file – but this requires Be careful because editing the .htaccess file risks making your site inaccessible if you fix it incorrectly.
- Simple . Static files generated by Supercache can be provided by PHP and this is how we recommend using this plugin. The plugin will serve the "super-static" file if it exists, and it's almost as fast as the mod_rewrite method. Configuration is also easier as there is no need to change the .htaccess file. You still need the custom permalink. You can keep sections of pages dynamically in this caching mode.
- WP-Cache style caching . This is mainly used to cache pages for known users, URLs with parameters and feeds. Known users are logged in users (logged in users), visitors who leave comments, or who need to display custom data based on the user. This is the most flexible and somewhat slow caching method. WP-Cache will also cache the page for users who are not logged in if hypercaching is disabled. You can also have dynamic sections for your page in this mode. This mode is always on, but you can disable caching for logged in users, parameterized URLs, or separate feeds. Set the “DISABLE_SUPERCACHE” constant to 1 in the wp-config.php file if you just want to use the WP-Cache method.
If you don't like editing PHP files then use the simple method. It is very easy to set up and also very quick.
- Use Simple caching.
- Compress pages.
- Do not cache the page for logged in users.
- Cache rebuild.
- CDN support.
- Expand the homepage test.
Garbage collection is the act of cleaning up old and outdated cache files. There is no exact value to set the expiry time but a good starting time is 1800 seconds.
Consider clearing the contents of the “Deny user agent” text box and let the machine look up the cache file for you.
Preload as many articles as possible by enabling “Preload mode”. Collection of old cache files will be disabled. If you don't mind the widget sidebars updating frequently, set the preload interval to 2880 minutes (2 days) so all your posts won't be cached too often . When preloading is enabled, the cache file for the article that is refreshing is deleted and then recreated. The garbage collector then collects all the old files to get rid of the old cache files. Even if preloading is enabled for a cache file, that cache file will be deleted when a post is edited or commented on.
Your cache directory will fill up over time, which will take up space on your server. If storage is limited or expensive, or if you are worried that the cache pages on your site will be too old, then garbage collection must be done. Garbage collection takes place regularly and deletes old files in the cache folder. In advanced settings you can specify:
- Cache timeout (cache expiration time). How often should the cache file be reviewed and refreshed? After this time, they are considered obsolete and can be deleted.
- Scheduler (scheduling). Set how often the garbage collector should be performed.
- Notification emails (notifications via email). You can be informed about the progress of garbage collection. There is no right or wrong setting for garbage collection. It depends on your website.
If your page is updated frequently or has comments, set the timeout to 1800 seconds and set the timer to 600 seconds.
If your page changes very rarely (mostly statically), you can disable garbage collection by entering 0 in the timeout field or using a very large timeout value.
The cache directory, usually wp-content/cache/, is just a place to store temporary files. Never put important files or important folders in this folder. They will be deleted if the plugin has write permission to them.
You now have the ability to engage (hook) in the caching process using the add_cacheaction() function.
There are 3 “hooks” available:
- “wp_cache_get_cookies_values” – edit the key used by WP Cache.
- “add_cacheaction” – runs in phase2. Allows the plugin to add WordPress hooks.
- “cache_admin_page” – runs in the admin page. Use it to edit that page, possibly by adding new configuration options.
There is also a regular WordPress filter. Use the “do_createsupercache” filter to customize the pre-caching check. The filter allows one parameter. Output of WP-Cache's wp_cache_get_cookies_values() function.
You can create cache files for posts, folders and tags for your website via preloading. Preload will visit each page on the site to create cached pages, just like any other visitor to the site. Due to the sequential nature of this function, it may take time for the preload to complete if your site has a lot of posts.
For more efficient preloading, it can be helpful to disable garbage collection so that older cache files are not deleted. That is done by enabling “Preload mode” in the settings. However, be aware that pages will eventually become obsolete, but updates by posting comments or editing posts will clear parts of the cache.
OSSDL CDN off-linker has been integrated into WP Super Cache to provide basic CDN support. It works by rewriting (rewriting) the URLs of the files (except .php files) in wp-content and wp-include in your server so that they point to a different hostname. Many CDNs support "origin pull". This means that the CDN will automatically download the file from your server when it receives the first request and will continue to serve the file for the configured amount of time before reloading the file from your server. . .
Edit this configuration on the “CDN” tab of the plugin settings page. This is technically advanced and requires a basic understanding of how a server or CDN works. Make sure you clear the cache file after you tweak the CDN.
Fix possible errors
If something is not working properly when you install the plugin, here are a few things to check:
- wp-content writable by web server (web server)?
- Does wp-content/wp-cache-config.php file exist? If not, copy the file wp-super-cache/wp-cache-config-sample.php to wp-content/wp-cache-config.php and make sure WPCACHEHOME points to the correct location.
- Is the wp-content/advanced-cache.php file available? Otherwise you have to copy wp-super-cache/advanced-cache.php to wp-content/. You have to edit the file and change the path so that it points to the wp-super-cache folder.
- If the page is not cached at all, remove wp-content/advanced-cache.php and recreate it, following the instructions above.
- Make sure the bold line below is in wp-config.php and above the line “require_once(ABSPATH.'wp0settings.php')”: define( 'WP_CACHE', true );
- Try Settings->WP Super Cache again and enable cache.
- Looking at wp-content/cache/supercache/. Are there folders and files there?
- What's in the error_log php file?
- If your browser still asks you to save files after installing super cache, you must disable Super Cache's compressor. Go to Settings-> WP Super Cache page and disable it here.
- The plugin doesn't work well with PHP safe mode enabled. Your administrator must disable it.
- If your page is cached very randomly and sometimes not, your blog can be viewed with both “www” and non-www” prefixes in the URL. You need to select a plugin and install the www-priority enforcement plugin if you are using an old WordPress installation. The latest version redirects itself (you should be running the latest version of WordPress anyway).
- Private server users at Dreamhost must edit the wp-content/wp-cache-config.php file and set the cache directory to “/tmp” if they get an error about increasing CPU usage..
- File locking errors like “failed to obtain key 0x152b: Permission denied in… / could not obtain key 0x152b: Permission denied in…” or “Page not cached by WP Super Cache. The mutex lock could not be obtained./ The page is not cached by WP Super Cache. Unable to lock mutex. " is an indication that you are using file/file locking. Edit wp-content/wp-cache-config.php and uncomment "$use_flock=true" or set $sem_id to a different value. You can also disable file locking from the Administration screen as a last resort.
- Make sure cache/wp_cache_mutex.lock is writable by the web server if raw file locking is used.
- The cache directory cannot be set in an NFS or Samba share or a NAS. It must be on the local disk. Locking files and deleting expired files do not work properly unless the cache folder is on the local machine.
- The old file cleaner can't work if WordPress can't find wp-cron.php. If your hostname points to 127.0.0.1, it may prevent the garbage collector from working. Check the access_logs for the wp-cron.php entry. Do they return 404 (file not found) or 200? If it's a 404 code or you don't see wp-cron.php anywhere, WordPress is probably looking for it in the wrong place. You must ask the server administrator to edit or fix this on the Unix server and remove the following line. Your hostname must point to an external IP address that is different from the one on the network/Internet uses. See also https://yoast.com/wp-cron-issues/ article for more details. A line like “127.0.0.1 localhost localhost.localdomain” is fine
- If legacy pages are made available to visitors via supercache, you may lose Apache modules (or equivalent modules if you're not using Apache). The following three modules are needed: mod_mime, mod_headers and mod_expires. The last two are especially important to ensure that the browser loads new versions of existing pages on the page.
- Error message, “WP Super Cache was installed but corrupted. The path to wp-cache-phase1.php in wp-content/advanced-cache.php must be fixed! / WP Super Cache is installed but there is a problem. The path to wp-cache-phase1.php in wp-content/advanced-cache.php must be fixed! ” appears at the bottom of all pages. Open the wp-content/advanced-cache.php file with your favorite editor. Is the path to wp-cache-phase1.php correct? This file will usually be located in wp-content/plugins/wp-super-cache/. If it is incorrect, the cache will fail to load.
- Caching does not work. The timestamp on my blog keeps changing when I reload. Check that the path in the rules you set in .htaccess matches the supercache directory. You may have to encode it. Try disabling super cache mode.
- If the supercache cache file is generated but not served, check the permissions on all your folders in wp-content/cache/supercache (and each wp-content cache and supercache folder) and wp- content/cache/.htaccess. If your PHP runs as a different user than Apache and the permissions are strict/strict, Apache may not be able to read the cache files generated by PHP. To edit you have to add the following lines in your wp-config.php file (And it is above the definition of WP_CACHE). Then clear your cache. umask (0022);
- If you see junk files in your browser after enabling compression in the plugin, then compression may have been enabled in your web server. In Apache you must disable mod_deflate, or in PHP zlib compression can be enabled. You can disable it in three ways. If you have root access, edit php.ini and find the setting zlib.output_compression and make sure it is “Off” or add the following to .htaccess: disable php_flag zlib.output_compression. If that still doesn't work, add the following to wp-config.php: ini_set('zlib.output_compression', 0);
- The “white screen of death” or a blank page when you visit a website is almost certainly caused by a PHP error but it can also be caused by APC. Disable the PHP extension if you have problems and replace it with eAccelerator or Xcache.
- After uninstalling, your static link may break if you also remove the mod_rewrite rules. Recreate those rules by going to Settings->Permalink and re-save the form.
- If your page refuses to load, make sure that wp-config.php is set up correctly. Did you miss any PHP opening or closing tags?
- Your homepage is fine but posts and pages return 404 results? Go to Settings->permalinks and click “Save” once you have selected the static path structure. You may need to manually update the .htaccess file
- If some characters are not displayed correctly on your website, your server may not be configured correctly. You need to let your visitors know which character set to use. Go to Settings->Read and copy the value “Encoding for Pages and Feeds/Encoding for Pages and Feeds”. Edit the .htaccess file with your entire Supercache and WordPress rewrite rules and add it to the top, replacing the CHARSET copy value. (eg 'UTF-8'): AddDefaultCharset CHARSET
- Use Cron View to help diagnose preload and garbage collection issues. Use a plugin to make sure jobs are scheduled and at what time. Find the wp_cache_gc and wp_cache_full_preload hooks.
- Error message “WP Super Cache is installed but corrupted. WPCACHEHOME must be set up in the wp-config.php file and point to the “WP Super Cache plugin” folder that appears at the bottom of each page. You can either delete wp-content/advanced-cache.php and reload the site settings or edit wp-config.php and search for WPCACHEHOME and make sure it points to the wp-super-cache folder. It's usually wp-content/plugins/wp-super-cache/ but you'll probably need the full path to the file (so the settings page would be easier to fix). If it is incorrect, the cache will not be loaded.
- If your server is having problems due to the number of semaphores used by the plugin, it could be because your users are using file locking which is not recommended (but only necessary for some users). small users). You can disable all file locking by defining the constant WPSC_DISABLE_LOCKING or specifying the constant WPSC_REMOVE_SEMAPHORE so that sem_remove() is called after each cached page but seems to cause problems for requests to process. physical. different from the semaphore. It is best to disable it.
- Set the $htaccess_path variable in wp-config.php or wp-cache-config.php to the global path of .htaccess if the plugin finds this file in the incorrect directory. This can happen if you install WordPress in an unusual way.