@tsteur @sgiehl @mattab please read & review this PR. Not done yet, but should be reviewed before moving on.

Would it be maybe possible to iterate recursive in https://github.com/piwik/piwik/blob/3.0.5-b2/plugins/API/WidgetMetadata.php#L40-L41 and mark it here as widgetizable or so? https://github.com/piwik/piwik/blob/3.0.5-b2/plugins/Goals/Pages.php#L305

If you then made this here recursive to include categories and subcategories of widgets in containers the naming issue might be resolved as well: https://github.com/piwik/piwik/blob/3.0.5-b2/plugins/API/WidgetMetadata.php#L31 (to be tested). It might still somewhat have the same name as in the reports so probably won't fix 100% the problem just yet.

I would not really want to add a dimensionName etc to those widgets as they are not related in any way to a dimension etc. A widget is often just a plain widget that shows a help info but not a report etc. It also complicated things with specifying different names etc. If it is needed to add this, then it should be somehow only added to a ByDimensionWidgetContainerConfig class if somehow possible.

I would try to fix the above mentioned issues and then it might show it correctly as they have basically a subcategory set like "Goals by XYZ", it would only need to be added to the right category. Currently they are not shown there since we do not recursively search for all widgets in containers (and not yet create categories dynamically)

Would it be maybe possible to iterate recursive in https://github.com/piwik/piwik/blob/3.0.5-b2/plugins/API/WidgetMetadata.php#L40-L41 and mark it here as widgetizable or so? https://github.com/piwik/piwik/blob/3.0.5-b2/plugins/Goals/Pages.php#L305
If you then made this here recursive to include categories and subcategories of widgets in containers the naming issue might be resolved as well: https://github.com/piwik/piwik/blob/3.0.5-b2/plugins/API/WidgetMetadata.php#L31 (to be tested). It might still somewhat have the same name as in the reports so probably won't fix 100% the problem just yet.

So is this your suggested solution?

• Add categories recursively from createMissingCategoriesAndSubcategories(), so categories like 'Sales by Referrers' will show up in the widget metadata.
• Then in the dashboard manager, instead of showing them as:

  Ecommerce - Products
    ...
  Sales by Referrers
    - Referrer Type
    - ...
  Sales by ...
  

  show them as

  Ecommerce - Sales
    Sales by Referrer Type
    Sales by ...
    ...
  

  ? (I haven't tested if this is how it would appear as w/o modifications, but I'm pretty sure.)

I'm not sure if I understand completely, seems like it won't work out of the box.

A ByDimensionWidgetContainerConfig class might work, it would let us separate dimension name/dimension category from widget name/category. Let me know if this is an acceptable solution.

Check out https://github.com/piwik/piwik/compare/11942?expand=1 there it seems to work for me.

The only downside I see is that an added widget with only the title of eg "Device Type" it is not clear that it is "Ecomerce Sales by ... Device Type". We could change the widget title with some hack dynamically (eg when API.getWidgetMetadata is requested) but would make things just complicated. Maybe always adding the subcategory to the widget title shown in the dashboard but would result in long widget names. Would make things possibly much more clear though.

Here you can see you would know that those device types are only for sales:

The fix for the widget title would be actually that when there are widgets in a widget container with a "by dimension" layout, that we automatically prepend the subcategory of the widget to the widget title like Sales by user attribute: Device type in WidgetMetadata.php but only when getting getWidgetMetadata(). This would not even by a hack but a proper solution.

The issue linked specifies that there should be one new widget category "Ecommerce - Sales", not multiple "Ecommerce - Sales by ..." categories. @mattab can you confirm having multiple categories is ok?

We could fix this as well in WidgetMetadata.php that we define to always apply the first level subcategory for WidgetContainers and prepend the subcategory of the actual Widget within a WidgetContainer to the widget title. I wouldn't even consider this a hack since it makes sure we keep showing our reporting menu structure again in the dashboard selector and we have clear widget title names.

There may be a hack needed to do this only for WidgetContainers when the layout is ByDimension but not sure if it would change existing structure if we did this in general.

Maybe I'm not understanding, but if we use the widget category of the container (in this case 'Sales') for the widget category of the actual widget (ie, 'Sales by Referrer'), then the widget will appear in the dashboard manager AND in the Ecommerce > Sales page, right? Then in that page, there will be the widget + the widget container with the ByDimension layout.

This was one of the problems I encountered, setting the right category on the WidgetConfig makes it appear in the dashboard manager, but it also shows it twice in the actual page.

EDIT: Nevermind, I think getPagesMetadata doesn't recurse, while getWidgetsMetadata does.

Ok, I think I understand the system now, thanks for your patience @tsteur ;)

Oki :)

Just to roughly explain it: We basically would need to change only the logic in WidgetMetadata.php in my other branch and only when calling API.getWidgetMetadata (not API.getPagesMetadata).

When we iterate over the widgets, we would basically somehow remember the first level subcategory in WidgetMetadata::getWidgetMetadata() maybe like this and forward it to all calls:

diff --git a/plugins/API/WidgetMetadata.php b/plugins/API/WidgetMetadata.php
index 2d77e76..453a6ec 100644
--- a/plugins/API/WidgetMetadata.php
+++ b/plugins/API/WidgetMetadata.php
@@ -36,6 +36,8 @@ class WidgetMetadata
 
             /** @var WidgetConfig[] $widgets */
             $widgets = array($widgetConfig);
+            $subcategoryId = $widgetConfig->getSubcategoryId();
+
             if ($widgetConfig instanceof WidgetContainerConfig) {
                 // so far we go only one level down, in theory these widgetConfigs could have again containers containing configs
                 $widgets = array_merge($widgets, $widgetConfig->getWidgetConfigs());
@@ -47,7 +49,7 @@ class WidgetMetadata
                     continue;
                 }
 
-                $flat[] = $this->buildWidgetMetadata($widget, $categoryList);
+                $flat[] = $this->buildWidgetMetadata($widget, $subcategoryId, $categoryList);
             }
         }

it is just a rough idea on how to implement this but haven't tested if it would work like this

Ready for review, though the UI tests might not pass (there were some failures in the last run I couldn't explain, they might be random).

One thing to note: this adds widgets like 'Sales by Referrers: Referrer Type', but it also changes the name of some existing widgets, eg, 'Actions: Content Name'. Let me know if that is not desired.

I think @mattab can probably say more about 'Actions: Content Name' whether it is desired or not.

it also changes the name of some existing widgets, eg, 'Actions: Content Name'. Let me know if that is not desired.

It should be fine to prefix the name, if it becomes a problem we could adjust later on