Only use the custom Logger when explicitely running a build task #448
Conversation
maxime-rainville
changed the title
| @@ -42,15 +44,8 @@ public function build(HTTPRequest $request) | |||
| echo "<div class=\"build\">"; | |||
| } | |||
| $clear = true; | |||
| $verbosity = strtoupper($request->getVar('verbosity') ?? 'INFO'); | |||
There was a problem hiding this comment.
Had to remove the verbosity because the default logger doesn't support this. Since the scope where Logger is used has been substantially curtail by this PR, this seems reasonable.
There was a problem hiding this comment.
Verbosity is currently explicitly mentioned in the docs as something that can be controlled, so I think that section in the docs needs to be removed.
There was a problem hiding this comment.
Created a related PR to fix the doc silverstripe/silverstripe-framework#10279
maxime-rainville
changed the title
|
Lots of deprecation warnings in the PHP8.0 travis run |
Co-authored-by: Guy Sartorelli <36352093+GuySartorelli@users.noreply.github.com>
|
Answered everyone's feedback. |
There was a problem hiding this comment.
Tested locally in both dev and live modes, looks good to me.
Logging during dev/build and dev/graphql/build both with CLI and in browser works the same as it did before the PR.
Logging during a schema build on first request used to output the logs into the HTTP response which caused errors on the front-end - now logs using the Psr\Log\LoggerInterface.errorhandler logger defined in Framework instead.
|
@maxime-rainville Do you think it might be worth writing a test to ensure the logged output doesn't sneak into http responses on on-demand builds? |
|
I think it's a bit too meta to test. To test that properly I would need something that nukes the GraphQL folder and rerun a request ... the logging is just as likely to break because it gets captured by PHPUnit instead of being captured in the response. |
The logger is echoing build info statement when building the schema on-demand
Parent issues