Implementing a Web Design the Drupal Way (not just any old way)

Drupal has a particular way of doing things, which is sometimes not to the taste of everybody. This can lead to a misplaced feeling that it is weird or difficult. However, the Drupal way comes from years of developed good practice, and is backed by tens of thousands of developers' knowledge and experience.

Doing things the Drupal way means working with the framework, and not at odds with it. Doing it the Drupal way saves headaches down the line. It means coding to standards, which leaves your code in a state where it can be read and understood after the project has gone live. It makes it maintainable. It means thinking about the next developer who has to work with the code and making sure that they can figure out what is going on before making changes.

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”
― John Woods

Use the Framework

Drupal is modular. It makes no assumptions about how you want your site to function. Therefore, it is extremely versatile. The correct approach when doing a site build is to get most of the way there with contributed modules and only when it comes to tweaks and minor changes do you crank up your editor and write custom code.

This distributes the burden of security maintenance because module maintainers will be upgrading and patching their modules for you.

When you are presented with a new challenge, remember: there's probably a module for that.

Make things configurable

One of Drupal's great strengths is its configurability. The Drupal way is to enhance that strength. When writing your own modules, allow the user to configure them, rather than hard-coding settings into them. Drupal provides a solid API just for this. Following on from this, think about making your modules generic. In this way you may be able to reuse them from site to site and save yourself work. You could even contribute the module back to drupal.org and give back to the community that has built such an fantastic tool. Here's how much Annertech has contributed to the Drupal Community.

Override, don't hack

Often it can seem easier to developers unfamiliar with the framework to dive into existing published code and make changes to it to get the desired result. The result of this approach is a site that cannot be upgraded in the face of security patches and new releases. Core and most modules provide hooks (functions that you can use) to hook into the processing workflow and make your customisations in a controlled manner. By respecting published code and using hooks, keeping your custom code separate, you can keep your site safely upgradeable and all your custom code in an obvious place, for easier maintenance.

Use templates for presentation only

Novice developers will almost certainly delve into the theme system as it feels like a natural progression to move from writing CSS to making simple modifications to templates. The golden rule when working with templates is this: templates are for presentation, not logic. A template should contain mostly HTML, with at most some conditional print statements. A template that contains business logic is wrong. Logic belongs in a module, or at a pinch in template.php, if related to presentation. A sure sign that a developer is inexperienced is when you find more PHP than HTML in template files, and lots of them.

Keep Modules Atomic

It always seems easy to hurl all your site's logic into a single module. However, it is worth the effort to separate out discrete chunks of code into different, themed modules. Maybe there's one for dealing with forms. Maybe there's one for listings. Maybe there's one for dealing with integration with a CRM. Keeping your modules separate makes it easier to find your code when you need to make changes, and allows you to turn off parts when necessary (e.g. if you do not want to send test data to an external application).

Never, ever, put PHP in the database.

Seriously. Just don't.

There is a module which will allow you to enter PHP directly into an input field through the admin interface. This is a huge security risk, and can result in massive problems. A missing curly brace can take down your entire site. A deprecated function in the database can destroy your site if you upgrade PHP without finding it. You cannot search your codebase for code in the database. It is invisible to you and will cause you massive problems. You cannot put this PHP into version control. All in all, it may well be the single worst thing you can do to your site.

Views Vs SQL

Views is amazing. It allows you to quickly build really complex queries and then format them in an astonishing number of ways for display on a page, and all without writing any code. Sometimes, however, Views can reach its limits, far-reaching as they may be. However, any query built on Views can easily be changed, tweaked, rebuilt and remoulded to another purpose.

SQL queries, on the other hand, can be faster, as they are talking directly to the database, and can do anything the language will allow, but do nothing about presentation or building an output to display on the page. They cannot be edited through the UI and are often more difficult to understand.

The Drupal way would be to use Views for any user-viewed listing, and resort to SQL for only the very simple, back-end queries, for speed, or the extremely complex queries that Views cannot handle.

Learn to use theme()

The theme() function allows a developer to specify markup in a module, but allows the themer to override that markup without hacking the module. If you are putting HTML markup into your code, it should be in a theme function, and called via the theme() function.

Use the Drupal API

A lot of thought has gone into Drupal. Knowing PHP is not enough to build a good site. You need to get to grips with the API and use it. Leverage entities. Figure out how to use the entity_metadata_wrappers. Wise up about when to load entities to get the data you need. Embrace the form API and make your forms dynamic and reliable. The API is there for excellent reasons and should not be ignored.

Don't forget about security

There are plenty of articles on writing secure code. The thing to remember is: never forget about the need for security. Drupal provides excellent filters for sanitizing user input on display, such as check_plain, filter_xss, etc. They will save your site.

Structure Your Content

One thing that is sure to bite you down the line is content that is all jumbled together into a single body field. Drupal provides a user interface and solid field API for modelling complex data structures in a simple way. This makes responsive sites, data re-use, publishing on different platforms etc. all possible.

Look at the Field Collection and Paragraphs modules, all the Media modules and embrace sturctured, rich media experiences.

A WYSIWYG is great for editors, but make sure that it can only do what is needed, not everything. Having said that, there are noises about meeting half way between stucture and freeform content. See this rather informative presentation from DrupalCon LA - the Battle for the Body Field.

Would you like your site built the Drupal Way?

We'd love to hear from you!