Freek.dev

Q: What does this code return? date('Y-m-d',strtotime('00-00-00'));

A: 1999-11-30 B: 0001-01-01 C: 2001-01-01

The correct answer is A: 1999-11-30.

You'll find the reasoning behind this result as a comment on this bug report.

There is no bug here, 00-00-00 means 2000-00-00, which is 1999-12-00, which is 1999-11-30. No bug, perfectly normal.

Read more

Garrett St. John wrote a clear example on how to use UUIDs in Eloquent models. This kind of logic could go in a trait so it can be reused across multiple models.

By default, Eloquent uses an auto-incrementing integer as the primary key for its tables. While most of the time this is totally acceptable, sometimes there is a need for primary keys to be less predictable.

EDIT: Kirk Bushell has made a trait for this functionality. Take a look at his Eloquence package on GitHub.

Read more

The Retry library by Igor Wiedler has only 19 lines of code. Line 17 is a goto statement. In this issue on GitHub a user asks why Igor chose to use goto instead of resorting to recursion. Igor took the time to write out the reasoning behind that decision. It's a very interesting read on the PHP compiler and opcodes.

Why hello! Thank you for asking this most excellent question!

I have indeed considered alternatives to the goto. I have evaluated them to a great extent, and I am happy to present the results to you here.

Read more

After giving excellent talks at both Laracons, contributing to Laravel's new ACL, putting out an interesting Full Stack Radio episode with Wes Bos, Adam Wathan today published a new screencast. He is now officially on a roll.

After my presentation at Laracon this year, a lot of people asked me how I'd take that same polymorphic approach when the objects would have to be retrieved from the database.

This screencast covers how I'd approach implementing the same idea in a real Laravel application with Eloquent, by using polymorphic relationships and delegation to accomplish the same thing without having to resort to any nasty conditionals.

Read more

When I first learned to program, I made many objects that were mutable. I made lots of getters and lots of setters. I could create objects using a constructor and mutate and morph the heck out of that object in all kinds of ways. Unfortunately, this led to many problems. My code was harder to test, it was harder to reason about, and my classes became chock full of checks to ensure that it was in a consistent state anytime anything changed.

...

Now, I favor creating immutable objects.

The post clearly explains the benefits of using immutable objects and a nice example.

Read more

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.

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.

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.

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?

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.

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

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.

Read more

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

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`.

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?"

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