Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Display the log context in the debug pages #24151

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Oct 10, 2018

Conversation

javiereguiluz
Copy link
Member

Q A
Branch? 3.4
Bug fix? no
New feature? yes
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets #23589
License MIT
Doc PR -

Before

before

After

after

I'd like to exclude the event channel context because it only adds noise:

event-noise


This change would require to add a hard dependency to the VarDumper component. Do we want to do that? Thanks!

@fabpot
Copy link
Member

fabpot commented Sep 11, 2017

Removing the event channel should probably not be harcoded, but moved to the default configuration in Flex/Symfony SE.

@ro0NL
Copy link
Contributor

ro0NL commented Sep 11, 2017

@fabpot is there a (hacky) way in twig to check if profiler_dump exists? Can we think of one? :)

edit: a wrapper in CodeExtension could do

@javiereguiluz
Copy link
Member Author

Instead of complicating things with a new config option to make the list of excluded channels configurable, could we hardcode it? For our own log channels this is correct (event is annoying but the rest are useful). The only problem could be if users want to exclude some custom channels that are also annoying. I'd say: let's not implement that unless a significant number of people ask for it.

@jvasseur
Copy link
Contributor

jvasseur commented Sep 24, 2017

Maybe we could detect if all the informations from the context are used in the message an hide the context in those cases ?

fabpot added a commit that referenced this pull request Sep 27, 2017
This PR was squashed before being merged into the 3.3 branch (closes #24244).

Discussion
----------

TwigBundle exception/deprecation tweaks

| Q             | A
| ------------- | ---
| Branch?       | 3.3
| Bug fix?      | yes
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes/no
| Fixed tickets | #... <!-- #-prefixed issue number(s), if any -->
| License       | MIT
| Doc PR        | symfony/symfony-docs#... <!--highly recommended for new features-->

- 1st commit) if you view a exception in the profiler, there is no logger available. Making the tab useless, disabled state is now triggered at zero log messages. There's a specialized panel here.
- 2nd commit) when an exception occurs this highlights deprecations in the log table outside the profiler with a warning status. This follows the same signal colors in the profiler.
- 3rd commit) hide the default inactive tabs from CSS to avoid scrollbar flickering.
- 4th commit) favors document.DOMContentLoaded over window.load, we dont want to wait for images to be loaded

Further out-of-scope improvements could be;

- From #24191; i think the logs table should show a direct `View file` link for every error/deprecation/red or yellow line in here. Traversing with `Show context` is tedious.
  - links to file.php for your trigger_error() calls
  - links to config.yml for trigger_error() calls by SF
- From #24151; having the same tooling on both sides is nice
- Events/Translations logs is noise, we have specialized panels for those. To further reduce the overall page size container logs can be moved away too, linked from Configuration and/or Logs. Also see #23247

Commits
-------

