Using this module on a website with SSL enabled requires that SSL is enabled on the Matomo server

[Wylbur]

Just installed the module, and enabled the site on our matomo server. When the "Locally cache tracking code file" is NOT checked, the location of the matomo.js file is set relative to the url path, but unavailable and returns a 404 error:

url https://twincitiesamnesty.org/event/2022-01-16/january-2022-meeting js file url https://twincitiesamnesty.org/event/2022-01-16/matomo.js

homepage url https://twincitiesamnesty.org/ js file url https://twincitiesamnesty.org/matomo.js

This obviously breaks the tracking process.

[indigoxela]

Hi @Wylbur,

many thanks for taking the time to report. I'm not sure if I get the problem, though...

the location of the matomo.js file is set relative to the url path

This is the part that causes me head scratching. The location to the matomo.js file is controlled by the "Matomo HTTP URL" setting(s) on top of the form. It's about the matomo.js file from the Matomo install, not the js file from the module.

I verified on one of my installs that there are no 404 - I do have the "cache locally" setting off, too. And tracking does work.

[Wylbur]

Hold the phone - as they say - we do not have SSL set on the Matomo server yet, and that seems to be having an effect on this. We are working on that, and will report back.

Thanks for quick response!

[Wylbur]

@indigoxela ^^

[Wylbur]

@indigoxela

I've updated the issue title after some further testing. What I've found is that using this on a website with SSL enabled requires that the Matomo server also use SSL. Without SSL on the server, the tracking code does not work because the website links are mixed with SSL and non-SSL links.

There are two items that might help, updating the module documentation, and requiring the SSL URL on the configuration page. Would these be appropriate?

It seems that SSL is becoming the new normal. Can we assume that here? Will this be helpful to potential users of this module?

I am happy to work on this if you have a recommended approach.

Thanks!

[indigoxela]

we do not have SSL set on the Matomo server yet...

Ah, that explains a lot. The browser, when on httpS, will refuse to load js from non-ssl resources.

... updating the module documentation, and requiring the SSL URL on the configuration page

Providing hints re the mixed content problem (ssl vs. non-ssl) absolutely makes sense. I'm not sure about the ssl url requirement, yet.

[indigoxela]

FTR ssl does get mentioned in the form description, but that doesn't seem to be enough:

[indigoxela]

@Wylbur a PR is now available for testing: #20 Would that work for you?

Additionally we probably should add some info in the module readme - what do you think?

[indigoxela]

@Wylbur re info in readme: does the following make sense to you?

HTTP URL vs. HTTPS URL

If your website has https turned on, it is necessary that the Matomo install *also has https* turned on.
This prevents "mixed content" warnings in browsers.

It's absolutely OK and actually recommended that both url settings use https - if your Matomo install has it.
Browsers load content via https from within a http page, but refuse to load http content from within a https page.

Example:

- Matomo HTTP URL: https://matomo.example.com/
- Matomo HTTPS URL: https://matomo.example.com/

Or do you have better suggestions?

[indigoxela]

I decided to switch the label to "bug", because depending on their setup, people might run into trouble. And the module could easily catch that with a conditional required state.

[Wylbur]

Copying @stpaultim on this issue, as we are sharing a Matomo server for testing and use.

Cloud Users

We should probably also consider the less technical users, and users who sign up for the cloud service. Not sure, but the assumption is at subscribers would use the HTTPS url. The subscription service only has high scale pricing, with the minimum subscription level of $23 usd. Based on Backdrop's target audience, I don't see that we will get many cloud users.

Self-hosting

This will imply more technical expertise, so I think your approach of calling out HTTPS on the form and README is sufficient.

Tim and I will test the new release in the coming days!