We shall do a deep dive of Drupal's database schema. For the purpose of simplicity, we shall deal exclusively with SQL queries and not step out of DB land unless its required. By doing this exercise, we can derive Drupal's schema from first principles. Let's start with a humble node, more specifically, an article content type which ships by default with Drupal's core. It consists of the node ID, the node type and node properties, i.e. the node title and node status. We are assuming only one bundle, the "article" bundle for now.
I had been getting by with shell scripts and SFTP to deploy Drupal sites until recently. After using Ansible for a few weeks, I realized how much I've been missing all these days. I share some of my notes on how to use Ansible to setup and deploy Drupal infrastructure in this post. Besides, this is also meant to be a full blown introduction to Ansible. A lot of tutorials don't cross the "hello world" realm and I wanted to go beyond that, hence an epic post!
There are some assumptions I'm holding about the reader and the setup, like:
We saw how general authentication works with Drupal 8 in the previous post. We shall see how the actual authentication happens when user logs in. It all begins with a humble login route in
user.services.yml of the user module.
Ever wondered how Drupal 8 authenticates a user? Let's do a deep dive and find out.
In this journey, we will encounter a few new concepts which I'll try and explain briefly here and in detail in separate blog posts. Many of these concepts are borrowed from Symfony and adopted in Drupal 8. The journey of a request begins in a Symfony component called HTTP kernel. The job of HTTP kernel is to handle requests and respond to them in an event driven way.
Time for a little confession. I didn't intend to showcase DrupalVM as a DIY Drupal hosting solution when I conceived this series idea. Jeff Geerling, DrupalVM's creator hinted at using DrupalVM as a viable solution for small to medium sites in the first post of the series. It was an idea worth exploring and the result is this post.
Richa(all proper nouns changed to protect privacy), our QA, is doing the final testing of a client feature which will go live in a while. Its 4 PM and Friday Happy hour will start soon. Richa is testing a Drupal 7 site packed with tons of contrib and custom modules, and in case you are wondering, yes, we do deploy on Friday evenings at Acme Inc. Its like any other day here.
I had started this series with a post about what features will be evaluated when selecting DIY Drupal hosting solutions. We shall start with the most simplest and earliest solution of them all, Aegir. First, the nomenclature. Aegir is the God of seas and oceans in Norse folklore, much like Varuna in the Hindu pantheon.
The meta stuff
I'll be writing a series of posts exploring DIY drupal hosting options. Many agencies and freelancers need a workflow to manage and maintain their Drupal sites on a budget. Of course, they incur the cost of maintaining and deploying the system(at least initially) and the additional learning curve involved in using the system, but they get the following advantages:
More control over the hosted sites. It is easy to create and deploy new environments to demo sites to clients, triage bugs, run tests etc.
Ever wondered what exists inside the vendor/ directory of your Drupal or PHP codebase? Let's dive down the rabbit hole and see.
A little bit of history
Let's digress into a little history lesson to see why things are they way they are in the PHP autoloading world.
We've seen how validation works and how to create a custom validation component previously. Chances are, a validation component already exists for most of the requirements. Thanks to Composer and the way Symfony is organized as components, it is easy to reuse existing components. We will try our hand at one such component, the Zip Code validator.