I previously looked at injecting context providers into context aware plugins. This time I will explore more about creating our own context providers to plug into this system.

The context provider system is an ideal way to provide context to context aware plugins, with blocks being the prime example. You would use a context provider to inject an entity or value into the block so that actions can be taken using that data.

For example, we could load the currently loaded node from the route object using the context so that we didn't have to bake the route provider logic into the block.

The values we inject also plug into the cache systems and so we don't need to worry about making sure we integrate the cache systems within the block system. That is all taken care of upstream.

When developing plugins in Drupal a common task is to inject context so that certain tasks can be performed.

For example, we might have a block plugin that needs to know about the content entity of the page it is currently being rendered on. We could potentially inject the routing system into the plugin and use this to find the currently loaded entity, but there is a drawback to this. There is a fair amount of custom logic involved in finding the content entity from the route and we would need to use this same code every time we want to solve this problem.

This method also hard codes the route into the plugin and so makes it difficult to select any other sort of context. There is also a problem when it comes to caching as you also need to inform the plugin about the use of routing so that the caching layers know how to cache things.

A pie chart is a great way of showing the relationship between numbers, especially when showing percentages. Drawing a pie chart from scratch takes a fair amount of maths to get working and so people usually go for third party charting libraries in order to add charts to the page.

I recently came across a technique that allows you to create a pie chart using just CSS, which means you can create simple charts without including massive charting libraries into your page loads. This makes use of just a few lines of CSS, using conic-gradient() CSS function.

The conic-gradient() CSS function is part of the background style attribute and is part of a family of functions like radial-gradient() and linear-gradient(). It is used to create a gradient rotated around a central point and is opposite the radial-gradient() function that draws the gradients radiating away from the centre.

Whilst working on a module I found that I needed to do something that was difficult to find information for. I think part of that is because the solution is simpler than I was thinking, but it did cause me to get lost in source code and internet issues for a while.

What I needed to do was to load in a list of configuration entities that matched certain parameters. The configuration entity I was dealing with was used to manipulate the output of a form, but only if certain conditions were met first. I thought that this information might be useful to others who are looking to load configuration entities.

I have been using the Drupal dependency injection system for a while now, even giving talks and writing articles on the subject. As the release of Drupal 10 is just around the corner I have been thinking more about how to override dependencies to plugin classes.

I wanted to share a trick to overriding dependency injection that will make your life easier. The Drupal codebase itself does not use this trick, but it seems that many contributed modules have started to use this trick to create plugin classes.

In this article I will go through how to add dependency injection to Drupal classes in two different patterns.

Drupal has a number of coding standards and best practices that govern the way code should be written. This has many benefits but can allow for a consistent and maintainable code to be created.

All Drupal modules and themes are written with coding standards in mind and that allows Drupal developers to look at any project and see a similar style of code. If you ever submit code to Drupal or a contributed project you will be required to adhere to these coding standards, so it makes sense to get used to knowing about them.

The main tool that is used to test coding standards in Drupal is PHP_CodeSniffer, which is a widely used static analysis tool for testing PHP coding standards. It comes with a set of coding standards built in, but it is possible to add the Drupal coding standards for the tool to use.

Ajax Dialogs in Drupal are a good way of presenting content to a user without them having to navigate away from the page they are looking at.

This is useful when presenting a list of items or a link to something like a terms and conditions page. Users can click a link and view the content as a dialog box.

Creating dialogs in Drupal is built into the platform and are powered through the jQuery UI dialog component.

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.