Request a Quote

Featured Client

.Net Project for a Danish Company

Option Matrix has been working over last 2 years for an IT solutions firm in Denmark that provides portal solutions to sports clubs

Drupal 7 Standards

Option Matrix team strictly follows recommendations on when it comes to coding standards. The Drupal Coding Standards apply to code within Drupal and its contributed modules. The standards are loosely based on the PEAR Coding standards.

Coding Best Practices

The Drupal Coding Standards apply to code within Drupal and its contributed modules. These are loosely based on the PEAR Coding standards. Comments and names should use US English spelling. This covers the following aspects:

  • Doxygen and comment formatting conventions
  • Namespaces
  • Object-oriented code
  • PHP Exceptions
  • SQL coding conventions
  • Temporary placeholders and delimiters
  • Use Drupal Unicode functions for strings
  • CSS coding standards
  • JavaScript coding standards
  • Indenting and Whitespace
  • Operators
  • Casting
  • Control Structures
  • Line length and wrapping
  • Function Calls
  • Function Declarations
  • Class Constructor Calls
  • Arrays
  • Quotes
  • String Concatenations
  • Comments
  • Including Code
  • PHP Code Tags
  • Semicolons
  • Example URLs
  • Naming Conventions (Functions, Constants, Global Variables, Classes, Files)
  • Helper Module

Secure Code

The common areas to ensure code security in Drupal 7 area are listed as follows and we have more detailed / illustrated guidelines on each topic:

  • Use check functions on output to prevent cross site scripting attacks
  • Use the database abstraction layer to avoid SQL injection attacks
  • Use db_rewrite_sql to respect node access restrictions.
  • Handle user input with care
  • Create forms in a safe way to avoid cross-site request forgeries (CSRF)
  • Database access
  • Do not use /e in preg_replace() – use preg_replace_callback() instead
  • File uploads, downloads and management
  • Handle text in a secure fashion
  • Handling Private/Personally Identifiable Information
  • JavaScript
  • Session IDs
  • Use of hash functions
  • Using PHP with eval() or drupal_eval()
  • When to use db_rewrite_sql or hook_query_alter()
  • Writing views
  • Safely Impersonating Another User


Web accessibility refers to the practice of making websites usable by people of all abilities and disabilities. When sites are correctly designed, developed and edited, all users can have equal access to information and functionality. It covers the following aspects:

  • Using headings to improve accessibility
  • Creating accessible site and page navigation
  • Creating accessible structure and markup
  • Improving readability with fonts and typography
  • Managing images and media for accessibility
  • Specifying colors and contrast for accessibility
  • Building accessible forms
  • Maintaining accessibility in rich Internet applications and Javascript/Ajax features


Here are the standards and best practices for Theming:

  • Browser Support – Themes must be cross-browser tested and look as similar as possible in standards compliant browsers. Non-standards compliant browsers down to IE7 are still supported (for now) and therefore must “function.” This means that layouts must not break, and obvious differences/bugs should be worked out. It also means, for example, that using border-radius to create rounded corners is perfectly acceptable and browsers that don’t support this (lte IE8) are fine without them.
  • Drupal Coding Standards must be adhered
  • CSS Coding standards should be adhered to as much as possible.
  • Template files should not exist in the theme unless they have been changed.
  • Core stylesheets cannot be removed entirely by the theme. Instead selective overriding of CSS rules should be used in the theme’s stylesheets.
  • Template files should not remove critical RDFa nor Accessibility functionality.
  • Default regions should be used where possible (as opposed to creating new similar ones with different names)
  • A print stylesheet must be included
  • RTL styles must be added
  • Color module must be supported
  • Custom theme settings are not allowed (per webchick in D7)
  • Overlay must be supported
  • Primary and secondary links need to be supported
  • At least one additional region for navigation and content-related blocks
  • Markup must be semantic and standards compliant
  • Must pass XHTML 1.0 Strict validation
  • CSS must validate under profile level 3 (CSS3), with the exception of browser extensions
  • Skip navigation needs to stay in place
  • Font sizes need to be relative, i.e. em, %
  • Proper headings, good heading structure, use H2 for node teaser and block titles, h3 for comments and not h5

