System - Debug relies on __destruct which is never triggered (Fix #5826)

[mbabker]

This PR addresses #5826 by changing the method that renders the system profiler data to listen to the onAfterRespond event, the absolute last thing that Joomla does before PHP should start shutting down the application.

Testing Instructions

Make sure the profile data still renders correctly.

[zero-24]

hmm after applying the patch i can't see any issues with the debug plugin output.

the absolute last thing that Joomla does before PHP should start shutting down the application.

hmm not sure if/how we can test this.

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/7279.}

[mbabker]

Just what you did. Instead of the debug data being rendered while PHP is going through the shutdown process (this is when __destruct() magic methods are called), it is instead rendered by a proper system event before Joomla technically finishes executing. For an advanced test case, I'd suggest trying out what the original issue reporter was doing with the use of PHP's register_shutdown_function(). I don't though see anything in PHP's documentation about the behavior he ran into. Either way, this can at best be considered a good practice.

[zero-24]

Thanks.

BTW. Travis want to have a @return tag. 😄

FILE: /home/travis/build/joomla/joomla-cms/plugins/system/debug/debug.php
--------------------------------------------------------------------------------
FOUND 1 ERROR(S) AFFECTING 1 LINE(S)
--------------------------------------------------------------------------------
 187 | ERROR | Missing @return tag in function comment
--------------------------------------------------------------------------------
UPGRADE TO PHP_CODESNIFFER 2.0 TO FIX ERRORS AUTOMATICALLY
--------------------------------------------------------------------------------

How to test the advanced test case

• install the fatal catcher plugin http://www.rupostel.com/free-virtuemart-extensions/extensions/fatal-catcher-plugin
• enable debug
• access the frontend
• see the debug box there
• enable the plugin
• see that the debug is gone
• apply the patch
• debug box is back 😄

[mbabker]

Fixed

[jwaisner]

@test

PR works as intended.

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/7279.}

[zero-24]

RTC Thanks 😄

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/7279.}

[wilsonge]

So the thing with this is now the debug plugin wants to load first to ensure that all the loggers are primed. But also last when dumping data out to ensure the timers in onAfterRespond are as accurate as possible (and db queries aren't missing etc). I'm not sure if there's some sort of workaround for this or it's just something we're going to have to sucker up and document appropriately.

I mean what's the ideal even? The plugin being first in the list so the loggers are active?

[mbabker]

The actual fix in this PR is that the plugin renders the debug console while PHP shuts down and if you're using custom code to have a different shutdown operation, then the destructor does not get triggered. Since plugins are prioritized by class and not by event (another inherent weakness in JEvent), there is no way to re-prioritize the execution orders.

onAfterRespond is literally the last thing JApplicationCms::execute() does. So the only thing that could possibly come after this is another plugin also listening to that event. The only change that changes is if that plugin somehow manipulates the application profiler (adds a mark for example), that won't be included in the console's output any longer.

A proper long term fix is going to mean refactoring the event system to properly subscribe plugins to events with method level prioritization, not just class level.

[Kubik-Rubik]

Thank you @mbabker! Merged.

[infograf768]

@mbabker
This has broken some aspects of debug.
See #8362