Currently the segment that gets archived can have a different hash than what is requested in the browser. Encoding the segment before sending it to RequestCommand seems to fix this, but I'm not exactly sure why.
@diosmosis is there an issue or comment where there's more information about this? It be unexpected this is suddenly needed or was this an issue in 3.X as well?
@tsteur it's to solve the problem reported by this user: https://github.com/matomo-org/matomo/issues/16842#issuecomment-742466061
there's a small discussion there. It wasn't required in 3.x, I guess in 3.x the segment was already encoded once in core:archive, then the single
urlencode() double encoded it properly? It's strange, but the hash is only correct on both UI requests and climulti requests, if it is double encoded here.
👍 I suppose it's not really trivial to add a test here? Or a test would probably archive the data when browser archiving is enabled. This would also explain why some archives aren't showing any data (while some others do) for our web account.
Eg this segment is showing data
while such a segment isn't showing data since Matomo 4
Can we make sure it won't cause any problems with other segments like that it's not falsely double encoded when using ActionsInVisit>1 for example?
On our demo for matomo website we can reproduce this as well by the looks. I'll patch it there already as well so we can see if the data eventually comes alright. Good find!
Might be possible to add a test... will see.