Code Documentation

  • When submitting (or maintaining) modules, good documentation is vital in order for the module to receive a wide user base and help future developers expand on your module. The following guidelines should be used when coding modules that are to reside in the Drupal contributions repository.
  • The README.txt file should repeat the synopsis on the project page on
  • The project page on should contain a direct link to the README.txt.
  • Like all other module files, README.txt and other *.txt files, should use unix-style line-endings (n), and not windows (rn) or mac (r) line endings.
  • The file should be formatted to hard-wrap at 80 characters with unix-style line-endings.
  • If the module provides general menu items (ie, non-admin interface links), list the paths, so the user doesn’t have to search through the code or admin interface to find them.
  • If the module modifies existing user interface forms using Form API, tell the user what to look for to ensure it is working.
  • If the module requires configuration, provide a link to the settings page and write a small walkthrough on how to get it started.
  • In your file, you have the ability to define a “package” group. Most modules should not use packages at all. Quoting from the Writing .info files page, “In general, this field should only be used by large multi-module packages, or by modules meant to extend these packages, such as CCK, Views, E-Commerce, Organic Groups and the like.”
  • Many IDEs can automatically detect Doxygen doc-blocks, and provide context-sensitive help, not to mention the obvious advantages to people reading your code.
  • If your module creates any hooks or has an associated API, add examples of these hooks in a file named modulename.api.php. This not only helps other developers understand the provided API a little easier, but also gives IDEs the hook information. In order for this to be useful, the hooks should be fully documented with doxygen comments about the parameters and return values. Note that you should use st() rather than t() within .install files.
  • Create links cross-referencing the module action page and its setting page (and help page). These locations are often 3 or 4 clicks away from each other! Using the hook_help method to add a paragraph at the top of related pages may help.
  • Inline, context-sensitive cross-referencing is probably better documentation than any number of paragraphs in a third text document explaining how to get from A to B.
  • If appropriate, add extra documentation as part of the project distribution, under a subdirectory called docs/. Alternatively, consider using the help/ subdirectory with static HTML-file documentation, as part of the emerging standards in the Advanced Helpmodule.
  • Screenshots of the user interface, or diagrams of the processes are especially helpful.
  • Try installing and running your code through the API module.
  • It’s not perfect, but it shows the level of your current documentation, and what it could be if you reviewed your docblock formatting a little.
  • If you are hosting your own development or Drupal demo site elsewhere online, consider making your code documentation available, and linking to it from your project page. This is also an Open source best practice. If you do not have a demo site, consider requesting that your code be added to, which adds API documentation for contributed drupal modules upon request.
  • Install and run the Coder module or Drupal Code Sniffer over your code. This will ensure higher code quality, and coding standards, making your code easier to maintain between users.
  • Use inline comments for hint, explanations, or reasoning of any potentially tricky bits of the code. They should hard-wrap at the 80 characters.
  • Inline comments are intended for and read mainly by maintainers and coders who wish to read the source code to gain deeper understanding of the module functionality. Contextual ‘de-obfuscation’ comments, TODOs, known limitations, notes-to-self, excuses for doing something the long way and ‘gotcha’ workaround warnings go here.
  • Use Doxygen @see references liberally to link related functions. Function names and files are interpreted and linked, so no additional markup is required beyond the @see command itself.
  • Keeping functions short is good means you shouldn’t have to write up too much extra about the implementation details.
  • Encourage contributors to help improve the documentation. Users are encouraged to contribute patches that clarify comments, and such a patch is harmless to fold into version control. Often another pair of eyes will see things that seem to need further explanation even when the developer is more familiar with the mechanics of the module.
  • Writing a conceptual overview of the purpose of the code and its general methodology in the @file section is helpful to future developers. It may even help designing the code during the planning stages.

Programming standards

The programming standards cover some aspects listed below:

  • Use Drupal API and don’t constantly reinvent the wheel
  • Naming your modules, functions, and variables
  • Never Hack Core
  • Smaller the better; keep your functions short
  • String translation is mandatory
  • Use version control every time, all the time
  • Writing efficient code and avoid un-necessary coupling