Last week I visited the city of Prague to attend the European DrupalCon 2022. The event was held between September 20th and 23rd, and was attended by over 1,200 people.

This was my first physical conference since DrupalCamp London 2020, and the first DrupalCon I have attended since DrupalCon Dublin 2016. Despite the worries about covid I was still pretty exited to attend the event. I arrived on Monday night and as the event didn't start properly until Tuesday afternoon it gave me a small chance to explore the city of Prague before the conference started.

Client requirements can be complex and those complex requirements often require custom code to be written. This includes making sure that the editing process conforms to certain validations.

Drupal can easily handle simple validation like having a value in the field or making sure an email is valid, but with more complex validations usually require custom code.

Whilst it is possible to inject custom validators into form submissions, I find using validation constraint classes makes the whole process much more predicable. Also, validation constraints are applied at a lower level than form validations, which means we can validate the data is correct even if we are creating the entity from an API. 

Drupal has a robust and dynamic cache system that allows complex pages to have different parts of it cached in different ways.

Having a cache means that Drupal doesn't need to go back to the database and ask all the elements of the page to re-render everything for every page request. The results of the render can be stored in a cache and served much faster than having to recreate them again.

You might have a page that displays content from a node and contains a few blocks to show menus, search forms, share links, and similar. Each part of this page can be cached in different ways and all of this information bubbles up to the aggregate page cache.

I was writing unit tests for a API mapping function recently and came across this interesting issue. The code I was writing tests for was in a legacy codebase that I was making changes to, and it made sense to have some unit tests in there before I started work to ensure everything worked before and after.

The mapping function in question would take a value as input and return another value as the output. The code seemed like it should work, but then applying certain values to the mapping function it would produce an incorrect result.

Embedding image within pages of content helps both within the design of the page and when shared on social media. If you set up meta tags to point at a particular image then that image will appear when the page is shared on social media. This makes your page stand out more.

A while ago I added a header image to the articles in the form of a field that references a media item, which is quite typical when adding images to pages. To add an header image to an article I just had to upload an image and Drupal would handle the size, placement and meta data for that image.

With the field in place, however, I spent a while adding a default header image to new articles so I haven't been making good use of it. My GIMP skills aren't that amazing and so the prospect writing an article and spending time fiddling with text elements on an image every week wasn't that appealing.

The PHP Standards Recommendations (called PSR) are a set of standards that aim to make certain aspects of working with PHP easier. They include things like coding standards (PSR-1), sending HTTP requests (PSR-7), and the autoloading standard PSR-4.

PSR-4 describes the ability to include PHP classes based on their file paths. This means that instead of manually including every class file you need, you can write an autoloader that will do this for you.

The key bits of information are the namespace and the name of the class. Using this information you can then look up and include the class you need as the code is running.

I have recently been looking at generating custom content entities and this lead to generating a minimal entity that would be useful on a Drupal site.

If you've ever used Drupal Console to generate a content entity, then you'll know what it generates a lot of files. There's all sorts of classes and configuration files generated that handle everything from generating lists of entities and forms for creating new entities.

This got me thinking about what is the minimal amount of configuration needed to generate a usable content entity. This might be used to store some simple data or to attach to other entities through an entity reference. As it happens, setting up a minimal content entity takes just a single file.

Derivers in Drupal are one of the ways in which you can inform Drupal about the presence of plugin types. This allows you to generate multiple custom types of a plugin so that it can be represented as multiple different plugins within the system.

Perhaps the most useful deriver example I have seen is the menu deriver. This allows us to use the Drupal plugin architecture to generate custom menu links.

If you want to create a menu link for your module then you would normally add them one at a time to a *.links.menu.yml file. This is an example of using the menu links plugin system to inform the menu system about the links you want to add.

The Tkinter library in Python has a number of file dialogs that allow programs to ask for a file from a user. Using these dialogs it is possible to accept a file from a user and read the contents of that file.

Tkinter comes with a number of different dialogs that have a number of options. These allow users to load directories and files into your python applications, or to point to files that they want to save information into.

In this article we will be concentrating on reading information from files and so the save dialogs will not feature here.

PHPStan is a great command line tool for looking at how your PHP code will run without actually running it. It's great for finding potential bugs that you wouldn't have otherwise discovered using other tools or through unit testing.

With regards to Drupal projects there is a little problem in that PHPStan doesn't know how to interpret Drupal plugins, entities, controllers or all the other Drupal architecture that goes into a Drupal module. For this reason, if you try to run PHPStan on your module code you'll find that it produces a lot of errors regarding missing objects or incorrect parameters.

Thankfully, it's possible to easily teach PHPStan about Drupal and make the tool more useful when writing Drupal code. First we need to install it.