Freek.dev

I recently ran into a problem where I had a suite of applications hosted on a set of subdomains that all needed to be able to share a single cookie. Any cookies other than the shared cookie needed to stay specific to their subdomain, but this one shared cookie needed to be accessible to any of them. I also wanted to accomplish this using Laravel's `Cookie` facade.

Read more

Matt Stauffer wrote another excellent article on Laravel. This time he gives a tour of Laravel Spark.

In case you're still having a bit of trouble understanding what Spark is really about, Spark is a tool designed to make it quicker for you to spin up SaaS applications, and it handles user authentications, plans and payments and coupons, and team logic.

Most SaaSes have these same components: user accounts, Stripe-based payments, and different payment plans. And many have payment coupons and team payment options.

Rather than re-creating this functionality with every new Laravel app you create, just use Spark, and you'll get all that and a free SaaS landing page to boot.

Read more

If you're going to read one article on ActiveRecord vs Data Mapper let it be this one by Matthew Machuga.

The next time you come across the ActiveRecord vs. Data Mapper argument, or ones like it, be critical of what is being said. If it impacts your work in some way, do some research to find out if what is being said is true or if it has been something lost in translation. Don't feel bad for using a pattern that has spread across multiple languages and ecosystems successfully, and is probably the reason we have most of the web frameworks we do today. While the ActiveRecord existed well before Rails, it was Rails that gave it a beautiful API and made other frameworks like CodeIgniter, Laravel, .NET, Fuel, Django, etc want to have something comparable.

If you use Eloquent, ActiveRecord for Rails, or any other AR ORM, make sure you know that you are not alone. You are in good company of many, many developers who use it successfully day-to-day. However, if one day you choose to use a Data Mapper implementation or something else, then you will still be in good company, and still deserve respect regardless of which side of the fence you fall.

Read more

When we built Facebook's mobile applications, we needed a data-fetching API powerful enough to describe all of Facebook, yet simple enough to be easy to learn and use by our product developers. We developed GraphQL three years ago to fill this need. Today it powers hundreds of billions of API calls a day. This year we've begun the process of open-sourcing GraphQL by drafting a specification, releasing a reference implementation, and forming a community around it at graphql.org.

There's already a package to use GraphQL with Laravel.

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

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

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

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

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