-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Description
Background: In #7131 and #4734 we want to allow plugins to define a new type (eg Website, Mobile App, Server, ...). Types will be able to rename and to remove/add reports.
Problem 1: We have many pages in Piwik that display multiple reports in one page. They usually define the name of the report hard coded in the twig template such as in https://github.com/piwik/piwik/blob/2.13.0-rc3/plugins/VisitorInterest/templates/index.twig#L3 . This is not good as the name could have been changed by a plugin from eg Visits by days since last visit
to Sessions by days since last session
Problem 2: All reports that should be displayed are hard coded in twig templates and controller eg https://github.com/piwik/piwik/blob/2.13.0-rc3/plugins/VisitorInterest/templates/index.twig#L3 and https://github.com/piwik/piwik/blob/2.13.0-rc3/plugins/VisitorInterest/Controller.php#L21-L26 . If some reports are disabled by a type, they would be still rendered and displayed. Instead only the actual enabled reports should be displayed.
Problem 3: Links to such a page are hard coded in the Menu
class like this: https://github.com/piwik/piwik/blob/2.13.0-rc3/plugins/VisitFrequency/Menu.php#L17 There is no way for us to find out whether all reports within that page are disabled or not. Eg if all reports within that page are disabled, we should not display this link in the menu. There would be a way for a plugin to disable that menu item by using the translation key of the menu name but this is no good. It is hard to find the translation key to use and the key could change; and another plugin does not know which plugins are displayed in that page (this can change over time) etc.
In some cases a report class defines a $menuTitle
causing it to be displayed in the menu. When such a report is disabled by a type, the menuTitle will not appear in the reporting menu which is good.
Goals:
- When displaying a report name in a page, use the
$name
of the$report
instance - Display only reports in a page that are actually enabled
- If no report within a page is enabled/displayed, do not show the link in the reporting menu
- Make it easy for plugin developers to define where a report should be displayed
- When creating a report, a developer should not need to know anything about controller or view
- We want to get rid of
Menu::configureReportingMenu
. The reporting menu should be built based on top of the API output of whatever composes those pages - We need to get rid of hard coded reporting menu links like this https://github.com/piwik/piwik/blob/2.13.0-rc3/plugins/Actions/Menu.php#L23-L26
- Types will be later able to rename a page, (maybe even change pages such as layout etc)
This will also help us make report pages look and feel more "similar".
Out of scope:
- We do not need to allow plugins to move a report from one page into another page (not for now, probably needed later)
There are many ways to solve this. Ideally, we would generate the pages etc based on the reporting metadata. It could be as well a new API. This API / layout information could be interesting for Piwik Mobile as well.
As we want to render everything in the frontend anyway (long term), we could fetch the reports metadata (layout) via ajax and render the layouts (not the report itself) + reporting menu via angularjs.
Pages might be the wrong word, on a phone it is eg a "Screen". What would be a good name for eg an API method API.getReportPages
? Or do we have to adjust API.getReportMetadata
(might be hard since pages != report)
Maybe we can decouple pages and reports. Eg a report says it belongs to a category Visits, subcategory Devices. A subcategory devices decides what layout to use (and maybe also adds a report?) ... maybe rather not.
Ideas?