This post is the first in a series about getting Drupal to run as a persistent server, responding to requests without bootstrapping each and every time.

This is how many other application frameworks and languages run: nodejs, Rails etc.

In those systems you start some instances of your application and then they do whatever bootstrapping they need to do and then they enter an endless loop waiting for requests.

I recently upgraded our internally hosted Redmine server to run on Ruby 2.3 and during that upgrade took a look at our NewRelic monitoring for the application. Some of the page...

I've previously written about dynamic forms in Drupal, using #states to show or hide input boxes depending on other inputs. Since then, Drupal 7 and 8 have both got the ability to combine conditions with OR and XOR operators. This makes it possible to apply changes when a form element's value does not equal something, which is not obvious at all.

In Drupal 8, there are many ways to interact with configuration from PHP. Most will allow you to write the config values, but some are read-only. Some will include 'overrides' from settings.php, or translations. There are many layers of abstraction, that each have different purposes, so it can be easy to run into subtle unintended problems (or more obvious errors!) if you pick a method that doesn't quite suit what you actually need to do. Here I'm going to outline some of them and when you might pick each one.

I have honed a selection of commands that I regularly use in the creation and application of patches. Here is a run-down of my most useful commands.