Update widget registration to declare associated modules

[aaemnnosttv]

Feature Description

In #4807 the infrastructure for widget registration and selection was extended to allow for widgets to have one or more associated modules and to select them optionally filtered by a list of modules.

This issue is about updating the widget registration for (nearly) all widgets to declare their respective modules – i.e. the modules they are for or depend on.

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• All widgets should have their registration updated to include all modules they depend on, passing the module slug(s)
  • Widgets registered in a module's registerWidgets function should all declare the current module as a minimum (in most cases, this will be all that's needed)
  • Any widget that depends on another module (e.g. AdSense's DashboardTopEarningPagesWidget – note the multiple whenActive use) should be registered with both/all modules
  • Note: At this point, the (legacy) URL search widget should be the only widget not associated with any module.

Implementation Brief

• Using assets/js/modules/adsense/index.js,
  • Update all registerWidget calls to include modules: [ 'adsense' ] in their second parameter except the following widgets where additional modules should be added:
    • adsenseTopEarningPages: analytics should be added modules
    • adsenseModuleTopEarningPages: modules should contain analytics only (no adsense).
• Using assets/js/modules/analytics/index.js,
  • Update all registerWidget calls to include modules: [ 'analytics' ] in their second parameter.
• Using assets/js/modules/idea-hub/index.js,
  • Update all registerWidget calls to include modules: [ 'idea-hub' ] in their second parameter.
• Using assets/js/modules/pagespeed-insights/index.js,
  • Update all registerWidget calls to include modules: [ 'pagespeed-insights' ] in their second parameter.
• Using assets/js/modules/search-console/index.js,
  • Update all registerWidget calls to include modules: [ 'search-console' ] in their second parameter except the following widgets where additional modules should be added:
    • searchFunnel: analytics should be added modules

Test Coverage

• No new tests to be added.

QA Brief

• This functionality will properly be QA'd in Limit widgets displayed on the shared dashboard to those which the user has access to #4813.
• For now, make sure all the widgets are rendering for the authenticated user as usual.

Changelog entry

• Update widget registration to declare associated modules.

[aaemnnosttv]

@felixarntz is there anything you can think of more concretely that should determine when a module (other than the main module for a widget) should be associated with a widget?

[felixarntz]

@aaemnnosttv There may be widgets that don't depend on any module, I think that would be good to point out in the ACs as well. For example the (legacy UI) URL search widget, but potentially also the AdSense CTA widget? For the latter, I'm actually wondering, what does "associated module" really mean for us? The AdSense CTA widget does not get any real data from AdSense, so the user doesn't need to have shared data access to see it. At the same time, that widget still shouldn't be shown to non-signed in users since they can't configure the module anyway.

[aaemnnosttv]

For example the (legacy UI) URL search widget, but potentially also the AdSense CTA widget? For the latter, I'm actually wondering, what does "associated module" really mean for us?

Yes, I think the search widget is the only one I found that would be without any module.

As for the AdSense CTA widget (and your question about what the associated module really means for us), I think the association is primarily about the data source(s) used within it, but even for a widget that did not display any data, if it was somehow specific to the AdSense module, it should be associated with it.

At the same time, that widget still shouldn't be shown to non-signed in users since they can't configure the module anyway.

Right, which could be handled either as conditional widget registration, logic within the widget (returning WidgetNull if not capable) or maybe we could further extend widget registration with required capabilities? This one would then require our MANAGE_OPTIONS to be returned. With that in mind, maybe using capabilities would be a cleaner separation to use that would still allow for the a list of widgets by module using the new meta capabilities (although not sure exactly how that would work for authenticated admins)? This is a bit closer to how WP registers some things as well (e.g. admin pages). I'm not necessarily suggesting we make this change, but what do you think?

[felixarntz]

As for the AdSense CTA widget (and your question about what the associated module really means for us), I think the association is primarily about the data source(s) used within it, but even for a widget that did not display any data, if it was somehow specific to the AdSense module, it should be associated with it.

That makes sense. I agree we can then include a "manual" capability check in the CTA widget to return WidgetNull if the user doesn't have the required capability.

maybe using capabilities would be a cleaner separation to use that would still allow for the a list of widgets by module using the new meta capabilities (although not sure exactly how that would work for authenticated admins)? This is a bit closer to how WP registers some things as well (e.g. admin pages). I'm not necessarily suggesting we make this change, but what do you think?

That's a great idea. However I don't think it's necessarily a replacement for what we're doing here, it could be another future enhancement, allowing to control widget access based on capability. I think for now we can rely solely on the module approach as originally defined and check for capabilities in the few places needed manually, but it would be great to eventually have a (not dashboard sharing-related) issue to explore capability-based access.

We can move this forward to IB.

[eugene-manuilov]

IB ✔️

[wpdarren]

QA Update: ⚠️

make sure all the widgets are rendering for the authenticated user as usual.

@kuasha420 please could you confirm if this should be tested with dashboardSharing enabled, or not? Or, is it worth running through both enabled and disabled at this point? Please clarify.

[aaemnnosttv]

@wpdarren it just means make sure the widgets are all showing as before and that no regressions have been introduced in changing the widget registrations. There is no intended change to what should be seen on the dashboards yet at this point. The changes here are related to dashboard sharing but not based on the feature flag.

[wpdarren]

QA Update: ✅

Verified:

• Checked that all widgets appear on main and entity dashboard.
• Checked with zeroDataStates enabled and disabled. Check
• Checked on a site with data and also one with zero/gathering data.