Oleg Meglin

Hi @rockfire,

I used your code and your code returns false. That was the goal. I haven’t changed anything about that. But the actual filter value remained unchanged on true.

I changed the source code (includes/api/class-endpoint-api.php from line 307) a bit to understand what happens.

From this query here:

if ( apply_filters( 'wp_rest_cache/skip_nonce_caching', true, $this->request, $this->request_uri ) && ! is_null( $wp_nonce ) ) {
    return true;
}

I did this here:

$skip_nonce_caching = apply_filters( 'wp_rest_cache/skip_nonce_caching', true, $this->request, $this->request_uri );
error_log( $skip_nonce_caching );
if ( $skip_nonce_caching && ! is_null( $wp_nonce ) ) {
    return true;
}

The logged value was true, although the filter was overridden to false.

Hello @rockfire ,

Thanks for the tip. You’re right, it was indeed the nonce header. Unfortunately, the hook in the sample code didn’t work. The value remained unchanged on true and could not be overwritten. I tried to debug it, but without success. Since I was running out of time on this project, I gave up.

I’ve made life easier for myself and now use axios because I don’t need the nonce header. The endpoints are public.

How can this be due to the Apache config? If you have taken steps to block the path, then the path should be blocked. Nothing special is defined in my Apache configuration. Directory listing is of course disabled.

I’ve now looked at it myself in detail. I recognized the following:

• You have an empty index.html file in the directory.
• I can’t find a .htaccess file in the plugin directory that restricts access.
• In the WordPress main .htaccess file, no rule is included that restricts access.

This means that all the requirements are met for an empty page to be returned with status code 200. In this case my Apache server is behaving correctly. I’m going to assume that your test environment has a special Apache configuration because it’s not behaving normally.

Hi @vmarko,

the files/folder permissions are the recommended one:

• directory permissions 755
• file permissions 644

• This reply was modified 1 year, 8 months ago by Oleg Meglin.
• This reply was modified 1 year, 8 months ago by Oleg Meglin.

Hi @vmarko

did you test it on a fresh installation or just on an existing one? Do you have any additional .htaccess rules that are not set by default?

Hi @vmarko,

thank you for your reply.

To reproduce, I just installed a complete flesh WordPress System with only W3 Total Cache installed and configured. I get the same behavior as with the other sites with this plugin.

Here is the demo installation:
https://demo.megl.in/wp-content/plugins/w3-total-cache/pub/

Let me know if you need any further information.

EDIT: I checked the “.htaccess” file. It seems to be complete.

• This reply was modified 1 year, 8 months ago by Oleg Meglin.
• This reply was modified 1 year, 8 months ago by Oleg Meglin.

Hi @vmarko,

I tried to replicate the errors on a fresh installed WordPress system. I installed a few of the Plugins that are also installed on the system with the errors. However, only a few plugins that I considered critical (like Really Simple SSL Pro and Siteground Security). I couldn’t replicate the errors either.

Unfortunately, I cannot make the link to the affected page public. I’m also running out of time to do more research on this issue. So I would leave it alone for now.

There could be so many causes. The system is also a bit more complicated:

• The system is a bit old (built in 2016).
• The theme does not support Gutenberg (Classic Editor mode enabled).
• It used to be a multisite and has been converted to a single site.
• There are 33 plugins installed.

If I ever find the cause of the error, I’ll let you know. Thank you again for your commitment.

Hi @vmarko,

thank you for your commitment.

Yes, I’m checking the correct .htaccess file. I suspect the rules disappeared because the .htaccess file was accidentally overwritten. So the missing rules shouldn’t be a bug in your plugin.

However, it would be nice if your plugin catches the errors in such a case and gives you the opportunity to restore the rules.

When I visit the page you suggested (Performance > Install) I get more errors. One of them is new:

