No cache directory no caching files exists

You’re welcome, @javierdemuga. The wp-content/cache/cache-enabler directory is only created if it does not exist and a cached page is created. Its existence has no affect on whether the cache is bypassed. It can be deleted if the complete cache is cleared, which is not new in version 1.8.

Pages not being cached, or in other words the wp-content/cache/cache-enabler directory not being created and filled with cache files and folders strongly indicates something is causing the cache to be bypassed. Eventually Cache Enabler will be able to indicate this itself, but until then it will just take a couple troubleshooting steps to figure out this reason. To start, can you please provide a direct URL to a website that this is occurring on?

Site is super healthy, plugins zero (my special test for these case), and url is a subdomain. define cache ? true is not complete in wp-config sometimes. I cleared all opcaches etc. too. Not needed but cacher not working by itself.
Note: under old Apache my workaround explaint above works. Under NGINX not! NGINX 1.21.2; WP 5.8; php7.4 fpm, Debian 10.10

And I have my own dedicated root server and I can do what I want, so hosting is not the problem!

• This reply was modified 3 years, 6 months ago by agenciesFirst.

Sure https://www.ceroresiduo.com/ also any page was cached succesfully with version 1.7.2

My settings file: https://www.ceroresiduo.com.php

return array (
‘version’ => ‘1.8.1’,
‘use_trailing_slashes’ => 1,
‘permalink_structure’ => ‘has_trailing_slash’,
‘cache_expires’ => 1,
‘cache_expiry_time’ => 10,
‘clear_site_cache_on_saved_post’ => 0,
‘clear_site_cache_on_saved_comment’ => 0,
‘clear_site_cache_on_saved_term’ => 0,
‘clear_site_cache_on_saved_user’ => 0,
‘clear_site_cache_on_changed_plugin’ => 0,
‘convert_image_urls_to_webp’ => 1,
‘mobile_cache’ => 1,
‘compress_cache’ => 1,
‘minify_html’ => 0,
‘minify_inline_css_js’ => 0,
‘excluded_post_ids’ => ‘wp-login.php, 15’,
‘excluded_page_paths’ => ”,
‘excluded_query_strings’ => ‘/^(?!(fbclid|ref|mc_(cid|eid)|utm_(source|medium|campaign|term|content|expid)|gclid|SuperSocializerAuth|fb_(action_ids|action_types|source)|age-verified|usqp|cn-reloaded|_ga|_ke)).+$/’,
‘excluded_cookies’ => ‘/^(wp-postpass|wordpress_logged_in|wordpress_sec|comment_author|(woocommerce_items_in_cart|woocommerce_cart_hash)_?)/’,
);

I can provide any other detail required.

I was suspecting about WebP Express plugin which also parses html to rewrite images in wepb format but I already tried deactivating it with no luck. Also tried deactivating Autoptimize.

Maybe a security config can affect? I am using HSTS and CSP configuration in htaccess

@javierdemuga HSTS CSP and some security headers I also use are not the reason, because I deactivated all without effects.

@javierdemuga, thank you. That’s exactly what I needed. ?? For the next step, can you please try disabling the cache compression setting in your Cache Enabler settings? Please let me know when this has been completed.

Gzip compression disabled ??

@javierdemuga, thanks for the confirmation. That ruled out any compression-related issues. For the next step, can you share your Site Health Info, which can be obtained by going to the WordPress dashboard > Tools > Site Health > Info > Copy site info to clipboard. This can be shared through our contact form while referencing this thread if you prefer.

info sent

Hi Corey, what I’m observing is that activating the Cache Enabler plugin takes an extremely long time, around a minute. The server is powerful and it is definitely not due to the load or the database. For me it is an indication that CacheEnabler cannot create something, but I cannot find any information in the php logfie. Usually, according to the previous version, it is activated in a few seconds, as with any other plugin. Can you tell me what CacheEnabler does? Is there an unintentional PHP intrusion that is blocked by our server because you are calling something unorthodox with php? We have an intrusion protection, an active protective mechanism that evaluates and monitors log files in real time, which prevents malicious code from being smuggled into the server. thanks

@coreyk
Tried before uninstalling and installing again with no luck.

Sent site info by the contact url you posted.

@coreky

Maybe that can help, while updating to version 1.8.2 I got some Warnings

PHP Warning: chmod(): Operation not permitted in /usr/home/ceroresiduo.com/web/wp-admin/includes/class-wp-filesystem-direct.php on line 173

This Warning appeared 14 consecutive times, the update hang the server for around a minute.

It could be related to an absolute path / security restriction as i am in a shared hosting environment?

@javierdemuga and @jordiniubo, thanks for the information sent through our contact form. I received this and it is very helpful. I’m still digging into these details of your specific setups and trying to replicate what is occurring for you.

@agenciesfirst, what occurs during the plugin activation can be found here. The code for this is here. You’re correct, it taking that long to activate is abnormal. Does your security system indicate anything was blocked during this process?

@javierdemuga, that error you received during the update to 1.8.2 is very helpful. As far as I’m aware that will occur when the server user does not have permissions to call chmod(). Are you able to update these permissions to allow this to be called? If you have a managed hosting provider they may be able to assist with making sure this is set properly (if it is allowed). The odd thing is this was introduced in the 1.7 branch, so maybe something on your server happened to be updated in the meantime?

Hi Corey, in the meantime the plugins has normal activating speed without problems. The problem was, the ‘web’ directory must have chmod 755 and switched back automatically to 744. Now stayed in 755. Activating normal, but again, no cache directory declared on NGINX = no chaching! The version 1.7.2 works perfect, what is so fundamental different in 1.8? I am frustrated. Have you rewritten cache enablers? Do you have to give NGINX new instructions that I don’t know about? thanks

• This reply was modified 3 years, 6 months ago by agenciesFirst.

@agenciesfirst, great, I’m glad to hear that. Just a reminder that the cache directory is ONLY created if a static HTML file is created. It’s never created on plugin activation. Another reminder is that the cache directory can be completely deleted upon the cache being cleared. A static HTML file being created is not affected by the server type, but it can be affected on the server permissions (whether that’s for the server user or files/directories).

The changes introduced can be found in the changelog or the GitHub repository. It’s an open source plugin so you have access to it all. There is likely one thing that is causing this, which is why I’ve been trying to go down a line of troubleshooting steps with you to identify this. However, that has been difficult as I still don’t have the information that I’ve requested a couple times. Eventually Cache Enabler will be able to tell the reason, but that handling hasn’t been able to be built yet.

I’d really like to get this resolved for you. If you can allow me to go through these steps that’d be helpful. They all have a meaning and are not pointless. So, can you please provide your Site Health Info through our contact form?

Ok, I’ll sending you all information to the contact channel soon as possible.