Custom contact

The Custom Contact module creates a custom user contact page using Views. The Flag module is used to mark which users to include on the page so the views can include any arbitrary collection of users. The Draggable Views module is used to allow you to drag 'n drop the entries to arrange the list in any order.

Drupal does not ordinarily allow anonymous users to access personal contact pages, so the Contact Forms module is used to create contact pages that can be accessed by anyone, and we use the Flag module to toggle on and off the option to make the contact form available to anonymous users.

The User Management page is available as a tab on the User list, at Admin >> User Management >> Users >> Custom Contact Page. On that page users with permission to administer custom contact page can toggle options for each user to add them to the Custom Contact page.

Users with permission to administer the custom contact page can also toggle those options on the user edit forms.

API: Styles

OpenLayers styles definitions are a light wrapper around the functionality provided by styles in the OpenLayers javascript library. A simple style definition (one of the defaults included by the module) is

 * Implements hook_openlayers_styles().
function modulename_openlayers_styles() {
  $styles = array();
  $style = new stdClass();
  $style->api_version = 1;
  $style->name = 'default';
  $style->title = t('Default style');
  $style->description = t('Basic default style.');
  $style->data = array(
    'pointRadius' => 5,
    'fillColor' => '#FFCC66',
    'strokeColor' => '#FF9933',
    'strokeWidth' => 4,
    'fillOpacity' => 0.5
  $styles[$style->name] = $style;
  return $styles;

The contents of $style->data are passed directly to the OpenLayers javascript, and therefore have documentation on

Coded Styles

To provide custom styles in a module or feature, implement hook_openlayers_styles(), and return an array of styles, keyed by style name (like seen above).

Also, in order to tell CTools about your new hook, you will have to implement the following hook, like so:


HowTo: How to apply a patch to a contributed module - Beginner's version (Windows)

This page answers the question: How do I apply a patch to a module?

Much of the existing patching documentation on how to apply a patch (see links below) is extremely cryptic and assumes more technical knowledge than some aspiring, but worthy patchers have.

But even those with somewhat lesser technical know-how may want (or need) to apply a module patch from time to time. For instance, there is an important feature that has been developed for your module, but it is still not available in an official release. Or, you have reported a bug in the module, and the module maintainer has asked you to test a patch that fixes it.

This how-to provides a detailed step-by-step guide to applying patches to contributed modules. It is designed for first-time patchers and/or less technical folks who have the need to apply a patch. The how-to specifically relates to applying patches on Windows machines, but the basic information and steps may be helpful for others. It is also written for a localhost (i.e., a development environment, and the particular directory structure follows XAMPP's naming) configuration, but the same steps would apply to a hosted environment as well, if it is a Windows environment. You'll just need to switch the location where some of the steps are executed.

Comparison of modules for HTML tables

If you are looking for ways to simplify the creation or maintenance or uploading of HTML tables for display within blocks or nodes, these table modules might help. These modules are not about managing Drupal database tables.

I have downloaded and tried most these modules, but spent more time with some than others. Each works in a somewhat different way - you may have try more than one to find the one that best fits your needs and workflow.

HOW-TO: Use a view as a source for a node reference field

Here are instructions for using a View to dynamically populate the list of options in a node/user reference field. The most common use cases for this feature are:

  1. When just the node title / user name by itself doesn't provide enough context to know what you're referencing (for example, you want to see options like "John Smith" instead of "stinky500")
  2. If you need to filter the list of options in ways that aren't provided by the field configuration options. For example, selecting from a list of nodes that are tagged with a particular set of keywords.

Here is a simple example: A node reference field showing only nodes that are of type "Story" and have their "Sticky at the top of lists" box checked.

  1. Go to Administer >> Site building >> Views.
  2. Add a new View with the name 'nodereference_featured_nodes' (or whatever you'd like). The other options can be left at defaults. Click "Next."
  3. The next screen gives you the Views interface. Next to "Fields" click the "+" sign. Here, you are selecting what values to display in the node reference field's drop-down list/autocomplete field. Change "Groups" to "Node" to filter the list down, then select "Node: Title", then click "Add."


Subscribe with RSS Subscribe to RSS - Site administrators