Articles

This is the sixth article in a series of articles about the Batch API in Drupal. The Batch API is a system in Drupal that allows data to be processed in small chunks in order to prevent timeout errors or memory problems.

So far in this series we have looked at creating a batch process using a form, followed by creating a batch class so that batches can be run through Drush, using the finished state to control batch processing, processing CSV files through a batch process and finally adding to running batch processes. These articles give a good grounding of how to use the Drupal Batch API.

In this article we will look at how the Batch API is used within Drupal. The Batch API in Drupal is either used to perform a task, which I will call "direct", or to pass on the batch operations to a hook, which I will call "indirect". These aren't official terms you understand, I'm just using them here to separate how Drupal uses the Batch API.

This is the fifth article in a series of articles about the Batch API in Drupal. The Batch API is a system in Drupal that allows data to be processed in small chunks in order to prevent timeout errors or memory problems.

So far in this series we have looked at creating a batch process using a form, followed by creating a batch class so that batches can be run through Drush, using the finished state to control batch processing and then processing CSV files through a batch process. All of these articles give a good grounding of how to use the Drupal Batch API.

In this article we will take a closer look at how the batch system processes items by creating a batch run inside an already running batch process. This will show how batch systems run and what happens when you try to add additional operations to a running batch.

This is the fourth article in a series of articles about the Batch API in Drupal. The Batch API is a system in Drupal that allows data to be processed in small chunks in order to prevent timeout errors or memory problems.

So far in this series we have looked at creating a batch process using a form, followed by creating a batch class so that batches can be run through Drush and then using the finished state to control batch processing. All of these articles go together to form a basis of batch processing in Drupal.

In this article we will look at bringing these concepts together to perform a task that is quite common on websites, processing Comma Separated Value or CSV files, which we will do using the Drupal Batch API.

This is the third article in a series of articles about the Batch API in Drupal. The Batch API is a system in Drupal that allows data to be processed in small chunks in order to prevent timeout errors or memory problems.

So far in this series we have looked at creating a batch process using a form and then creating a batch class so that batches can be run through Drush. Both of these examples used the Batch API to run a set number of items through a set number of process function callbacks. When setting up the batch run we created a list of items that we wanted to process and then split this list up into chunks, each chunk being sent to a batch process callback.

There is another way to set up the Batch API that will run the same number of operations without defining how many times we want to run them first. This is possible by using the "finished" setting in the batch context.

This is the second part of a series of articles looking at the Batch API in Drupal. The Batch API is a system in Drupal that allows data to be processed in small chunks in order to prevent timeout errors or memory problems.

In the previous article we looked at how to setup the batch process using a form, with the batch methods being contained within the structure of the form class. When the form was submitted the batch process ran through 1,000 items and then printed out a result at the end.

Whilst there is nothing wrong with running the Batch API with everything in a form class, it is normally better to abstract the batch processing code into a separate class.

The Batch API is a powerful feature in Drupal that allows complex or time consuming tasks to be split into smaller parts.

For example, let's say you wanted to run a function that would go through every page on you Drupal site and perform an action. This might be removing specific authors or removing links in text. You might create a small loop that just loads all pages and performs the action on those pages.

This is normally fine on sites that have a small number of pages, like under 100 pages. But what happens when the site has 10,000 pages, or a million? Your little loop will soon hit the limits of PHP execution times or memory limits and cause the page to be terminated. How do you know how far your loop progressed through the data? What happens if you tried to restart the loop?

A common web design pattern is to incorporate an image into the design of the page. This creates a tighter integration with the image and the rest of the page.

The main issue in designing a page around the image is that the colours of the page must match the image. Otherwise this creates a dissonance between the image and the styles of the site.

In this article I will look at extracting a colour palette from an image so that it can be used in the design of a web page.

XML is a useful format for configuration, data storage, and transmitting data from one system to another. As a human readable format that can be easily read by machines it quickly gained favor in lots of different systems as a mechanism for data storage.

Many systems transparently make use of XML without the user ever seeing it. The API system SOAP is built around XML data, and it is normally possible to ask API endpoints to respond in either JSON or XML. It is common to see XML files used in configuration of systems as they can be easily edited and parsed when needed.

I have a lot of CDs. It isn't a "serious" collection, but I have been collecting CDs for at least 30 years so I have a couple of hundred there.

Taking a large CD collection everywhere with you isn't feasible, so I've been ribbing my collection to MP3 for a number of years. Recently, I've started to notice that MP3 doesn't have amazing sound quality, which is more apparent on higher quality audio equipment. MP3s are fine for cars and similar, but not ideal for listening on more serious sound systems.

Since my CD player died a few years ago I have been unable to listen to them in any other way. There is just something about the physical experience of playing music from a medium like the CD that appeals to me so I have still been buying CDs since then.

I was watching a video from NDC by Dylan Beattie the other day on The Story of Typography and a particular section stood out to me.

The talk ranges from the initial start of writing symbols to the formation of typography as an art form and the creation of eInk displays. Well worth a watch if you have some time to spare.

The part that was interesting to me was then discussing early word processors and the ASCII character standard. Early word processors couldn't store the amount of data required to fully render a font, so characters were rendered using a bitmap system.