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.

Creating a Drupal site can be a complex process. Some people put together Drupal sites using a collection of different modules whilst others use Drupal as a framework and build the site using code.

No matter what sort of Drupal site you have, you'll need to have some testing in place to make sure that it works correctly. This is especially important when applying updates to your sites as the updated code can create unwanted side effects (or contain bugs) that might cause the site to malfunction. Generally, Drupal modules are very good with updates, but there are sometimes interactions between modules can cause problems that weren't taken into account.

When it comes to testing, there are a number of different options available to a Drupal developer. Each of which have their own uses and depend on the type of Drupal site you are trying to test.

In this article, I will go through a number of testing strategies that you can use to test a Drupal site. I won't delve too deep into each topic as this is more of an overview of the different technologies and strategies available.

Occasionally, I have come across Drupal sites that have base64 encoded images embedded into content fields. This is the approach of taking the binary data contained in a file and converting it into a string of characters. The original binary data can then be re-created using this string and the data is understood by lots of different technologies (including web browsers).

Whilst this is technically possible, it massively balloons the size of the database and can often slow down page load times due to the database being slow to respond to the request. Instead of fetching a few kilobytes of data from the table the database is forced to fetch many megabytes of data, which can create a bottleneck for other requests.

A recent challenge that I faced on a project was to generate the HTML of a full Drupal page, from within a Drupal request. The project called for a template to be rendered within the structure of a Drupal theme and also to include the styles associated with that theme.

At first, this doesn't seem like a big problem, but once I started trying to figure things out it became much more complex than I was expecting.

The problem is that you can't just render a page using the 'html' and 'page' templates as there is a lot of context surrounding those templates. Without this context in place Drupal produces a page of markup that contains no styles or blocks. The context is how Drupal knows what theme to load, what libraries to add to the page, what preprocess hooks to call, what menu items to generate, and so on.

I have written lots of detail about using update hooks to manage updates in Drupal and they have all been about the hook_update_N() hook. The hook_update_N() hook is just one of the options available in running updates as the update pipeline also includes hook_post_update_NAME(). The hook_deploy_NAME() hook, bundled with Drush 10, can also be used as an update hook in the same way.

Each of these update hooks has a number of different best practices when considering their use. All of these hooks are run once and once only and the key idea is that they take Drupal (or a module) from one version to another by adding database changes or configuration updates as the module gets updated.

For example, if you have a module that has a database table then it will be stored as schema information within your module. Once you release the module you must ensure that everyone who already has the module installed can still use it after the schema has changed. This means that as well as updating the schema information you also need to provide steps in the update hooks to update existing installs. Without this step the module would likely crash as it attempts to inject data into tables or fields that don't exist.

The Marp suite of tools is great for creating presentations from simple Markdown rules.

I've previously written about how to get up and running with Marp, but as I have been using it for a while I have come up with a few things that might be useful to know about if you are getting to grips with it.

Here's a list of what I'll be talking about.

1. Using HTML In Slides
2. Adding Speaker Notes
3. Using Spot Directives
4. Using Images
5. Generate A Presentation From A Document
6. Jump To A Slide
7. Creating Custom Themes

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.