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 maintiaining and deploying the system(at least initially) and the additional learning curve involved in using the system, but they get the following advantages:
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.
In the first part, we saw how entity validation works in Drupal 8, why it is a separate component and how most parts are adopted from Symfony's entity validation framework.
Drupal 8 has its entity validation separate and decoupled from the typical validation given by its form API. This is done for a lot of reasons. For one, entities might get added from other non UI means, like via the REST API, or programmatically, while importing data from an external source. Under these circumstances, the entity validation API comes in handy.
There is a lot of literature about entities and their purpose in Drupal 7 context. Most of it has been adopted in Drupal 8 as well. In this post, I'll highlight the differences between D7 and D8 entities and how to use the entity API in 8.
Drupal 8 allows module developers to write their own customized authentication schemes. In this post, we shall see how we create one. Let's take a hypothetical custom authentication mechanism called the token authentication mechanism. It works like this:
The routing system of Drupal 8 is a complete rewrite of Drupal 7 and its previous versions'
hook_menu. A Drupal route is a URL path with a specific return content. This return content is usually specified as a method of a controller class which returns a render array.