Unfortunately we can't help with debugging TLS issues here since it depends on how you have things setup there. Closing since the issue is unrelated to the MatomoAnalytics extension.

By certificate I strongly think it is talking about the certificate your matomo server is presenting to your mediawiki server during the TLS handshake. Your mediawiki server doesn't trust the issuer. Fixing this is very dependent on what exactly your CA setup is, what OS you're running on the mediawiki server, how you're running mediawiki, and how you want to approach this. If it is a self signed certificate, you should trust it at the OS level. If it is signed by some kind of internal CA that CA should be trusted by your mediawiki server.

After diving into wiki's GuzzleHttpRequest.php object I was able to fish out an error. On line 273 doing a var_dump on $handlercontext I can see the error 'Peer's Certificate issuer is not recognized.'

This returns null
MediaWikiServices::getInstance()->getHttpRequestFactory()->get(url goes here)

I am able to confirm this function:

Still nothing.

Whilst I'm not 100% sure, I think the token just needs to be the value of the token, ie, without &token_auth= just whatever the actual token is.

Grabbed the &token_auth following the instructions from here: https://matomo.org/faq/general/faq_114/

That's likely the issue; can you try setting the api key? I think that is where your issue lies. MediaWiki needs the API key to get the data.

Looks like I'm getting nothing into $siteReply.

This is the configuration. I'll setup something to capture what is being returned to that function.

The error is because whatever is being returned into $siteJson is not what is expected. It's pretty much impossible for us to help you without further details, i.e, seeing what you're passing as configuration into the extension, or what is being returned by the api call here:

			wfAppendQuery(
				$config->get( 'MatomoAnalyticsServerURL' ),
				[
					'module' => 'API',
					'format' => 'json',
					'date' => 'previous30',
					'method' => $module,
					'period' => $period,
					'idSite' => $this->siteId,
					'token_auth' => $config->get( 'MatomoAnalyticsTokenAuth' )
				]
			)
		);

In T9814#209385, @Paladox wrote:

https://github.com/miraheze/MatomoAnalytics/pull/93 fixes this.

https://github.com/miraheze/MatomoAnalytics/pull/93 fixes this.

https://github.com/miraheze/MatomoAnalytics/pull/91

Forget the above, it was because of using var_dump in my script. No problems with the string in PHP 8.0.27.

<s>I've narrowed it down to the string. I've made a stand-alone script and am getting the same error as the extension.</s>

If I had to guess, MatomoAnalyticsHooks::matomoScript, a function listening to the SkinAfterBottomScripts hook, is being called twice, for some bizarre reason most likely.

In T9814#200511, @Reception123 wrote:

Is this a huge issue or something quite minor?

Triaging as low as there doesn't seem to be a huge effect because of this.

Is this a huge issue or something quite minor?

I dont think this is an issue with the extension, but Matomo itself, as it definitely isn't defined twice within the extension.

@Agent Isai

yes i changed managewiki

Y

You were advised on how to disable Matomo’s analytics collection on the Community noticeboard. Have you followed those steps?

Can confirm this hasn't happened with the new rename. Closing for now per above.

I would say close this task, it's not possible to extensively debug so long as not present on the mentioned wiki. Therefore, it could be reopened when it happens again, but since unactionable till then, I don't see why it should remain open.

Moving to low as it doesn't seem to be a systemic issue per @Universal_Omega and will have to wait until the next rename anyway.

My only theory at the moment is that this was due to tampvanwiki previously existing, and never had it's Matomo data in the database properly deleted. Though I can't confirm that.

Does the recalibrate script work?

Thank you all for the comments. I close this because the usage is unclear.

In T8611#175194, @Lens0021 wrote:

