Software-update: Laravel 5.5

Laravel is een opensource PHP-framework waarmee webapplicaties kunnen worden ontwikkeld. Achter Laravel staat een uitgebreide community en er is uitgebreide documentatie. Niet voor niets is het naast Symfony en Yii een van de meest populaire PHP-frameworks van dit moment. Woensdag is versie 5.5 van Laravel uitgekomen, een long term support-uitgave, en de release notes daarvan zien er als volgt uit:

Laravel 5.5 is the Next LTS Release

Laravel 5.5 is the next long term support (LTS) version of Laravel (the last being 5.1). LTS versions receive bug fixes for two years, and security fixes for three years.

General minor releases receive bug fixes for six months and security fixes for one year.

Whoops Package

You might recall the filp/whoops package from Laravel v4 provided elegant stack traces for your most frustrating debugging moments. The whoops package returns to Laravel 5.5!

Collection Dumping

Another great debugging feature (that I’ve seen previously as a package or macro) is collection dumping methods. Read our collection dumping post for more details.

Exception Rendering

Exceptions now can render a response if they define a public “response” method. Typically, in earlier versions of Laravel you might add a check to the App\Exceptions\Handler::render() method, and conditionally send back a response based on the exception type.

You can also implement the Responsable interface in your exception classes, and Laravel will respond automatically.

The Responsable Interface

The Responsable interface is another response addition to laravel that we’ve covered at Laravel news. A class implementing the interface can be returned from a controller method; the router now checks for an instance of Responsable when preparing the response from Illuminate\Routing\Router.

In this simple example, you could automatically respond with JSON if you make a request via AJAX, and by default response with a redirect the songs.show route.

Request Validation Method

In past versions of Laravel you would pass the request instance to the $this->validate() method in a controller. Now, you can just call validate on the request object.

Another nice benefit from this style of calling validation is that the return value acts like Request::only(), returning only the keys provided in the validation call. Returning only the validated keys is an excellent convention to use, avoiding Request::all().

Custom Validation Rule Objects and Closures

My favorite feature in Laravel 5.5 is hands-down the new custom validation rule objects and closures. Creating a custom rule object is an excellent alternative to creating custom rules with Validator::extend (which you can still use), because it’s more clear where the rule logic is located at a glance.

The closure style takes the attribute and value, and a fail parameter that you call if the validation rule should fail. The closure is a nice way to experiment with custom validation before you extract it to a dedicated rule object, or for one-off custom validation needs.

To create custom validation rule objects, you can use the new make:rule command.

We have a dedicated post to custom validation rules here on Laravel News, be sure to check it out!

Auth and Guest Blade Directives

We have written about Blade::if() directives in 5.5. A few new conditional directives in 5.5 are @auth and @guest.

Frontend Presets

When you are starting a new project, Laravel 5.5 provides Vue.js scaffolding by default. In Laravel 5.5 you can now pick from a few presets and remove all frontend scaffolding with the “preset” Artisan command in Laravel 5.5.

If you look at the help, you can see that it allows you to pick “none,” “bootstrap,” “vue”, or “react”.

Separate Factory Files

Factory files were previously defined in one ModelFactory.php file. Now, you create different files for each model. You can create a factory file when you are creating a new model. You can also create a factory file directly with “make:factory”.

The migrate:fresh Migration Command

The new “migrate:fresh” migration command 5.5 is a nice addition to creating a clean database in development. The migrate:fresh command drops all the database tables and then runs the migrations.

You might be familiar with the existing migrate:refresh command, which rolls back migrations and then reruns them. Usually in development you want to just drop the tables, getting a fresh database, and running migrations.

The RefreshDatabase Trait

On the testing front, the RefreshDatabase trait is the new way to migrate databases during tests. This new trait takes the most optimal approach to migrating your test database depending on if you are using an in-memory database or a traditional database. The DatabaseTransactions and DatabaseMigrations traits are still available in 5.5, allowing you to upgrade without using the new RefreshDatabase trait.

