I was recently working with a Drupal 9 site and found some strange behaviour when saving certain types of content. The page would appear to save, but much of the content appeared to be missing. It had even failed to generate the paths for the page based on the path auto rules.

Digging deeper I found the root cause of the problem was an improperly created redirect in an insert hook within custom code written on the site. This code looked for the creation of a particular content type and then forced the redirect to happen.

Marp or Markdown Presentation Ecosystem is a collection of tools that allows the generation of presentations of different formats from a markdown template. The tools are written in JavaScript and have a number of options that allow presentations of different styles and formats.

This tools stood out to me as it has syntax highlighting built in and allows the creation of presentations using markdown. The presentation can also be altered using standard CSS styles.

I've spent many hours fiddling with presentations in Keynote and Google Slides, so I wanted something that would be simple to use and generate the presentation files I needed.

Generating a PDF document from a web page through PHP can be problematic. It's often something that seems quite simple, but actually generating the document can be difficult and time consuming.

There are a number of libraries available that allow you to generate PDF documents, but in reality they solve one problem and introduce several more. Packages exist as either HTML to PDF converters or allow you to generate a PDF by placing elements into the document.

Generating a PDF manually is not normally a good way to go just due to it being a very time consuming process and is difficult to test. You will probably have to spend time creating a rendering engine just for this purpose, and that will take time to create and maintain.

The lazy builder API in Drupal allows the creation of highly dynamic content within a render array without having to disable the cache for the entire render array or the page the content is attached to. What this means in real terms is that the initial render array can be cached quite heavily, but lazy builders allows for additional rendering to be done in after the initial rendering pass to generate content.

There are several reasons why lazy builders might be useful. The most useful reasons are to present some highly personalised or dynamic content to a user, but you might also want to offset the rendering of some slow code to give it some more fine grained caching that stores the outcome in a cache bucket.

Lazy builders work by using a normal render array, but instead of rendering the content you inject a lazy builder placeholder into the content. A callback method is used to tell Drupal how to inject the content into the placeholder.

The cache system in Drupal has a number of different components with time, contexts and tags being used to determine the cache.

Whilst all of these mechanisms are really useful you can also inject data directly into the cache system. This is beneficial if you have an expensive function that takes a long time to complete. The result of the function can be stored in the Drupal cache system just like other cache data.

For example, let's say you are pulling data from a slow API. If the data doesn't change much it might be better to add a cache to the request so that instead of going to the slow API the fast cache systems are used instead.

I was recently working on a Drupal form where I needed a user to select from a list of options that were available in a field attached to an entity. As the entity itself didn't exist when the user was filling in the form I needed a way of finding out the options that could be applied to the field. 

Getting a list of values from a field allows for numerous possibilities within Drupal, including configuring modules and creating wizards for generating content. As it took me a little while to track down how to do this I thought a quick post might come in handy for anyone looking to do the same.

In order to get the values available in a field we first need to create a blank entity. This will be used by the field storage system to load the correct field definitions.

Composer is an excellent way of managing dependencies but in order to use it properly it does require a build and deployment process.

The two ways of deploying a site built with composer is to either generate an artefact with the composer dependencies installed, or to install composer as part of the deployment process. Both of these approaches require not committing the vendor directory and other third party libraries (like Drupal core for example) to the git repository.

Many developers tend to go for the approach of committing the composer dependencies to the repository in order to simplify their workflow. This approach, while simple, does have its problems. I have talked about the problems of committing the composer vendor directory in detail in a previous article.

Google PageSpeed tool was created to give webmasters an indiction of how their site will perform when analysed by the Google search engine. As Google takes a variety of different factors into consideration when ranking sites the tool gives an indication of the health of the site.

The score it calculated using a percentage, with different bounds of the score being coloured differently. Between 0 and 49 is poor and is coloured red, between 50 and 89 is average and is coloured orange, above 90 is considered good and is coloured green.

Getting a perfect score in the Google PageSpeed Insights tool is by no means the end goal of site performance improvements or even search engine optimisation. It will absolutely have some benefits in terms of your site traffic though and is worth including in your site key metrics.

Timing web requests is possible in curl using the -w or --write-out flag. This flag takes a number of different options, including several time based options.

These timing options are useful for testing the raw speed of requests from a web server and can be an important tool when improving performance and quickly getting feedback on the response.

The -w or --write-out flag in curl has a number of different options, far more than I can add here. You can use these options by surrounding them in a "%{parameter}" structure and passing this as a string to the -w flag.

This is probably not relevant to some people, but I find that I'm always searching for this information when I need to print out a URL or find the current page path.

The difficulty is that finding or printing out a URL is very contextual and there is more than one way to get or use this information in Drupal. You might have a node object that you need to convert into a fully qualified path, or you want to print out the path of a route, each of which have different approaches. I think that's why there are so many questions asking variations of this topic on sites like Stackoverflow.

What is surprising to me is that there is very little documentation on drupal.org about this. Creating URLs and printing out links is perhaps the most common thing that needs to be done by developers creating themes, outside of changing the classes or markup of a block of HTML.