The Patterns module allows you to define and combine features on new or existing Drupal sites as well as automate setup and configuration. Here are some common questions asked about Patterns:

Questions: Answers:

Why was the Patterns module created?

The primary goals were:

  • Create the ability to define and automate the setup of small or large bits of reusable functionality and features.
  • Provide the ability to mix and match and combine patterns and sub-patterns.
  • Do this on new or existing sites.
  • Support multiple formats that are easy to manage, non developers can use, and can reside in revision control systems.
  • Make it easy to share and collaborate on patterns/features.

How is it different from Install Profiles?

  • The main difference is that rather than one large file that defines your entire setup, you create smaller definitions of features that can be combined or chosen from a list.
  • The second difference is the ability to use patterns on existing sites rather than only during the initial installation.
  • Third, it supports additional formats such as XML or YAML.
  • It is much easier to create/write a pattern configuration file then install profile, no knowledge of PHP or Drupal APIs is required
  • Also check out the Patterns Installation Profile which installs the Patterns module for you and allows you to pick multiple patterns to run during your initial Drupal installation.

How is it different from Context/Features/Spaces modules?

  • The primary difference is that Context/Features/Spaces only use available module specific APIs such as Views Imports/Exports. Patterns on the other hand uses the FormAPI because it's the one consistent API that can work for all configurations/features currently available in Drupal. Patterns does also support using Views module direct import and export arrays but it does not define them statically in code.
  • The secondary difference is the format. Context/Features/Spaces define the feature in code as a module while Patterns defines the configuration in XML, YAML or PHP arrays. This is because the Patterns developers want them to be more easily shared and allow non developers to contribute to them. With Context/Features/Spaces you end up with one module per feature (or defined set of functionality and with Patterns you can define features or configuration as small or as large as you like and then mix and match them.
  • There are discussions under way about combining these efforts to support both methods in parallel and use the APIs when available and fall back to FAPI when necessary (until there is a common import/export or Data API in Drupal core.)

How does Patterns work?

  • Define small bits of functionality or features in PHP arrays, XML, or YAML. (Automated export is being worked on)
  • Enable/run a pattern to automate the site configuration.
  • Pattern Processing is run through the Batch Operations and Forms API.

Why does it use the FormAPI?

  • FAPI is the one true common API in Drupal that all modules use and support. Without this only limited parts of Drupal can be supported until FormAPI is split up into a Data API with validation and separation of forms.
  • Validation. All of the existing core and contrib module's validation logic resides in the forms layer. If you don't use FAPI then there isn't a consistent way to ensure validation of your data or configuration.
  • The developers also plan to use module specific APIs where available and possible.

What formats does it support?

  • PHP
  • XML
  • YAML
  • There are plans for full pluggable support to allow you to support any format you choose.

Are there example patterns I can look at?

How do I create patterns?

  • Currently the are written manually but a pattern builder and tools to automate the creation of patterns are being developed. Check out the example files for syntax.
  • Check out the Creating or writing Patterns documentation page.

Why XML, YAML, or other formats?

  • Patterns module does support using direct PHP arrays for your configurations, but we wanted to also provide formats that are easier for non developers to work with and use. YAML is a good example of this. Ultimately, we want developers to be able to use any format of their liking by using pluggable formats.

What parts or how much of Drupal core and contrib are supported?

  • Any setup or configuration that you can do using forms on a Drupal site is supported. This means that almost all of Drupal core and all of contrib are supported. Patterns also has the ability to simplify the syntax used in patterns so that they are easier to read and write. Most of Drupal core and the key contrib modules such as CCK, Views, Pathauto, Imagecache, are specifically supported.

Isn't there a better way?

  • Not until the Data API (or import/export api) is in place (hopefully Drupal 8) with validation and separation of forms then there will be a common, unified method that doesn't rely on FormsAPI.
  • A Configuration Framework module has also been written to improve the core of the Patterns module.