Reflecting on namespaces in Drupal 8

Last month I was preparing to give a lightning talk to the local Drupal group about PHP namespaces. As I was being forced to organise my thoughts in order that I could produce something that was (hopefully) articulate and informative, it prompted me to re-examine some of the standard responses to creating custom Drupal code.

The format for modules that Drupal 8 supports with autoloading is /Drupal/my_custom_module. That follows the composer convention of <vendor>/<package> except that the <vendor> element wouldn’t be the platform that you’re using. It’s more usual for that to be connected to the developer (either a collective or individual name) or the client/project.

As Drupal developers we tend to have a reflex response to fire up our custom module templates to solve all our requirements. However I don’t have the same approach with other projects that use Symfony components. The work I’m undertaking there relies as much on the work of others, but I don’t expect my code to exist in their namespace.

I think that it’s better to go through these questions in order to find the most appropriate structure for our custom Drupal code:

  • Is it for the wider PHP community?
  • Is it implementing your business requirements?
  • Is it integrating external functionality into Drupal?
  • Is it a specific Drupal enhancement?

We can see a practical example of this with the way that Commerce Guys have approached the new version of Drupal Commerce. They have split off some of the key libraries into separate packages that are available to the rest of the PHP community, but still have the Drupal-specific elements in a module.

I can then imagine working on a future ecommerce project where I would put the logic for the particular store’s taxes, etc. into its own namespace. After all if the client chooses at some stage to migrate from Drupal Commerce to another platform I want to minimise the rewrites involved.

What are the benefits?

  • Embracing the ‘Proudly Found Elsewhere’ mindset — looking to the wider PHP community means that someone else might have a package that meets your requirements; that there are more people to test and maintain the code your project relies on; that you could start a new package and find contributors more readily.
  • Increasing the possibility of contributing your code — having isolated the project/business requirements into a separate package means that the rest of your code is more generic, and can be easier to make public.
  • Simplifying the contributions to Drupal — the requirements for your module are more focussed, and the code will reflect that.

And Drupal 7 devs can start now

If you haven’t started to use namespace yet then I can highly recommend this simple step forward to simplify and organise your code. Add in the X Autoload module and you can begin to prepare for the Drupal 8 upgrade.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.