Module Development Best Practices

This page is designed to detail best practices when implementing routine features in Ãœbercart modules. The purpose of this document is to establish a uniform user interface so tables, forms, and pages of all sorts have a similar look and feel across the cart. Please refer to this page at least once when posting a contribution to to help improve your module.

Use Drupal's Coding Standards and Naming Conventions

Ãœbercart is a Drupal module. As such, all the core modules and any excelling contributions will abide by Drupal's coding standards and naming conventions. This is really a good practice for any of your PHP development. Refer to the documentation at

Use Sentence Capitalization

Menu items and any related bits of text should use sentence capitalization. This means the first word should be capitalized and the rest of the words should be capitalized as if they were in a sentence (i.e. you would capitalize a proper noun). Note that this does not mean you should use punctuation at the end of the text as if it were a sentence. Sometimes even Ãœbercart is guilty of overlooking this rule, but we try to fix these errors as soon as we notice them.

Use Include Files for Certain Functions

To make the code more manageable, modules should be split so that functions all pertaining to a certain Ãœbercart system reside in their own include file. For example, the payment module provides some default payment methods that are split out into the file The naming convention is the module name followed by the system - payment_method, checkout_pane, order_pane, etc. While it is not an Ubercart specific module, include files should also be used to hold all of a module's Workflow-ng hook/callback functions. Be sure to use the function drupal_get_path() to include the files, like this example from uc_payment.module:

= drupal_get_path('module','uc_payment');
$path .'/');

(Please note that the $path variable was used because this module includes more than one file. If your module only has a single file to include, this is not necessary.)

Include a Cancel Link on Add/Edit Forms

Many modules use stand alone form pages to add or edit something. For example, there is a form that lets you add new line items to orders that is accessed through the order edit screen. These forms generally have a single save/submit button at the end. You should additionally provide a Cancel link that returns the user to the page from which they accessed the form in case they decide against the action. This should be included as a #suffix in the form array like so:

['submit'] = array(
'#type' => 'submit',
'#value' => t('Add Line Item'),
'#suffix' => l(t('Cancel'), 'admin/store/orders/'. $order_id .'/edit'),