The withoutExceptionHandling() method

The base test case inherits a method withoutExceptionHandling(), which allows you to disable exception handling for a test. Disabling exception handling allows you to catch the exception in your test and assert the exception instead of the exception handler responding. It’s also a useful debugging tool when your test is doing something you don’t expect, and you want to see the actual exception.

Automatic Package Discovery

The last feature we are going to look at is automatic package discovery. While Laravel packages aren’t usually hard to install, the package detection feature means you don’t have to set up providers or aliases. You can disable auto-discovery for specific packages.

Learn more about this feature from the Taylor Otwell’s article on this feature, and on our post.

Helaas!
De video die je probeert te bekijken is niet langer beschikbaar op Tweakers.net.

Versienummer	5.5
Releasestatus	Final
Besturingssystemen	Scripttaal
Website	Laravel
Download	https://laravel.com/docs/5.5/installation
Licentietype	GPL

Reacties (29)

Is er een andere versie van de video in de omloop? Source code bekijken in 360p is knap lastig!

[edit] Er is dus een dikke versie @ Youtube: https://www.youtube.com/watch?v=I8chAg9RxWc
waarom linken we die niet??

[Reactie gewijzigd door Red devil op 31 augustus 2017 16:47]

Omdat tweakers eigen ads heeft op videos.

Hoe makkelijk is Laravel eigenlijk te upgraden? Ik heb nog wel een paar sites en Laravel is de #1 framework in PHP-land voor zover ik dat weet.

Maar ik heb maar een paar sites en ik wil het liefste de upgrades zo eenvoudig mogelijk houden, zonder al te veel breaking changes. Hoe is dat tot nu toe met Laravel?

#1 PHP framework ben ik t niet mee eens...er is een grote groep liefhebbers maar een even grote groep "haters" waar ik mezelf wel onder schaar. Als iemand er blij van wordt lekker zelf weten en gebruiken maar ik vind het erg rommelig met alles in de global scope en random overal maar aanroepen wat je wilt waar er allemaal magie achter de schermen wordt weggestopt. Als minder gevorderde vast lekker simpel maar ik heb alles graag zo expliciet mogelijk. Ook is t compleet bloated met allemaal spul erin wat je vaak totaal niet nodig heb, ik laad dat liever in wanneer ik t nodig heb. Daarnaast kan de auteur zeer slecht tegen kritiek wat soms lachwekkende situaties oplevert op Reddit waar hij zichzelf nog wel eens tegenspreekt. En geen semver, ik blijf het een rare keuze vinden

[Reactie gewijzigd door Cartman! op 31 augustus 2017 22:04]

Jeffrey Way met z'n beruchte Visual Debt video (in een notedop: neem een grote hamer en sloop al het goede van (wat versie 7.x brengt in) PHP eruit) is een noemenswaardige klassieker

Ja, dat moet wel de slechtste tutorial zijn van afgelopen jaren

Als minder gevorderde vast lekker simpel maar ik heb alles graag zo expliciet mogelijk.

Dit punt begrijp ik niet helemaal. Als het voor een minder gevorderde simpel is, dan is het toch helemaal appeltje eitje voor iemand die wel gevorderd is? Ik vind het een beetje krom wat hier staat. En 'zo expliciet mogelijk' kan met Laravel natuurlijk net zo goed. Dat is juist de kracht van PHP. Een framework bepaald niet wat de (on)mogelijkheden zijn van PHP.

Ook in Laravel kan je dus alles opzetten en doen zoals je het zelf wilt, ook als je het allemaal expliciet wilt hebben. Je bent niet verplicht om de providers en/of aliases array te gebruiken, om een package te kunnen gebruiken, bijvoorbeeld. De benodigde use-statements kun je ook gewoon handmatig doen in de classes waar je de package wilt hebben.

