Showing 21 posts by,

Deji Akala

The Field API, introduced in Drupal 7, allows data fields to be attached to entities with the API taking care of data storage, loading, update, and rendering. When a new field is created, a table is created for it in the database. If the entity it is attached to supports revisions, then a second table is created to store versions of the field content. Creating a field from the UI As you start typing a label for a new field, a machine name is gene [...]

User redirection is often required on a website, and Drupal-based websites are no different. For instance, after successful authentication, users are taken to their account profile page. In Drupal 7, drupal_goto() is the API function for this. It accepts an optional internal $path argument to redirect to. If none is provided, it redirects to the same page. This was later discouraged and $path should always be provided. Two things to note. Firstly [...]

The settings.php file is the main configuration file for a Drupal site where a number of system variables, among other things, may be configured. In Drupal 7, there is an optional setting, $base_url, which specifies the absolute URL of the installation. This is often used when generating site URLs, for example, when using Drush to log in as another user. drush user-login This will log you in as admin user (uid: 1). To log in as another user, you [...]

Drupal implements the Front Controller design pattern. All HTTP requests are directed to the index.php file, and a response is generated and returned. With the architectural decision to use Object-Oriented Programming and Symfony Components, the file has remained very short and concise. However, the request and response aspects of the process are given prominence. This is the index.php without comments: <?php use Drupal\Core\DrupalKernel; use [...]

The introduction of the EventDispatcher Component has brought an interesting approach to how components of an application talk to each other in a clean and organized manner. Interestingly, this is what the hook system, which is as old as the Drupal project, was designed to do. From the documentation of Drupal 1.0: The idea is to be able to run random code at given places in the engine. This random code should then be able to do whatever needed to [...]

The module and hook systems are as old as Drupal. From the documentation in Drupal 1.0: In places where hooks are made available, the engine calls each module's exported functions. This is done by iterating through the modules directory where all modules must reside. Say your module is named foo (i.e. modules/foo.module) and if there was a hook called bar, the engine will call foo_bar() if this was exported by your module. Although the Content [...]