The content moderation module in Drupal core is a powerful way of allowing content to pass through a moderation workflow. This allows you to create workflows that take content from draft modes into a published state and back again.

Each content moderation state can have a "published" setting that tells Drupal if an item of content in this state should be considered as published. This means that if a page of content is put into a published state then users with the "view published content" permissions can view it.

Users would need the opposite permission "view any unpublished content" to be able to see a content in a state without this flag set.

Creating services that listen events in Drupal is pretty straightforward; you just need to create and register a service class and let Drupal know what event you want to trigger on.

Altering routes in a Drupal site is also done through an event trigger, but in this case the implementation is slightly different. This is because Drupal takes care of the trigger setup and allows you to create an event subscriber that will automatically trigger when the routes are created.

A while ago I wrote about including oEmbed providers in a Drupal site and briefly touched upon creating custom providers. I didn't go into any more detail there so I decided to write another article looking at creating custom oEmbed providers.

In this article I will cover what oEmbed is and how to set up a custom oEmbed endpoint. I will also then go onto show how to setup and configure a Drupal site to consume that custom oEmbed endpoint. 

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