A Dev’s View of Drupal 8
With the release of Drupal 8 promised for Winter 2013, Drupal developers will soon be working with a package incorporating the biggest structural changes ever introduced to the CMS. Get ready to go back to school, because big changes to the way you code are right around the corner.
At Drupalcon 2013 in Portland this Spring, Dries Buyetart talked about the need for Drupal to interact smoothly with other products in order to better establish itself in the Enterprise marketplace. This is a welcome strategy for Drupal, promising to push the CMS into more markets while establishing itself as a legitimate option for large-scale clients.
Making this happen requires a fundamental restructuring of the product itself. Drupal 8 integrates key components of the Symfony framework, requiring a restructuring of Drupal core. Object oriented code patterns will increasingly become the norm. New outside code libraries will do much of the heavy lifting of day-to-day tasks. Theming patterns will be significantly different and file-based configuration files using the YAML language will fundamentally change how we deploy and manage Drupal 8 sites.
So what are the key concepts of Drupal 8 to pay attention to in the coming months? Here’s a quick look at what’s in store, and what it means for your daily coding.
The inclusion of key components of the Symfony Framework into Drupal core will affect every aspect of your day-to-day coding life. If you’re not familiar with Symfony, it’s an open-source project that --among other things--provides a set of libraries for common programming tasks. These include, managing HTTP Request Objects, YAML configuration files, even a new theming engine (Twig), to name a few.
If you’re wondering why Drupal is leveraging an outside code framework right now, consider Dries Buytaert’s keynote address at Drupalcon 2013.
ln it he made the case that where many competing private companies that are trying to build all-in-one platforms for web services. Drupal’s advantage comes in it’s ability to integrate smoothly with other products. With enterprise-level customers choosing different products for CRMs, ERPs and e-commerce needs, Drupal’s strength will be defined by its ability to interact with any number of outside products.
That’s where a third-party framework comes into the picture. Symfony introduces a new set of code libraries that can be used in many projects, not just Drupal. This means the integration hurdles an enterprise user will face will be far smaller than if all of Drupal’s code was written for Drupal alone.
What’s more, the Symfony Framework offers a degree of legitimacy other languages have offered for years. For example, Symfony leverages Object-oriented coding practices that Drupal hasn’t yet fully embraced. It also brings stricter coding standards, naming standards and deployment practices to the CMS that have been sorely lacking for years.
Namespaces and Files Structures
Adopting Symfony introduces a new set of requirements for coding in Drupal. Central to these are coding and naming conventions described by PSR-0.
PSRs (Proposals for Standards Recommendations) come from the PHP Framework Interoperability Group http://php-fig.org. They provide a structure for formatting code and -- important for Drupal Developers -- recommendations for namespaces and file structure. In a nutshell, PSR-0 naming conventions allow Symfony libraries and Drupal code to work together.
This new systems radically changes where code is stored in Drupal, and how modules are named. For example, contributed and custom modules will now be stored in the /modules directory, previously used only for Drupal’s core modules. Almost all of the D7 core files have been moved to the /lib/Drupal directory -- following a naming pattern that dictates that code is organized by vendor. (You custom code might also be stored in /lib/Drupal/MyModule/YourClassName.php .)
YAML provides Drupal developers a new way to configure -- and deploy -- almost every aspect of a Drupal installation. For those not familiar with the language, it’s meant to be a more human readable text format for storing arrays. It looks a bit like JSON, but somewhat easier to understand. For example, here’s a YAML file for the minimal Drupal installation profile:
description: 'Build a custom site without pre-configured functionality. Suitable for advanced users.'
As you can see, it’s human readable, but maintains the basic structure of an array or JSON file.
Yaml will server many purposes in Drupal 8. Among other things, these files will replace the .info files in modules. They will also be used to store configuration options that are now stored in the Drupal database. This promises to make deployments far, far easier for developers since these files can be uploaded like any other file posted to a server. No more fiddling with the database during code promotions or deployments.
Here’s an example of a YAML file used for configuration. An image preset might look something like this:
label: ‘Large (480X480)
Creating yaml files for Drupal promises to reduce deployment headaches by eliminating the need for db configurations through the feature module, or by completing manual configurations through the administrative backend.
While Drupal 8 comes out-of-the-box with a host of pre-installed third-party code libraries, developers will be able to install additional libraries using a dependency management tool called Composer. Composer is a bit like using PEAR libararies in a standard PHP Application. But where PEAR libraries are used globally throughout a PHP installation, Composer allows developers to downloads its classes strictly within the Drupal instance.
This means developers won’t have to worry about class collisions in separate instances of Drupal. It also limits the tedious process of having to update multiple classes in the event that another class is updated elsewhere in the system.
This is a lot like the Bundler Gem for Ruby. A welcome tool for PHP developers.
Imagine a Drupal project using a third-party mailing class library for part of its functionality. A developer in this scenario might download a the class via Composer. The class is stored locally -- as are the configuration files linking this version of the class to this particular Drupal installation. No matter what changes the future bring to this class, any instance of Drupal using this configuration will alway be able to use this particular class.
Strict Code, Safe Code
Drupal 8 grows up substantially, with safer, more secure code. Take for example the HTTP request object. Syfony provides a full API for securly accessing $_GET and $_POST variables. In fact, the request object includes these variables, along with all other request variables, accessible in one convenient package. Now, instead of using the simple -- but notoriously insecure $_GET[‘var’] construction, you’ll be able simply write something like
$request = Request::createFromGlobals();
$name = $request->get(‘var);
What’s delivered back is a completely sanitized string, along with all the other request data, easily accessible in the $request value.
Finally, Symfony provides a new way of routing HTTP requests through Drupal. This means that the while you can still use the traditional hook_menu system for passing variables to different modules, you can now use a .yml file to set these paths independently of the menu system. This should lead to a more rational use of the menu system, where hook_menu would only be called for “real” menus.
For example, an while an ajax callback *could* still be written with hook_menu; a better approach would be to list the callback within a routing.yml file, like so:
_permission: ‘administer site configuration’
This should introduce a new, more rational approach to dealing with Drupal menus.
Welcome to the Future.
New changes coming to Drupal 8 will revolutionize the way developers work with the system. These advances promise a bright future for the CMS.