A "type" could be a plugin that defines a type "Website" or "MobileApp". Different types need different reports and different naming of reports.
To be considered
%s by days since last %sif possible. This would lower the amount of reports having to rename a lot. This won't be easy and needs to be considered when working on this. I couldn't think of a nice solution so far. If it is not possible then okay. Maybe it gets more clear once we resolved the possibility to rename metrics in #7824
getReportMetadata($idSites). In this case we might need to fallback to generic wording and do not apply the rename (or we apply a generic rename on top). We might deprecate
$idSitesin the future.
Reports::getAllReports()to build a list of widgets. To do this it needs eg the name of the report which can be renamed by a type.
WidgetsListis in core. If we rename the Reports only in
API.getProcessedReport/getReportMetadatawe could never get the renamed report name in
WidgetsListas the core does not know anything about APIs and other plugins. Therefore we might need to apply some renaming in
Report::getAllReports()and some in
getProcessedReport(eg only metrics). Another solution would be to move
WidgetsListto a plugin so it would know about APIs and would be able to access the metadata but Widgets are not only reports, it can be anything and it is kinda a core feature. Another reason why Widgets are Core: A report (which is a core feature) currently can add a widget. If Widgets were entirely done via a plugin, report would not be able to know anything about it. So moving widgets to a plugin also effects reports etc.
getReportMetadataand manually decide which reports are relevant is possible but quite a bit of work. Maybe we can make this somehow easier to get module/action for the reports to disable. Maybe a UI builder in a next step?
$this->name = Piwik::translate('MyKEy'). They should not do that. Otherwise renaming can become difficult and we need the actual translation key for other things (eg it will allow us to cache report instances, maybe even serialize them). This will be a must do when working on reports. Instead we should translate where needed. This will also improve performance.
WigdetConfigwe might want to introduce a
static configure(ReportConfig $config)method.
Questions / TBD
Here are some of my initial thoughts re possible implementations.
Piwik::postEvent('Reports.getAllReports', array($idSite))when initialising the report instances, iterate over all instances and rename the report if needed. We'd need to post the
idSiteas well, otherwise we cannot find the correct type. This solution would work but might be a bit slow (as we need to post many events under circumstances and we will be able to cache report instances only per site (a "Decorator" could fix that))
getName, ... we could check whether there is something to rename but we do not have the current
idSitethere. So we do not know with what to replace. Also plugins could overwrite that method and that could lever out that behaviour. Also wouldn't work when
$this->nameis used directly within the class (easily fixable).
$report->getMenuTitle(), rename the title if needed. That could work as we usually have the
idSiteat this point, but we'd have to do it whenever we use those methods no matter where. Error-prone... A "decorator" could help but still error-prone. Another problem: In
Report::getAllReports()the reports are sorted by category, this can lead to issues if we allow to rename categories as well as they would not be sorted by there actual renamed names but by their original names.
Report::getAllReports()and initialise menu title based on that. This might work. We'd also have to do this for
Report::factory(). This is similar as
1)just that we do not post an event and couple report and title a bit more. Not 100% sure whether we always have the
API.getProcessedReport(), hook to that event, and rename any report name if needed. This might work, but it'll work only there. If something doesn't use
getProcessedReportwe have a problem. Also we have again a problem if reports are eg sorted by category. Renaming them afterwards would lead to a wrong sort order (same problem as in 4.). Edit: I think it is wrong that reports are sorted in
getAllReportsso this could be an acceptable solution.
Typeclass which uses generic words by default. Eg "Property" instead of "Website". When creating a report instance we require a
ReportBuildereg via DI and set the current type. From there we create a report. A
ReportRepositorymight handle multiple reports. A report can create more Metrics by using eg a
MetricsBuilder. A report can access the current type and do eg
$this->name = Piwik::translate('MyKey', $this->type->getNamePlural());or
$this->name = Piwik::translate('MyKey', $this->visitsMetric->getNamePlural());. As a report can currently define its metrics like
$this->metrics = array('nb_visits', 'nb_visitoors')we could maybe keep it this way and resolve the metrics into classes in the background (maybe).
idSite. Should also work for removing report(s) and for
processed report / report metadata. I think we might actually need to render reports in the browser and only consume data via
$typeto it and everything is easy. Problem are translations if we use report names like
%s (Visits) by days since last %s (visit)
What a report is or what a report can do, what they are used for, ...
If we have generic wording everywhere then it is ok to do it after 3.0.0 I'd say. Although it might be still needed to rename same reports. I'd say let's move it to Mid term and if needed move it to 3.0.0