Dashboards and Joomla\CMS\Installer\InstallerScript

[nikosdion]

Is your feature request related to a problem? Please describe.

As I'm writing my book on Joomla Extensions Development (which will make it into the new Joomla docs when it's ready) I came across a few problems when trying to talk about custom Dashboards and how to populate them when you install or update your extension:

• addDashboardMenu will always add a menu module to the dashboard, regardless of whether one already exists.
• The $dashboard argument for custom dashboards has to be in the form com_example-example whereas the <dashboard> element in the XML manifest requires it in the form com_example.example.
• The addDashboardMenu code will calculate a language string key which is invalid, therefore impossible to provide in the language files of the extensions.
• There's no way to add any other type module in the dashboard except for a menu. A more useful dashboard would probably also include modules providing graphs, stats and possible even a quick item create form module.
• Uninstalling the extension does not remove the modules from the dashboard's module position, nor is there any code to do that.
• Dashboards cannot have custom logos, only one of the icon classes Joomla (and FontAwesome) provide. This is a deterrent for third party developers.
• Dashboards cannot have quick icons unless they are implemented as plugins (or at least I have not found a way to add custom quick icons without using plugins). In most cases for third party software it makes more sense to have some of the (high traffic) preset menu items show as quick icons.
• Since this code only exists in the installer there's no obvious way for the user to “reset” the dashboard. However, I think this can be easily addressed by asking the user to just install the same version again on their site as long as the other problems are addressed.

Describe the solution you'd like

The addDashboardMenu should run conditionally. If there is an existing mod_submenu module instance for the dashboard's position and the specified preset it should not run. This allows developers to install dashboards when the user is updating their extension to a new version as opposed to only on installation.

The $dashboard argument should accept both dashboard formats com_example.something and com_example-something. It should then use the component and the dashboard key to construct a title instead of the unusable horror show I does right now. It would be even better if you'd allow the developer to provide a custom key.

We need an addDashboardModule which works similarly to the proposed addDashboardMenu (runs conditionally) and allows the developer to specify custom module options.

_Note: I have some rough first drafts of code for suggestions up to here, see https://github.com/akeeba/release-system/blob/development/component/script.ars.php)

We need a removeDashboardModules so the uninstall() method can remove the dashboard module instances instead of them lingering in the database until the end times.

Dashboards, i.e. com_cpanel, should try to load the joomla.asset.json of the extension of the dashboard and check for a style key com_example.dashboard.something. If it exists, it should load it. This would allow 3PDs to not only provide custom logos for the dashboard but also further customise the look and feel of the dashboard. For example, I don't particularly like the masonry layout for all of my extensions and it's a trivial CSS rule to override it — if only I could load one…

Presets' <menuitem> elements should allow a new type called quickicons and a new property called icon. Instead of a <menuitem type="heading"> you'd use <menuitem type="quickicons"> to define a section of the menu preset to display as icons. Its children would define which icon class to use with the icon attribute.

Finally, and totally optional, I would like to see a module which allows us to display a component's view in a module output. Joomla 4 is actually capable of (a rough approximation of) HMVC. Such a module would be massively useful in the context of Dashboards, but also outside of them. Maybe even in the frontend. But probably that's a different suggestion for another day — maybe after I reach the point where I document how you can do HMVC in the Joomla 4 MVC 😉

Additional context

Also see https://github.com/joomla/joomla-cms/pull/38757#issuecomment-1246714243

Tagging @wilsonge and @brianteeman as the first two interested parties. Also tagging @roland-d and @fancyFranci as the release leads and @bembelimen as the production leadership contact since this is touching on the overall vision for the CMS.

[crystalenka]

I can't comment to the technical implementation, but from a usability perspective, a little more consistency between component dashboards (like from third parties) would be hugely helpful. From what I understand, these changes would encourage 3PDs to use core dashboards more and it would be more consistent across the board? Is that accurate?

[nikosdion]

@crystalenka Correct. The other missing part for Dashboards adoption is documentation which I am already working on.

[brianteeman]

Probably should @hackwar as he wrote the original Pr

[nikosdion]

@brianteeman As you can read in my issue, I am not even touching the Dashboard feature at all — that's what Hannes wrote. This part works fine.

I am only touching the installer script which was contributed by @wilsonge based on the code of the F0FUtilsInstallScript class included in FOF 2.x.

[brianteeman]

it was a long issue to read ;)

[rdeutz]

Valid issue

[nikosdion]

You are actively harassing me by reopening the issues I have closed because your organisation has bullied me away. What kind of dystopian hell is this project?