[00:00] Hello guys, so in this week's Laravel new minor version, I saw this pull request emerged. First party support for image processing. And now it's also in the docs, in that menu item, image manipulation.
[00:14] And I was really intrigued by that, because, well, we have tools for image manipulation in Laravel ecosystem. Of course, many people use popular Laravel media library by Spotty, which under the hood uses Spotty image for image manipulation,
[00:29] Also, for PHP general users there is intervention image. So why? That was my first question and what is the difference between first party support and those libraries.
[00:41] This is exactly what I will show you in the video, because I tried it out. I asked Cloud Code to build me a demo with comparison of intervention image, Laravel native and media library and let's dive in and I will show you the difference.
[00:54] So let's try to upload some kind of image with intervention image first and I will show you the code and then I will show you the code of the new Laravel native way. And speaking of native, the screenshot will be about super native of native PHP, which
[01:09] I will test separately on my native PHP daily channel. So the result of that is original image and WebP thumbnail. And this is the code of the controller using that intervention image package without first
[01:21] party support, without Apache Media Library, without any other packages. So there's image manager, then you have a lot of choices to make basically, and functions to call,
[01:33] like WebP encoder. So this is the typical code of intervention image, which is not really a bad code, but look at how many manual decisions we have to make. We have to generate random file name,
[01:47] we have to have the image manager and driver here, and driver is gd in this case, so we need to define what driver do use, we need to call encoder, and we need to actually know what that is. So the
[02:00] flow is that we call Laravel functions to upload the file, then we call intervention image in the middle to process the file, and then again Laravel functions to store the thumbnail. And this was exactly the multi-step flow which Laravel image first party is trying to solve. It's not exactly
[02:18] a problem, but more like a convenience thing. So if we try to upload an image with Laravel native, the functionality will be roughly the same. So, let's upload another image, and we have the original and the WebP thumbnail,
[02:32] but the code is different. So this is the code when using the new Laravel native another controller so we have this chained functions with first support for everything that in case of
[02:45] intervention image is a little bit more manual it's kind of less friction and fewer intermediate steps so for example in case of intervention image we need two variables here the photo itself and the path because the photo then is used
[03:00] here and path is used down below. In case of Laravel first-party support we don't need the original image object, it's just request file photo and request image is
[03:13] what is doing the most of the work. So this is one of the examples of quite a few Laravel functionality that they took as first-party solution, like for example recent Laravel AISDK, its first-party solution for a lot of
[03:28] functions that were scattered all over packages previously. Or it also reminds me of Pest, for example, which was released as kind of a wrapper over PHP unit, and a lot of people were questioning that at the time. So why separate framework in addition to PHP unit? But over the
[03:45] time, of course, Pest evolved into something much bigger. But the main idea was basically PHP unit, but just more native for Laravel, first party. Well, in case of Pest, technically,
[03:57] it's not first party, but you get the idea. Basically, the goal is to have more convenience using already native first party Laravel functions under the hood, like file manipulation, file
[04:10] system and stuff like that, instead of creating driver manually, like in this case. But in fact, interestingly, it does use the same driver under the hood. So in the composer JSON, you can see
[04:22] that intervention image is actually used under the hood for laravel image manipulation. So in the official documentation of image manipulation, you can see that intervention image is a prerequisite.
[04:36] So before using laravel image manipulation, you need to do compose require that. So you can technically call it a wrapper, first party wrapper over intervention image, but again,
[04:48] more native to Laravel syntax. Now, what about spotty media library and spotty image? Is it the same or different? Do we still need spotty media library? And the answer is in the name of the package of media library. Well, it's not only for images, and it's also building library just may or
[05:07] may not use images under the hood So for example if we try to do the same thing as in other examples to upload the image Yes you can use Media Library for that and you would get the same result with a bit different code but Media Library is so much more on top of that
[05:25] So, for this specific scenario, SpyT code is probably the shortest, just this. And then, in the Eloquent model, you configure all the parameters for all possible media collections,
[05:38] conversions and stuff like that with the syntax of spartan media library so the code is actually similar to laravel controller here so chain of methods is just more geared towards well
[05:51] collections and gallery and library so the question do we still need spartan media library yes because it does much more under the hood and this is for a simple example of one image if we
[06:03] go Media Library++, I called it, separate page. For example, let's upload multiple images, up to eight files, it says. Let's choose all three, then something something, generate the gallery.
[06:17] This is what the Media Library is about, about the collection, the library, the gallery of images, which looks like this. So this is one image with a lot of conversions and thumbnails and cropping
[06:30] So, this is another image and the third image. So, yeah, this is what Sparky Media Library is about, and that's why the first-party image manipulation is not in conflict with that.
[06:43] Image manipulation takes just small part of Sparky Media Library functionality. So, in case of that controller, what Sparky Media Library can do is something like this. Add multiple mediaform requests, each with custom properties and stuff like that, and
[06:58] again it's all defined in the model, so you register collections, you register conversions for the whole library, for the whole set of images.
[07:10] And then also spicy media library takes care of the database structure, the media database table, which then contains all the information about the files, and in case of regular liable first party controller you need to take care of database yourself.
[07:24] This is just about the image file manipulation. And at the end of this video I want to discuss the original pull request a bit, what changed since March until the actual final release, but before I do that, there's a sponsor quote
[07:37] unquote to this video, which is myself. So I've shot a separate, deeper dive video demo with more functionality, I called it Laravel Native so how we built the asset set from one image high resolution so a separate premium tutorial on a lot of the daily it not a course but there a section called premium tutorial for premium members and there a six minute extra video also including the repository link so if you
[08:05] want to play around with that project yourself and see the difference, the repository will be available for premium members of Laravel daily. The link will be in the description below. So if you get back to the original pull request, it's fascinating to see that the beginning, the first commit was in March, so four
[08:21] months ago, Luna committed that, and this was the first kind of version. The idea was quite a big introduction and explanation what that package even does, what that functionality does,
[08:33] and at the time, Intervention Image was at version 3, now it is version 4, and also the idea was to use not only GD and Emagic, but also Cloudflare images as a driver, and also one of the ideas
[08:48] is to support multiple drivers in the future. So one of the description points was custom image driver if you want to use something like that. And a lot of people greeted that with likes and hearts and lockets.
[09:02] Not everyone, there were four downvotes. But anyway, the conversation continues in April. And then after some silence last week, it seems that Laravel core team was ready to release and push it forward,
[09:15] probably for LaraCon US. I have a suspicion that they will talk about that on stage, where I will also participate. I'm a speaker this year. We'll talk about filament. That's kind of a side note. But yeah, commits last week, more changes, more fixing, and then Taylor took care of
[09:32] polishing, and then this was the message from Taylor about the final version of that image manipulation, what he decided to change, and one of the changes was to remove, at least for now, Cloudflare driver support.
[09:46] So for now, that image manipulation is local GDE magic via intervention. But technically, in the future, it is almost ready to support other drivers like CloudFlare if you want to. So this is the final comment and final version of the thing that is actually released in 13.20 version of Laravel.
[10:06] So yeah, what do you guys think? Another feature that became first party citizen in Laravel framework itself in the core, It was never really an issue or a problem with manipulating images because we had packages for many years for that
[10:20] But now it's more convenient So will you use this one or will you stick with other third-party packages? Or do you use something else that I didn't mention in this video? As usual, let's discuss in the comments below That's it for this time and see you guys in other videos