1c595fc [TwigBundle][WebProfilerBundle] Switch to DOMContentLoaded event
ea4b096 [WebProfilerBundle] Hide inactive tabs from CSS
0c10f97 [TwigBundle] Make deprecations scream in logs
03cd9e5 [TwigBundle] Hide logs if unavailable, i.e. webprofiler
@@ -22,6 +22,12 @@
</td>
{% endif %}
<td>{{ log.message|format_log_message(log.context) }}</td>
{# hide the context of the 'event' channel because it only displays duplicated information #}
{% if log.context ?? false and log.channel != 'event' %}
<div class="text-muted">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

invalid markup. A div cannot be a child of a <tr>

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've checked the HTML spec and a <tr> can have <td> children and <td> can have children of any type included in "flow content": https://www.w3.org/TR/html51/tabular-data.html#the-td-element. And <div> is one of those "flow content" types: https://www.w3.org/TR/html51/dom.html#flow-content. So, are we good?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but this is not inside the <td>. It is after it

@ro0NL
Copy link
Contributor

ro0NL commented Sep 27, 2017

Why do we care about event channel, to be excluded here, actually? What we need are filters right?

Profiler doesnt do this AFAIK.

@fabpot
Copy link
Member

fabpot commented Oct 1, 2017

@javiereguiluz Can you fix @stof comment here?

@nicolas-grekas
Copy link
Member

ping @javiereguiluz should we move this to 4.1?

@nicolas-grekas
Copy link
Member

Moving to 4.1.

@nicolas-grekas nicolas-grekas modified the milestones: 3.4, 4.1 Oct 12, 2017
{# hide the context of the 'event' channel because it only displays duplicated information #}
{% if log.context ?? false and log.channel != 'event' %}
<div class="text-muted">
{{ profiler_dump(log.context) }}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this will indeed create a hard dependency on WebProfilerBundle in TwigBundle (which will break things in environments where WebProfilerBundle is not available)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How can we solve this? Maybe we can replace profiler_dump by yaml_dump? https://symfony.com/doc/current/reference/twig_reference.html#yaml-dump

@stof stof changed the base branch from 3.4 to master February 21, 2018 11:50
ostrolucky pushed a commit to ostrolucky/symfony that referenced this pull request Mar 25, 2018
This PR was squashed before being merged into the 3.3 branch (closes symfony#24244).

Discussion
----------

TwigBundle exception/deprecation tweaks

| Q             | A
| ------------- | ---
| Branch?       | 3.3
| Bug fix?      | yes
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes/no
| Fixed tickets | #... <!-- #-prefixed issue number(s), if any -->
| License       | MIT
| Doc PR        | symfony/symfony-docs#... <!--highly recommended for new features-->

- 1st commit) if you view a exception in the profiler, there is no logger available. Making the tab useless, disabled state is now triggered at zero log messages. There's a specialized panel here.
- 2nd commit) when an exception occurs this highlights deprecations in the log table outside the profiler with a warning status. This follows the same signal colors in the profiler.
- 3rd commit) hide the default inactive tabs from CSS to avoid scrollbar flickering.
- 4th commit) favors document.DOMContentLoaded over window.load, we dont want to wait for images to be loaded

Further out-of-scope improvements could be;

- From symfony#24191; i think the logs table should show a direct `View file` link for every error/deprecation/red or yellow line in here. Traversing with `Show context` is tedious.
  - links to file.php for your trigger_error() calls
  - links to config.yml for trigger_error() calls by SF
- From symfony#24151; having the same tooling on both sides is nice
- Events/Translations logs is noise, we have specialized panels for those. To further reduce the overall page size container logs can be moved away too, linked from Configuration and/or Logs. Also see symfony#23247

Commits
-------

1c595fc [TwigBundle][WebProfilerBundle] Switch to DOMContentLoaded event
ea4b096 [WebProfilerBundle] Hide inactive tabs from CSS
0c10f97 [TwigBundle] Make deprecations scream in logs
03cd9e5 [TwigBundle] Hide logs if unavailable, i.e. webprofiler
@javiereguiluz
Copy link
Member Author

To not add a hard dependency on VarDumper, I propose a different implementation: the log context is dumped according to what you have installed.

If your app has VarDumper, you see this:

var_dumper

If your app has Yaml, you see this:

yaml

Otherwise, you see this:

php

