fixes issue with stderr when there was "]" character.

[nikopeikrishvili]

Fix log message handling for messages with ']' character (Issue #48924)

This commit resolves the issue where log messages containing the ']' character were incorrectly processed due to the explode function splitting the log string on this character. This issue was traced to the explode function in ServeCommand.php, which removes the DateTime from the actual log message.

framework/src/Illuminate/Foundation/Console/ServeCommand.php

Line 290 in 20085fe

$warning = explode('] ', $line);

Previously, a log message like [2023-11-11 10:08:06] local.ERROR: [Test] This is a test error log entry
P.S. The framework prepends DateTime. It's not part of user input
That was split into an array, with only the second element being printed, leading to the loss of part of the log message.

// Result after  explode('] ', $line);

Array
(
    [0] => [2023-11-11 10:08:06
    [1] => local.ERROR: [Test
    [2] => This is a test error log entry
)

framework/src/Illuminate/Foundation/Console/ServeCommand.php

Line 291 in 20085fe

$this->components->warn(count($warning) > 1 ? $warning[1] : $warning[0]);

The fix involves replacing the explode logic to handle log messages with ']' characters, ensuring complete and accurate logging. The updated code now processes log messages correctly, preserving the full content.

[Radiergummi]

@nikopeikrishvili This is a good fix, thank you! I'm wondering, though... this still relies on all output lines starting with something in brackets, that is, a specific log format, right?

There are currently two problems with the way artisan serve handles process output. One, it essentially wraps the built-in PHP webserver, which doesn't report the request URL, so the serve output simply shows dots and the request time in seconds.
Two, it assumes developers don't touch the logging config.

This issue got me thinking if it really has to be that way. If there was an ad-hoc "serve" log channel that would wrap all output to stderr in JSON, we could solve both issues: On requests, issue a specific log message with the request details, so serve could display the URL (like Octane does); and on application-generated log messages, print the output without any truncation. This would even allow using different styling based on the severity.

@taylorotwell would you be interested in a PR that enables proper logging integration for serve, such that it would show request URLs and format messages according to their severity in the output?

[driesvints]

@Radiergummi Taylor doesn’t sees comments on closed prs so your best bet is to just send in a pr for him to review.