Pro theme conflicts with script blocker of Borlabs Cookie - making it unable to find scrips (e.g. Google) anymore

[TrendRaider]

Hi,

we’ve got complex and serious problem and are hoping you can help us with this:

We are using Pro and “Borlabs Cookie” (a GDPR Consent plugin) along with the plugins “Google Tag Manager for Wordpress” and “WooCommerce Google Analytics Pro” for quite a long time. To be able to use the two Google plugins according to GDPR law we needed to use Borlabs’ script blocker to block the Google Analytics and Google Tag Manager scripts as long a user hasn’t confirmed.

Some weeks ago after a theme update we noticed that GTM and GA were not blocked anymore wich is illegal. After several tests for plugin and theme conflicts I found out that when Pro is active the script blocker isn’t able to find the GA and GTM scripts anymore (even though they are still in the source text of the page). When switching to e.g. “Twenty TwentyOne” theme all is fine again. So something in one of your recent (major?) updates is causing this but I don’t have enough knowledge of JavaScript to figure something out.

I talked to Borlabs and they said they can’t help because it’s somehow a bug in your theme. They answered: “Some bug in the Pro theme seems to disturb the buffer by closing Borlabs’ buffer or by opening a buffer itself without closing this buffer. We can’t apply a workaround for such a behaviour. This is something that must be fixed by the theme’s author”

Borlabs is one of the most used GDPR plugins vor Europe and GDPR is a serious law over here. The script blocker of Borlabs is an essential feature. I am afraid this will happen to many users out there.

Thanks a lot!

[ruenel]

Hello Alex,

Thanks for writing in! To better assist your with your issue, please provide us your WP credentials so that we can log in and investigate. You can create a secure note in your next reply with the following info:
– Link to your site
– WP login URL
– WP username
– WP password
– WP Administrator Role
- Confirmation that we can access and make changes to your site
​

To know how to create a secure note, please check this out: How The Forum Works

Best Regards.

[TrendRaider]

Thanks for your help @ruenel! I really appreciate it!
I will enter the credentials to our staging site in secure note. I’ve also uploaded a video on WeTransfer where you can see all steps to reproduce the behaviour. Sadly Borlabs Cookie seems to be only available in German, so please check out my video as I tried to help you find your way through the settings. You’ll find the video along the credentials in secure note. Thanks again!

[TrendRaider]

WeTransfer is deleting the video tutorial soon, so I’ve uploaded it to a more permanent location. You can find the link in secure notes.

[alexander]

Hi @TrendRaider,

Thank you for the detailed video walkthrough of how to test the problem. I’ve tested extensively on your site, and unfortunately haven’t come to anything conclusive. I even tried a version of Pro (5.0.8) from a previous cycle (August 2021) and the same issue was occurring. It would appear that Borlabs scanner is not picking up any scripts in the head when Pro is active.

I’m not sure the buffering issue they are referring to is accurate. While Pro does use some buffering on the front end, it is always self contained - we open and close a buffer in the same function, so there aren’t outside buffers getting flushed. We’re following best practices and using the right WordPress apis to output and manage scripts.

I’m sorry, but at this time we can’t provide a solution. We don’t support third party plugins, although we try to do what we can to avoid common issues. We’ve investigated this as far as we reasonably can. From here I would recommend bringing this back up with Borlabs, with the following info:

• See if they have any inclinations why body/footer scripts are detected but not anything in the head
• Advise them we’ve checked for buffering issues but couldn’t find any. Feel free to send them a copy of Pro, or if they reach out through our contact form (https://theme.co/contact) we can create an account for their team to access our products. I’m not saying their conclusions were incorrect, but only that I couldn’t effectively find a problem like they described. I checked all the usages of object buffering in our codebase and nothing looked out of place.

Thanks! Hoping that if we work together, we can get to the bottom of this problem.

[TrendRaider]

Thank you for your help @alexander! I’ve wrote back to Borlabs and sent them your informations.

[TrendRaider]

They’ve already answered. I am trying to translate it from German to English although I don’t understand much of this technical stuff…

The script blocker of Borlabs is starting the buffer via hook template_redirect and closes it in wp_footer. So the JavaScript in the head has to be available. Basically everything in the buffer starting from < html > to right before < / body > (this tag has to be missing) has to be there. If is it not there then there has to be a buffer conflict in which Borlabs’ buffer has probably been closed and a new one was started. Our system is running fine with thousands of themes, e.g. with the default WP themes, but not with Pro theme so the error has to be in this theme.

So they say they are out. Just like you did. For us it is the dilemma that we can’t stop using Pro theme and can’t stop using Borlaks Cookie and also need the plugins which we have to be able to block with Borlabs script blocker.

Is there a place where we can download older versions of Pro? Much older than 5.0.8 from August 2021 for testing? Before we ran into the issue we used a much older version of Pro with success. But sadly I don’t remember which one.

[alexander]

Hi @TrendRaider,

Thank you for reaching out and for translating the response. I understand from your translation what they are saying. Let me start by saying we don’t make previous versions beyond the stability release of the last cycle available because we can’t support them and most of the time there are incompatibilities with the latest versions of WordPress (and WooCommerce). However, the fix is something we can implement directly in the theme files. It depends on how you manage your staging environments.

I was able to identify a potential workaround we can make in Pro but I will need FTP (or admin panel) access to safely update the files and test it. I will need to directly modify the theme files, and if it works we can consider making it an official change for the next release. Please add those credentials in a secure note and we can try it out.

---

I also think there is a better solution if Borlabs is open to changing their plugin. I apologize if this is overly technical, but I need to expound on the underlying problem. When the Cornerstone Footer Builder is active, the entire closing markup is buffered including wp_footer. This means when Borlab’s code checks the current buffer contents, they’re just looking at the footer instead of the whole page.

If they opened and closed their buffer from within wp_footer, it wouldn’t be a problem. The issue is that they have a very long lived buffer that extends over several WordPress lifecycles. While it sounds like they may have been doing this without a problem for some time now, it will be prone to conflicts with more advanced systems like Cornerstone.

Respectfully, they should be using the WordPress shutdown hook instead. While it still stretches across multiple hooks, it will be much more reliable. It would also allow capturing/rewriting scripts that users add directly in child themes, or any code inserted after wp_footer which is a common occurrence with new WordPress users.

If you can get me in touch with them, I can mention it. Or at least send them this URL so they can see the code snippet below as an example:

// This code demonstrates buffering the entirety of a front end WordPress request
// It is more resilient to edge cases like...
// - plugins that fully take over theme output
// - child theme (or custom theme) code that is added after wp_footer

add_action('wp', function() {

  if ( ! wp_using_themes() ) {
    return;
  }

  ob_start();

  add_action( 'shutdown', function() {

    $content = ob_get_clean();

    // manipulate $content

    echo $content;

  }, 0);

}, 0);

[TrendRaider]

Hey @alexander wow that’s sound good! Thank you very much! You can find ftp credentials to our staging in the secure notes of this posting. If it is working you can tell me which files are affected and I can transfer them to our live site. I will of course also send your message/the link to Borlabs. Awesome service, thank you much!

[alexander]

Thank you! That appears to have done the trick. I’ve applied the patch, and after following the steps in your video walkthrough I see all the scripts (not just those in the footer). There was a single file changed with this path: wp-content/themes/pro/framework/legacy/functions/frontend/view-routing.php

I can confirm this file has been updated in our codebase as well. This means you can safely update via automatic updates whenever our next release rolls around.

I’m glad we were able to get this worked out, and finally see the two products working nicely together. At this point Borlabs shouldn’t need to change anything, but they could still benefit from using a more resilient technique for altering HTML on the fly.

[TrendRaider]

Hey @alexander that’s fantastic! I’ve tried myself and applied it to our live site afterwards and YES IT’S WORKING AGAIN! Thanks for the early christmas present!!

[ruenel]

You are most welcome, @TrendRaider!