WordPress.org

Ready to get started?Download WordPress

Forums

W3 Total Cache
W3 Total Cache critical Vulnerability disclosed (44 posts)

  1. r_mizan
    Member
    Posted 1 year ago #

    W3 Total Cache critical Vulnerability disclosed, allow attacker to retrieve password hashes and other database information.

    http://thehackernews.com/2012/12/wordpress-plugin-w3-total-cache_26.html

    http://wordpress.org/extend/plugins/w3-total-cache/

  2. Samuel Wood (Otto)
    Tech Ninja
    Posted 1 year ago #

    The author is aware of the issue and is working on a fix.

    At a quick glance, however, this only affects users who use the "Database Cache" option with the "Disk: Basic" or "Disk: Enhanced" modes of caching. It won't affect all users of the plugin, and is a rather minor issue at that.

    Disclosure of the password hashes is not a highly critical issue, because the passwords are salted and ran through multiple iterations of the PHPass system. They are very difficult to crack if you use strong passwords and not dictionary words.

  3. r_mizan
    Member
    Posted 1 year ago #

    Thanks for your information. That's mean its not a critical issue.

  4. Samuel Wood (Otto)
    Tech Ninja
    Posted 1 year ago #

    It's an important issue, certainly, and if you use the plugin it is worth checking your settings to make sure you have it configured properly.

  5. ithacaindy
    Member
    Posted 1 year ago #

    Can someone specify what the correct settings for "Database Cache" should be in order to avoid the exploit?

  6. Samuel Wood (Otto)
    Tech Ninja
    Posted 1 year ago #

    ithacaindy: Essentially, don't use the "Disk: Basic" or "Disk: Enhanced" settings for the cache. Or, if you do, then make sure you have Directory Indexing disabled on the site, which is generally a good idea anyway.

    To disable directory indexing on a site, add Options -Indexes as the first line in the site's .htaccess file.

    IMO, the database cache isn't particularly effective in most cases anyway, and you probably should not have it enabled. The Object Caching mode will likely be more effective. Although this depends on your specific server configuration, among other things.

  7. ithacaindy
    Member
    Posted 1 year ago #

    Otto: I updated my .htaccess to prevent directory indexing. Since I'm on a shared host, I need the database cache; disabling it brought things to a crawl. It would be nice if Object Caching were available for shared hosting accounts.

  8. AITpro
    Member
    Posted 1 year ago #

    @ithacaindy & anyone else who needs to use DB caching - then you can create a deny all .htaccess file and upload it to your /w3tc/dbcache folder.

    To create a deny all .htaccess file:
    1. Open Notepad (not Word or WordPad)
    2. Add these 2 lines of code.
    order deny,allow
    deny from all
    3. Save the file with this name: denyall.htaccess.
    4. Upload it to your /wp-content/w3tc/dbcache folder
    5. Rename the denyall.htaccess file to just .htaccess.

    And just an FYI - if you are using secure passwords then you have nothing to worry about since one-way hashed passwords cannot be cracked. If you are using a non-secure password then they can be easily cracked and a hacker would just use a tool like BackTrack R3 and not even bother with the extra effort required to download a W3TC dbcache file and crack it.

    Note: downloading the hashed password does have one benefit - it allows unlimited attempts at cracking the hashed password, but if it is a secure password then the end result will be the same - the password will not be crackable.

  9. Frederick Townes
    Member
    Plugin Author

    Posted 1 year ago #

    For those of you that use W3 Total Cache to make your sites more performant, thank you. Security issues are always of paramount interest, no matter the scope.

    The root of the possible vulnerability lies in the intersection of two configuration settings, one at the Web Server level and the other at the W3 Total Cache database caching level. You may be vulnerable if the following are true: your server is configured to allow directory listing with enabled public access on W3TC’s database caching directories and also use database caching via the disk caching method. These settings would allow a hacker to break the md5 hashing used for the then publicly accessible cached database objects. The manner, extent and timing of the vulnerability’s report leave much to be desired; nonetheless, the versions have now been patched on wordpress.org. Thanks to those that offered remediation advice. I’m sorry for the delay in turning this around, none of the proposed solutions were satisfactory.

    The hotfix (tested with WordPress version 3.5) will help those who are just now upgrading to 0.9.2.4 or are otherwise getting started with W3 Total Cache. Specifically, the hash logic is improved via wp_hash(), significantly stronger than the previous md5 hashing at the compromise of a bit of speed. I’ve also made sure that a web server’s lack of security around directory listings and the standard file structure of W3TC’s hashing logic are no longer of consequence for those attempting to download them from your server.

    For those who are using database caching to disk already, please be sure to disable directory indexing and deny web access to the “wp-content/w3tc/dbcache/” directory in your web configuration, then empty the database cache for good measure. Or, simply deactivate W3 Total Cache, uninstall it, and re-install it via wordpress.org to have the hotfix applied upon re-activation. Again, empty the database cache for good measure. Your settings will not be lost during this process. If all of this is gibberish to you, then simply disable database caching to disk until the next release or use another method if available. Once again, empty the database cache using the button of the same name available on the database caching settings tab.

    If you’re reading this and have seen a post about the issue that does not have this response on it, please do post this for me. Thanks in advance. Happy Holidays.

  10. sLa NGjI's
    Member
    Posted 1 year ago #

    Frederick Townes, 0.9.2.5 version was released, but my question is:

    0.9.2.5 version include enhancements and corrections contained on previous development 0.9.2.5b (2011-08-31) versions?

    :)

  11. Frederick Townes
    Member
    Plugin Author

    Posted 1 year ago #

    No.

  12. sLa NGjI's
    Member
    Posted 1 year ago #

    Is planned development 0.9.2.6b version with enhancements and corrections contained on previous development 0.9.2.5b (2011-08-31) versions, or enhancements and corrections contained on previous development 0.9.2.5b (2011-08-31) versions are deprecated and discarded on future release?

  13. Frederick Townes
    Member
    Plugin Author

    Posted 1 year ago #

    Ongoing development will move to 0.9.2.6b.

  14. TDF
    Member
    Posted 1 year ago #

    Apparently along with the changes on how the database queries are caching to disk, @Frederick also made changes on how the pages are caching to disk.

    That certainly made some problems with the page caching and probably the cron job, at least in some environments. So this is what is happening:

    1. When caching pages to disc (basic), W3TC fails to even serve the cached pages. Time-stamps change on every single visit. The pages are created on disc, but not served.

    2. When caching pages to disc (enhanced), W3TC fails to collect the garbage and refresh the pages at specified intervals. Time-stamps remain the same long after the collect garbage interval have passed. After some testing I'm assuming that what is happening is that W3TC is taking into account the caching intervals from the database caching, page caching, and browser html caching cumulatively.

    When setting page cache (enhanced) to expire let say at 300, the cache will be gone at 600-700, depending on what I have set for the database and browser caching.

  15. sLa NGjI's
    Member
    Posted 1 year ago #

    0.9.2.5 versione release is only simply security fix: all problems discovered on 0.9.2.4 version is the same and unfixed ... Nothing, for now, was fixed!

    :)

  16. gianpaolo.cipicchia
    Member
    Posted 1 year ago #

    Hello,
    there is a new critical vulnerability affecting object cache.
    I disabled this feature because some attacker executed malicious code through this component. Do you have some suggestion ? I also noticed that if I use some security plugins suggestion in folder permissions, W3 Total Cache doesn't work as expected. For example also if my .htaccess contains all page cache directives, with 604 permission I got this error: It appears Page Cache URL rewriting is not working. If using apache, verify that the server configuration allows .htaccess or if using nginx verify all configuration files are included in the configuration.
    Any help is appreciated !
    Best Regards
    Gian Paolo

  17. Frederick Townes
    Member
    Plugin Author

    Posted 1 year ago #

    @gianpaolo.cipicchia, How do you know that this was done through the object cache?

    As for the permissions problems, that's not unexpected and no one in these forums can even guess why that's happening without looking at how your particular server is set up.

  18. sLa NGjI's
    Member
    Posted 1 year ago #

    @gianpaolo.cipicchia

    For my personal experience, with various hosting, dir and file chmod permission is not problem ... W3TC work perfectly with dir 705 and file 604 chmod permission, on various situations.

    @Frederick Townes

    1 - What happens if the same malicious script used to exploit db cache is applied to object cache with W3 total Cache 0.9.2.5?

    2 - What happens if the same malicious script used to exploit db cache is applied to advanced cache (disk and enanched mode) with W3 total Cache 0.9.2.5?

  19. DigiP
    Member
    Posted 1 year ago #

    I would agree with most everything here, including best practices for htaccess and so forth, but I take issue with the statement "And just an FYI - if you are using secure passwords then you have nothing to worry about since one-way hashed passwords cannot be cracked."

    Hashcat with on a workstation with a number of GPU's, can and will crack wordpress passwords, and people do it all the time. Collisions can and will happen. Especially passwords under 8 characters, will only take about an hour or two on a high end machine with multiple GPU's doing the cracking. 8 or more characters take a bit longer exponentially for every character over 8 or more in length.

    At a minimum, 14 or more would be more desirable as well as implementing your own form of two factor authentication, or doing as I do and disabling access to wp-login.php and the wp-admin directory via htaccess for anyone other than my own IP.

    Still, its not impossible to break, as the algorithm used to create the hash, can have any number of possibilities for the hash itself and its only a time trade off issue as to when, not if, the password can be broken. Type in any word, and do it continually, the hash changes every time. I use this for myself, when I've forgotten the password on systems that don't have the ability to email passwords or no SMTP setup, and I have to manually edit clients sites that need password resets, I can make my own and just paste in whatever this outputs directly to the database file itself and it works - http://www.attack-scanner.com/pass.php

    If you are going to block access to indexes, be sure to block access to wp-login.php and wp-admin as well except for your own IP. Its a hassle to update the htaccess file every time your IP changes, but its worth it in my mind. Another alternative, is add htpasswd protection to the wp-admin directory so no one can login, which in some ways, adds a second layer of authentication. Just don't use the same login name and password for both htpasswd and your wordpress login, but that should go without saying.

  20. AITpro
    Member
    Posted 1 year ago #

    @DigiP - Yes of course you are correct. Some secure passwords can be cracked in hours, some take months and some take years. I will rephrase my statement - "If you create new secure passwords over 14 characters each month then you have nothing to worry about."

  21. DigiP
    Member
    Posted 1 year ago #

    @AITpro hope no offense was taken either way. Was not my intention, just wanted to illustrate a point that length with respect to the current password hashing scheme for wordpress alone is not a deterrent for attackers at this point in time and easy access to user names is all they really care about, since they usually just brute force logins once they know the user names and don't care about needing the hash itself.

    Still, password cracking is a common threat in todays landscape of GPU hardware based password cracking machines, and wordpress passwords in general are quickly broken in hash cracking competitions since the average user only uses a small subset of actual characters for their passwords, often limited to lowercase letters and numbers only and usually no more than 8 characters. Not to mention hash length extension attacks that use probability statistics in reducing the common key space used to only commonly used characters and removing certain letters, special characters, etc, the process of cracking most(but not all) passwords becomes even that much faster when you add additional cracking techniques.

    Not trying to hijack the thread or to cause hysteria, but users should be aware of a number of security practices, not just htaccess control and strong password use, but also monitoring of login attempts, something I hope is someday implemented into wordpress itself to notify admins if a failed password attempt has taken place. There good thing is there are plug-ins to help users in that area to fill the void, including one I've written myself, but you don't need to use mine to be able to log these attempts. There are plenty of other plug-ins that help with that regard and I would suggest every WordPress user consider using some form of login monitoring plug-in that emails the admins of attempts. Just one more layer in a balanced approach to securing your site, and something most users would probably be surprised at how many people are already brute forcing their way into your sites already, directly against the login page of wordpress itself. One of the first things I do when setting up WordPress is install a login alerts plug-in, and change all usernames to use different nicknames for posts and comments, so attackers can't use default names like admin to login with(which is a topic for a whole other discussion on why you should never setup wordpress with the username admin).

  22. alexwoolfson
    Member
    Posted 1 year ago #

    I deactivated the plugin, upgraded & reactivated the plugin and it is now giving me this error when it didn't before:

    It appears Minify URL rewriting is not working. If using apache, verify that the server configuration allows .htaccess or if using nginx verify all configuration files are included in the configuration.

    I deactivated and reactivated the plugin again. Deactivated and reactivated the minify part of the plugin. Restarted my Apache server, but the error persists. Looking above at Frederick's comment, I can see that it's unlikely that anything can be done without someone knowledgeable about both this plugin and my server looking into it. But if anyone has any suggestions for what kind of permissions setting I'd need to change or look at just for this minify issue (my server does currently allow .htaccess), I'd be grateful for that.

    Also, is it better to leave minify turned off for now?

    Thanks!

  23. MediaInk
    Member
    Posted 1 year ago #

    alexwoolfson,

    I have the same problem, except the issue also impacting disk cache

    "It appears Page Cache URL rewriting is not working. If using apache, verify that the server configuration allows .htaccess or if using nginx verify all configuration files are included in the configuration."

    Based on the load of the CPU it looks like that the disk cache is not working for me at all. Also reloaded 0.9.2.4; have still the same problem on the site tried to the the upgrade.

  24. sLa NGjI's
    Member
    Posted 1 year ago #

    alexwoolfson wote:

    Is it better to leave minify turned off?

    @alexwoolfson

    Turn Minify to manual and take advantage of HTML minification. Minify CSS and JS manual ... this work better ;)

    MediaInk wrote:

    Disk cache is not working for me at all. Also reloaded 0.9.2.4; have still the same problem on the site tried to the the upgrade.

    @MediaInk

    0.9.2.5 versione release is only simply security fix: all problems discovered on 0.9.2.4 version is the same and unfixed, and also on 0.9.2.5 have some negative unfixed problems ... Nothing, for now, was fixed!

    @DigiP

    Default password on WordPress since version 3.1 is 12 characters (alphanumeric+simbles)

    Foe my personal opinion best numbers is 15 characters! (alphanumeric+simbles) Strong Password Generator

    For some for some reason of general security is recommended chmod:

    /.htaccess 404
    /favicon.ico 404
    /robots.txt 404
    /index.php 400
    /wp-blog-header.php 400
    /wp-config.php 400
    /xmlrpc.xml 400 if CMS 404 if BLOG
    All others files 604

    / 705
    /wp-admin/ 701 (dir and subdir)
    /wp-content/ 705 (dir and subdir)
    /wp-includes/ 701 (dir and subdir)

    This WP-Trik described take advantage of 404 not found HEADER error reply (same of default /wp-includes/) ;)

    delete /wp-content/index.php
    delete /wp-content/plugins/index.php
    delete /wp-content/themes/index.php
    delete /wp-content/upload/index.php

    Change default wp_ table prefix with wp_????????_ (?=alphanumeric character)

    wp-config.php

    define('FS_CHMOD_FILE',0604);
    define('FS_CHMOD_DIR',0705);
    define('DISALLOW_FILE_EDIT',true);
    define('DISALLOW_FILE_MODS',true);//disable dashboard update link

    .htaccess rules:

    IndexIgnore *
    Options -Indexes
    #
    # WP Upgrade Protection
    #
    <Files upgrade.php>
    Order Allow,Deny
    Deny From All
    </Files>
    #
    <Files upgrade-functions.php>
    Order Allow,Deny
    Deny From All
    </Files>
    #
    # WP Install Prevention
    #
    <Files install.php>
    Order Allow,Deny
    Deny From All
    </Files>
    #
    <Files install-helper.php>
    Order Allow,Deny
    Deny From All
    </Files>
    #
    <Files setup-config.php>
    Order Allow,Deny
    Deny From All
    </Files>
    #
    <Files wp-config-sample.php>
    Order Allow,Deny
    Deny From All
    </Files>
    #
    # WP Default Protection
    #
    <Files .htaccess>
    Order Allow,Deny
    Deny From All
    </Files>
    #
    <Files wp-config.php>
    Order Allow,Deny
    Deny From All
    </Files>
    #
    <Files readme.txt>
    Order Allow,Deny
    Deny From All
    </Files>
    #
    <Files readme.html>
    Order Allow,Deny
    Deny From All
    </Files>
    #
    <Files license.txt>
    Order Allow,Deny
    Deny From All
    </Files>
    #
    <Files gpl-2.0.txt>
    Order Allow,Deny
    Deny From All
    </Files>
    #
    RewriteEngine On
    RewriteBase /
    #
    RewriteCond %{ENV:REDIRECT_STATUS} 200
    RewriteRule .* - [L
    #
    RewriteCond %{REQUEST_METHOD} ^(TRACE|DELETE|TRACK) [NC]
    RewriteRule ^(.*)$ - [F,L]
    #
    RewriteCond %{REQUEST_METHOD} !^(GET|HEAD|POST|PROPFIND|OPTIONS|PUT)$ [NC]
    RewriteRule .* - [F,NS,L]
    #
    RewriteCond %{THE_REQUEST} !^[A-Z]{3,9}\ .+\ HTTP/(0\.9|1\.0|1\.1) [NC]
    RewriteRule .* - [F,NS,L]
    #
    # Block the include-only files
    #
    RewriteRule ^wp-admin/includes/ - [F,L]
    RewriteRule !^wp-includes/ - [S=3]
    RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
    RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
    RewriteRule ^wp-includes/theme-compat/ - [F,L]
    #
    # Skip WordPress 404 Error for Static Files
    #
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} \.(php|css|js|htc|html|htm|rtf|rtx|svg|svgz|txt|xsd|xsl|xml|asf|asx|wax|wmv|wmx|avi|bmp|class|divx|doc|docx|eot|exe|gif|gz|gzip|ico|jpg|jpeg|jpe|mdb|mid|midi|mov|qt|mp3|m4a|mp4|m4v|mpeg|mpg|mpe|mpp|otf|odb|odc|odf|odg|odp|ods|odt|ogg|pdf|png|pot|pps|ppt|pptx|ra|ram|svg|svgz|swf|tar|tif|tiff|ttf|ttc|wav|wma|wri|xla|xls|xlsx|xlt|xlw|zip)$ [NC]
    RewriteRule .* - [L]
    #
    # BEGIN WordPress

    Hardening WordPress and Changing File Permissions

  25. sLa NGjI's
    Member
    Posted 1 year ago #

    .htaccess headers rules:

    #
    FileETag none
    #
    Header set X-Frame-Options "SAMEORIGIN"
    Header unset Accept-Ranges
    Header unset ETag
    Header unset Pragma
    #
    BrowserMatch MSIE ie
    Header set Imagetoolbar "no" env=ie
    Header set X-Content-Type-Options "nosniff" env=ie
    Header set X-UA-Compatible "IE=edge" env=ie
    Header set X-XSS-Protection "1;mode=block" env=ie
    #
    BrowserMatch SAFARI safari
    Header set X-XSS-Protection "1;mode=block" env=safari
    #
    BrowserMatch CHROME gc
    Header set X-Content-Type-Options "nosniff" env=gc
    #
    BrowserMatch chromeframe gcf
    Header set Imagetoolbar "no" env=gcf
    Header set X-Content-Type-Options "nosniff" env=gcf
    Header set X-UA-Compatible "IE=edge,chrome=1" env=gcf
    Header set X-XSS-Protection "1;mode=block" env=gcf

    w3-total-cache-config.php

    Never cache the following pages:
    wp-.*\.php
    Cache exception list:
    wp-comments-popup.php
    wp-links-opml.php
    wp-locations.php
    wp-login.php
    Non-trailing slash pages:
    index\.php
    humans\.txt
    robots\.txt
    sitemap\.txt
    sitemap\.xml(\.gz)?
    sitemap_index\.xml(\.gz)?
    Specify page headers:
    Accept-Encoding
    Accept-Ranges
    Connection
    Content-Encoding
    Content-Length
    Content-Type
    ETag
    Pragma
    Server
    Transfer-Encoding
    Vary
    X-Frame-Options
    X-CF-Powered-By
    Imagetoolbar
    X-Content-Type-Options
    X-Pingback
    X-UA-Compatible
    X-XSS-Protection

    W3TC injection protection:

    delete /wp-content/w3tc/index.html
    delete /wp-content/w3tc/index.php

    Put this .htaccess on:

    /wp-content-/w3tc/dbcache/
    /wp-content-/w3tc/objectcache/

    .htaccess to put it:

    Order Allow,Deny
    Deny From All

    functions.php

    /* Disable Self Pings */
    function no_self_ping(&$links){$home=get_option('home');foreach($links as $l => $link)if(0 === strpos($link,$home))unset($links[$l]);}add_action('pre_ping','no_self_ping');
    
    /* Remove WordPress version from header */
    remove_action('wp_head','wp_generator');
    
    /* Hide blog URL from WordPress 'phone home' */
    function disabler_remove_url($default){global $wp_version;return 'WordPress/'.$wp_version;}add_filter('http_headers_useragent','disabler_remove_url');
    
    // Remove Login Error Message on wp-login.php
    add_filter('login_errors',create_function('$a',"return null;"));
    
    /* Block Bad Queries*/
    $request_uri_array = apply_filters('request_uri_items', array('eval\(', 'CONCAT', 'UNION\+SELECT', '\(null\)', 'base64_', '\/localhost', '\/pingserver', '\/config\.', '\/wwwroot', '\/makefile', 'crossdomain\.', 'proc\/self\/environ', 'etc\/passwd', '\/https\/', '\/http\/', '\/ftp\/', '\/cgi\/', '\.cgi', '\.exe', '\.sql', '\.ini', '\.dll', '\.asp', '\.jsp', '\/\.bash', '\/\.git', '\/\.svn', '\/\.tar', ' ', '\<', '\>', '\/\=', '\.\.\.', '\+\+\+', '\:\/\/', '\/&&'));
    $query_string_array = apply_filters('query_string_items', array('\?', '\[', '\]', '\.\.\/', '127\.0\.0\.1', 'localhost', 'loopback', '\%0A', '\%0D', '\%22', '\%27', '\%3C', '\%3E', '\%00', '\%2e\%2e', 'union', 'input_file', 'execute', 'mosconfig', 'environ', 'path\=\.', 'mod\=\.'));
    $user_agent_array = apply_filters('user_agent_items', array('binlar', 'casper', 'cmswor', 'diavol', 'dotbot', 'finder', 'flicky', 'jakarta', 'libwww', 'nutch', 'planet', 'purebot', 'pycurl', 'skygrid', 'sucker', 'turnit', 'vikspi', 'zmeu'));
    
    if (
    	preg_match( '/' . implode( '|', $request_uri_array ) . '/i', $_SERVER['REQUEST_URI'] ) ||
    	preg_match( '/' . implode( '|', $query_string_array ) . '/i', $_SERVER['QUERY_STRING'] )
    	// || preg_match( '/' . implode( '|', $user_agent_array ) . '/i', $_SERVER['HTTP_USER_AGENT'] )
    ) {
    	header('HTTP/1.1 403 Forbidden');
    	header('Status: 403 Forbidden');
    	header('Connection: Close');
    	exit;
    }

    If use FeedBurner (plugins) to replace default WordPress Feed, instruct W3TC to no Minify Feed:

    w3-total-cache-config.php

    HTML minify settings:
    Don't minify feeds (checked)

    Instruct W3TC to no Minify Inline Script to maintain default WordPress behavior:

    w3-total-cache-config.php

    HTML minify settings:
    Inline JS minification (unchecked)

    Instruct W3TC Don't cache pages for logged in users to reduce server load:

    w3-total-cache-config.php

    Page Cache General:
    Don't cache pages for logged in users (unchecked)
  26. MediaInk
    Member
    Posted 1 year ago #

    sLaNGjI's, thank you for your kind reply.

    My site was working fine before the upgrade using 0.9.2.4. I have also four other sites with 0.9.2.4 and have no problems. My issue is specific to 0.9.2.5. TDF in this tread above had also similar issues with Disk cache.

    I am using Litespeed web server. Any pointers are appreciated.

  27. alexwoolfson
    Member
    Posted 1 year ago #

    @sLaNGjI's: Thank you very much for your kind reply. I actually was already using manual with the Minify. I agree, it is better.

    Started getting numerous 500 errors on my website tonight. My ISP host looked into it and told me "On further checking, I could see that there were large number of cache files under the plugin w3tc. It was the processing of these files that delayed the execution of the PHP scripts."

    She "renamed the cache files and this has significantly reduced the server load."

    I do understand that the changes made to this version of the plugin were very minor. It could all be a coincidence. But reporting here in case it's helpful to someone.

    In the meantime, I've disabled minify in the settings.

  28. sLa NGjI's
    Member
    Posted 1 year ago #

    @alexwoolfson

    If you Set Minify to Manual, No CPU Load was Increased ... ;) Consider to re-enable it!

    Bye :)

  29. awhig
    Member
    Posted 1 year ago #

    I've updated to .5 and now all page caching is non-functional as TDF and Mediaink have reported.

    Timestamps are always fresh and turning on debugging for page caching, it always reports "not cached".

    I'm using Disk: Basic.

    I'm going to try and revert back to .4 as the load on my server is too high!!!

    Please help.
    Thanks,
    Rich

  30. awhig
    Member
    Posted 1 year ago #

    I've reverted back to .4 and I still get no page caching.

    This is not good!

    Rich

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic