-
Notifications
You must be signed in to change notification settings - Fork 11.1k
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
[5.4] Blade: no way to setContentTags() anymore #17736
Comments
It was removed yes, you can use |
Thanks, just was there a reason to add such regression? |
This is kind of a significant change that shouldn't be in a "minor" version revision (5.3 -> 5.4) as it's a breaking change. I'd recommend holding off making a change of this magnitude until the next major version. |
Laravel minor versions are the same as semver major versions, and laravel patch releases are the same as semver minor versions. |
It was removed because it's generally a really bad idea to use it. It makes using any Blade related packages essentially impossible since developers will not know which mark-up tags to use for Blade. |
Thanks @taylorotwell. While this particular change is not a big deal, your team is trying to decide for us what we shall stick to. It's hard to customize Laravel because of such hardcodes. Could you leave setter as "undocumented feature", mark it as @deprecated maybe?
The PHPStorm is highlighting calls of deprecated methods, so people will know that they're using those on their own risk. Please don't remove setter just because it may lead to a problem, we're not children to hide matches from :) |
I have to agree with @denis-chmel on this. I totally understand your point that it shouldn't be used, I like the new way a lot better. Adding that was a great change. However It doesn't erase the fact that code using setContentTags already exists in nontrivial amounts (go do a code search). Continuing to support it keeps people productive, and adding the deprecated tag help people get the right idea for the future. We're all adults here. |
Is there a way to drop blade in favour of a more flexible template engine eg twig? We have an app on 5.3 using client side AngJS 1 templates rendered from blade. We need to use both blade tpl syntax and angJs syntax, adding an @ before each angjs tpl var is excessive as the app has only about 20% variables from blade. We are stuck on 5.3 now. |
Yes, you can use whatever templating engine you want. |
ah yes thanks! https://github.com/rcrowe/TwigBridge |
So use other peoples code in favour of clean own code... |
If anybody need it badly I've solved it for me via a local patch (switches to <<< and >>> tags) composer.json
patch_blade_tags.sh:
|
This is really a BAD idea! |
The bad idea is to violate open/closed principle, @icaife ;) |
This should really be part of the upgrade documentation from 5.3 to 5.4. This is a breaking change for many teams and should be at least highlighted. |
- Now uses Laravel auto registration feature. - No long need to remove 'Illuminate\View\ViewServiceProvider::class' from 'config/app.php' - The ability to 'setRawTags', 'setContentTags', and 'setEscapedTags' have been removed from Laravel (laravel/framework#17736). They are depreciated here. - The compiler function 'setDeleteViewCacheAfterRender', has been deprecated as I didn't find any code where it was actually being used. - Added more tests
It's preventing me from using vue's {{ It's annoying. Don't tell me to use @{{, I hate it. |
Description:
@taylorotwell
It's problematic to migrate to 5.3 -> 5.4 when e.g we reserve {{ .. }} for angularJS, and <?php echo .. ?> for everything else. There seems to be no (simple) way anymore to override Blade tag syntax, after setContentTags(), setEscapedContentTags() were wiped in 5e394bb.
Steps To Reproduce:
The text was updated successfully, but these errors were encountered: