Rui Guerreiro
Apr 8, 2022, 9:55:04 AM4/8/22
to AtoM Users
Hi everyone!,
The archivist responsible for our AtoM has received in Google Analytics a warning on GA type of key change, UA- to G-, that will happen next year, so she contacted the IT department to apply this change worried on statistics functionality loss...
To reply to her request I fiddled with config/app and that didn't work. Then searching a bit in github, though I never programmed in PHP, nor I know what am I doing in AtoM!, this hack seams to work:
- in config/app.yml a new property to prevent writing of template _footer GA block and write new GA block next to <head> tag
# Google Analitycs:
# Set a GA property API key to track page view hits.
# E.g.: UA-1234567-89
google_analytics_api_key:
# hack for v4 keys -> ga block on <head>
google_analytics_api_key_4: G-XXXXXXXX
- apps/qubit/config/qubitConfiguration.class.php , function responseFilterContent
public function responseFilterContent(sfEvent $event, $content)
{
ProjectConfiguration::getActive()->loadHelpers('Javascript');
$gaKey = sfConfig::get('app_google_analytics_api_key_4', '');
if (!empty($gaKey)) {
$newHead = '<head>'.PHP_EOL;
$newHead .= '<!-- Global site tag (gtag.js) - Google Analytics -->'.PHP_EOL;
$newHead .= '<script async src="https://www.googletagmanager.com/gtag/js?id=gaKey"></script>'.PHP_EOL.'<script>'.PHP_EOL;
$newHead .= 'window.dataLayer = window.dataLayer || [];'.PHP_EOL;
$newHead .= 'function gtag(){dataLayer.push(arguments);}'.PHP_EOL;
$newHead .= "gtag('js', new Date());".PHP_EOL.PHP_EOL;
$newHead .= "gtag('config', 'gaKey');".PHP_EOL."</script>";
$newHead = str_ireplace('gaKey', $gaKey, $newHead);
return str_ireplace('</head>', javascript_tag('jQuery.extend(Qubit, '.json_encode(array('relativeUrlRoot' => sfContext::getInstance()->request->getRelativeUrlRoot())).');').'</head>', str_ireplace('<head>', $newHead, $content));
}
return str_ireplace('</head>', javascript_tag('jQuery.extend(Qubit, '.json_encode(array('relativeUrlRoot' => sfContext::getInstance()->request->getRelativeUrlRoot())).');').'</head>', $content);
}
{
ProjectConfiguration::getActive()->loadHelpers('Javascript');
$gaKey = sfConfig::get('app_google_analytics_api_key_4', '');
if (!empty($gaKey)) {
$newHead = '<head>'.PHP_EOL;
$newHead .= '<!-- Global site tag (gtag.js) - Google Analytics -->'.PHP_EOL;
$newHead .= '<script async src="https://www.googletagmanager.com/gtag/js?id=gaKey"></script>'.PHP_EOL.'<script>'.PHP_EOL;
$newHead .= 'window.dataLayer = window.dataLayer || [];'.PHP_EOL;
$newHead .= 'function gtag(){dataLayer.push(arguments);}'.PHP_EOL;
$newHead .= "gtag('js', new Date());".PHP_EOL.PHP_EOL;
$newHead .= "gtag('config', 'gaKey');".PHP_EOL."</script>";
$newHead = str_ireplace('gaKey', $gaKey, $newHead);
return str_ireplace('</head>', javascript_tag('jQuery.extend(Qubit, '.json_encode(array('relativeUrlRoot' => sfContext::getInstance()->request->getRelativeUrlRoot())).');').'</head>', str_ireplace('<head>', $newHead, $content));
}
return str_ireplace('</head>', javascript_tag('jQuery.extend(Qubit, '.json_encode(array('relativeUrlRoot' => sfContext::getInstance()->request->getRelativeUrlRoot())).');').'</head>', $content);
}
We are using AtoM 2.6.2 and waiting to upgrade to 2.7.
Is there a way to properly use GA 4 G-XXXXXXXX in version 2.6.2? Will it be implemented in version 2.7?
Thanks
Dan Gillean
Apr 11, 2022, 9:48:49 AM4/11/22
to ICA-AtoM Users
Hi Rui,
Thanks for bringing this to our attention. Given that I don't think the switch to GA4 was announced when AtoM 2.6.2 was released, there's no official support for G4 in that release.
To ensure we address this before July 1st, 2023 when Universal Analytics will be deprecated, I've filed the following issue ticket:
As noted on the ticket's comments, I've tagged this for consideration in the upcoming 2.7 release. However, whether or not a fix is included in that particular release may depend on what is involved in supporting the transition. In general, anything that requires a database schema migration we only include in major releases. Given that there's been a longer-than-expected delay between releases 2.6 and 2.7, if a schema migration is required for G4 support, then I would personally want to prioritize support in 2.7 to ensure that no matter what happens with 2.8 release plans, there is a fix available by the time the deprecation date arrives. However, if no schema migration is required, then we will probably not include a fix immediately in 2.7 (to avoid delaying the release any further), and instead aim for a 2.7.x future minor release to include a patch for this.
Either way, we're now aware of this issue and will look into options for addressing it in the future. We've still got a little over a year to find the best solution!
Cheers,
he / him
--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/a6d1e583-1a45-48d6-9911-d5fc0e28c3fan%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages