Hi @Tomybrz, thanks for taking the time to report this!

I cannot reproduce this, I get the page content instead.

Does this also happen when directly going to https://doc.wikimedia.org/oojs-ui/master/demos/ ?
Which browser is this?
Does this also happen with other browsers?
Does this also happen in private mode of your web browser?

In T225882#5261087, @Aklapper wrote:

Hi @Tomybrz, thanks for taking the time to report this!

I cannot reproduce this, I get the page content instead.

Does this also happen when directly going to https://doc.wikimedia.org/oojs-ui/master/demos/ ?
Which browser is this?
Does this also happen with other browsers?
Does this also happen in private mode of your web browser?

• Does this also happen when directly going to https://doc.wikimedia.org/oojs-ui/master/demos/ ? : Yes
• Which browser is this? : Firefox quantum 67.0.2 (64 bits)
• Does this also happen with other browsers? : Yes , Microsoft Edge 44.17763.1.0, and also on Mobile : Firefox for android Release 67.0.2
• Does this also happen in private mode of your web browser? : Yes , tested in Firefox and Microsoft Edge

• Precision : same login message on Microsoft Edge but with one more line : nda/ops/wmf

@Bencemac also have this issue

Thanks! I can reproduce in Chromium 73 but not in Firefox 67.0.2 (but I block a lot of things in Firefox anyway).

I can confirm the problem with Firefox 67.0.2 and Edge 44.18362.1.0 on Windows 1903.

In @Volker_E's review of the Matomo-generated client code, a mistake was made that caused the client to ping the admin interface instead of where it should be going - the event tracking: https://gerrit.wikimedia.org/r/#/c/oojs/ui/+/516591/1..6/demos/index.html

I'll leave it up to you all to revert whatever part of that code you need to make it work, but it's a question about style, not a problem with Matomo (and it's not a security issue, any access to the Matomo admin interface will request an LDAP password, as it should).

@Milimetric That is incorrect. The original snippet was already wrong. See my patch https://gerrit.wikimedia.org/r/#/c/oojs/ui/+/517548 for detailed explanation.

The tracking snippet loads https://piwik.wikimedia.org/matomo.js,
which fails with HTTP 401 Unauthorized (and pops up an extremely annoying
"Sign in" dialog in browsers when you view the demos). Comparing our
tracking snippet to the one on https://wikimediafoundation.org/,
it seems that the correct URL is https://piwik.wikimedia.org/piwik.js>.

I'm also changing a reference to 'matomo.php' on the same domain into
'piwik.php', which also fails similarly after fixing the previous issue.

Piwik was apparently renamed to Matomo recently, but clearly the rename
is incomplete.

Also, shouldn't this task be public?

@Milimetric @fdans If you used the same snippet on other sites, you might want to track them down and fix it, or fix the server configuration so that the two new URLs don't require authorizarion.

For the record, I think this issue should have remained an "Unbreak Now". It's an extremely glaring issue that makes the demos nearly unusable. And the doc.wikimedia.org site is the closest thing to production for the OOUI tag. It is disappointing to me if we really consider issues on it so unimportant (and yet we go to great lenghts to add annoying analytics code…).

https://codesearch.wmflabs.org/search/?q=(piwik%7Cmatomo)%5C.php&i=nope&files=&repos=

Looks like the "new" (not-working) name was only used for OOUI so far.

@matmarex the original snippet is wrong indeed, the issue is on matomo UI itself as it is the one providing, at this time, the wrong snippet.

https://piwik.wikimedia.org/piwik.js is open to all users, https://piwik.wikimedia.org/matomo.js requires auth.

Thanks for fixing it, I think the new matomo just needs to allow open access to matomo.js javascript file.

It is disappointing to me if we really consider issues on it so unimportant (and yet we go to great lenghts to add annoying analytics code…).

Please have in mind that @Volker_E's is the one requesting analytics on this site. Analytics provides matomo as a service so teams can get stats for small-ish sites. In no case we add analytics snippets to sites ourselves and naturally we expect site owners to cut and paste the beacon snippet making sure it works locally before merging the code or deploying it.

Change 517564 had a related patch set uploaded (by Nuria; owner: Nuria):
[operations/puppet@production] [WIP] Enable downloads of matomo.js

https://gerrit.wikimedia.org/r/517564

I'm sorry if I came off as rude, it wasn't my intention.

Thanks for uncovering the source for the issue that quickly, @matmarex. And thank you, @Milimetric and @Nuria for following-up so quickly as well!

In T225882#5264042, @Nuria wrote:

@matmarex the original snippet is wrong indeed, the issue is on matomo UI itself as it is the one providing, at this time, the wrong snippet.

https://piwik.wikimedia.org/piwik.js is open to all users, https://piwik.wikimedia.org/matomo.js requires auth.

Thanks for fixing it, I think the new matomo just needs to allow open access to matomo.js javascript file.

Followed up on this, and I found https://github.com/matomo-org/matomo-package/issues/97. We have 3.9.1-2, and 3.9.1-3 is the package containing the fix (namely deploying matomo.js/php). I'll try to upgrade asap, after that Nuria's patch should work fine.

Change 517564 merged by Elukey:
[operations/puppet@production] matomo: make matomo.js/.php public

https://gerrit.wikimedia.org/r/517564

matomo.php/js seem available now, let me know if anything is missing!

Change 519341 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@master] Update OOUI to v0.33.0

https://gerrit.wikimedia.org/r/519341

Change 519341 merged by jenkins-bot:
[mediawiki/core@master] Update OOUI to v0.33.0

https://gerrit.wikimedia.org/r/519341