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
Logging to a file using relative path fails in cli mode #10551
Comments
From the information provided in the public slack channel about this issue, the actual path for the project was not in |
Upgrading to impact high since the upgrade path between majors includes logging out deprecation warnings. |
Copied from silverstripe/developer-docs#165 (comment) app/_config/mylogging.yml
Setup
When running dev/build flush=1 from CLI:
When requesting page via browser
|
We'll have a chat with our internal hosting team to make who will have more knowledge about how to handle this. |
I'd say the CLI should behave like if it was run from the webroot (in terms of relative paths resolution), and then the config can stay the same and be valid for either use case. |
CMS 4 / CMS 5 Docs were updated. Explanations and examples were added. |
Affected Version
4.11
Description
The documentation mentions to use a relative path to log on file.
This works on browser but not using command line.
It causes the following error:
ERROR [Emergency]: Uncaught UnexpectedValueException: The stream or file "/var/www/../silverstripe.log" could not be opened in append mode
Steps to Reproduce
Using the command line run a CliController class or BuildTask class which itself "raises logging diagnostic information"
Acceptance criteria
For CMS 5: Investigate ways to make the relative path work the same regardless of whether you're using CLI or HTTP requests.SS_ERROR_LOG
environment variable still works, it is clearly documented along side the above file logging and works as expected.Notes
Monolog\Handler\StreamHandler
which we obviously don't have any control over. It's very likely that we just can't do anything about it for CMS 5 and the solution across the board is to use absolute file paths.PRs
The text was updated successfully, but these errors were encountered: