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

Skip to content

Add options to monolog console handler and formatter #23929

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

Closed
wants to merge 4 commits into from
Closed

Add options to monolog console handler and formatter #23929

wants to merge 4 commits into from

Conversation

grongor
Copy link
Contributor

@grongor grongor commented Aug 18, 2017

Q A
Branch? 3.4
Bug fix? no
New feature? yes
BC breaks? no
Deprecations? no
Tests pass? yes
License MIT

TODO:

  • submit changes to the documentation, if people like this patch
  • send PR to monolog-bundle to allow users to use the options in configs

PS: this is my first contribution here, please be gentle :)

Copy link
Member

@chalasr chalasr left a comment

Choose a reason for hiding this comment

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

Welcome! Could you please explain your use case for this feature?

@@ -78,6 +78,7 @@ public function __construct($options = array())
'date_format' => self::SIMPLE_DATE,
'colors' => true,
'multiline' => false,
'ignoreEmptyContextAndExtra' => false,
Copy link
Member

Choose a reason for hiding this comment

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

using camel case seems inconsistent

Copy link
Contributor Author

Choose a reason for hiding this comment

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

wow I didn't even notice :) I will fix that

@grongor
Copy link
Contributor Author

grongor commented Aug 18, 2017

@chalasr hey! I tried to log some stuff in the console commands with PSR compatible logger, something like this:

$this->logger->info(
    'Done processing {rows} rows from {from} to {to}',
    ['rows' => 123, 'from' => '2017-08-06', 'to' => '2017-08-12']
);

and I expected to see this in console:

[2017-08-18 12:05:48] app.INFO: Done processing 123 rows from 2017-08-06 to 2017-08-06

but I got output like that one:

[2017-08-18 12:05:48] app.INFO: Done processing 123 rows from 2017-08-06 to 2017-08-06 {"rows": 123, "from": "2017-08-06", "to": "2017-08-06"} []

which doesn't seem nice or usefull to me at all. I didn't find any other way to fix this than by writing my custom Handler and Formatter.

EDIT: forgot to mention that I plan to submit another patch to allow unsetting context values that are used as placeholders. This PR actually solves half of the problem where this:

[2017-08-18 12:05:48] app.INFO: Done some processing [] []

becomes this:

[2017-08-18 12:05:48] app.INFO: Done some processing

That is something that I still don't like and think is not useful :) Or at least that it deserves an option to be turned off :)

EDIT 2: I added the "missing" patch which enables what I described above. I hope that now you understand what I wanted to achieve :)

@grongor
Copy link
Contributor Author

grongor commented Aug 20, 2017

I added another commit which enables you to optionally remove context fields that are used as placeholders. All these changes combined make the log messages look much cleaner and without unnecessary variable dumps.

If you want to split changes somehow or change something, please let me know. Thanks!

@nicolas-grekas
Copy link
Member

@grongor would your use case be covered by #24300? If yes, then better not add complexity and close this?

@grongor
Copy link
Contributor Author

grongor commented Sep 26, 2017

@nicolas-grekas I'm sorry, but I fail to see the relevance here. It appears to me that the #24300 only adds a minimal PSR-3 logger implementation if there is none present. This PR addresses missing configuration options when using Monolog, which is a PSR-3 logger, ergo #24300 doesn't apply. Am I missing something?

@nicolas-grekas
Copy link
Member

nicolas-grekas commented Sep 26, 2017

The relevance is that adding options increases the complexity for users, so if we can find a way that is not configurable but works great for everyone, that's better IMHO. #24300 uses a very simple format, that contains no json context, so maybe that was enough for you. If yes, then better not plan for what others could maybe (not) need :)

@grongor
Copy link
Contributor Author

grongor commented Sep 26, 2017

Yeah, of course, I understand that adding unnecessary complexity is a bad thing to do :) I went through both PRs 3 times now, and I understand your motivation not to increase complexity, but I still not see how is #24300 relevant to this PR. I don't think that it can solve my use case.

I want to use Monolog and the context variables; I just don't want them to clutter the output. #24300 is irrelevant for anyone using Monolog (or at least it looks like that to me - please correct me if I'm wrong, I'm not a Symfony nor Monolog expert by a longshot).

@nicolas-grekas
Copy link
Member

Moving to 4.1. Rebase on master might be needed, where PHP 7.1 features can be used btw.

@nicolas-grekas nicolas-grekas modified the milestones: 3.4, 4.1 Oct 8, 2017
@nicolas-grekas nicolas-grekas modified the milestones: 4.1, next Apr 20, 2018
$record = $this->replacePlaceHolder($record);

$levelColor = self::$levelColorMap[$record['level']];
$context = $extra = '';
if (!empty($record['context']) || !$this->options['ignore_empty_context_and_extra']) {
Copy link
Member

Choose a reason for hiding this comment

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

we should not ignore an empty context if extras are not empty. Otherwise, you won't be able to know it is the extras (it will look like as if it is the context being dumped)

@lyrixx
Copy link
Member

lyrixx commented May 16, 2019

Hello, I think this issue is solved thanks to #30345 and symfony/monolog-bundle#297

@grongor Could you confirm it's OK?

@grongor
Copy link
Contributor Author

grongor commented May 17, 2019

@lyrixx Hi, only partially ... possibility to configure formatter options is great and appreciated but I still miss the options which I wanted to introduce in this PR. But if you don't want them in the upstream then that's ok, I'm using my "clone" anyway...

@Nyholm
Copy link
Member

Nyholm commented May 3, 2020

I think using a custom formatter for this case makes more sense.

This PR has been stalled for a long time. I suggest to close it.

@fabpot fabpot closed this May 3, 2020
@nicolas-grekas nicolas-grekas modified the milestones: next, 5.1 May 4, 2020
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