MaxtDesign

Hey, thanks so much for taking the time to dig into this and write it up. Updates like 1.7.6 are way more fun to ship when someone actually reads the changelog and comes back with sharp follow-ups, so genuinely, this made my day.

Let me answer these in order.

Re-prompting… You’re onto something here. Right now, closing the popup sets a short “already shown” cookie so we don’t nag, but you’re right that a dismissal isn’t really a choice. There’s a nice legal angle too. Under GDPR, closing without selecting is neither consent nor a refusal, so re-asking on a later visit is actually more defensible than re-prompting after someone explicitly declined. I’d want to ship this as an optional setting rather than default behavior (some site owners specifically don’t want any re-prompting), but it’s a good idea and it’s going on the list for a future release.

Inlining vs enqueuing… This one I want to explain properly, because it’s a deliberate design choice tied to how the plugin is built. The whole plugin runs on a “zero-footprint, performance-first” philosophy. No extra frontend HTTP requests, nothing render-blocking, nothing loaded that doesn’t need to be. A consent banner has to be on screen at first paint, so an extra network round-trip to fetch a small script is exactly the kind of thing we’re trying to avoid. Inlining means zero additional requests and the banner is ready the moment the page is.

On caching specifically. The popup only loads while it actually needs to show. The second a visitor makes a choice, the plugin stops emitting the popup CSS and JS entirely on every page after that. So an externally cached file wouldn’t really get re-served, because by the time caching would pay off, there’s nothing left to serve. The script is “show once, then disappear” by design.

On optimization plugins? it can go both ways. External files are the ones that tend to get combined, deferred, or caught by “delay JavaScript” features in the big optimization plugins, and that would break a consent gate that has to run before anything else. An inline block with its own config is usually the more predictable option for something this render-critical.

That said, you caught a good one! The inlined JavaScript currently ships with its full comments. The CSS is already minified, and there’s no reason the inline JS shouldn’t be too. I’ll get that added.

A filter for should_show_popup(). Yes, absolutely. Just the kind of clean, native escape hatch I’m happy to add, and it costs nothing on the footprint side. You’ll be able to do precisely what you described:

add_filter('mdcc_should_show_popup', function($show) {    return is_page('contact') ? false : $show;});

I’ll add that into both the render and enqueue paths so returning false cleanly skips everything.

Thanks again for the thoughtful feedback. The filter and the inline-JS minify are both easy wins I can fold into the next release, and the dismiss re-prompt goes on the roadmap. Really appreciate you taking the plugin seriously enough to push on it.

• This reply was modified 15 minutes ago by MaxtDesign.

No Problem!

Thanks so much for taking the time to point this out and the added supporting details, this was exactly the kind of writeup that makes a bug easy to track down. You were right about the cause: the popup wasn’t checking your stored consent before showing, so it kept reappearing even after you’d made a choice.

I’m just finishing up testing now and plan to push an update later this afternoon. I’ll follow up here once it’s live so you can update and confirm it’s sorted on your end. Really appreciate your help.

• This reply was modified 22 hours, 31 minutes ago by MaxtDesign.

Sorry for the long delay.

You can now update to 1.7.3 then use Loco Translate plugin.

I appreciate your efforts on this Christer. All update have been posted.

Hey there,

Thank you so much for reaching out and for the detailed explanation of what you’re experiencing. Your feedback has highlighted an important feature gap in our plugin.

What’s Happening Now:

You’re absolutely right that ‘Decline All’ isn’t preventing tracking. This is because our plugin was originally designed with an ‘opt-out’ model in mind – meaning tracking is allowed by default until a visitor explicitly declines.

What We’re Adding:

However, your report has made it clear that many sites (especially those with EU visitors or GDPR requirements) need an ‘opt-in’ model where first-time visitors are not tracked until consent is given

We’re currently developing this opt-in functionality and will be adding it as a configurable option in the plugin settings. This will let site owners choose which consent model fits their legal requirements and user base. I’m releasing version 1.7.1 in the next day or two that adds the missing first step. It’ll inject a small script into your site’s <head> section that sets everything to “denied” by default, so GTM knows not to track until the user actually gives permission.

In the Meantime:

If you need this working right away (totally understand if you do), you can manually add this snippet to your theme’s header.php file, right BEFORE your GTM code:

html

<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('consent', 'default', {
    'analytics_storage': 'denied',
    'ad_storage': 'denied',
    'ad_user_data': 'denied',
    'ad_personalization': 'denied'
});
</script>

That’ll hold you over until the update drops. Just remember to remove it after you update to 1.7.1 (the plugin will handle it automatically at that point).