Last week I attended the Drupal Dev Days in Cluj Napoca, Romania. I decided not to go to any talks but to join the ‘Media’ team for Drupal core and work on bug fixes. Here’s what I learned.
In one of my projects I found myself needing to save configuration (coming from a plugin) to content entities. In Drupal however, configuration is saved to configuration entities (or configuration objects).
If Drupal provides solid solutions for configuration, maybe the problem I was trying to solve was an XY problem? (Was I trying to find the answer to the wrong question?) Even the documentation on configuration management suggested content had nothing to do with configuration:
Configuration is the collection of admin settings that determine how the site functions, as opposed to the content of the site.
However, I discovered that several contrib modules have come across the same need to save configuration to content entities and have solved this problem in different ways.
Like the Views Reference module that saves configuration linked to a specific View to a string property belonging to field type made for the purpose. Other modules actually provide generic solutions that you could easily integrate in their own module: the Plugin module and Commerce come up with an agnostic field type for saving plugin configuration of any type.
In this post I will try to explain the way this works with an example module.
Recently I tried to create a Unit test for a Drupal service that creates and returns entities. In my test I wanted to check if the field values that were used for creating those entities were matching my assertions.
In Drupal , the static ::create method of any content entity returns the created entity. In my unit test, checking the returned entity for values would be a hassle, as I would have to mock and stub my way through all the services that it relies on to fetch those values. More useful would be to mock the entity and let the ::create() method return the values that were just passed as arguments.
¿Does that make any sense?
Let me try and explain:
As a freelancer I like my (potential) clients to be aware of my availability. I decided to build something that would allow me to fill in my availability in Google Calendar, which would then be displayed in a nice widget on the website.
The widget doesn’t need to display anything but whether or not I am available or busy on a certain day. I figured that the good ol’ jQuery Datepicker would do perfectly.
So here’s what I did.
When you google for accessing the Google API, most forums will point you in the direction of the OAUTH2 protocol. Using OAuth would be necessary if we wanted to access restricted content. For accessing publicly accessible content, the Google API is a lot easier. All you need is an URL and an API key.
Go to https://console.developers.google.com and create a new project. Select credentials and create an API Key. You can restrict the use of the key although you don’t have to. Copy the API key value somewhere: we’ll need it in our code.
I have updated this post as a result of the issue (https://www.drupal.org/project/drupal/issues/2392845) that added the ComputedItemListTrait trait to core.
In Drupal 8 we have on the one hand field types with some computed field properties, and on the other hand fields that are fully computed.
Computed field properties are quite common in Drupal 8. An example is the TextItem field type. The properties value and format are stored in the database, but a third property called processed is computed on the fly using the value and the format.
When it comes to fully computed field items, there are less examples in core. It seems that in Drupal 8.5 the only fully computed field is the moderation_state field, provided by the Content Moderation module. The field is added to all entities that add a moderation workflow.
Since the ComputedItemListTrait was added in this issue, however, adding a computed field has become A lot more straightforward than it seems.
Drupal is a full-fledged CMS for secure and complex websites and applications and is adopted by many big companies and governments accross the globe. Hugo is a static site generator built in GoLang that is blazing fast and quickly gaining popularity. For this website about my Drupal work I decided to go for Hugo. Here’s why.