Support » Plugin: DB Cache Reloaded Fix » [Plugin: DB Cache Reloaded Fix] Installation problem: Caching can't be activated

  • While installing and setting up the newest DB Cache Reloaded Fix 2.2.4 several problems were encountered due to misleading documentation. When enabling caching, the plugin gives these messages:

    “Caching can’t be activated. Please chmod 755 wp-content/db-cache-reloaded-fix/cache folder

    Settings can’t be saved. Please chmod 755 file config.ini”

    1. Should the first-mentioned directory be wp-content/plugins/db-cache-reloaded-fix/cache? It seems that the help text misleads by not mentioning “plugins/”.

    2. Installing the plugin has not created such a subdirectory. Hopefully the next version creates the directory and gives it the correct chmod.

    3. The WordPress site directory tree doesn’t have any file named “config.ini”. Which file needs to be chmodded to 755 and in which directory is it?

    4. In one blog we had successfully figured out the abovementioned misleading instructions and got DB Cache Reloaded Fix working correctly. I haven’t benchmarked, but if I remember correctly there was a noticeable speed improvement. Thanks for the developers for that. However, when I disabled caching, I got the same “config can’t be saved, chmod 755 config.ini” message. Despite this, the setting was saved and caching disabled. I then re-enabled the cache, got the same warning, and it was again incorrect as the settings were saved correctly.

    Thanks for your efforts in solving these four issues!