I have a question: When I google it, there are search results describing pageviews of Matomo. Is it what you said the instance of Miraheze especially does not collect pageviews by the policy? (I'm sorry for not having experience with Matomo)

I have a question: When I google it, there are search results describing pageviews of Matomo. Is it what you said the instance of Miraheze especially does not collect pageviews by the policy? (I'm sorry for not having experience with Matomo)

In T8611#175184, @YellowFrogger wrote:

True, I just saw it. So how so? Will the extension have the same functionality?

True, I just saw it. So how so? Will the extension have the same functionality?

In T8611#175181, @YellowFrogger wrote:

This is specific for wikimedia

The PVW, unfortunately

This is specific for wikimedia

Well it collects site views, but I don't know how useful/worthwhile doing this is just for that.

https://meta.miraheze.org/wiki/Special:Analytics is the information it does collect. So I don't think it even collects those, unless I am misunderstanding that.

In T8611#175127, @Universal_Omega wrote:

Matomo doesn't even collect per page info, so I'm not exactly sure how this would really be doable here.

Matomo doesn't even collect per page info, so I'm not exactly sure how this would really be doable here. Although this is a bit out of my expertise. Do you have any suggestions here, since you are the developer of PageViewInfoGA?

Running fix Matomo in magic repo should work

In T7974#160747, @RhinosF1 wrote:

As the code currently indicates, when the last update was made to it. 1.36 was the only version it worked with. Mediawiki core patches have now been backported so 1.35.3 will work once we update our code. I'll reopen this to take account of that. The code should be the source of truth as of when it was committed, we often don't update the mw.org docs.

https://github.com/miraheze/MatomoAnalytics/pull/54 now lowers the minimum requirement to 1.35.3

Well, I am sorry but you missed the point.

Since you modified the documentation to reflect the 1.36 minimum version, are you confirming that the extension is not compatible with 1.35 any longer?
If this is correct, is there no legacy branch compatible with that version?
As the code currently indicates, when the last update was made to it. 1.36 was the only version it worked with. Mediawiki core patches have now been backported so 1.35.3 will work once we update our code. I'll reopen this to take account of that. The code should be the source of truth as of when it was committed, we often don't update the mw.org docs.

The minimum version can be changed to 1
35.3.

In T7974#160709, @RhinosF1 wrote:

Docs are outdated. It's a wiki so feel free to update :)
(In future, I've done it now)

FYI, the version was bumped by @Universal_Omega seemingly because of replacing "DB_MASTER" with "DB_PRIMARY" which has been backported to 1.35.

Docs are outdated. It's a wiki so feel free to update :)
(In future, I've done it now)

• T7942: [ManageWiki] Create better CI for MediaWiki standards and security
• T7943: [CreateWiki] Create better CI for MediaWiki standards and security
• T7944: [MatomoAnalytics] Create better CI for MediaWiki standards and security
• T7945: [GlobalNewFiles] Create better CI for MediaWiki standards and security
• T7946: [RemovePII] Create better CI for MediaWiki standards and security
• T7947: [DataDump] Create better CI for MediaWiki standards and security
• T7948: [RottenLinks] Create better CI for MediaWiki standards and security
• T7949: [IncidentReporting] Create better CI for MediaWiki standards and security
• T7950: [WikiDiscover] Create better CI for MediaWiki standards and security

In T7939#160072, @John wrote:

In T7939#160067, @RhinosF1 wrote:

In T7939#160062, @John wrote:

One task - one end objective is a standard purpose. Why do we have a task for 9 separate objectives?

It's one end objective that all Miraheze maintained extensions have mediawiki-standard CI

9 different software components = 9 different tasks surely? They just good task management and makes things easily trackable and measurable.

It's probably better to be tracking things separately and have subtasks for each extension

In T7939#160067, @RhinosF1 wrote:

In T7939#160062, @John wrote:

One task - one end objective is a standard purpose. Why do we have a task for 9 separate objectives?

It's one end objective that all Miraheze maintained extensions have mediawiki-standard CI

In T7939#160062, @John wrote:

One task - one end objective is a standard purpose. Why do we have a task for 9 separate objectives?

It's one end objective that all Miraheze maintained extensions have mediawiki-standard CI

One task - one end objective is a standard purpose. Why do we have a task for 9 separate objectives?

I've extended the above mentioned PR to now also include phan.

https://github.com/miraheze/ManageWiki/pull/297 does this for ManageWiki, implementing eslint, stylelint, and phpcs. It also will make GitHub Actions automatically commit formatting fixes, when possible.