Drupal Development#

Drupal Standards#

Most Drupal 8 and beyond projects at Bixal use some version of Bixal drupal-project. The readme file in your project should be the first thing you do when on-boarding on to a new project. It should contain answers to most questions about how to set up the project and where to get resources. If there are addtional questions contact the project team in Microsoft teams for help.

Drupal-specific Coding Standards#

Git Commits#

Editor Configuration for Coding#

These are some example editor configuration values - each editor has it's own set:

// The default for most editors and printers. This is the displayed width
// of tabs, but is irrelevant as there shouldn't be any actual tabs!
// The default for Drupal (and many other languages) code. With this setting,
// pressing the TAB key inserts two actual spaces, instead of a tab.

To configure your editor/development environment for Drupal:

@todo this entire section below needs to be reviewed and updated

Drupal Site Building#


We prototype high risk items first#

We need to scope out high-risk tickets to inform basic site architecture decisions. As we know more about a problem, we reduce the risk. Therefore focusing on high-risk first enables early identification of architectural obstacles and opportunities, leading to better matching of functional requirements and system architecture.

How we do this#

When to do this#

When to avoid#



We use Drupal contrib projects rather than custom code#

We use established Drupal contrib projects rather than writing custom code. It's generally cheaper to maintain and the barrier to maintainability is lower (less programmer skills). There are often established best practices around projects that allow us to standardize. We can take advantage of other developers insights and skills.

How do we do this#

When to use#

When to avoid#


We create websites with flexible layouts#

Components, Twig, Container Paragraphs, and Master-display content views vs Blocks, Context, Rules, Panels, Panelizer and Page-display field views.




How we do this#

When to use#

When to avoid#

We build sites such that we can accommodate changing needs and requirements#

We are agile, and we expect our clients to require agility in their website.


We treat the designs of UX specialists and the user stories of content editors and creators seriously#

Drupal has a notoriously poor content workflow and editing experience OOTB. There are simple ways to improve this.

How we do this#

We configure sites that are optimized for SEO#

Modules that are easy SEO wins#

Other SEO practices#

We include social media functions#

How we do this#

When to use#

When to avoid#



We capture configuration settings in yaml files#

We consider Search configuration implications early in the development process#


We configure permissions to be as simple as possible for the user stories#

We consider when to use#

We use entity view modes rather than duplicated views field configurations#

We use entity view modes (e.g. teaser) to configure reusable displays for entities, rather than duplicated views field configurations. We do this so we can avoid fragile duplicated configuration and emphasize consistency of display and modular CSS. There are still occasions where field based views make sense, but these are generally singletons. Part of this needs to happen in the design phase, when we're thinking about doing these displays in a modular fashion.

When to use#

When to avoid#


We improve the registration/login experience beyond default Drupal behavior#

This is a very common, important user story in Drupal that often gets ignored.

Ways to improve#

We are ALWAYS clear on which site is the config/content master#

Never lose time working on the wrong site! [Hint: in nearly all cases the config/content master should be "live" from day 1.]

How we do this#

We don't install modules we don't need, and we remove ones we no longer need#

This means our sites are as simple, focused and performant as possible.

How we do this#

We build sites that make it easy to upload and display images and video#

How we do this#

We upgrade Drupal major versions with careful consideration#

Why? So that we can mitigate risk and ensure a good value proposition for the client.

How we do this#

When to do it#

When to avoid#


We update to new minor versions of Drupal core#

We do this so we can resolve bugs when necessary, or address security vulnerabilities.

How we do this#

We configure secure text filters#


We use Entityform instead of Webform whenever possible#

Unlike Webform module, Entityform module uses Form API instead of reinventing the wheel. This makes it far more easy to integrate with other modules, particularly Rules and modules that alter entity forms. Also, it's exportable in Features.

Projects where this has proven useful: RTM, Teach.

When to do this#

When not to do this#

We use panels layouts, rather than page specific layout adjustments#

We do this so that layouts are cleanly separated from other visual styles, and so that they are reusable.

We configure streamlined and semantic markup by default#

We do this so that our pages are smaller, faster and simpler to theme as well as more accessible. If wrappers turn out to be needed later in theming they are easy to add.


We set a "module budget" for a project#

We do this to prioritize functionality and keep things maintainable and performant.

We consider featurization strategies before starting a project#


All in One#
Functional separation#

(e.g. content types & views, roles/permissions; strongarm settings, theming and defaults, etc)

Granular/atomic content type/function#

(One feature per content type or function)

Tools / Resources to consider#

We avoid namespace conflicts#

We carefully consider our semantics, naming features/views/custom modules in ways that don't conflict with Drupal terms and client terms.

We use drush to update node access#

Make sure you set it to batch mode. You can use:

`PHP_OPTIONS='-d disable_functions=set_time_limit -d max_execution_time=0 -d memory_limit=1024M' drush php-eval "node_access_rebuild();".

to rebuild the node access table. If you leave off TRUE, it will attempt to update all nodes, and may result in some php out of memory errors.


What it does: Allows users to upload/maintain folders of resources using Media module integration.

Useful ONLY if you don't have to change anything about it.

Why not#

We don't like Drupal Commons#

Why not#

When to use it#

Edit on GitHub

Documentation built with MkDocs using a modified Windmill Dark theme