Ook is t compleet bloated met allemaal spul erin wat je vaak totaal niet nodig heb, ik laad dat liever in wanneer ik t nodig heb.

Dit is echt een non-argument. Met élk framework kun je dit aanvoeren als reden om het niet te willen gebruiken, want elk framework laadt modules en dingen in die je niet gebruikt. That said, draai het eens om; wat houdt je tegen om de modules die je toch niet gebruikt te verwijderen? Het mes snijdt twee kanten op hé.

Laravel zal vast ook een logische beredenering gebruiken voor versienummers, het is alleen niet çompatible' met semver, boehoe. Ik zie het probleem niet zo, waarom dat per se semver zou moeten zijn.

[Reactie gewijzigd door CH4OS op 1 september 2017 15:35]

Laravel spreekt in de meeste documentatie over de globale methodes als "$app = app('app');" en te pas en te onpas wordt in elk stukje code (procedureel of OOP) random maar wat aangeroepen waarvan je geen idee hebt wat t doet achter de schermen (de zogenaamde facades). Ik wil gewoon zelf met services werken en alleen code gebruiken die ik nodig heb. Het kan ongetwijfeld maar is niet wat 99% van de community doet want die roepen gewoon view() aan waar ze t denken nodig te hebben. Zie het overigens n beetje (extreem voorbeeld) als Lego; een minder gevorderde bouwt graag met Duplo en een gevorgde pakt technisch Lego. Kan die gevorderde het ook met Duplo? Ongetwijfeld...maar moet je dat willen?

Daarnaast bevat Laravel bijv Eloquent (Active Record) waar ik liever met Doctrine (Data Mapper) werk. Wederom, het kan wel maar moet je t willen als de maker van t framework van alles meelevert. Er wordt gekozen dat Vue.JS er goed bij past, queues, notitications.... ik moet t allemaal niet gewoon.

Symfony Framework optimaliseert de gehele DI container dat er alleen in zit wat nodig is dus alles wat ik niet gebruik wordt niet meegeladen.

Waarom semver? De gehele industrie gebruikt het dus als ik een nummering voorbij zie komen met 5.4.0 en 5.5.0 verwacht ik dat het compatible is maar bij Laravel is dat niet zo. Geef mij maar de duidelijke BC promise van Symfony (die ook geldt voor hun components, niet alleen t framework) waar je duidelijk weet waar je aan toe bent.

Zoals ik zei; ieder z'n eigen keuzes en ik wil geen gebruiker van t framework aanvallen. Persoonlijk vind ik Laravel helemaal niks en t ging mij om de uitspraak dat iemand dacht dat dit het nr #1 was en dan geef ik graag wat tegengas.

Ik voel mij ook zeker niet aangevallen en wil jou ook zeker niet aanvallen. Ik probeer alleen maar aan te geven dat wat je wil eigenlijk in elk framework wel kan en dat je in elk framework wel dingen krijgt die je niet gebruikt en dus altijd kan verwijderen. Geldt net zo goed ook voor Zend als Symfony.

In Zend en Symfony frameworks hoef je t niet te verwijderen want het zit er standaard niet in waar dit bij Laravel wel zo is. Opzich geen groot drama maar ik vind de opzet van dit gescheiden houden prettiger dan ieder los dingetje meeleveren.

Laravel spreekt in de meeste documentatie over de globale methodes als "$app = app('app');" en te pas en te onpas wordt in elk stukje code (procedureel of OOP) random maar wat aangeroepen waarvan je geen idee hebt wat t doet achter de schermen (de zogenaamde facades).

Sorry maar hier moet ik een klein beetje om lachen. Het klinkt alsof je totaal geen idee hebt wat het doet en je er daarom zo tegen af zet. Die app helper methode, compleet optioneel overigens, is om instances te resolven uit de container. Als je geen idee hebt wat het doet achter de schermen (niets is 'random' zoals je beweert) heb je de documentatie niet gelezen of snap je niets van DI. Het is ook niet zo dat maar lukraak van alles in de container wordt geladen, hier heb je gewoon controle over.

Daarnaast bevat Laravel bijv Eloquent (Active Record) waar ik liever met Doctrine (Data Mapper) werk. Wederom, het kan wel maar moet je t willen als de maker van t framework van alles meelevert. Er wordt gekozen dat Vue.JS er goed bij past, queues, notitications.... ik moet t allemaal niet gewoon.

Allemaal optioneel, Laravel werkt ook prima met Doctrine. Er is ook een uitgeklede versie van Laravel trouwens, Lumen

Ik snap juist hoe DI werkt, daarom gebruik ik Symfony Framework waar je dit zelf regelt ipv zomaar wat statics aan te roepen (die façades worden genoemd wat ze eigenlijk niet zijn). Zoals ik zei; het kan wel op een stricte oo manier maar je komt t zelden tot nooit tegen.

Ik ben zowel fan van Symfony als Laravel. Maar om Laravel #1 Framework in PHP land te noemen vind ik nogal gedurfd.

Enterprise sites zie ik toch eerder Symfony gebruiken of blijven gebruiken.

Ah sorry, de laatste keer dat ik research heb gedaan naar PHP frameworks is alweer een jaar geleden en ik keek voornamelijk naar mijn persoonlijke requirements.

Je zult gelijk hebben.

Het is een van de hardst groeiende, wellicht dat dat het verwarrend maakt. Daarnaast gebruikt het een aantal Symfony pakketten (tenminste, een jaar geleden, ik denk nog steeds toch?). Op de eerste plaats, Laravel is zeker een goed framework hoor! Enterprise zal wellicht kiezen voor Symfony, dat draait al langer mee, ik weet niet of het meer features heeft of zo, maar het is al wat meer uitgekristalliseerd als ik de meningen om me heen hoor.

Alhoewel dat de upgrade van Laravel van 5.4 naar 5.5 voor mij waarschijnlijk 2 minuten wordt als ik de guide zie, terwijl 5.3 naar 5.4 me een paar uur gekost heeft. Dus waar ik bij 5.3 naar 5.4 nog het idee had dat ze aan de basis aan het sleutelen waren, heb ik dat bij de update naar 5.5 veel minder.

Gewoon de upgrade guide volgen: https://laravel.com/docs/5.5/upgrade, eventueel kan het ook geautomatiseerd: https://laravelshift.com

Het ligt er vooral aan hoe jij je eigen code hebt geschreven en binnen jou Laravel project hebt verweven met het framework. Als jij het netjes geschreven hebt (SOLID), dan zou het niet zo'n probleem mogen zijn.

Verder sluit ik me aan bij @goodfella, dat Laravel niet perse nummer 1 is. Net als hij vind ik ook Symfony erg goed. De twee frameworks zijn echter oplossingen voor verschillende business cases. Daarom zou ik niet willen spreken van een beter framework tussen deze twee.

