Skip Navigation

[Resolved] How to create a GDPR consent for Toolset Maps

This thread is resolved. Here is a description of the problem and solution.

Toolset Maps lets us insert Google Maps, which in turn use Google's scripts to gather data from visitors of that map.
How can we create a consent for that asks the visitor to agree BEFORE the scripts are loaded and data potentially gathered by Google?

There are 2 solutions:

0% of people find this useful.

This support ticket is created 4 years, 10 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- - 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00
- - - - - - -

Supporter timezone: Asia/Ho_Chi_Minh (GMT+07:00)

This topic contains 17 replies, has 2 voices.

Last updated by Andreas K. 4 years, 9 months ago.

Assisted by: Beda.



I am using Toolset Maps along with the plugin "GDPR Cookie Consent" from webtoffee (which is one most widely used and fine plugins for gdpr/cookie consent/bar/popup etc. with 500.000+ active installs).

The plugin (pro/paid version) has a very nice function called "Script Blocker", where you can select various known third party scripts to block before the user has given consent - among these "Google maps embed”. Everything is fine when blocking everything but “Google maps embed” which for some reason results in the cookie banner suddenly being hidden as well. So somehow the scripts or css of the two must conflict in some way.

I actually had the same experience last week testing the site on older mobile devices, that could not display your maps (as you acknowledged here: which also made the cookie banner disappear, but only on the pages with Toolset Google Maps on them. As I don't have the luxury to not support older devices, I implemented a javascript to detect these devices and hide the Toolset Google Maps for them, which made the Cookie banner (which is more important than the map if I have to compromise) reappear.

So it seems to me that these two very fine and popular plugins conflict when the maps are blocked (either intentionally or by older devices/browsers).

Can you look into this and resolve it somehow?


We are aware of the general issue you try to address (GDPR and Google Maps consent).

We have plans to adjust this issue directly in Toolset.
However, given the concern is not geolocation permission (this is already handled) but the data Google (not Toolset) collects like the IP of the user, before even displaying a map, there is a need for a consent, before the scripts are even loaded, and that, is not possible easily with Toolset Maps scripts because they already act (partially) on page load.

Hence, if you'd block them (no matter how) they'd be loaded to later after if the client consents.

There are solutions to this, and we have plans to attack this issue, however, it is preliminarily slated for 1 version ahead of the next, at minimum. This may change, as development goes along.

There is currently no safe way to not load the scripts of maps - it would affect it features later when used.

I can, however, test your solution, and check if we can find something to fix the compatibility issue after we adjusted the code in Toolset.
Could you for this purpose send me a copy of that Plugin and instructions about how to replicate the precise issue you describe?

I enabled private replies to allow secure communication in the next reply.



Hi Beda

I have just tested the script blocking functionality of the "GDPR Cookie Consent" plugin with Google Maps script blocking turned on and the network tool Little Snitch running active on my computer (a tool for notifying you about network connections with the option to block them).

When I turn on the Google Maps script blocking I get no notification about the browser trying to connect to, and when I turn it off, I do get a notification.

So the script blocking does seem to work – it just somehow makes the cookiebanner disappear on the pages with Toolset Maps on them for some reason (js/css conflict I would presume).

Here is the plugin: hidden link

You activate the plugin and go to: GDPR Cookie Consent > General - and make sure the cookie bar is turned on and set as a banner (footer).

And then go to Script Blocker (via the menu to your left) - and make sure it is turned on and that Google Maps Embed is also turned on the list below.

Btw - the plugin also has a nice way of blocking stuff via a shortcode ( [cookie_after_accept] ... [/cookie_after_accept] ) until the user has given consent, but that does not work either for me when I put it around the my maps view shortcode in the frontend. It just shows the views short code on the frontend...
I have also tried to implement it in the views code (after having registered it as a third-party shortcode in the Toolset settings), but cannot figure out where to put it without it making Toolset show shortcodes ([wpv-layout-start] [wpv-items-found] .. etc) and so on on the frontend. But it does block the views, when no consent has been given, so that part does work, I just renders shortcodes and so on at the same time, which is not pretty to look at on the front end... Though this is also not a perfect solution, as you cannot, as far as I can see, put in a message where the map should have been, to tell the user, that it will not shown until consent is given... So the user doesn't know, that the map is missing and why...

Oh, and I am not sure what "private replies" is, please explain 🙂


I forgot to mention, that the second option mentioned with the [cookie_after_accept] ... [/cookie_after_accept] shortcode only blocks the wrapped content/code, and not the external server calls from the scripts, in the head and so on - as my network tool also notifies me about it, unlike the first mentioned option. So I guess the second one is completely ruled out then. But it could be useful for iframes fx and if one could put the shortcode around all the external maps calls in the head and so on (but that would probably not be possible or easy to do, I would guess).


I will update you shortly here how this precisely proceeds.

Eventually, someone from the Product Management will chime in directly here.

Note, for the technical issue mentioned there is little we can do right now:
The scripts must be loaded so for Maps to work, and cannot be consented in a clean way so the visitor can accept or deny to use the map.
Removing them until user consent is provided, means the scripts will be loaded too late.

What you could do is make the visitor consent thru an internal setting stored in a cookie or even logged in user.
A simple checkbox for consent would suffice.

If checked and submitted the form reloads your site and everything loads from thereon.
If not consented the user has to be redirected somewhere else, like the referrer URL or any other place not on your site.

This sounds harsh, but on the other end, it's the only solution I see right now to "exclude" scripts if a visitor doesn't consent, related to the maps service.


I'm downloading the plugin to check if someone could use it to create such consent workflow - however, given Maps doesn't work if we do not load the scripts, I fear there'll be little we can do.

I will check this as well with other Maps Plugins, and our Documentation team is working on something to communicate the appropriate approaches as well.

I'll update you here as soon I have other news.


Turning on Google maps script blocking (default in the Plugin) does not break the Cookie Baner on my end.

However as soon as a Map is inserted in the page visited, then (expectedly) the map is not rendered, but the Cookie Banner is gone too.

There are 2 errors:
Uncaught ReferenceError: jQuery is not defined
Uncaught ReferenceError: google is not defined

The first error can be solved with this:

The second issue is due to the Google Maps script not loaded, but other code (of Toolset) asking for it when rendering the map.

That JS error likely simply breaks subsequent JS functionality and hence also the Cookie Banner.

There's as well some CSS missing when this happens:

padding: 13px 20px;
    box-sizing: border-box;
    background-color: rgba(255, 255, 255, 0.9);
    color: rgb(51, 51, 51);
    font-family: inherit;
    bottom: 0px;
    position: fixed;
    display: block;

It's usually added to the Div ID cookie-law-info-bar.
Not when the JS error happens, and that is because the style is added/removed dynamically depending on if whether the visitors agree or not.

Note, this approach can not work with Toolset.
It does not reload the page after the consent, and the scripts are not loaded. The map cannot work like this. Actually as far I know, no map should work, in this case
I also don't see how the plugin saves the users choice, because reloading the page just shows the consent again - this even without Toolset.

Now, testing this with other plugins like WP Google Maps, the map is actually displayed even if I do not consent.
If the map is displayed most likely Google already has its data. Fact is, with that plugin you don't encounter the issue reported here for Toolset Maps.

I'm now downloading and installing the Little Snitch to check what actual data is shared without consent using WP Google Maps plugin, I fear something just skips the consent there.

I'll then share all my findings with the developers.


Just as I suspected, Little snitch reports call to when WP Google Maps is used, even if the script is blocked by the GDPR plugin
Verdict: that plugin does whatever it does to hide the call and do it anyway.

Toolset Maps as far I saw at least does NOT call the scripts if blocked in the GDPR Cookie Consent plugin.

I am discussing with the Maps developer what we could do about the JS issue and missign CSS, however given the issue sources from JS errors related to missign scripts, I think we can not do much and those scripts simply need to be loaded, to have Maps working (which of course difficults the consent a lot)

I will feedback here as soon as I have more news.


Hi Beda

Thank you so much for helping!

I have found a work-around, that seems to be working for me. Maybe you can try to replicate it on your end.

I (also) found that errors seem to stem from wp-content/plugins/toolset-maps/resources/js/wpv_addon_maps.js not working when some needed code is blocked/missing.

So I implemented a function as with a little help from in the plugin documentation: hidden link , that targets the rest of the mentioned Toolset code, and voila, now the cookiebar shows and the map can be hidden at the same time:

function scripts_list() {
    $scripts = array(
            'id' => 'toolsetmaps',
            'label' => 'Toolset Maps',
            'key' => array('wp-content/plugins/toolset-maps/resources/js/wpv_addon_maps.js', 'wpv_addon_maps.js', 'wpv_addon_maps', 'wpv-addon-maps'),
            'category' => 'maps',
            'status' => 'yes'
    return $scripts;

add_filter('cli_extend_script_blocker', 'scripts_list', 10, 1);

You also need to make sure that a cookie is assigned to the category that "Google Maps embed" and my custom cookie "Toolset Maps" is assigned to called "maps" in my case: hidden link . And I also set the settings to reload the page when the user accepts/rejects cookies.

That should be it, if I haven' forgotten anything. Seem to work perfectly 🙂

And little snitch on my end doesn't seem to detect any calls for this work-around - only when maps are show/the cookie is accepted - and it actually blocks the maps data/image from showing (except for the toolset markes) when the connection is rejected in little snitch.


OK, I have no more news here at the moment.

a) Toolset Maps offers no method to let a user consent all what's required before the map is actually loaded.
b) It is not clear we are going to implement something like it, or add compatibility with a plugin allowing it, or else

I will keep you up to date.


Our replies crossed, yes, makes sense.

That is what I meant with Toolset Maps expects the scripts as calling functions from in other places.

But removing them will have effects on how maps work.
You will need to reload the page at least, after you consent, as otherwise the maps will not be pulled correctly.
This may also affect later search and lists or markers when using AJAX updated Views.

That is why I cannot confirm the solution as you found it working to be the right one.

I will await some more confirmations or news from Developers about our plans.

I cannot fully baptize custom solutions that are not vetted and documented, in such cases.


The Toolset Maps developer actually provided me a good idea, I am not sure why I did not think about it myself:
Why not create a very simple form in Forms for consent, and encase map in a Views conditional block depending on that consent?
If the map is not rendered, the API won't be loaded.

This is as simple as it gets and uses only Toolset Features.
For not logged in users a cookie needs to be created, with the Forms API you could do this on cred_save_data().
Then you can use setcookie() in that code to set a cookie with user consent.

Then, submitting the form with consent will reload the page in question - it requires a little more work than with the GDPR Cookie Consent but could be a solution for now.

Do you think such a solution could help you on the site you work on now?


The script you shared here seems a good solution, I see after testing.
As -long you reload the page after the consent, this should work fine.

Please understand that if you do not reload the page then several map features might not work, whether in Views or only Maps.

I'll also keep you updated here about the other processes we may initiate in regard.


It was decided to not add such consent feature to Toolset Maps.
I was testing your proposed solution in-depth and see, after consenting and the page reloads, the map still isn't shown.

What do I miss?

1. I have created a Map, on a page, displaying a marker
2.GDPR plugin has a custom Cookie category maps, to which both Google Maps and Toolset maps are assigned. Plugin settings are set to reload the page after consent is given and to track consents.

However, after giving consent I still see no map.

I must miss something, given you had success with this. Yesterday I only tested the error logging, not the display itself.

I then added also a new COOKIE itself, connected that to my cookie category, assigned to my scripts that are blocked.
Duration and type is "session" and sensitivity is necessary.

This is the solution, it seems

Can you confirm my steps?
(Of course, additionally the custom filter needs to be applied)


Concluding on this issue, please find my details below.

There will be no inhouse consent mechanism for this in Toolset.
There are possibilities to resolve this either with Custom Code, with Toolset and little HTML + JS, or 3rd Party Software abd API.
Below 2 propose solutions.

### Approach 1, Paid Pro solution

1. Install [GDPR Cookie Consent PRO](hidden link) plugin. It allows you to block Google Maps scripts in its settings. Additionally, you will need to block a few more scripts of Toolset Maps, by adding this to your Theme's functions.php:

function scripts_list() {
    $scripts = array(
            'id' => 'toolsetmaps',
            'label' => 'Toolset Maps',
            'key' => array('wp-content/plugins/toolset-maps/resources/js/wpv_addon_maps.js', 'wpv_addon_maps.js', 'wpv_addon_maps', 'wpv-addon-maps'),
            'category' => 'maps',
            'status' => 'yes'
    return $scripts;
add_filter('cli_extend_script_blocker', 'scripts_list', 10, 1);

See hidden link API doc of the GDPR Cookie Consent PRO plugin.
2. Create a new GDPR Cookie Consent PRO plugin “Cookie category”, to which both Google Maps and Toolset maps scripts (blocked) have to be connected, see their DOC:
hidden link
3. Create a new GDPR Cookie Consent PRO plugin “Cookie”, connected that to above cookie category. Duration and type is “session” and sensitivity is “necessary”.

This will allow visitors to turning off and on maps scripts as they like, and maps will only display/load scripts if allowed.


### Approach 2, Toolset and Custom HTML/JS solution

1. Create a CT that is not assigned anywhere, it will be your “consent” form, so to say.
2. In that Content Template, you insert a custom HTML Consent Form. However you will design it is up to you, below a minimal example to get approval or denial from visitors and store that as a cookie valid for 30 days. of course, this is all up to Webmaster:

  <select name='ts_maps_consent'>
    <option value="yes">Yes</option>
    <option value="no">No</option>
 <input type="button" value="Go!" id="submit" onclick="putCookie(document.getElementsByTagName('form'));">

3. Add some JS to the CT, to set the cookie according what visitors will select in above form:

//Set cookie validity time
var today = new Date();
var expiry = new Date(today.getTime() + 30 * 24 * 3600 * 1000); // plus 30 days
//Set cookie function, fired later when submitting form
function setCookie(name, value){
	document.cookie=name + "=" + escape(value) + "; path=/; expires=" + expiry.toGMTString();
//When form is submitted
function putCookie(form){
       //Set our cookie
	setCookie("ts_maps_consent", form[0].ts_maps_consent.value);
       //hardreload page
       return true;

4. You just created your Consent form. Now you need to (wherever you want clients to interact with it) insert this wrapped in an HTML Conditional, like:

[wpv-conditional if="( '[ts-generic-get-cookie-value]' eq 'yes' )"]
    [wpv-map-render map_id="map-id"][/wpv-map-render]
[wpv-conditional if="( '[ts-generic-get-cookie-value]' ne 'yes' )"]
    [wpv-post-body view_template="consent"]

When you now visit the page where this is inserted, you will be asked to approve the scripts in the select. Submit, the page reloads and you will see the map.

Of course, this is a very minimal implementation but it shows how you can set ANY consent using Toolset.

Please let me know if there are any doubts on the issue left.

I also want to forward our appreciation for the patience and resolution of the particular issue you have shared here.

Thank you!

This ticket is now closed. If you're a Toolset client and need related help, please open a new support ticket.