Freek.dev

Everywhere that I go, conference, the supermarket, the dentist, building sites, people always ask me about the Composer lock file. It's a mystery that seems to cause confusion all across the globe. Well, boys and girls, I'm here today to de-mystify the lock file once and for all.

http://daylerees.com/the-composer-lock-file/

Read more

In my company, we use Twig instead of Blade for our Laravel projects. I know there are a lot of developers that also prefer Twig over Blade. So the question ‘Why choose Twig over Blade?’ often pops up. The reason is usually just a matter of preference, but in this post we’re going to compare the Blade and Twig templating engines side-by-side.

http://barryvdh.nl/laravel/twig/2015/08/22/comparing-blade-and-twig-templates-in-laravel/

If you want to try out Twig in a Laravel project, you can use this bridge package.

Read more

There is always value in learning about the internals of the frameworks and libraries we use. It allows for a deeper understanding of the problem being solved and appreciation of the work that has gone into these projects.

So today I will be building a basic router to explore this fundamental part of even the smallest framework. The idea is not to create something complete or production-ready but rather the minimum set of features needed to be considered a router.

https://medium.com/@dylanbr/building-a-basic-router-b43c17361f8b

Read more

The venerable Uncle Bob wrote some thoughts on picking a framework:

Before you commit to a framework, make sure you could write it. Do this by actually writing something simple that does the basics that you need. Make sure the magic all goes away. And then look at the framework again. Is it worth it? Can you live without it?

http://blog.8thlight.com/uncle-bob/2015/08/06/let-the-magic-die.html

I've quoted the end of the post, but you should read it in full, it's worth it. I agree with most things in the article. You should constantly learn stuff and try making the basic functionality yourself to get a better understanding of how things work.

Though there is certainly truth to it I don't fully agree with: "Before you commit to a framework, make sure you could write it." It's good advice when you're very experienced or if you have time enough to investigate lots of stuff. For most people this isn't that case.

When starting out writing PHP almost 10 years ago I made my own little framework because I didn't know any better. I thought I was doing fine. Looking back at the projects I made with it, I'd say they're all horrible.

Zend Framework 1 came out. It sped up my development because I didn't have to do every little thing myself. Did I understand everything ZF was doing behind the screens? Certainly not. Did ZF create value for me right from the start? Hell yes. While using the framework on various projects I read about how it worked and learned a lot about PHP. I thought I was doing fine. Looking back at the projects I made with it, I'd say they're all horrible.

A few years ago I read some positive articles about Laravel. I really liked the syntax and the feel of things. Sure, it was a gamble to choose a framework I didn't know but it worked out really well. While using Laravel I learned, thanks to some excellent learning resources, lots of things on design patterns and best practices.

It's certainly possible that, in the coming years, Laravel will be replaced by a new shiny framework. Maybe I'll then write a post on Laravel saying "I thought I was doing fine. Looking back at the projects I made with it, I'd say they're all horrible." .

Generally speaking I think the following applies to most frameworks and most programming languages:

1. When you see a framework / language that feels good to you, read a bit a about it.
2. If you still feel good about it, use it on a small project
3. If after that project you still feel good about it, use it again, maybe on a bigger project. Learn a bit more how framework and language works.
4. Repeat steps 2 and 3 until you find yourself at step 1 again.

The most important part is the learning in step 3. If you don't do this you'll be a programming cowboy forever.

Of course all of this depends on context. I would never pick a technology unknown to me when starting to work on a large and expensive task. Learn and experiment when working on small projects. Use what you have learned on the big ones.

Read more

The project I'm currently working on will have to send out mails to all its users on a regular basis. It's not a newsletter: the contents of each mail will be very specific to each user. The mail also should contain a link to unsubscribe the user from simular future mails.

The link could look like this: https://myapp.com/unsubscribe. Clicking on the link would direct the user to a login page. After the user has logged in the unsubscribe can be automatically performed. In my mind requiring the user to login first in order to unsubscribe from something isn't very user friendly.

This can be improved by adding the id of the user to the link. Here's what that could look like: https://myapp.com/user/1/unsubscribe. With this link you the app can unsubscribe the user with id 1 in one go. That'll work, but it's not very secure. Unsubscribe links for all other users can be easily guessed. Such links can be made more secure by adding a signature and an expiry date on them.

My colleague Sebastian coded up a Laravel package to create signed url's with a limited lifetime. Here's example where the url gets signed and made valid for only one day:

echo UrlSigner::sign('https://myapp.com/user/1/unsubscribe', 1);

This outputs an url that looks like: https://myapp.com/user/1/unsubscribe?expires=1123690544&signature=93e02326d75

The validate-method can be used the determine if a signed url is (still) valid:

$isValidUrl = UrlSigner::validate($theSignedUrlInTheExampleAbove);

The signature is calculated using the original url itself, the expiration date and a secret string that's specific to your project. When a malicious user tries to change any part of the url the signature won't match up.

I'm assuming that the most common use case of signing url's is to protect routes. The package supplies a middleware that protects routes from invalid signed url's. In the following example only requests with a valid signed url will hit the controller:

Route::get('unsubscribe', ['middleware' => 'signedurl', 'uses => 'UserController@unsubscribe']);

If you're interested in using the package, take a look at it on GitHub: https://github.com/spatie/laravel-url-signer

There's also a framework agnostic version: https://github.com/spatie/url-signer

E-mails can be intercepted and are never 100% secure. Bearing that fact in mind you should never use this kind of link for any destructive action.

EDIT: Some fellow developers pointed out that I could also obfuscate the id in the url. Here are two good libraries to do that:

• http://hashids.org/
• https://github.com/jenssegers/optimus

When using obfuscation of the id this url `https://myapp.com/user/1/unsub `would become something like: `https://myapp.com/user/kwxgqu5w/unsub`

And sure enough, the unsubscribe links of other users cannot be easily guessed. A small downside however is that the url becomes less readable. The big disadvantage is that the url will remain valid forever. As these links through an unsafe medium I think it's a good idea to give them a limited lifetime. Signing an url will do that.

Read more

Though the generators look cool, I've never used them much because I didn't find a good use case. Evert Pot demonstrates on his blog how they can help conserve memory.

Since the release of PHP 5.5, we now have access to generators. Generators are a pretty cool language feature, and can allow you to save quite a bit of memory if they are used in the right places.

http://evertpot.com/switching-to-generators/

Read more

A curated list of amazingly awesome PHP libraries, resources and shiny things.

http://getawesomeness.com/get/php

An epic list indeed!

Read more

Davey Shafik cleary explains the new exception hierarchy in PHP 7.

With PHP 7 errors and exceptions are undergoing major changes. For the first time, the PHP engine will start to emit exceptions instead of standard PHP errors for (previously) fatal, and catchable fatal errors. This means that we can now handle them much more gracefully with `try... catch`.

http://daveyshafik.com/archives/69237-an-exceptional-change-in-php-7-0.html

Read more

Hannes Van de Vreken has written a tutorial on how to display stream progress in PHP.

Opposite to HTTP requests, tasks run from the command line aren’t supposed to return instantly. They can take a very long time. Imagine a task that loops an entire database table or a task that references an external source repetitively, or maybe a taks that performs a large file transfer. It’s very important to show the issuer what is actually going on, or he/she will be left in the dark for minutes/hours. "Is this task still running?", "How long has this thing been running yet?", "Is it almost done?", "Is it running out of memory?"

https://hannesvdvreken.com/2015/05/12/stream-progress/

Read more

If you're into Laravel, I recommend taking a look at Laravel Daily. The idea behind the site is that you get one Laravel tip a day. I like the short and sweet format and have already learned a lot.

Read more

I've been enums lately instead of relying on class constants. The myclabs/php-enum package provides a nice implementation. The readme lists the benefits of doing so:

Using an enum instead of class constants provides the following advantages:

• You can type-hint: `function setAction(Action $action) {`
• You can enrich the enum with methods (e.g. `format`, `parse`, …)
• You can extend the enum to add new values (make your enum `final` to prevent it)
• You can get a list of all the possible values (see below)

This Enum class is not intended to replace class constants, but only to be used when it makes sense.

Check it out: https://github.com/myclabs/php-enum

 

Read more

One of the really great things about ORM’s that implement the Active Recordpattern like Eloquent is, they are really easy and really intuitive to use.

With Active Record, you basically just have an object that you can manipulate and then save. Calling save() on the object updates the database, and all of the magic persistence happens behind the scenes.

Having the business logic of the object and the persistence logic of the database tied together definitely makes working with an Active Record ORM easier to pick up.

In this tutorial I want to explore exactly how Doctrine 2, an ORM that implements the Data Mapper pattern, is different to Eloquent.

http://culttt.com/2014/07/07/doctrine-2-different-eloquent/

Read more

A typical request on an dynamic PHP site can do a lot of things. It's highly likely that a bunch database queries are performed. On complex pages executing those queries and hydrating them can slow a site down.

The response time can be improved by caching the entire response. The idea is that when a user visits a certain page the app stores the rendered page. When a second request to the page is made, the app shouldn't bother with rendering the page from scratch but just serve the saved response.

I've made a Laravel package named "laravel-responsecache" that does just that. Installing it is very easy: just add the service provider and facade to the app's configuration. And step two is... there is no step two. In most cases you're done. All successful responses (that is a response with a statuscode in the 200 or 300 range) to a GET-requests will now be cached for a week. If the response of a specific route or controller should never be cached middleware can be added that prevents caching. Furthermore each logged in user will have have it's own separate cache. Cached responses can be stored in any configured repository in Laravel. You could easily share a cache between servers by using memcached.

I think that behaviour will suit a lot of use cases. If you need some other caching behaviour (eg. cache error responses, exempting redirects, using a common cache for users with the same role, changing the expiration time of the cache) you can easily write a custom caching profile.

The package isn't supposed to sweep performance troubles under the rug. All apps should be optimized so that they'll respond in an acceptable timeframe without using response caching. My rule of thumb is that typical pages in a cms should be able to render within a second (and preferably much less). Anything above that is unacceptable. That number is by no means scientific. Make up your own mind what an acceptable responsetime should be. Of course all of this depends on the type of site and the amount of visitors it has to handle. Also keep in mind that that there are a lot of other aspects that need to be considered when trying to deliver a speedy experience.

There are some great alternatives to cache responses. Two well known solutions are Varnish and Nginx caching. They take response caching one step further by not even invoking php when serving a cached request. Both options are very robust and can work on any scale. The benefits the Laravel package has over Varnish-like solutions is that it is easier to set up and that application logic can be used to determine what needs to be cached.

If you're interested in speeding up your Laravel app using the package, go take a look at it on GitHub:

https://github.com/spatie/laravel-responsecache

Read more

Sammy Kaye Powers wrote a post on how to contribute to the PHP documentation.

If you've been wanting to contribute to PHP internals, starting with the documentation can be a great entry point; especially because it doesn't require dusting off those old C books from college.

But knowing where to start can be tricky since information on how to contribute to the docs is scattered across the internet.

Phew! After reading this process my intentions of contributing melted away like snow in the sun. Editing the documentation should be much easier. I believe there would be more contributions if the docs would reside in a git-repo as markdown-files.

Read more