• Symptom. The following message emits, even when WP_CACHE and WPCACHEHOME in wp-config.php are both correctly set.

    You must set WP_CACHE and WPCACHEHOME in your wp-config.php for this plugin to work correctly

    If opcache.validate_timestamps=0 somehow the file…

    ./wp-content/plugins/wp-super-cache/wp-cache-phase1.php

    Seems to get complied in such a way that wpsc_deep_replace() becomes undefined.

    Unsure how this can happen.

    The net effect is, when the definition check for wpsc_deep_replace() occurs in…

    ./wp-content/plugins/wp-super-cache/wp-cache.php

    fails, WP Super Cache can’t install, which is the correct behavior.

    Maybe at some point in the deactivation sequence wp-cache-phase1.php content changes or is zeroed out. Unsure.

    Anyway, disabling Opcache works.

    Also running with validate_timestamps enabled works after revalidate_freq changes, so if this value is high… like say a minute… then reinstall will fail + then magically start working after revalidate_freq expires + validate_timestamps fires + new wp-cache-phase1.php file contents are read + compiled.

    This one had me scratching my head for a good while.

Viewing 2 replies - 1 through 2 (of 2 total)
  • Can you check if wp-content/advanced-cache.php was created? Or if it was, was it loaded by WordPress?

    I think wp-config.php wasn’t reloaded by PHP after WP_CACHE and WPCACHEHOME was added. Can you check if that was the case?

    If you grab the development version of the plugin from here and then add opcache_invalidate() as described in this PR does that make a difference?

    That should invalidate the opcache any time the configuration file is written to, which will in general make writing to the config file slower but at least mean that any process about to read from it will have an updated version of that file.

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘You must set WP_CACHE and WPCACHEHOME in your wp-config.php for this plugin…’ is closed to new replies.