1 Correct answer
You have no problem placing this code fragment within a TEMPLATE.
If you're using several different templates, depending on the sections of your site, and since you're already using a proprietary aspect of DW, I'd advise you to use a LIBRARY element instead, which you'll then insert into each TEMPLATE. This way, if you need to modify GA's snipet, you'll only have to make one modification, and DW will pass it on to all the templates, and then all the pages.
For my part, I prefer to place this fra
...
26
Replies
For my part, I prefer to place this fragment just before the closing BODY, as this allows me to intercept only real user interaction, not to interfere with the loading time of real content and thus improve usability. Placing it in the HEADER benefits GA more, as it analyzes various behaviors that are favorable to it, and not really to you.
By @L e n a
There are various ways of proceeding, the simplest of which, in my opinion, is to start by selecting the desired code fragment, in this case the entire code supplied by GA, including the SCRIPT tag upstream and downstream of this code fragment directly in the code view, then :
- Open the assets palette
- Select library elements
- From the Asset palette context menu
- Select New library item
- Remember to rename this newly created element
That's it...
Your first element on the page, the selection you've made, will automatically be converted into a library element.
Now for the other locations, simply drag and drop this element from the assets palette to the desired location in your code.
Each time you will modify your library item, DW will automaticaly update it wherever it will be in your pages.
For more information about Library item, visit the Adobe page at : https://helpx.adobe.com/dreamweaver/using/library-items.html
If you're using several different templates, depending on the sections of your site, and since you're already using a proprietary aspect of DW, I'd advise you to use a LIBRARY element instead, which you'll then insert into each TEMPLATE.
By @L e n a
I'm probably missing something here but why not ditch the proprietary DW library item and just use a script tag:
<script src="google_ analytics.js"></script>
If you link that to every page in which you want the GA code snippet to appear you then only have to update the google_analytics.js file, if needed. However I can't see it would need updating too frequently.....do Google regularly update it? I can't remember ever needing to update the scripts on any website on which I included the GA code. For sure they had a recent big update, I think, but prior to that I don't think anything changed, that I know of anyway, not that I paid too much attention to that side of things as none of my clients could ever be bothered to analyse their data.
I dont like proprietary solutions myself when not strictly necessary as they lock you into a workflow which can't be shared with other editors very easily. Given that DW is not currently being actively developed I would not be advising anyone to lock themselves into a padlocked box just in case they need a quick escape route.
I'm probably missing something here but why not ditch the proprietary DW library item and just use a script tag:
<script src="google_ analytics.js"></script>
By @osgood_
I understand your astonishment and you're right, however from another point of view, it avoids the need for an additional HTTP request, because instead of inserting simply the link to a JS file, one can directly insert the code contained in this JS file within a library element.
Well, it's true that here at the studio we use Matomo, but it seems to me that the principle is identical (at least the last few times we had to use GA, which goes back a few years I must say)... so the tracing JS code looks something like this :
<!-- Matomo -->
<script type="text/javascript">
var _paq = window._paq || [];
/* tracker methods like "setCustomDimension" should be called before "trackPageView" */
_paq.push(['trackPageView']);
_paq.push(['enableLinkTracking']);
(function() {
var u="//urltobetracked/";
_paq.push(['setTrackerUrl', u+'matomo.php']);
_paq.push(['setSiteId', '1']);
var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
g.type='text/javascript'; g.async=true; g.defer=true; g.src=u+'matomo.js'; s.parentNode.insertBefore(g,s);
})();
</script>
<!-- End Matomo Code -->
Therefore, by using a library item, it's quite possible to update i.e the variable refinements (lines 12 , 13 and so on), but not only... because trackers are full of tricks... (the code is a dummy example)
<!-- Matomo -->
<script type="text/javascript">
// ...
_paq.push(['setSiteId', '1']);
_paq.push(['setCustomVariable',1,'Fonction','<?php echo $_SESSION['fonction'];?>','page']);
_paq.push(['setCustomVariable',2,'Structure','<?php echo $_SESSION['structure'];?>','page']);
// and so on
// ...
})();
</script>
<!-- End Matomo Code -->
So updating the library item, will update all the concerned pages that will avoid an http request to that script... and it's not awkward to use this DW proprietary feature since @edinav24550678 already uses TEMPLATE, which is itself DW proprietary.
I get your point about additional http requests but that's the modern way isn't it? According to gen Z web developers the more links to various scripts, cdns/local included on every page, even if they are not required for that page, the better is what lm currently witnessing.......so yes, whilst this should not be, it's obviously not a huge concern.
@L e n a wrote:
......and it's not awkward to use this DW proprietary feature since @edinav24550678 already uses TEMPLATE, which is itself DW
2 wrongs don't make a right in my opinion.
I get your point about additional http requests but that's the modern way isn't it? According to gen Z web developers the more links to various scripts, cdns/local included on every page, even if they are not required for that page, the better is what lm currently witnessing.......so yes, whilst this should not be, it's obviously not a huge concern.
By @osgood_
Not just Gen Z. It is what it is when the HTTP server is version 2 or higher. Please read up on it so that you can convey the correct message yourself.
I get your point about additional http requests but that's the modern way isn't it? According to gen Z web developers the more links to various scripts, cdns/local included on every page, even if they are not required for that page, the better is what lm currently witnessing.......so yes, whilst this should not be, it's obviously not a huge concern.
By @osgood_
Not just Gen Z. It is what it is when the HTTP server is version 2 or higher. Please read up on it so that you can convey the correct message yourself.
By @BenPleysier
I was referring to gen z as its those mostly who seem to enjoy over complicating web development by following ridiculous workflows used by multi billion dollar companies. For sure there are going to be a percentage of "grandad" web developers whose ability to think for themselves has long since faded who will follow trends.
I know that I am ancient, but is this blindly following trends????
One would be stupid not to take heed.
What next http/3
By @osgood_
HTTP/3 is the most current protocol. An important difference in HTTP/3 is that it runs on QUIC, a new transport protocol. QUIC is designed for mobile-heavy Internet usage in which people carry smartphones that constantly switch from one network to another as they move about their day. This was not the case when the first Internet protocols were developed: devices were less portable and did not switch networks very often.
An important development for today's clients.
What is next? AI
What next http/3
By @osgood_
HTTP/3 is the most current protocol. An important difference in HTTP/3 is that it runs on QUIC, a new transport protocol. QUIC is designed for mobile-heavy Internet usage in which people carry smartphones that constantly switch from one network to another as they move about their day. This was not the case when the first Internet protocols were developed: devices were less portable and did not switch networks very often.
An important development for today's clients.
What is next? AI
By @BenPleysier
l understand the need for progression in certain sectors, obviously live streaming, for instance, is intensive and requires more application but lm not really addressing that as its not something l do or am familiar with. I still use a 'field" phone with a 3 foot ariel, I'm sure you're old enough to remember those. All lm saying is most websites, given the developer streamlines their code probably do not require the atom bomb approach. Going back to the original suggestion and comment regarding including additional http calls, I would use that approach as l wouldnt have an excessive amount of http calls anyway, regardless of http 1 or http 2. However if l was producing a WordPress website then that may need http 2 given the usual 20 plus http requests, but is that just poor workmanship or an 'accepted' casualty of more developers relying on bloated external widgets.
I dont like proprietary solutions myself when not strictly necessary as they lock you into a workflow which can't be shared with other editors very easily. Given that DW is not currently being actively developed I would not be advising anyone to lock themselves into a padlocked box just in case they need a quick escape route.
By @osgood_
I completly agree with you, but if the web site is already done that way blocked by TEMPLATE used, apart from restarting the site from scratch, it's somehow a way to go waiting for a better approach.
Please do what @BenPleysier suggested and add the Google Analytics 4 code just above the closing </body> tag of your main Template.dwt file.
By @Nancy OShea
Ben didn't suggest it, Lena did. The bloody big 'thumbs up' emoji is rather eye catching though!
By @osgood_
=========
I stand corrected.
The mention of Library Items chased me away. 🙂
1. I don't recommend using Library Items. They're too limited. And besides, you're already using a sitewide Template. You don't need both.
By @Nancy OShea
Following this reasoning, I would rather say, no longer use DW which is in limited maintenance...
On the other hand, the LIBRARY item and TEMPLATE do not fulfill the same function, they are complementary and can precisely be used together, especially from when several templates are used for the same website.
Let's imagine a classic use case of a website, imagine :
- a template for the marketing department,
- a template for the sales department
- and a template for customer support...
We could go further but we can also stop here, which makes three distinct areas of DW proprietary code... using TEMPLATE.
Now, let's add the tracker (Matomo , GA, whatever)... this tracker having to be physically added to each of the templates will require three injections... and this is where the LIBRARY item will be very useful...
That said, these elements can also be used outside the templates and placed within any other page of the site.
The LIBRARY item are not limited at all and they are largely complementary to the TEMPLATE which could not circumvent the problems mentioned previously on their own.
AdChoices