Skip to main content

Using a trait to add UUID to a Laravel 5 Model

The past weeks i’m spending my free time with building a application using Laravel 5.4, but I wanted to use an UUID on a few models. So I did what I always do, go look on packagist to find if somebody already done that work for me. And they did, but what I found was either over engineered and / or implementing their own logic of creating and validating the UUID.

But I know that Laravel comes with the UUID package of Ben Ramsey so that kind of bugged me a lot. Why duplicate logic when there is a battle tested library reachable within the /vendor folder?

This was a good opportunity to dive in the world of Laravel models,and especially the events ( ) that models fire off. Sure I could’ve done the same per model, but somewhere I read that the proper way of doing this was using a trait and a event.

The model, the code and the trait.

Firstly I added a UUID to my table with a migration and added the UUID as fillable to my model. Not sure if that actually needs to be fillable. But it got the job done ;)  

The UP of the migration

public function up()
  Schema::create(‘images’, function (Blueprint $table) {

The model with UUID

namespace App\Models;
use \App\Traits\Uuids;

use Illuminate\Database\Eloquent\Model;

class Image extends Model
  use Uuids;

  protected $fillable = [

Now I could have added the code of the trait to this post, but I thought it was more usable as a GIST on github.

There are two methods in the trait, first there is the static::creating in the boot method, add a static method that is executed just before the model get’s persisted to the database. And within that method I use create a new UUID4 and set the value to the uuid field on the model. For convenience I’ve added a config variable to the app namespace that allows me to globally change the UUID column in the model. 

Then there is the ScopeUuid() method that allows me to receive the model from the database simple by calling  Image::Uuid(‘a8c33a08-04b0-4af3-a972-60d3587a7f4a’); and retrieve on Model class back. This method validates if the passed UUID is actually a valid on.

That’s it, one simple trait and I had all the UUID handling I needed for now.

(disclaimer, if I made mistakes or wrong assumptions, find me on twitter and tell me. I’m new to Laravel and still learning about the ins and outs of the framework)  

Drupal, seriously WTF??

This morning, like almost every morning I started with catching up on my Twitter feed and saw a tweet from Josef (@dasjo) that really pissed me of.

To recapture, apparently Dries 'had' to ask Larry (Crell) to leave the drupal community because of his private life style. This goes so deep against my believes as a human being I had to write a comment on Dries his blog post. And just in case my comment might not make it true the administration review I cross posted it on my own site.


waiting for approval.

the comment itself

I really don't care about Larry's private life, I do care about the maturity of the Drupal project. And I do believe you as project crossed a line here. Of course there are two sides of this story, but to ask a person to leave the project of what he MIGHT do in his private life. Yet you are still daring to use the words diversity and inclusion in your post. This reeks of so much the same FUD you're battling with when it comes to positioning Drupal against proprietary systems.

Are you really becoming that american? Because you are mimicking the behaviour of being a goody two shoes, that rather hiddes 'scary' things in a closet, then openly admitting people can have a 'alternative' lifestyle compared to commons?

In all the years i've been following the Drupal project, being a part of this community, seeing Larry talk quite a few times on various official D.O cons and smaller camps he NEVER EVER talked about his Gorean lifestyle, this in great contrast to some of the LGBT members of our community. 

If you really honestly cared about the diversity in our community Dries, I dare you to address the elephant in the room, eat some humble pie and try your best to reverse this horrible mistake. That is, if Larry is still willing to be a part of this community after all this.


Drupal 8 string overrides


With the new language system in core the need for most of the functionality of the string overrides module is not really needed. That is if you just want to replace a string in general or have added the right context using the {% trans %} filter in your twig templates (see documentation for a more detailed overview)

Bare in mind, that translating strings is not the same translating content. Drupal makes a clear separation between interface and content translation. All the strings looped through the translation using the t() method are interface text not content. Also you need to keep in mind that the system always translates from english to another language. Even if your site is in Dutch, you still want to write the translatable strings in english and then translate them. 

Enabling the system.

So to translate strings, you first need to enable the language system and the interface modules, yes even if you only have one language.

enable modules

After installation, you need to enable the interface translation for the language or languages you want to have custom strings. By default, english is marked as not translatable.  Goto /admin/config/regional/language and click the edit button to change that.

Click the checkbox for "Enable interface translation to English" and press save language.

Enable interface translation

Overriding the strings.

If you now visit /admin/config/regional/translate you will notice that all the system strings are now overridable in the interface. Like always the strings are case sensitive and need to be entered exactly like in your template or module. Like in Drupal 7, this system only discovers new translatable strings after they have been looped through the t() function. So you string does not show up in the list, try to load the page first, preferably after a cache clear and being logged in as a admin user.

Storing the translations in GIT.

Personally I like to change the location of anything related to the configuration system outside of the public webroot. And the .po files containing the string overrides is no exception. First you might want to change the location of the translation files from the default "sites/default/files/translations" to something else. Goto /admin/config/media/file-system and change the "Interface translations directory" to something outside of your webroot. In my projects i create a private folder on the same level as the public folder. So set the translation directory to '../private/translations'

By doing this only the imported language files are saved in that directory. That means every language except english. So you might want to create a extra directory that holds your custom translations if you only export the customized translations or you end up either translating things over and over again, or exporting the translations manually after every update.

Export only what you need

Goto /admin/config/regional/translate/export pick the language you changed the strings for and check that you only want to export the customized translations. And press export. This downloads a .po file you manually need to place in the above created translations directory and commit that file into your repository.

Export strings


Although not 100% perfect and very developer friendly the new Drupal 8 language system is a serious improvement over the old D7 system. And I am convinced that somebody in contrib will find the need to scratch the itch of some of the DX issues like saving a .po directy into the languages directory instead of downloading and copying it.

Mamp PRO 4 and the never generated images.

When working on the final touches of a Drupal 8 project we ran into a very strange issue. Every single time I opened the file browser, apache got stuck and the system load went sky high. First I blamed the media browser, but a quickly generated view that rendered a list of all the image/* items in de file library showed the same problem.

Tailing the logs brought nothing, no strange segfaults or other memory errors. In a last resort I switched Mamp to PHP 7.1 and to my surprise the images where rendered. Deleted the files/styles content, re-ran the view. And presto images were back.

But our production environment runs PHP 7.0.15, so the sites needs to work with that PHP version as well. Started to compare the php.ini files and the only difference was that for PHP 7.0.x I turned on MAMP directly in the php.ini instead of using the MAMP interface. I wanted to run both Opcache and APCU like we do in production. Turned off the in php.ini, cleared the files/styles content and to my amazement the image derivates where re-generated, no more sysload and deadlocked apache process. So if you have bugging or hanging Drupal 8 image generation in MAMP, turn off APC and see if it solves your issue ;)