{
$logs = array();
foreach ($logger->getLogs() as $log) {
if (class_exists('Symfony\Component\VarDumper\Dumper\HtmlDumper')) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could use ::class consts.

$dumper = new HtmlDumper();
$dumper->dump($cloner->cloneVar($log['context']), $output = fopen('php://memory', 'r+b'));
$contextAsString = stream_get_contents($output, -1, 0);
} elseif (class_exists('Symfony\Component\Yaml\Yaml')) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here

if (class_exists('Symfony\Component\VarDumper\Dumper\HtmlDumper')) {
$cloner = new VarCloner();
$dumper = new HtmlDumper();
$dumper->dump($cloner->cloneVar($log['context']), $output = fopen('php://memory', 'r+b'));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can just pass true as the second argument since 3.2 (4be9776) to get the string as returned value.

@javiereguiluz
Copy link
Member Author

My question ... should we complicate this so much ... or should we just always use json_encode() which works reasonable well in all cases?

@@ -22,6 +22,9 @@
</td>
{% endif %}
<td>{{ log.message|format_log_message(log.context) }}</td>
{% if log.context ?? false %}
<div class="text-muted prewrap log-context">{{ log.context_as_string|raw }}</div>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

currently, you have a XSS issue here: you apply the raw filter, but only the rendering using VarDumper is producing HTML properly. Other case are not escaping anything to produce HTML

} elseif (class_exists('Symfony\Component\Yaml\Yaml')) {
$contextAsString = Yaml::dump((array) $log['context'], 1024);
} else {
$contextAsString = json_encode($log['context'], JSON_PRETTY_PRINT);
Copy link
Member

@stof stof Mar 27, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest also adding the JSON_UNESCAPED_UNICODE and JSON_UNESCAPED_SLASHES flags to make the output more human-readable (having \u... codes for non-ASCII chars makes things harder to read)

<td>
{{ log.message|format_log_message(log.context) }}
{% if log.context ?? false %}
<span class="block text-muted prewrap m-t-5">{{ log.context|json_encode(constant('JSON_PRETTY_PRINT') b-or constant('JSON_UNESCAPED_UNICODE') b-or constant('JSON_UNESCAPED_SLASHES')) }}</span>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is is a block display with prewrap, why not using <pre> ? It would be the dedicated markup rather than a span

@@ -24,7 +24,7 @@
<td>
{{ log.message|format_log_message(log.context) }}
{% if log.context ?? false %}
<span class="block text-muted prewrap m-t-5">{{ log.context|json_encode(constant('JSON_PRETTY_PRINT') b-or constant('JSON_UNESCAPED_UNICODE') b-or constant('JSON_UNESCAPED_SLASHES')) }}</span>
<pre class="text-muted prewrap m-t-5">{{ log.context|json_encode(constant('JSON_PRETTY_PRINT') b-or constant('JSON_UNESCAPED_UNICODE') b-or constant('JSON_UNESCAPED_SLASHES')) }}</pre>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you still need prewrap here ? If no, this could be removed (and removing the class from the cSS as your PR is adding it)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think it's needed because when outputting long lines (e.g. long class namespaces) the <pre> doesn't break lines and makes the debug page hugely wide.

@nicolas-grekas nicolas-grekas modified the milestones: 4.1, next Apr 20, 2018
@fabpot
Copy link
Member

fabpot commented Oct 10, 2018

Thank you @javiereguiluz.

@fabpot fabpot merged commit c59fbde into symfony:master Oct 10, 2018
fabpot added a commit that referenced this pull request Oct 10, 2018
…luz)

This PR was squashed before being merged into the 4.2-dev branch (closes #24151).

Discussion
----------

Display the log context in the debug pages

| Q             | A
| ------------- | ---
| Branch?       | 3.4
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #23589
| License       | MIT
| Doc PR        | -

### Before

![before](https://user-images.githubusercontent.com/73419/30269760-564ff2e8-96ea-11e7-98fa-0610d6a0322f.png)

### After

![after](https://user-images.githubusercontent.com/73419/30269764-5830482e-96ea-11e7-946a-a6805c28741a.png)

I'd like to exclude the `event` channel context because it only adds noise:

![event-noise](https://user-images.githubusercontent.com/73419/30269774-67036f52-96ea-11e7-87c0-5ef8328f315a.png)

-----

This change would require to add a hard dependency to the VarDumper component. Do we want to do that? Thanks!

Commits
-------

c59fbde Display the log context in the debug pages
@nicolas-grekas nicolas-grekas modified the milestones: next, 4.2 Nov 1, 2018
This was referenced Nov 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants