Adds support for Matomo Tag Manager containers

[matt-bernhardt]

One of the instances of this application, GeoData, has an existing integration with Matomo using their legacy approach that relies on a site ID.

The USE UI project will be using a newer integration, which requires us to support Matomo Tag Manager.

Ticket:

https://mitlibraries.atlassian.net/browse/use-160

How does this address that need:

This adds a second option for integration with Matomo, using just a single ENV variable - for the container URL. We do this by extending the conditional in the _head partial, allowing the application to support either a tag manager container or the legacy approach, but not both.

Once GeoData gets converted over to using a tag manager container, we will be able to drop that half of this conditional.

Document any side effects to this change:

The legacy integration has a bit of bespoke javascript in order to let turbo frames interactions be sent to Matomo. Thanks to whomever left the URL to the github issue about this approach, which led me to https://developer.matomo.org/guides/spa-tracking - which tells me that we don't need to worry about this under a tag manager context. As a result, I've left that code out of the new integration, and we'll handle tracking all changes directly within the Matomo container.

Developer

Accessibility

• ANDI or WAVE has been run in accordance to our guide.
• This PR contains no changes to the view layer.
• New issues flagged by ANDI or WAVE have been resolved.
• New issues flagged by ANDI or WAVE have been ticketed (link in the Pull Request details above).
• No new accessibility issues have been flagged.

New ENV

• All new ENV is documented in README.
• All new ENV has been added to Heroku Pipeline, Staging and Prod.
• ENV has not changed.

Approval beyond code review

• UXWS/stakeholder approval has been confirmed.
• UXWS/stakeholder review will be completed retroactively.
• UXWS/stakeholder review is not needed.

Additional context needed to review

E.g., if the PR includes updated dependencies and/or data
migration, or how to confirm the feature is working.

Code Reviewer

Code

• I have confirmed that the code works as intended.
• Any CodeClimate issues have been fixed or confirmed as
  added technical debt.

Documentation

• The commit message is clear and follows our guidelines
  (not just this pull request message).
• The documentation has been updated or is unnecessary.
• New dependencies are appropriate or there were no changes.

Testing

• There are appropriate tests covering any new functionality.
• No additional test coverage is required.

[coveralls]

Pull Request Test Coverage Report for Build 19515133385

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 98.023%

---

Totals
Change from base Build 19514453678:	0.0%
Covered Lines:	942
Relevant Lines:	961

---

💛 - Coveralls

[matt-bernhardt]

Please note:
I've worked with @djanelle-mit to define a site within the staging Matomo platform for USE UI, and he has created a container within that site definition. The review app for this PR has been configured to use that container, so you should be able to see it being loaded successfully within the review app by using the web developer tools in your browser.

The existing GeoData integration via the legacy matomo approach should still be operational under this change, but I haven't looked at that specifically - I'm relying on an understanding of how if / elsif / end works in Ruby.

[jazairi]

Seems to be working as expected. Thanks for setting this up! I assume we overrode the theme gem here because of the Turbo bits, but that made me wonder if we should include this container code in the theme gem. I don't think that change would be in scope of this ticket, though, so from my perspective this is good to go.

[matt-bernhardt]

I think the plan is to move a lot of these changes up to the theme gem, yeah. Support for both Matomo configurations seems like a natural to move up to the theme gem, even if the other customizations here don't move up. I could see there being a Matomo-specific partial that gets called from _head, for example.