This task number"4" from the parent issue:

Implement code to retrieve logs and build render array from logs. Port all theming code - theme functions, JavaScript and CSS that was used in D7 to render and provide style and actions to the on-screen debug log. Conditionally display debug logs on screen (if settings permit) and (if settings permit) forward them to the system dblog.

This is the last step to completing #2762157: [meta] Log to the logging service. All the other steps have been completed. Debug messages are being created and sent to the logger, we just need a way to render them and view them in the UI. Patch to follow ...

CommentFileSizeAuthor
#5 3104109-5-render-debug-logs.patch12.96 KBtr
#4 3104109-4-render-debug-logs.patch12.65 KBtr
#3 3104109-3-render-debug-logs.patch10.28 KBtr
#2 3104109-2-render-debug-logs.patch10.37 KBtr

Comments

TR created an issue. See original summary.

tr’s picture

tr commented
Status: Active » Needs review
StatusFileSize
new 3104109-2-render-debug-logs.patch10.37 KB

After applying this patch and turning on debug at /admin/config/workflow/rules/settings you should see debug logs of Rules execution. It wouldn't hurt to clear your caches first ...

I have chosen to render this output on-screen using the system messenger service, in an "error" message. This makes the logs visible and hard to ignore. In D7, it was possible to accidentally leave debug logging on because it was inconspicuosly rendered in grey and black at the bottom of the screen, often below the fold.

Please try this out and let me know what can be improved. There are a number of things I know need work:

  1. The "open all" JavaScript isn't complete and doesn't work the right way. But this does not prevent you from viewing the logs. I will get this fixed in the next day or two.
  2. Timestamps don't represent the actual Rule execution time - the times shown are dominated by the rendering process. The actual execution times when debug is off can be a factor of 10 less than what is shown when debug is on. I would like to find a way to minimize the debug overhead, but as the debug output can't be cached I think that we are somewhat limited by the speed of D8 core in this matter.

There are also two other bugs that are exposed now that you can actually see the debug ouput, but these are not a result of this patch:

  1. The "edit" links don't work. (This is computed in RulesDebugLogger.php). See below.
  2. Rules are named "Rule" instead of using the actual label of the executing Reaction Rule. (This is computed in RuleExpression.php). See below.

In regards to these last two, they are both because I don't know how to get a link to the running Reaction Rule from within the component that is being executed. I know I can do it by brute force, but this problem seems to be pointing to an architectural problem in D8 Rules. In D7 this was addressed by the RulesPluginUI, but I can't find the same capability in the D8 version of the Ui handler. I do NOT see fixing this as critical to this issue, because even with these two things working this patch represents a major improvement to the usability of Rules. But if anyone can help me address this problem I would be grateful.

tr’s picture

tr commented
StatusFileSize
new 3104109-3-render-debug-logs.patch10.28 KB

Some cleanup.

tr’s picture

tr commented
StatusFileSize
new 3104109-4-render-debug-logs.patch12.65 KB

This patch fixes the JavaScript and cleans up a few other things. This is the patch I'm likely to commit, unless I notice a problem with it.

I have the naming issue and the links fixed, but those fixes will be in a separate issue because as I said those aren't bugs with the code in this patch.

tr’s picture

tr commented
StatusFileSize
new 3104109-5-render-debug-logs.patch12.96 KB

And let's turn off the coding standards for those four lines, as the code intentionally uses t() in that manner and it's not an error in this case.

  • TR committed 50c7cca on 8.x-3.x 
    Issue #3104109 by TR: Implement rendering of debug logs to screen and...
tr’s picture

tr commented
Status: Needs review » Fixed

Committed.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.