Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
So it appears that Taylor has taken away the Form:: facade, so how would one pull this in via composer and can it still be referenced as a facade?
Anyone know the reason why Taylor chose to do this?
I don't know the reasons why it's been removed, but to use it again, you need to include
"illuminate/html": "@dev"
within your composer.json require section, then in config/app.php update the providers array to include 'Illuminate\Html\HtmlServiceProvider' and the aliases array to include
'HTML' => 'Illuminate\Html\HtmlFacade',
'Form' => 'Illuminate\Html\FormFacade',
Ok yes I thought that having looked it up on Github, just thought I would check to be sure, maybe @jeffreyway can answer this and I'll also try Taylor on twitter.
I would think, with the videos scheduled, Jeff will answer all of our questions. No need to bother Taylor. Laracon is on anyways, they're all busy.
Laracon is over now and am sure he wouldn't mind answering the question, I've asked him things before and he's been cool with it, not that it bothers me why it took it out, I'm just curious.... :)
@lstables - Because they were a pain to manage, created countless unnecessary issues and PRs, and are better left to the community to steer. He's been wanting to do this for a while. Actually, 4.0 removed them...but he added them back in, after people freaked out.
No worries I understand his reasoning that's cool just was curious thanks for clearing up Jeff
Not to derail, but did SSH get the same treatment? I pulled in illuminate/remote but it is having none of it.
@TravisBlasingame not sure buddy, maybe @JeffreyWay can shed some light on this.
@lstables @TravisBlasingame I think the remote component is still here.
Looks like it was removed. At least in the version I downloaded yesterday. You can pull it in the same as html, but there is an error in the construct method where $app isn't type hinted and the IoC container throws a fit.
Interesting. It seems like the form components get plenty of usage, I wonder if Taylor is planning on updating it in a way that ties it more closely to views. Preferably, it would work the same way that Plates works, where you could specify an extension in the config and then access it a view via something like this:
@form->open(/* */);
@form->label('Foo')
@form->input('foo', $foo, ['class' => 'required'])
I think that's a pretty strong decision to take out the html/form component out of the core on a minor release update. I'm sure it will break lots of app code and require heavy refactoring if you don't pull in the "illuminate/html" component.
Which raises some questions...
Has anyone got some input on these?
Good questions @santacruz and you make a very good point about it being a minor release. But I think there's a bit too much drama over this. It takes about 30 characters, a few seconds waiting and a couple of copy/pastes to sort out.
I'm also confused behind the reasoning to remove the Form and Html facades. Calling html and forms common in a website isn't even a bad joke; it's what a website is. So why then should two critical parts of web development be removed from a framework that is so good a simplifying and streamlining? 4.3 includes an updated "Form Requests for Validation." It seems contrary to make this update while removing the Form facade?
I'm willing to learn and adapt but this does seem like a strange decision.
Laravel isn't the only way to build a front-end... For instance, when when using AngularJS or another JavaScript framework to create a Single Page Application (SPA) you would not need the Forms but rather just the backend logic and the JSON response...
Just because a site has forms, doesn't mean they were generated by a Laravel view... Regardless of where the form came from, be it Angular, Backbone, Ember, or Laravel, they still send a FormRequest that will need validated and processed. Therefore, it makes sense to keep and even improve upon the form validation and request objects.
Also, you can create forms without using the Form facade... It's more of a convenience thing... Either way, it takes 30 seconds to pull in, not a big issue. :)
The reason it was removed is that the intention with Laravel is and and always has been to have a clean very simple starter framework. Similar to the reason of why Cashier is not included by default. With a lot of companies starting to build apps that are all API based forms are no longer required as they are used for frontend. This is why the App folder is also changed so drastically from what I can tell. I believe I read in the issues on github that it will the html repo will still be maintained as is cashier.
These are both reasonable explanations. I just don't seem the harm in leaving them in. I do however hope that they are maintained similar to Cashier.
when i use Form::open() it returns the form tags like it was parsed by htmlspecialchars()
i added "illuminate/html": "4.3.*"
@extends('layout')
@section('content')
<h1>Registreeri</h1>
<div class="row">
<div class="col-md4">
{{ Form::open(['role' => 'form']) }}
<div class="form-group">
{{ Form::label('email', 'E-mail') }}
{{ Form::email('email', '', ['class' => 'form-control']) }}
{{ Form::label('password', 'Password') }}
{{ Form::password('password', ['class' => 'form-control']) }}
{{ Form::label('password_confirmation', 'Password Confirmation') }}
{{ Form::password('password_confirmation', ['class' => 'form-control']) }}
</div>
{{ Form::close() }}
</div>
</div>
@stop
<form method="POST" action="http://dater.local/auth/register" accept-charset="UTF-8" role="form"><input name="_token" type="hidden" value="ljjkGp7Yr34lFr8VdcB7rzlBOSkNWoZA6c0jQsvP">
<div class="form-group">
<label for="email">E-mail</label>
<input class="form-control" name="email" type="email" value="" id="email">
<label for="password">Password</label>
<input class="form-control" name="password" type="password" value="" id="password">
<label for="password_confirmation">Password Confirmation</label>
<input class="form-control" name="password_confirmation" type="password" value="" id="password_confirmation">
</div>
</form>
Try using {!! !!} instead of {{ }}.
More info in this thread: https://laracasts.com/discuss/channels/general-discussion/new-blade-tag-for-unescaped-data-thoughts
{{ Form::open() }} worked fine for me but yes adding {{!! !!}} should do the same thing.
I also figured out that {{!! !!}} doesn't parse correctly so I removed a { bracket like so:
{! Form::open() !}
Works just fine and same for the closing brackets.
Here's a video that will lighten your day.
Please or to participate in this conversation.