Viewing 14 replies - 1 through 14 (of 14 total)
  • I got it working by creating an empty /wp-content/db-config.ini, copying /wp-content/plugins/db-cache-reloaded-fix/db.php to /wp-content/db.php and chmodding both to 777 (755 didn’t work on my host).

    Here’s what I found out and wrote before trying that last part out on how to improve DBCRF and it’s output:

    1. On the blog that has had DBCRF running for a while and it was also working a long while ago, DBCRF tries to use the directory /wp-content/tmp as DBCR_CACHE_DIR. Deactivating and activating the module didn’t change this. I didn’t dig deep enough to find an explanation for this but a check seems to be missing that would force the plugin to start use the new direction after update to newer than 2.2.3.

    On a new blog where DBCRF hasn’t been used before, it tried to use /wp-content/plugins/db-cache-reloaded-fix/cache as DBCR_CACHE_DIR. Documentation said the same but without “plugins/”.

    2. DBCRF created the directory by itself after step 5.

    3. As suspected, “config.ini” is misleading. What DBCRF is looking for is “WP_CONTENT_DIR.’/db-config.ini'”, which translates to /wp-content/db-config.ini. It is also similarly looking for /wp-content/db.php. It would sound more logical to me that DBCRF would look for such files under its home folder DBCR_PATH instead. Db.php is there already, but again an empty db-config.ini might be good to be included in the FTP install.

    After creating an empty /wp-content/db-config.ini and chmodding it 777 (not 755) DBCRF said it was able to save the settings.

    4. The messages are now more informative in my copy of DBCRF after doing the following modifications to db-cache-reloaded.php:

    Change line 275 from
    _e('Caching can\'t be activated. Please <a href="" target="blank">chmod 755</a> <u>wp-content/db-cache-reloaded-fix/cache</u> folder', 'db-cache-reloaded');
    _e('Caching can\'t be activated. Please <a href="" target="blank">chmod 755</a> the folder <b>' .DBCR_CACHE_DIR. '</b><br />If that doesn\'t work, you might need to use chmod 775 or chmod 777 instead.<br />You may also need to copy <b>' .DBCR_PATH. '/db.php</b> to <b>' .WP_CONTENT_DIR. '/db.php</b> and chmod it 755 (or 775 or 777).', 'db-cache-reloaded');

    and line 420 from
    _e('Settings can\'t be saved. Please <a href="" target="blank">chmod 755</a> file <u>config.ini</u>', 'db-cache-reloaded');
    _e('Settings can\'t be saved. Please <a href="" target="blank">chmod 755</a> the file <u>' .WP_CONTENT_DIR. '/db-config.ini</u><br />If that doesn\'t work, you might need to use chmod 775 or chmod 777 instead. You may need to create an empty file of that name first.', 'db-cache-reloaded');

    An example output of line 275 ([WPDIR] is your WP dir):

    Caching can’t be activated. Please chmod 755 the folder /[WPDIR]/wp-content/plugins/db-cache-reloaded-fix/cache
    If that doesn’t work, you might need to use chmod 775 or chmod 777 instead.
    You may also need to copy /[WPDIR]/wp-content/plugins/db-cache-reloaded-fix/db.php to /[WPDIR]/wp-content/db.php and chmod it 755 (or 775 or 777).

    An example output of line 420:

    Settings can’t be saved. Please chmod 755 the file /[WPDIR]/wp-content/db-config.ini
    If that doesn’t work, you might need to use chmod 775 or chmod 777 instead. You may need to create an empty file of that name first.

    I didn’t have time to hack and see if DBCRF would work so that it would use db-config.ini and db.php from its own installation directory. That could remove the manual steps in installation.

    After this got the following speedup on one blog’s front page:

    First try generated in 0.276 seconds, 14 db queries, 0 cached queries, memory used 5.47 MB
    Third try generated in 0.098 seconds, 5 db queries, 9 cached, 5.36 MB

    The ones after showed otherwise the same numbers as third with only the generation time between 0.069 and 1.132.

    Then after disabling cache:

    First try generated in 0.104 seconds, otherwise same as above
    Second try generated in 0.092 seconds, 14 db queries, 0 cached, 5.47 MB
    Third try generated in 0.390 seconds, 15 db queries, 0 cached, 23.42 MB (I wonder what script was run there)
    Fourth try generated in 0.122 seconds, 14 db queries, 0 cached, 5.37 MB
    Fifth try generated in 0.076 seconds, 14 db queries, 0 cached, 5.36 MB
    Sixth and so forth otherwise the same as fifth, but generation times between 0.72 and 0.114 (once 0.171)

    My feeling is that caching generated the page on average 0.010 seconds faster or less. I’m keeping the caching on for now as it might be that it serves its purpose well when the server experiences a lot heavier load than my refreshing-Firefox’s-source-window-several-times-a-second, but I’m not yet convinced of its usefulness.


    2. On one blog had to manually create the cache/ directory and chmod it 777. On another DBCRF was able to create it and chmod it 755 by itself and that sufficed to have it working. The blogs are on the same host and have mostly the same settings and plugins so this is most mysterious.

    Plugin Author Ivan Kristianto


    Yes i heard some reports that DBCRF couldn’t activated on some hosting. At the time i was thinking it was because the PHP setting. some host use suPHP and some use fastcgi, which have different folder and file permission rules. But after more digging around, it is still mysterious that somehow it failed to create db-config.ini and cache folders and copy the .htaccess file to cache folder, which cause this error.
    I’m still in the development to rewrite the plugin from the scratch (DCRF is the 3 fork of the DB Cache Plugin) which i’m not the original developer.
    And i’m developing the new DBCRF from the scratch, hopefully somewhere before february next year would be finished.


    The host the blogs mentioned above use uses suPHP.

    Great news about the rewrite, I wish you success in that.

    Would you consider including my patch above (change lines 275 and 420 in db-cache-reloaded.php) for 2.2.5 of non-rewritten DBCRF? It might help many users including me for not having to maintain my fork 🙂

    For fixing the problem itself, the two problems and solutions are:

    #1 Problem: Trying to create db-config.ini and copy db.php under WP_CONTENT_DIR

    Solution: Let’s add an empty db-config.ini to the installation package. Let’s not copy anything to WP_CONTENT_DIR, let’s use both files from DBCR_PATH.

    #2 Problem: Chmod 755 is not always enough for db-config.ini, cache and db.php (for db.php it’s enough if we don’t try to overwrite it all the time – I don’t see any reason for doing that)

    Solution in theory: When 755 is not enough, let’s have DBCRF try 777. For example change in db-functions.php from line 209 (trying to copy htaccess to DBCR_PATH .’/cache’ after creating it) from:

    if ( !@copy( DBCR_PATH.'/htaccess', $path.'/.htaccess' ) ) {
    				return false;


    if ( !@copy( DBCR_PATH.'/htaccess', $path.'/.htaccess' ) ) {
            if ( !@chmod( $path, 0775 ) || !@copy( DBCR_PATH.'/htaccess', $path.'/.htaccess' ) ) {
              if ( !@chmod( $path, 0777 ) || !@copy( DBCR_PATH.'/htaccess', $path.'/.htaccess' ) ) {
                return false;

    Tried this in practice, and unfortunately it didn’t work as intended: on one blog the cache/ needs to be chmod 777, on others 755 is enough. The above if-chmod-sentences don’t make a difference.

    Unrelated to the above, I noticed a possible bug while debugging these: function install() assumes that DBCR_PATH . ‘cache/’ is already created, but no part of the code seems to create it in case it doesn’t exist.

    Useful post.

    Got the exact same 2 lines of error after trying to enable the plugin.
    (I must mention that the plugin created none of the plugin files and folder that I mention below).
    By instinct, after having done the same thing as you did:

    1. creating the files that did not exist:

    • an empty /wp-content/db-config.ini,
    • copying /wp-content/plugins/db-cache-reloaded-fix/db.php to make a /wp-content/db.php

    2. creating the folder that did not exist:

    • wp-content/plugins/db-cache-reloaded-fix/cache

    3. playing with both the permissions (all combinations of 777 and 775) and the plugin activation/de-activation

    I’m still having no luck at all.
    Worse, my wp-content/plugins/db-cache-reloaded-fix/cache folder gets deleted everytime I try to save the settings.
    If you guys have another idea… 😉


    Does the cache folder get deleted whether you’ve set the caching enabled or disabled when saving the settings?

    And what message does the plugin say when it removes the cache folder? Does using wrapper mode change anything?

    All the related code seems to be in db-cache-reloaded.php. You can seek the devil by finding line 318 @rmdir( DBCR_CACHE_DIR ); and backtracking which function calls the function this one is in, which function calls that one and so forth until you find the place where things go the wrong way. I tracked as much as to say that from line 379
    } elseif ( isset( $_POST['save'] ) ) { starts the code that attempts to save the config.

    (Sorry for the late reply: the new year got on the way 😉 )

    The cache folder used to be deleted in both cases.
    After some more unsuccessful hacking, I did the 3.3.1 WP update though, deleted and re-installed the plugin and weirdly enough… IT WORKED!

    I’m clearly at a loss here, but, oh well…

    Thanks a lot for the quick reply and the tips though Daedalon, it’s people like you that make open source and wordpress evolve fast (I know way better the plugin now).

    Thank you for showing your appreciation and good news that you got the plugin working 🙂

    Ivan: Any chance you’d release a new version that implements my patch?

    Mathieu Bourgie


    First of all, thank you for your notes Daedalon, they are very useful.

    I had the same issues as you all after upgrading to WP 3.3.1.

    To fix it, on top of creating the folders in /wp-content, I had to CHMOD 777 the wp-content/plugins/db-cache-reloaded-fix/cache folder to get the plugin working.

    Hope this helps anyone else having this issue.

    Awesome plugin Ivan, keep up the great work 🙂

    Plugin Author Ivan Kristianto


    Thanks Daedalon for the patch,
    i will review and test it and if it is good to go, then i will update the plugin.
    It has been very busy month lately, but i will try my best to fix this plugin.
    Thanks for all your support guys, really appreciate it.





    Sadly, none of the above worked for me. Any other suggestions?



    OK, finally got it working. Since I had it working on an older install, I figured there must be something wrong with the latest version. So I installed version 2.2.3. Once everything was set and working. I deactivated it. FTP’d 2.2.4 over the previous. Then activated. Seems to be working now.

Viewing 14 replies - 1 through 14 (of 14 total)
  • The topic ‘[Plugin: DB Cache Reloaded Fix] Installation problem: Caching can't be activated’ is closed to new replies.