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.

Nightwatch.js is an end to end testing framework, written in JavaScript. It can be used to test websites and applications and uses the W3C WebDriver API to drive modern browsers to perform the tests.

In this article I will look at setting up Nightwatch.js in a project and getting started with writing tests.

Installing Nightwatch.js

To install Nightwatch.js you should have a npm project. This can be an existing project, but Nightwatch.js can be easily installed as a standalone application; which is useful if you just want to get familiar with the system.

Creating a new, empty, npm project can be done with the following command.

npm init -y

You can now include Nightwatch.js as a development dependency into your project.

npm install nightwatch --save-dev

PyScript is a framework that allows browsers to run Python code using HTML and the power of Pyodide and WebAssembly. This means that the Python runtime runs natively and can make full use of any Python code or package available.

PyScript has some amazing features like being able to plug into the browser DOM and bi-directional communication between Python and JavaScript. This essentially means that you can use PyScript as a drop in replacement for JavaScript. It's better than that though as you can also include all of the Python packages you need to do what you want.

As a web developer who has recently been learning more Python, PyScript was very interesting to me. In this article I will look at how to get up and running with PyScript and what tags are available to make the most of the framework.

The Drupal tempstore.private service is used to allow temporary user data that is available from one web request to the next. It is intended to be used for non-cache data that cannot easily be rebuild. This includes work in progress data that isn't in the position to be saved permanently.

The temporary store is a key value/store and cam therefore store anything from a single vale to a serialised object.

The tempstore.private service is really a factory (called PrivateTempStoreFactory) that will allow you to create instance of a PrivateTempStore object. It's this object that van be used to manage the data in the store. If you are familiar with the way that configuration factories work then this will seem familiar.

Custom Drupal codebases (or any codebases really) can be difficult to maintain. New developers to the system need to familiarise themselves with how the code works and what the system is doing before they can make any contributions.

What makes things more difficult is when a site with lots of custom code has modifications that adapt the functionality to specific users.

I will occasionally come across sites that provide some sort of service, but have made modifications to their code that changes things for a particular user (or set of users). This is often to appease the largest user base on the system that wants things done in a certain way, but the site is unwilling to change things for all users.