Het upgraden van Laravel 5.4 naar Laravel 5.5 is ook een fluitje van een cent. Je hoeft dan in principe enkel de versienummers van Laravel (duh) als PHPUnit te verhogen, zie ook de documentatie. Ikzelf maak echter ook gebruik van laravel-collective/html, die moest ik dan als enige extra updaten (deed ik althans uit voorzorg, omdat die in het verleden (bij eerdere releases van Laravel) wel bijgewerkt moest worden.

Kijk even of je wel laravel-collective/html wel wilt. Die was namelijk bij mij alles super sloom aan het maken bij wat projecten. Kan best dat het nu niet meer zo is hoor - ik heb de afweging gemaakt om gewoon zelf de HTML te schrijven aangezien dat toch niet veel moeite is. Alleen geef ik toe dat ik de laravel-collective/html manier veel mooier vind!

Ik denk dat het dan een issue is geweest bij jouw projecten, want in de webapp die ik ontwikkel in Laravel heb ik totaal geen last van performance issues, icm laravel-collective/html. Had je wellicht laravel-collective/form erbij? Volgens mij gaf die inderdaad wel traagheid, maar die is tegenwoordig niet meer nodig, zover ik weet.

[Reactie gewijzigd door CH4OS op 31 augustus 2017 17:42]

Is wel wat jaren terug hoor maar volgens mij had ik idd die van form erbij. Ik zal binnenkort weer even kijken!

denk je van lts versie naar lts versie te gaan maar dat is dus niet zo.

dit wordt een flinke upgrade vanaf 5.1

Van LTS naar LTS is lijkt misschien handig, maar uiteindelijk kost dit meer dan het oplevert.
https://stovepipe.systems...sioning-and-compatibility

Een goed framework dat o.a. semver volgt bied de mogelijkheid om naar de volgende minor versie over te stappen zonder dat je dan het risico loopt dat je alles moet bijwerken (er zullen ongetwijfeld deprecation warnings zijn of in uitzonderlijke gevallen een optie die veranderd is vanwege veiligheidsproblemen).
Maar op een LTS blijven hangen omdat het voor langere tijd word ondersteund heeft al meerdere bewezen geen complete oplossing te bieden voor frameworks.

Ubuntu bied ook LTS releases aan, maar dan alleen te maken met software versies en compatibiliteit onderling. Bij een framework is dit een ander verhaal omdat je te maken hebt een meestal diepe integratie.

Daarnaast is het zo dat een LTS van het framework niet perse aan LTS betekend van andere libraries en dat deze een oudere framework versie ondersteunen. Ik heb verschillende bundles en libraries ontwikkeld, en voor lange tijd had ik als minimale eis Symfony 2.3, maar dit ging op dan duur meer tijd kosten dan het waard was, dat ik hiermee gestopt ben. Als ik nu Symfony 3.1 vereist dan is het probleem om over te stappen op Symfony 3.3, want Symfony volgt semver (in zekere zin), en is dus geen spraken van een BC break.

Bij Laravel is dit een ander verhaal, ik heb gehoord dat de maker het geen probleem vind bestaande features te verwijderen tussen minor releases. Dan is een tussentijdse upgrade inderdaad een stuk complexer.

In het geval van Symfony Framework is de duidelijke roadmap dat je van 2.3 t/m 2.8 compatible blijft en dus kunt upgraden zonder dat er wat stuk gaat. Je krijgt ook overal te zien wat deprecated is voor de 3.x versie en als je die hebt weggewerkt kun je veilig upgraden naar de nieuwste versie in 3.x (momenteel 3.3). Persoonlijk vind ik dit een van de sterkte punten van dit framework wat t erg geschikt maakt voor langer lopende projecten.

Bij Laravel is dit een ander verhaal, ik heb gehoord dat de maker het geen probleem vind bestaande features te verwijderen tussen minor releases. Dan is een tussentijdse upgrade inderdaad een stuk complexer.

Klopt...public api's zijn meerdere keren gewijzigd zonder waarschuwing waardoor er best wat boze users waren. Juist semver maakt het zo prettig om dit soort dingen te voorkomen.

Eindelijk kan ik weer een cool-kid zijn met whoops!

-

[Reactie gewijzigd door chronoz op 31 augustus 2017 20:48]

Maak een gezocht advertentie op Vraag en Aanbod voor werving en selectie of plaats een vacature op IT banen, dan heb je een wat groter bereik, denk ik zo.

[Reactie gewijzigd door CH4OS op 1 september 2017 12:57]

AngularJS 1.4.x good luck with that

Tweakers heeft een vacature sectie waar je dit kan plaatsen (maar dan hopelijk wel wat uitgebreider).
Daarom krijg je een -1.