hm, I tried to test and got (when open "Quick Icon - Joomla Update Notification" ):

Notice: Trying to get property of non-object in <root>/libraries/src/Plugin/PluginHelper.php on line 130
Notice: Trying to get property of non-object in <root>/libraries/src/Plugin/PluginHelper.php on line 130
Warning: class_implements(): Class Plg does not exist and could not be loaded in <root>/administrator/components/com_plugins/Model/PluginModel.php on line 391
Warning: in_array() expects parameter 2 to be array, boolean given in <root>/administrator/components/com_plugins/Model/PluginModel.php on line 391

or I missed something?

okay, I found
@mbabker the error comes when the plugin is unpublished,
for published plugin all works fine

Like that, but for the end user we probably need so show some more meaningful text than onGetIcons.

The best you can do I think is link to a documentation page for core events. Otherwise you get to a point where you start trying to create language strings for event names that turn into full paragraph descriptions. Not to mention that we would probably need to arbitrarily load a language file from somewhere to ensure event names have meaningful text as extensions can (and do) implement their own events.

I know that subscribe is the correct technical word it will confuse non technical users especially if they have some plugins that are for user subscription type stuff. The best I can come up with right now is to rename the tab to be advanced or developer information

At least let the eventname run trough JText, so extension devs have then the possibility to add some explanation for it.

At least let the eventname run trough JText

What's the key prefix? If the string's not part of the globals or the plugin's language file, where are we loading this from? And do we really want to introduce 60+ language strings that are essentially JGLOBAL_EVENT_NAME_ONGETICONS? This is in part why I think we're better off hardcoding an alert div into the layout with a link to the docs, which at least covers the core events.

Agree with Michael

The issues with disabled plugins are addressed now.

As I hinted at, I've added a link to the docs wiki page describing the core plugin events to help give more useful information without turning this tab into a mini-docs page. Screenshot in original post updated.

I have tested this item ✅ successfully on 95e1e46

I have tested this item ✅ successfully on 95e1e46

Ready to Commit after two successful tests.

OK So honestly my gut reaction was to actually close this PR as I think actually the number of times people use it is going to be relatively low and it's going to be interface clutter most the time. However most people think this is going to be useful during site building as a debugging tool. So I'm going to ask that we actually do just that, let's put this tab behind the debug config variable so that it's accessible when people are having plugin issues but in day to day usage there's just the parameters that people will be needing to use.

removing rtc

i'm not sure this is a day by day feature, but i'm just scaried about like i'm a 4.0 newcomers

let's put this tab behind the debug config variable so that it's accessible when people are having plugin issues but in day to day usage there's just the parameters that people will be needing to use.

A plugins parameters also not in day to day usage,
you configure it once and then forgets it exists. ?

I do not think that it a good idea to hide it behind "debug" flag, will be another "hidden feature".

I would like to see it as it is.

If putting this into the UI is going to be a controversial option (FWIW I'm not a fan of hiding features behind JDEBUG, it really makes them forgotten and it has bitten us in the past), the other option is a console command. But this gets to be painful as all can be because that would be forced to load all plugins in the system or start passing arguments to limit plugin/group, but at that point you might as well RTFC and the command is useless). So I'd rather just roll with this as is, sure it adds some UI clutter but it's exposing a reference point that doesn't exist otherwise and IMO this is a self-documenting functionality that belongs in the code versus being cross-referenced into the docs wiki or some other place which lists plugins and the events they operate on.

Console command sounds also interesting. Don't think it would be so much of an issue to load all plugins. Something similar to what symfony has app/console debug:event-dispatcher.

Closing, has no real utility unless we force plugins to implement the subscriber interface, which at the earliest would be 5.0.