Until #17444 is sorted I would not add more subscribers to the onBeforeExecute event. Repeating the TL;DR here, the introduction of that event has side effects that cannot be fixed without massive architectural changes.

Changed to the function when the listeners are registered.

I wouldn't do it this way either. Not quite sure how an initialization hook belongs in a step that is intended purely for registering listeners with the event dispatcher. And the fact that these steps have to be done after the constructor is a huge red flag that something deeper is broken.

This is a workaround to FUBAR architecture at best. The root problem should be identified and fixed.

Valid point. Changed to init the plugin when the first event is triggered. But as @mbabker pointed out, it is not solving the cause. Somehow the logged entries are collected correctly, but they get stripped out before adding them as messages to the debug bar. No clue why, perhaps somebody with more logger experience can help out here.

This is no good either. Logging should be set up as early as possible, otherwise some log entries are lost. The issue can be solved by adapting the plugin to changes made in #20547. But I can't tell if this should be a requirement or not. Basically, plugins that haven't be adapted could get issues like this when doing stuff in the constructor. I guess #24913 is related.

Not sure why there is an issue with the constructor honestly. Because it happens at the same time as before #20547. So I barely think this is the cause. But you never know.

Part of the problem is "debug mode" in Joomla isn't baked into core. It's a plugin. Plugins are instantiated at a specific step in the application cycle. Making "debug mode" a first class citizen requires changes in places that go far beyond what a plugin should be doing.

Logging should be set up as early as possible, otherwise some log entries are lost.

Core doesn't actually define any default loggers. They're all created as part of components and plugins. So you're stuck with a catch-22 because instantiating some of the services used before plugins are instantiated are logger aware (application and database for sure) but there are definitely going to be database queries before a plugin can create any loggers (at a minimum to the users table if you have an authenticated session, the extensions table for the active plugin list, and if database sessions or session metadata is in use you'll have queries there). You almost need a "core" debug mode configured in global config that the core bootstrap process and APIs can use regardless of the plugin's settings and then any plugin which handles extended debugging capabilities (i.e. adding the debug bar for core, or if someone wanted to add more debug capabilities, I can't find it anymore but I had a plugin I used to toy with that decorated the Language class to add profiling to loading all the language files).

I was referring to logger within this plugin. Since last commit it's being set up in onAfterDispatch.

The main point still stands though in that relying on a plugin to bootstrap the entire application's debug logic is architecturally flawed because as you've so rightly noticed that is too late for the plugin to catch things you would want it to catch (everything up to onAfterInitialise because I refuse to acknowledge the mistake of the onBeforeExecute event I created is a black box as far as the debugger goes).

But the problem is not that the plugin is collecting the log entries too late. The problem is that when stuff gets initialized in the constructor the entries from the deprecated category are removed somehow from the array here, despite they are added previously here. When I debugged it, the logEntries counter went over 500 in the logger function but when collectLogs is called the logEntries array doesn't contain anymore the entries of the deprecated category and the count of logEntries was again below 500.

Apparently, it is the same issue as #24913 and the solution by @joeforjoomla works for old plugins.

More specifically it seems that this happens because you move the registerListeners() out of the CMSPlugin __construct to the PluginHelper class

If it would be the same, then no logs would be collected at all.

I have tested this item ✅ successfully on 6387e5a

work as descriped

I have tested this item ✅ successfully on 6387e5a

Test OK

RTC

This one is not right actually, too late to collect the logs.