MarcGuay

Makes sense, thank you!

Fixed for me, thank you.

Running into this as well.

Working, thank you!

I found that you need to reference it by the full namespace path e.g. $d = new WebberZone\Contextual_Related_Posts\Frontend\Display();

Another way:

add_theme_support( 'disable-layout-styles' )

ref: https://make.www.ads-software.com/core/2022/10/10/updated-editor-layout-support-in-6-1-after-refactor/

Although it “shouldn’t be a problem” we all know that it still could be!

I have 2 cookies set. One like the one you described and a second with everything the same except the cookie ID is _ga.

@m440 Are you entering the CookieYes settings manually in the WP admin or have you connected it to the webapp and have the settings managed there? I have it connected to the webapp.

Sorry I didn’t notice the follow up questions. My solution was to move the hardcoded GA code to the google-analytics-for-wordpress plugin and it now works as expected.

The GA code was conditionally included using the following:

<?php if (conditionally_display_gtm_tag()) : ?>
<!-- Google Analytics script -->
<?php endif ?>

function conditionally_display_gtm_tag() {
    
  //if cookieyes cookies are set
  if (isset($_COOKIE['cookieyes-consent'])) {
    
    // Read current user consent
    $CookieConsent = array_column(array_map(function ($pair) {
      return explode(':', $pair);
    }, explode(',', $_COOKIE['cookieyes-consent'])), 1, 0);
    
    //checking whether functional cookies are accepted
    if (filter_var($CookieConsent['analytics'], FILTER_VALIDATE_BOOLEAN)) {
      return true;
    }
  }
}

I did a similar integration on a custom non-WP site that required disabling GA via JS before reloading the page so that the cookies were not reset. The docs for this are here: https://developers.google.com/tag-platform/security/guides/privacy#turn-off-analytics.

After narrowing the problem down to a relationship between cookies and the Woocommerce plugin I believe the issue was related to this Woocommerce bug: https://github.com/woocommerce/woocommerce/pull/43504.

Thanks for your help.

That definitely seems to match the problem, thanks Peter!

I searched and found no other .htaccess files that are trying to modify this variable. The user.ini modification is working for frontend pages (as I echoed phpinfo in a theme file and it recoginizes the auto_prepend_file value). However, I inspected the call that Wordfence makes to generate the diagnostic phpinfo output and saw that it is an admin-ajax call. So I echoed phpinfo inside the wp-admin/admin-ajax.php file and the value is not set. Can you think of a reason the user.ini instructions would be respected in theme files but not in admin-ajax?

Curious, I see that auto_prepend_file is no valuein the Wordfence diagnostic report but when I add a file to my server which echos phpinfo() it is pointing to the WAF file. Any idea on what could explain this difference?

I tested echoing phpinfo() inside one of the theme’s template files and it also has the correct value for auto_prepend_file.

• This reply was modified 1 year, 3 months ago by MarcGuay.

Thanks again for your help. I think there was a misunderstanding, auto_prepend_file in phpinfo() is correctly displaying the path to the wordfence-waf.php file. Regardless, I tried the htaccess approach and observed no change.

Commenting for visibility in case this thread has been lost again.