Tealium

Hi @des2019,

The report relates to the ‘Advanced Tag Code’ feature within the plugin:

This was added some years ago in response to a request from a customer who had internal reasons to deviate from our standard method of loading the Tealium utag.js file.

There’s no easy way to santize the input of that field without also invalidating the intended functionality. I’m also aware of a few customers who are actively using it, so deprecating it is also not ideal.

On a standard WordPress installation there are other areas of the admin console where users with Administrator privileges can edit files and potentially inject code. For example, the file editor within the template section. One option might be to disable the Advanced Tag Code option within the Tealium plugin if we can see that the template file editor has also been disabled.

It looks like the file editor can be disabled by adding define( ‘DISALLOW_FILE_EDIT’, true ); to your wp-config file. We could potentially use this value to determine if we should enable the advanced tag code option in our plugin, on the assumption that if a user is willing to accept the risk of administrators being able to add code directly to template files, they’re probably also ok with the same functionality existing in a plugin.

However, there are probably other ways to disable template edits (e.g. directory permissions at a server level). How are you mitigating the risk of admins using the template editor on your instances of WordPress?

• This reply was modified 11 months ago by Tealium.
• This reply was modified 11 months ago by Tealium.

Hi @des2019, this is the first time we’ve been made aware of this. If you could share some more detailed information on the warnings you’ve seen we can investigate further. Thanks.

@mikeg_de thank you. The admin page was calling join() with the array to join followed by a string of the separator, this has been deprecated in PHP 8 and it is now expected that the separator will come first followed by the array to join/implode. I’ve just released version 2.1.16 to address this.

Hi @danipolo,

We’ve just released a new version of the plugin (2.1.14) which will create an additional data layer variable called user_role. You should be able to use this when creating load rules in TiQ to exclude logged in users based on role.

Hope that’s useful – we felt that removing the tag completely for logged in users might prove confusing.

Hi @danipolo,

That’s a good idea, thank you for suggesting it. I’ll look into working it into the next release.

I think the current user role should also be added to the data layer. Doing so would enable you to build load rules in TiQ around the user and achieve a similar thing with a little more control.

H Livio,

Version 2.1.10 was committed this morning, this introduces the option for a custom utag_data name.

Thanks for the suggestion!

Ian

Hi Shaun,

I’ve released a new version of the plugin (2.1.8) which includes a fix that was submitted to us through Github. I believe that it’s the same issue that you’re running into, could you update and let me know if the error is resolved?

Many thanks!

Hi,

It looks like ACF is maybe using the standard WordPress meta data concept to just store a reference to the data for each custom field, rather than the actual data.

ACF has an export feature, so you might be able to manipulate the output of that into a list of field names in a comma separated list to add to the data layer exclusions option in the Tealium plugin settings.

If you run something like this, pasting in the code from an ACF PHP export in a script outside of WordPress that should hopefully do the trick:

<?php
$names = array();

function register_field_group($groups) {
	global $names;
	foreach ($groups['fields'] as &$value) {
    	if (!empty($value['name'])) {
    		 $names[] = $value['name'];
    	}
	}
}

/* -- PASTE IN OUTPUT FROM ACF PHP EXPORT --
e.g...
if(function_exists("register_field_group"))
{
	register_field_group(array (
	));
}
*/

echo implode(', ', $names);