Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Page Overlay doesn't seem to work when tracking code Matomo URL is different from Matomo GUI URL (e.g. proxy configuration) #18291

Open
peterbo opened this issue Nov 11, 2021 · 9 comments
Labels
Potential Bug Something that might be a bug, but needs validation and confirmation it can be reproduced.

Comments

@peterbo
Copy link
Contributor

peterbo commented Nov 11, 2021

Expected Behavior

When opening the Page Overlay feature for a given URL, the Page Overlay should open and display the corresponding numbers and overlay data for a given page.

Current Behavior

Currently, if the Matomo tracking URL is different from the Matomo GUI URL (e.g. in proxy environments), Overlay does open, but keeps the loading screen in the left frame (no data will be loaded), and no overlay data is shown in the website view frame.

Possible Solution

Steps to Reproduce (for Bugs)

  1. Have the Matomo Tracking URL implemented in the website via URL A
  2. Have the Matomo Reporting GUI accessible via URL B
  3. try to open page overlay

Your Environment

  • Matomo Version: 4.4.1
  • PHP Version: ?
  • Server Operating System: ?
  • Additionally installed plugins: -
  • Browser: Firefox
  • Operating System: Windows 10
@peterbo peterbo added the Potential Bug Something that might be a bug, but needs validation and confirmation it can be reproduced. label Nov 11, 2021
@sgiehl
Copy link
Member

sgiehl commented Nov 11, 2021

@peterbo could you maybe check if there are failing requests when opening the overlay? Maybe there are some CORS headers in place that are causing issues?

@heurteph-ei
Copy link

heurteph-ei commented Nov 16, 2021

@peterbo Other possible bug source: the site is in HTTP and Matomo in HTTPS. Your browser won't allow this (it won't allow display an HTTP frame in an HTTPS page)...

@mikkeschiren
Copy link
Contributor

I can confirm this bug.
Manually overriding pPiwikRoot is fixing the issue, as pPiwikRoot get the domain of URL A instead of URL B.
Still present in 4.6.2.
(all sites in HTTPS)

@tomper00
Copy link

I have been looking into this today again.
We would really need to implement a solution where the "tracker domain" like this plugin from @mikkeschiren does https://github.com/digitalist-se/TrackerDomain and use that variable to handle this.
I will for now create a patch for the Overlay plugin to make our environment work with a separate tracker domain.
I really think this should be part of core in the end (both the TrackerDomain and the changes in the Overlay plugin and potentially a lot of other plugins that might have similar issues.

@mikkeschiren
Copy link
Contributor

Started to dig into this again, but having a hard time figuring out where pPiwikRoot URL is coming from?

@sgiehl
Copy link
Member

sgiehl commented Feb 3, 2023

@mikkeschiren It is passed through from the tracking code. In piwik.js the overlay scripts are initiated here:
https://github.com/matomo-org/matomo/blob/4.x-dev/js/piwik.js#L6588

It also provides the configTrackerUrl as parameter, which is in the end used as pPiwikRoot.

@mikkeschiren
Copy link
Contributor

Why is the main reason behind that the code for the display of the Overlay is in the piwik.js? As that mainly is for tracking, should code not used for tracking, be part of that file?
I am sure there is a good reason, but I just doesn't understand it :)

@sgiehl
Copy link
Member

sgiehl commented Feb 13, 2023

@mikkeschiren Haven't looked in detail, but I think it wouldn't be possible to inject custom javascript into a website shown in an iframe. As the tracking code is always included we use it to load additional javascript for the overlay features.

@mikkeschiren
Copy link
Contributor

Ah, that makes sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Potential Bug Something that might be a bug, but needs validation and confirmation it can be reproduced.
Projects
None yet
Development

No branches or pull requests

6 participants