search

matomo-org / matomo

Empowering People Ethically with the leading open source alternative to Google Analytics that gives you full control over your data. Matomo lets you easily collect data from websites & apps and visualise this data and extract insights. Privacy is built-in. Liberating Web Analytics. Star us on Github? +1. And we love Pull Requests!
https://matomo.org/
GNU General Public License v3.0
19.87k stars 2.65k forks source link

No read-only / read-write segmentation approach support #14699

Open ohadm2 opened 5 years ago

ohadm2 commented 5 years ago

Hi.

The system lacks read-only / read-write segmentation approach support (the ability to use 2 different Matomo servers with different privileges on each - one will update settings using the UI and the other will only collect data and the UI will be blocked) which makes the Tag Manager feature cause problems.

We use this approach and we had to make changes to the code itself for it to work as we need.

More info is available in the attached text file. matomo-issue.txt

tsteur commented 5 years ago

@ohadm2 not really 100% sure what you mean by that. Maybe you can explain in more detail. In general it doesn't sound like something we support though or plan to support.

Re the other points in the txt file:

  1. A new option in the settings file that disables auto generation of JS Assets. This sounds like a Matomo issue. In general what you can do though is to execute these commands eg every hour and then the JS files will be generated on the server that you want:
MATOMODIR/console custom-piwik-js:update
MATOMODIR/console tagmanager:regenerate-released-containers

This will update all trackers and JS containers

  1. A new option in the settings file that sets a custom location for JS Assets. This you could already do by specifying a config/config.php with eg such a content:
    'TagManagerContainerStorageDir' => function () {
        return '/tmp/alternative/path/';
    },
  1. When the above options are on, no JS files will be generated and instead they will be pulled from the 'read/write' server using some sort of a infrastructure-based copy process. That way the 'read-only' server will be updated via the 'read-write' server and not via itself.

I don't understand what you mean here unfortunately.

ohadm2 commented 5 years ago

Thanks for these interesting suggestions. That may help us in the future.

  1. The idea here is to make the 'read/write' (a.k.a the back-end server) server the ONLY server that writes data. In such a case, every change in the UI will update only files inside this server. If another server is used as a front end for the system and only through that server system's resources (such as JS files etc.) are available anonymously thought the internet, it must be updated via some sort of sync process with the back-end server, otherwise it will hold different and out-dated files.
tsteur commented 5 years ago

Thanks for the explanation, will move this to Matomo repo