[07-Mar-2023 08:54:59 UTC] PHP Warning:  Undefined variable $rewrite_rules in /www/www.example.com/public/wp-content/plugins/w3-total-cache/BrowserCache_Environment.php on line 97
[07-Mar-2023 08:54:59 UTC] PHP Warning:  foreach() argument must be of type array|object, null given in /www/www.example.com/public/wp-content/plugins/w3-total-cache/BrowserCache_Environment.php on line 160
[07-Mar-2023 08:54:59 UTC] PHP Warning:  Undefined variable $other_areas in /www/www.example.com/public/wp-content/plugins/w3-total-cache/inc/options/common/header.php on line 372
[07-Mar-2023 08:54:59 UTC] PHP Fatal error:  Uncaught TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given in /www/www.example.com/public/wp-content/plugins/w3-total-cache/inc/options/common/header.php:372
Stack trace:
#0 /www/www.example.com/public/wp-content/plugins/w3-total-cache/inc/options/common/header.php(372): count()
#1 /www/www.example.com/public/wp-content/plugins/w3-total-cache/inc/options/install.php(8): require('...')
#2 /www/www.example.com/public/wp-content/plugins/w3-total-cache/Generic_Page_Install.php(28): include('...')
#3 /www/www.example.com/public/wp-content/plugins/w3-total-cache/Base_Page_Settings.php(71): W3TC\Generic_Page_Install->view()
#4 /www/www.example.com/public/wp-content/plugins/w3-total-cache/Root_AdminMenu.php(289): W3TC\Base_Page_Settings->options()
#5 /www/www.example.com/public/wp-includes/class-wp-hook.php(308): W3TC\Root_AdminMenu->options()
#6 /www/www.example.com/public/wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters()
#7 /www/www.example.com/public/wp-includes/plugin.php(517): WP_Hook->do_action()
#8 /www/www.example.com/public/wp-admin/admin.php(259): do_action()
#9 {main}
  thrown in /www/www.example.com/public/wp-content/plugins/w3-total-cache/inc/options/common/header.php on line 372

What I tried to restore the rules:

1. Deactivate and activate the Plugin. Didn’t help.
2. Changed various settings to force the plugin to re-modify the .htaccess. Didn’t help.
3. Run the Setup Guide again. Didn’t help.
4. Disabled and enabled the Browser Cache to force the plugin to re-modify the .htaccess. Didn’t help.

Again as a summary to avoid misunderstandings:

• We are talking about the standard .htaccess file, which is located in the root directory of the WordPress installation.
• This .htaccess file should have the file permission “644”.
• This .htaccess file should contain a few rules created by your plugin.

Are these statements correct?

Is there a way to force the plugin to create the rules?

Hello @vmarko,

sure.

Browser Cache is enabled. Here is a screenshot with all Settings:

I don’t see any W3TC rules inside the .htaccess file.

Hi Marko,

I have to correct one of my given information. PHP 8.0.27 is in use and not 8.1.14.

Hi Marko,

thank you for the reply. Here are some more informations:

• Webserver: Apache 2.4
• PHP: 8.1.14
• Using the recommended WordPress file permission: 644 on files and 755 on folders

Hi guys,

I don’t have a solution, but I have a workaround to reduce the warning only to the pages with a contact form:

/**
 * Removes the CF7 scripts if the shortcode is not on the page
 */
function mm_deregister_cf7_scripts() {
    if (class_exists('WPCF7')) {
        global $wp_query;
        $content = '';

        if ($wp_query->post) :
            $content = $wp_query->post->post_content;
        endif;

        if (!has_shortcode($content, 'contact-form-7')) {
            wp_deregister_script('google-recaptcha');
            wp_deregister_script('contact-form-7');
        }
    }
}

add_action('wp_enqueue_scripts', 'mm_deregister_cf7_scripts'); 

This workaround also has the additional advantage that the CF7 JavaScript is not loaded unnecessarily.

• This reply was modified 4 years, 5 months ago by Oleg Meglin.

Sure. Pretty much every WordPress with installed Contact Form 7 and activated Google reCAPTCHA. I’ve just created a fresh installation for better understanding:
https://demo.megl.in

The above page is a complete fresh installation without any other plugins installed.

Additionally, I tested it in other browsers. With the following result:

Firefox (v69.0.2)
Content Security Policy: Ignorieren von “‘unsafe-inline'” innerhalb script-src: ‘strict-dynamic’ angegeben
Content Security Policy: Ignorieren von “https:” innerhalb script-src: ‘strict-dynamic’ angegeben
Content Security Policy: Ignorieren von “http:” innerhalb script-src: ‘strict-dynamic’ angegeben
Content Security Policy: Ignorieren von “‘unsafe-inline'” innerhalb script-src: ‘strict-dynamic’ angegeben
Content Security Policy: Ignorieren von “https:” innerhalb script-src: ‘strict-dynamic’ angegeben
Content Security Policy: Ignorieren von “http:” innerhalb script-src: ‘strict-dynamic’ angegeben
Content Security Policy: Ignorieren von “‘unsafe-inline'” innerhalb script-src: ‘strict-dynamic’ angegeben
Content Security Policy: Ignorieren von “https:” innerhalb script-src: ‘strict-dynamic’ angegeben
Content Security Policy: Ignorieren von “http:” innerhalb script-src: ‘strict-dynamic’ angegeben

Safari (v12.1.2)
[Error] The source list for Content Security Policy directive ‘script-src’ contains an invalid source: ”strict-dynamic”. It will be ignored.
[Error] The source list for Content Security Policy directive ‘script-src’ contains an invalid source: ”strict-dynamic”. It will be ignored. (x2)

Obviously, the problem should be the Google ReCAPTCHA script. Any suggestions for a workaround?