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

Jump to bottom

SitesManager.getJavascriptTag and GUI report different end points (piwik vs matomo) #17947

Closed
mssc-hoffleit opened this issue Aug 31, 2021 · 3 comments
Closed

SitesManager.getJavascriptTag and GUI report different end points (piwik vs matomo) #17947

mssc-hoffleit opened this issue Aug 31, 2021 · 3 comments
Labels
worksforme The issue cannot be reproduced and things work as intended.

Comments

@mssc-hoffleit
Copy link

Expected Behavior

The GUI (Websites/Tracking Code) and the API function SitesManager.getJavascriptTag should use the same end points: Either both matomo.js/php or both piwik.js/php.

Current Behavior

The GUI ("https://example.com/piwik/module=CoreAdminHome&action=trackingCodeGenerator&idSite=1") shows Javascript code with "matomo.php" und "matomo.js".

The API ("https://example.com/piwik/?module=API&method=SitesManager.getJavascriptTag&idSite=1") delivers the same Javascript snippet, but with "piwik.php" und "piwik.js".

This is an ancient Piwik site upgraded to Matomo 4.4.1.

GUI:

<!-- Matomo -->
<script>
  var _paq = window._paq = window._paq || [];
  /* tracker methods like "setCustomDimension" should be called before "trackPageView" */
  _paq.push(['trackPageView']);
  _paq.push(['enableLinkTracking']);
  (function() {
    var u="https://example.com/piwik/";
    _paq.push(['setTrackerUrl', u+'matomo.php']);
    _paq.push(['setSiteId', '1']);
    var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
    g.async=true; g.src=u+'matomo.js'; s.parentNode.insertBefore(g,s);
  })();
</script>
<!-- End Matomo Code -->

API:

# curl -s "https://example.com/piwik/?module=API&method=SitesManager.getJavascriptTag&idSite=1&token_auth=XXXXXX" |recode html..ascii
<?xml version="1.0" encoding="utf-8" ?>
<result><!-- Matomo -->
<script>
  var _paq = window._paq = window._paq || [];
  /* tracker methods like "setCustomDimension" should be called before "trackPageView" */
  _paq.push(['trackPageView']);
  _paq.push(['enableLinkTracking']);
  (function() {
    var u="https://example.com/piwik/";
    _paq.push(['setTrackerUrl', u+'piwik.php']);
    _paq.push(['setSiteId', '1']);
    var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
    g.async=true; g.src=u+'piwik.js'; s.parentNode.insertBefore(g,s);
  })();
</script>
<noscript><p><img src="https://example.com/piwik/piwik.php?idsite=1&amp;rec=1" style="border:0;" alt="" /></p></noscript>
<!-- End Matomo Code -->

Possible Solution

The outcome should be consistent for both methods.

Since wasMatomoInstalledBeforeVersion('3.7.0-b1') for this site, this site obviously shouldPreferPiwikEndpoint(). So I guess the API page is wrong using matomo.js/php.

Steps to Reproduce (for Bugs)

The demo site account lacks sufficient permissions to reproduce.

So to reproduce:

  1. Get access to an site where wasMatomoInstalledBeforeVersion('3.7.0-b1').
  2. Have a look at the tracking code in the GUI at this site, i.e.: https://example.com/piwik/module=CoreAdminHome&action=trackingCodeGenerator&idSite=1
  3. Fetch the tracking code using the API, somewhat along: 'curl "https://example.com/piwik/?module=API&method=SitesManager.getJavascriptTag&idSite=1&mergeSubdomains=0&mergeAliasUrls=0&disableCookies=0&crossDomain=0&trackNoScript=1&token_auth=XXX"

Context

In our case, it makes WP-Matomo use the legacy tracking end points piwik.js/php. We would like WP-Matomo to use the current end points matomo.js/php instead.

Your Environment

  • Matomo Version: 4.4.1
  • PHP Version: 7.3.29
  • Server Operating System: Debian 10.10
@mssc-hoffleit mssc-hoffleit added the Potential Bug Something that might be a bug, but needs validation and confirmation it can be reproduced. label Aug 31, 2021
@tsteur
Copy link
Member

tsteur commented Aug 31, 2021

@mssc-hoffleit this is actually expected behaviour. We still return piwik.php in the API to not regress anything there. We can't return matomo.php there for older installations as that endpoint might not be accessible and would break the tracking. Therefore to keep BC by returning piwik.php. But in the UI we recommend matomo.php so when someone copy/pastes the tracking code for a new site then the new recommended endpoint will be used.

If you would like to get matomo.php in the API as well then you can append &forceMatomoEndpoint=1 in the API request.

@tsteur tsteur closed this as completed Aug 31, 2021
@tsteur tsteur added worksforme The issue cannot be reproduced and things work as intended. and removed Potential Bug Something that might be a bug, but needs validation and confirmation it can be reproduced. labels Aug 31, 2021
@mssc-hoffleit
Copy link
Author

@tsteur, thanks for the clarification!

Is there any way to set forceMatomoEndpoint=1 in the Matomo configuration?

Would be reasonable for sites which have been fully migrated to the new end points.

As an example, we're using WP-Matomo. WP-Matomo calls SitesManager.getJavascriptTag to autoconfigure the Matomo setup for the site (fetching the tracker code etc.). It feels odd when I would have to manually reconfigure WP-Matomo to use &forceMatomoEndpoint=1 just in order to make auto configuration work (apart from the fact that WP-Matomo doesn't support this, currently).

@tsteur
Copy link
Member

tsteur commented Sep 1, 2021

@mssc-hoffleit forcing it to use that endpoint without a parameter would be only possible by developing a small custom plugin unfortunately. If you are using WP-Matomo then I would suggest maybe to create an issue there to offer an option the Matomo endpoint there maybe?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
worksforme The issue cannot be reproduced and things work as intended.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@tsteur @mssc-hoffleit