Blade @includes are appending extra white space to the end
test/include.blade.php
this is only a test
parent.blade.php
<div>@include('test.include')</div>
expected html output:
<div>this is only a test</div>
actual html output:
<div>this is only a test
</div>
In most circumstances, this isn't really an issue, but in cases where you need to prevent white-space between html elements, it becomes an issue as the extra whitespace creates a gap between them.
In Laravel 5.7.x, the same code returned the expected behavior. Potentially even within an earlier version of 5.8, but I'm not sure.
Heya, I think this might be related to https://github.com/laravel/framework/pull/27544 which adds an extra linebreak at the end. This got fixed in https://github.com/laravel/framework/pull/27976 which will be released tomorrow. Feel free to report back if tomorrow's release doesn't fixes your problem.
I just updated to Laravel 5.8.8 and this issue does not appear to be resolved.
I'm getting the same. Here are some copy-and-paste steps to reproduce:
composer create-project --prefer-dist laravel/laravel=5.8.3 issue-27996
echo -n "<div>@include('partial')</div>" > issue-27996/resources/views/parent.blade.php
echo -n "contents" > issue-27996/resources/views/partial.blade.php
echo "Artisan::command('issue-27996', function () {
\$this->comment(view('parent'));
});" >> issue-27996/routes/console.php
php issue-27996/artisan issue-27996
Expected vs Actual output:
- <div>contents</div>
+ <div>contents
+ </div>
Okay, re-opening.
Ping @bzixilu. Do you maybe have an idea if this is related to the changes you made?
It appears they may be related.
The cached view code for parent.blade.php:
<div><?php echo $__env->make('partial', \Illuminate\Support\Arr::except(get_defined_vars(), ['__data', '__path']))->render(); ?></div>
<?php /* /path/to/issue-27996/resources/views/parent.blade.php */ ?>
The cached view code for partial.blade.php:
contents
<?php /* /path/to/issue-27996/resources/views/partial.blade.php */ ?>
So when partial.blade.php is included, it has that new line.
A fix may be to leave out the \n when appending the path to the compiled view.
diff --git a/src/Illuminate/View/Compilers/BladeCompiler.php b/src/Illuminate/View/Compilers/BladeCompiler.php
index 0f084b06f..c5a51c36f 100644
--- a/src/Illuminate/View/Compilers/BladeCompiler.php
+++ b/src/Illuminate/View/Compilers/BladeCompiler.php
@@ -123,7 +123,7 @@ class BladeCompiler extends Compiler implements CompilerInterface
);
if (! empty($this->getPath())) {
- $contents .= "\n<?php /* {$this->getPath()} */ ?>";
+ $contents .= "<?php /* {$this->getPath()} */ ?>";
}
$this->files->put(
@fitztrev it's the base of the whole reason why the feature was added: so the path line would exist at the very last line so PHPStorm could pick it up.
Ok, I don't know the inner workings of PHPStorm. But maybe they would be able to parse it out when it's not on its own line.
But now that you mention that, I'm curious why this was added. https://github.com/laravel/framework/pull/27963#issuecomment-475618587 Maybe this should belong in a package too.
But now that you mention that, I'm curious why this was added. #27963 (comment) Maybe this should belong in a package too.
@fitztrev touch茅 and you make an excellent point here. Ultimately this wasn't my call though for this feature. And I do believe that the impact of this particularly feature (the path in the view) is worth adding because it empowers such a useful debugging feature in PHPStorm.
However, I fully agree that we should look at how we can look at a way to keep the feature while solving this bug.
Is this only a problem when you use an include between html tags? Or also in other ways/usages?
However, I fully agree that we should look at how we can look at a way to keep the feature while solving this bug.
馃憤 We'll wait to see what @bzixilu says, if there's another way PHPStorm could parse it.
Is this only a problem when you use an include between html tags? Or also in other ways/usages?
Other ways/usages too. A blade @include() is always appending a newline when rendered. The surrounding <div> tag was only used in the example to better illustrate the problem.
This was touted online by JetBrains, Taylor, Laravel News, etc. Though not specifically mentioned, it seems like it would work out-of-the-box. So including it in the core makes sense. I think we should keep trying to make this work without going the third-party route.
Hi all, sorry for one more breakage of Blade usage scenario. I'll start an investigation today and will do my best to come back soon with the possible solution.
Closing this because we've decided to revert the feature for now. Please see https://github.com/laravel/framework/pull/28099#issuecomment-479900212 for more info.
Most helpful comment
Hi all, sorry for one more breakage of Blade usage scenario. I'll start an investigation today and will do my best to come back soon with the possible solution.