I learned this by digging through the code base for a while, and uncovered:
From which I deduce that in the same directory where I might have a
config/config.ini.php file, I can also have a
config/blog.example.org.config.ini.php file - which, if it exists will be used instead.
Also undocumented is that there can be a
/config/common.config.ini.php file which will be used by all sites within a Matomo install before applying the per-hostname or generic
I would have expected to find this on one or both of the following doc pages:
However, these only mention
global.ini.php (as the dont-change-this containing the software deaults) and
config.ini.php (as the for-all-your-sites overrides) . It seems like the documentation about
config.ini.php should be changed to be about
common.config.ini.php instead, and then add some documentation about the per-site overrides and it falling back to
I'd like to help write this if that would help. Let me know where/how to do that, and whether my above understanding is correct and/or how you'd like it to present it instead.
I'm actually not sure this works on a per site basis. It might actually work (and be awesome for some cases like enabling different features per site or applying different settings) but there would be some possible drawbacks like should you enable a plugin or make any other change through the UI, not all config files would be updated.
This feature is actually meant for hosting multiple Matomo installations with one code base where each config file connects to a different database. If we document it, we would only support it for that case cause otherwise we'd need to implement various fixes like disabling plugins management, CORS settings, or any other feature that writes to the config file.
There would be also drawbacks when archiving if you use multiple config files connecting to the same DB. When you archive data using
./console core:archive then it would use the
common/config.ini.php file. Matomo would not load the correct config file when archiving the different sites. You would for example need to use
./console core:archive --force-idsites=1 --piwik-domain=blog.example.org to make this work correctly and you'd need to configure the correct mapping of idSites to host (domain). There are likely also few other problems. Just wanted to mention there would be unexpected site effects. It may be fine though if you configure eg all settings in common config, then overwrite a few specific config settings per site. They may not be respected though if the settings need to be applied in archiving and you don't force the site and you don't configure the domain.
@tsteur Thanks, I wasn't aware of the limitation.
Perhaps I can ask about the problem that led me here: Is it possibile to change the
action_url_category_delimiter configuration on a per-site basis? The default of
/ is fine for structured content websites, but not so useful for a blog where the permalink may contain slashes to signify the date (e.g.
blog.example/2020/03/some-article/). In that case, disabling this setting would help by making all urls equal siblings of each other in the root (treating the whole url as one thing).
However, I'm not sure how to do that without it affecting other sites.
@Krinkle it's unfortunately not possible yet.
I've looked at the code and this setting is used in archiving. So it could work (haven't tested) by creating a config file for that site and then running
./console core:archive --force-idsites=1 --piwik-domain=blog.example.org in the crontab to archive the data for that site. The downside though is that you would also need a crontab entry for every other site within the same Matomo. I know this is hardly a solution/workaround as it means editing the crontab every time a new site is added.
Technically, if all sites had little traffic, browser archiving could be enabled and then it would likely work. However, this would mean Matomo aggregates the reports from the raw data on demand instead of in the background making things a bit slow. Especially if the sites have a bit more traffic.
I suppose a custom plugin could also do as it could technically hook into archiving events and change the config setting on demand. There are the events
CronArchive.archiveSingleSite.finish https://developer.matomo.org/api-reference/events#cronarchivearchivesinglesitestart . See also getting started https://developer.matomo.org/guides/getting-started-part-1 and our docs on events https://developer.matomo.org/guides/getting-started-part-1 and the config https://developer.matomo.org/guides/piwiks-ini-configuration
Wish I had a better workaround.
see https://github.com/matomo-org/matomo/pull/17636 where we are allowing tracker configurations per site. Basically the format is
[Tracker_$idSite] eg [Tracker_58] to overwrite settings for site 58
And these site specific settings will overwrite the regular setting.