Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Feb 19 2021
Feb 19

We had a custom user registration form for use in our Commerce checkout account registration workflow that allows users to register during the checkout process. We wanted to add additional fields to the custom registration form but adding the fields to the standard user entity would not display the fields in our custom form as its fields are all created manually in the custom form.

In Drupal 7 we would use the field_attach_form() function but it is removed in Drupal 8. Below is how we achieved this in Drupal 8/9.

Jan 12 2021
Jan 12


Chosen uses the Chosen jQuery plugin to make your

Apr 06 2020
Apr 06

If you have a site that has content populated using a file/image type field and want to convert it to use a Media field type you would need to create a new media type field and re-populate all of the image content. This is not practical for a website with lots of content so we came up with a method to use an update script to automatically populate the new media field from the old file/image field type.


If you haven't already, the first step is to create your Media entity. Then create the new media reference field on your existing content type.


Now place the following code (modified for your field and content type values) in a custom module and run Drupal's update script (/update.php or "drush updb")

use Drupal\media\Entity\Media; /**
 * Create media entities from existing file fields.
function MY_MODULE_update_8101() {
// Load all of the article and page nodes.
$nodes = \Drupal::entityTypeManager()
loadByProperties(['type' => ['article']]);
  foreach (
$nodes as $node) {
// Verify that the file field has a value.
if (!empty($node->field_OLD_FIELD_NAME->entity)) { // * use your existing file/image field name here
      // Create the new media entity and assign it to the new field.
      //dpm($node->field_OLD_FIELD_NAME->entity); // * use your existing file/image field name here
sprintf('preparing image for node "%s".', $node->getTitle())
$node->field_NEW_MEDIA_FIELD_NAME->entity = MY_MODULE_create_media_image_entity
sprintf('Updated image for node "%s".', $node->getTitle())
 * Creates a media image entity from a file entity.
 * @param $file
 *   The existing file object.
 * @param string $alt
 *   The image alt text.
 * @return \Drupal\media_entity\Entity\Media
 *   The media entity.
function MY_MODULE_create_media_image_entity($file, $alt = NULL) {


$media_entity = Media::create([
'bundle' => 'teaser_image', // * use your bundle name here
'uid' => '1',
'name' => $file->alt,
'status' => TRUE,
'field_media_image_1' => [
'target_id' => $file->id(),
'alt' => $alt,
Feb 25 2017
Feb 25

Introducing the Commerce Abandoned Carts module

Users abandoned their shopping carts before completing the checkout process results potential lost sales. The Commerce Abandoned Carts module allows you to automate the sending of emails to users who have abandoned their carts, thereby allowing you to remind them of the incomplete checkout and/or provide additional information to them.


Install and enable the module normally.

drush en commerce_abandoned_carts -y


When the module is first installed it is in TEST mode. While in TEST mode email will be sent to the configured test email address or the site email address if this empty. Also, while in test mode the database records are not updated so that the same test emails will be sent on each cron run.


Commerce Abandoned Carts module settings

To access the settings navigate to STORE→CONFIGURATION→COMMERCE ABANDONED CARTS (admin/commerce/config/abandonded_carts)

  • Send Timeout: This is the amount of time to wait before a cart is considered abandoned (in minutes). For example, the default setting of 1440 minutes will wait one day from the time a cart is first created before sending the message.
  • History Timeout: This setting is used to prevent the module from sending messages to users who have created their cart too long ago. The default setting of 21600 minutes will prevent the messages from being set for carts that are more than 15 days old.
  • Abandoned Statuses: Check all of the cart/order statuses to be considered not completed. When the module runs it will query for carts/orders that meet the above setting requirements, ere one of these checked statuses and the user has entered an email address.
  • Batch Limit: This limits the amount of emails that will be sent per cron run. A higher number will user more resources per cron run. If you set this to a lower number for efficiency then you should set your cron to run multiple times per day if you want to process for abandoned carts.
  • From Email Address: This is the email address that the abandoned cart messages will be sent from. Leave blank to use the site email address.
  • From Email Name: This is the name that will be shown as the abandoned cart messages will be sent as. Leave blank to use the site name.
  • Email Subject: This is the subject line that will be displayed on the abandoned cart messages.
  • Customer Service Phone Number: Optional phone number to be included in the phone number variable to be used in the email template. Leave blank to omit.
  • Enable Test Mode: Check the test mode box the enable test mode. While in test mode all abandoned cart messages will be sent to the test email address entered, or to the site email address if left blank. No database updates will be made while in test mode, this means that the same emails will be sent during each cron run while in test mode. Once test mode is disabled then emails will be sent to the user/customer email and the database will updated to only send one email per cart/order.


Email can only be sent if the user has entered their email address during the checkout process. Obviously, we can't send an email to a user if we don't have their email address.

Proper cron setup is required.See the cron notes below.


Proper setup of your site's cron system is required for proper functionality. We recommenced not using Drupal's built in "poor man's cron" but rather setting up a cron task on your host/server.

When setting up your cron task it should run at least as often as your "send timeout" setting or your messages will not send as often as you'd like.

More information about setting up cron on Drupal.

Email Template:

The email message sent to users can be easily customized by copying the files from the module's theme directory into your default theme directory. Then clear the site's caches and customize the template as needed.

NOTE: See the template file for further information and available variables. You can also override the commerce_abandoned_carts_theme() function to further customize if needed.

Apr 13 2016
Apr 13

A tell-tale sign that a website is a Drupal site is the login page. If you go to WEBSITE_URL/user of most Drupal websites the login form that you're presented with is almost always the default and very Drupal-looking login. Now there's an easy way to change that on Drupal 8 using the Super Login module.

Default Drupal 8 login form page

Inspired by Morten DK's popular Drupal Watchdog article, "De-Drupalizing The login Form" and also Jeff Atwood’s, “The God Login”, we decided to make an easy way to turn the default Drupal login page into a Super login. Simply installing the Super Login module (and clearing the site caches) will change the form show above to one like this:

Drupal 8 Super Login Form Page

That's a big improvement just by installing one module. One important note though is to be sure to disable the "user login" block that Drupal provides by default as the Super Login module only modifies the login page form. Most of the changes provided are also configurable in the module's settings. By navigating to admin/structure/super_login/settings we have control over all of the text displayed on the forms and buttons/links, as well as:

  • Allowing users to login with their Username or Email Address, Username only or Email Address only (Drupal default)
  • Turning off the module's provided stylesheet (CSS) so you can theme the forms yourself
  • Turning off the module's provided CSS3 submit button theme
  • Turning off the dynamic caps lock warning for the password field
  • Turning off the placeholder text

The Drupal 8 version of Super Login module is only in beta at this time and will require more extensive testing on live sites. If you have suggestions to improve it or find any bugs or issues please create an issue in the module's issue tracker.

Jul 14 2015
Jul 14

Tips to minimize Form Spam on your Drupal Website


If you have forms on your website that the public can submit then you will, without a doubt, have to deal with form spam. Fortunately there are some easy steps you can take to greatly minimize spam submissions on your website.


Protects: Registration Forms, Password Reset Forms, Webforms, Node Forms with an additional option to protect all forms on your site.

Project Page: Honeypot

Also Protects: EntityForms with the additional Honeypot Entityform module.

The Honeypot module should be your first line of defense. It’s quite simple to use and works invisibly, behind the scenes without adding any complexity to the form for your users. Just enable it and then select which forms you want it to protect.

The Honeypot module will now look to see if a hidden field (called URL by default) has been filled out or if the form was submitted too quickly. In most cases only a bot would fill in the hidden form or fill out the form too quickly. If either of these conditions is met then the submission will be stopped.

The Honeypot module is typically all we’ll use on a website and in most cases almost completely removes spam. However, there are additional options for further protection.


Protects: Webforms

Project Page: Webform Validation

The Webform Validation module is a very flexible add-on module that extends Webforms with additional validation options that include verifying that a field is numeric, meets minimum or maximum lengths, has a number of words, equals a specific value, doesn't contain black list words and more. And if this wasn't enough you can even enter Regular Expressions which can create very complex filters like meeting a area-code and phone number formate.


Protects: Comments, Contact Forms, Registration Forms, Password Reset Forms, Node Forms and Webforms.

Project Page: Mollom

The Mollom module uses heuristics and data matching through a 3rd party service to analyze form submissions. You will need a Mollom account to use this module. Mollom gives you up to 50 legitimate posts free per day. If the form(s) you’re protecting have more than 50 legitimate posts per day you’ll want to look into their pricing.

Mollom is a sophisticated module with multiple configuration options including blacklist words. Each Webform will need to be added manually to Mollom’s list of protected forms and can be configured to always show a captcha or, as recommended, only show a captcha if the form submission looks suspicious. Mollom can be a great addition to your spam prevention methods and between this and Honeypot; almost all spam submissions should be caught.


Protects: User Login, Contact Forms, Registration Forms, Password Reset Forms, Node Forms, Webforms and Custom Forms.

Project Page: Captcha

Another choice is the Captcha module which allows you to present the user with a captcha challenge to prove they are not a bot. There are various types of captchas that can be selected from and more can be installed from other modules that extend the options. In our experience, captchas can be somewhat helpful in minimizing spam but can also aggravate your users who have a hard time figuring out the challenge. We prefer to use other methods that work silently behind the scenes without giving your users more work to do before they can submit the form.


Protects: All forms

Although the details are beyond the scope of this article, another option for minimizing form spam is to create your own form validation function. If you are creating your own forms using Drupal’s Form API then you can simply add your own validation function. If you’re using a built-in form of any other type then you can use HOOK_form_alter() to add your own validation callback to an existing form.


Form spam is going to happen but with a little effort and a multi-layered defense you can minimize it greatly.

Apr 23 2015
Apr 23


Drupal allows you to easily change the order of your displayed fields using the Manage Display option for your content types but it does not allow you to change the order of the title field (because this field is rendered directly from the node template). But there may be times that you want to display your custom field(s) before the title field. For example, if you have an image field that you want to float to the left of your title and remaining node content.

Displaying a field before node title in Drupal 7

Luckily, the solution is quite easy to implement.


Create a node template file for the content type you want to change the title order on. Note that if your theme already has a custom node template for the content type you want to change then you can skip to step 2.

If you don't already have a specific node template in your theme for this content type then you can simple copy the node.tpl.php from the /node directory in your root Drupal install file into your theme directory and rename it to node--CONTENT_TYPE_NAME.tpl.php.


If your content type's machine name is article then your copy of the node.tpl.php file will be named node--article.tpl.php.

If your content type's machine name is team_bio then the file will be named node--team_bio.tpl.php. Notice the underscore in the content type name are retained and not converted to dashed.

IMPORTANT: Be sure to clear your site caches so your new template file will be used.


Once you have a custom node template for your content type all we need to do is make a slight change to it. With Drupal 7 we can harness the power of render and hide within the template files.

This is a stripped down and simplistic version of what your current custom node template might look like:


print $title; ?>

  print render($content); ?>

Now we can modify our template to manually output our image field before the title like so:

print render($content['field_name_of_image']); ?>

print $title; ?>

  print render($content); ?>

And when a node of the template's content type if rendered it will now print the image before the title and when the remaining content is output using print render($content); Drupal will know that the image field has already been output and will now leave this off when the rest of the content is rendered.

Displaying a field before node title in Drupal 7

Render and hide are really quite powerful features to use in your theme's template files. For example, you can use hide($content['comments']); to prevent the comments from being rendered with render($content) and then manually render them later in your template using render($content['comments']).

The most important concepts to grasp when dealing with render and hide are:

  1. render($content['FIELD_NAME']) will manually print a field in your template.
  2. hide($content['FIELD_NAME']) will prevent a field from being rendered with the content is printed using render($content)
  3. You can always manually print a field that has been hidden from the main content rendering
  4. If you manually print a field using render then it will not be output when using render($content)
Mar 04 2015
Mar 04


The websites we build often require accepting a payment for something that isn't a product. For example, service payments, down payments or donations. There are different ways to handle this with Drupal Commerce and here we’ll outline the method we've adopted for use and explain how to implement it yourself.


To accept payments of varying amounts in Drupal Commerce you will need a custom line item type as well as a few other customizations. Although you can achieve this with contrib modules like Commerce Custom Line Item Types, we prefer to create our own module that will contain all of the logic needed for our payments. This not only provides a more concise way to achieve our goal, but it also allows us to put all of the pieces needed into one module, which is great for organization.

First, let’s create our custom module. For this example, we’ll call our module custom_commerce. If you’re not familiar with creating a custom module for Drupal yet it’s actually quite easy. There are many resources available to help you get started, our quick start article is Creating a Basic Drupal 7 Module.

Your module will start with the following two files: custom_commerce.info and custom_commerce.module. Please these two files into a folder called customer_commerce.

.INFO file

The .info file should contain something like:

name = Custom Commerce Code
description = Handles varying payments, etc.
core = 7.x
package = Commerce (custom)

dependencies[] = commerce

.MODULE file

The first step is to tell Drupal Commerce about our new, custom line item type. We'll do this by using hook_commerce_line_item_type_info() as shown below. You can adjust the names and description as needed for your situation.

function custom_commerce_commerce_line_item_type_info() {
$line_item_types = array();
$line_item_types['payment'] = array(
'type' => 'payment',
'name' => t('Payment'),
'description' => t('A payment or Donation'),
'product' => TRUE,
'add_form_submit_value' => t('Add Payment'),
'base' => 'commerce_product_line_item',

That's all there is to creating a new custom line item type. Once you save this code and enable your new module you will see your new line item type under STORE->CONFIGURATION->LINE ITEM TYPES

Drupal Commerce Donation / Payment Custom Line Item

Now, from the Line Item Types configuration screen, click the Manage Fields link for your new Line Item Type and add a new Decimal type field. You can name this field Donation, Payment, or whatever is relevant for your situation.

Drupal Commerce Donation Payment Line Item Field


Now create a new Commerce "Product" for your Payment or Donation by navigating to STORE->Add a Product. Give your new Product a SKU (such as PAYMENT) a title and a price of $0. After saving your new Product take note of its Product ID number as you'll use this in your custom module below.

Note that you can create a custom product type for your Donations or Payments if you'd like. In our case, we're not selling any products at all so we removed the default Product product type and added a new Payment product type in instead. We then used this new product type to create our Payment product to be used for our payments.


In this next step, modify (as needed) and add the following code into your custom_commerce.module file. This function is the callback from our second menu item we created. This function is called when our custom Add to Cart form (created in a following step) is submitted. This function will create a new Order object for the current user and then create a new line item in the order using your product and custom line item. It will then direct the user directly to the checkout page.

 * Menu call back to add customer payment amount to cart, create order and direct to checkout
function custom_commerce_cart_line_item_add() {
$amount = arg(1); // Load payment amount from URL argument
global $user;
$product_id = 1; // this is the product id number of your payment/donation product
if ($product = commerce_product_load($product_id)) {    
// Create and save new order object for user
$order = commerce_order_new($user->uid, 'checkout_checkout');
// Create a new line item using our custom line item type and attach it to our order
$line_item = commerce_product_line_item_new($product, 1, $order->order_id, array(), 'payment'); // "payment" is the name of our custom line item type.
$line_item_wrapper = entity_metadata_wrapper('commerce_line_item', $line_item);
$order_wrapper = entity_metadata_wrapper('commerce_order', $order);
$order_wrapper->commerce_line_items[] = $line_item;          


drupal_set_message('A customer message can be displayed if desired.');   
// Redirect to checkout page now
drupal_goto('checkout/' . $order->order_id);

Form API

Now we could create a Commerce Display Node to handle the displaying of our Add to Cart form but we're going to create our own form instead using Drupal's Form API (FAPI). This will allow us to have complete control over the Add to Cart form and functionality as well as negating the need for a Node to display our Add to Cart.

The first step is to use hook_menu to create two menu links. Insert code similar to the following into your custom_commerce module. This will create two menu router items. The first one (user/payment) is to display the form. The second (add-payment) is to process the payment/donation. Of course, adjust this code as needed for your situation.

 * Implementation of hook_menu().
function custom_commerce_menu() {
$items['user/payment'] = array(
'title' => 'Make a payment',
'file' => 'custom_commerce_payment.inc',
'page callback' => 'drupal_get_form',
'page arguments' => array('custom_commerce_payment_form'),
'access arguments' => array('access checkout'),
$items['add-payment'] = array(
'type' => MENU_CALLBACK,  
'page callback' => 'custom_commerce_cart_line_item_add',       
'access arguments' => array('access checkout'),

Now, create a new file in your custom_commerce module called, custom_commerce_payment.inc. This file will contain your custom Add to Cart form code. In this new file place your form code similar to the following:

function custom_commerce_payment_form($form, &$form_state) { 
$form['amount'] = array(
'#type' => 'textfield',
'#title' => t('Enter Payment Amount'),
'#required' => TRUE,
'#default_value' => 0, // Add a default value here if desired   
'#size' => 20,
'#maxlength' => 20,
'#attributes'=> array('placeholder' => '$'),
$form['submit'] = array(
'#type' => 'submit',
'#value' => 'Proceed to the next step',
// Here we'll validate the payment amount. First we'll strip any dollar signs and then make sure the value is a number larger than 0
function custom_commerce_payment_form_validate($form, &$form_state) {
$values = $form_state['values'];   
$str = str_replace('$', '', $values['amount']);
    if (!
form_set_error('amount', 'Please enter a valid payment amount.');
    if (
$str <= 0){
form_set_error('amount', 'Please enter a valid payment amount.');
$form_state['values']['amount'] = $str;  
// Menu callback to add payment to cart
function custom_commerce_payment_form_submit($form, &$form_state) {    
$amount = $form_state['values']['amount']; 
drupal_goto('add-payment/' .$amount); // This is our menu callback used to handle the payment

There is extensive documentation for Drupal's Form API online. You can use this API to customize your form, validation and submit function as needed for your situation. This will allow you a great amount of control and flexibility over your Payment or Donation's functionality.


The last step is to create a Rule to Calculate the Sell Price of our new payment or donation. Our new Rule will contain something similar to:

  • EVENT: Calculation the Sell price of a product
  • CONDITION: Entity has field
    • Set the field to the field you created in your Custom Line Type
  • Actions:
    • Calculate a value, using the custom Line Item field times (*) 100 and set the variable name to Result
    • Set the unit price to a specific amount, using the Result variable

We've made an export of our Rule available for download here. You can import and use this Rule on your site if the Custom Line Item Type's payment field name is "field_payment_amount". Otherwise, Rules will give you a validation error when trying to import it.


As of this writing, there is an issue with the latest release of Rules (2.8) that causes the price calculations to fail. You must use the 2.7 version of Rules, or, once released, a version past 2.8 (more info)


This may seem a bit complicated but in actuality, once you understand the basics, we were able to use a few lines of code in our custom Drupal module to create a self-contained payment or donation system that allows us complete control over the Add to Cart form and processing logic. Once you've adapted and used the above steps you should now have an Add to Cart form available at the URL you specified in your hook_menu (user/payment). You can adjust this URL as needed, including limiting access. Our completed custom Add to Cart form looks like this:

Drupal Commerce Custom Payment Donation

And clicking the "Next Step" button performs our custom form validation and submit functions, creating the custom line item, adding it to the cart and then redirecting the user to the checkout page. We've also created a one page checkout to make the process as quick and simple as possible for our customers.

Feb 13 2015
Feb 13


Drupal’s default login page form is functional but does leave a lot to be desired. It’s pretty bland and, if left as-is, is always a telltale sign that your site is a Drupal website.

Super Login Module for Drupal

The above image is the default Drupal login page and, as we've pointed out, there are multiple areas that could be improved upon.

Over the years, we've incorporated improvements to our site’s login forms via various theme and module hooks. Some of them started with Morten DK’s Watchdog article, “De-Drupalizing The login Form” and have evolved over the years.

Then, we recently read Jeff Atwood’s, “The God Login” Article which led us to incorporate more changes to our login forms and inspired us to release the Super Login module for Drupal 7.

Super Login is a simple, light-weight module that, once enabled, instantly changes the login page from the above screenshot into one like the one below.

Improve Drupal login page form


As you can see from the screenshot, there are multiple improvements to our login page. Some of which include:

  • The tabs are removed and replaced with links within the login form itself
  • The submit buttons are replaced with Retina Display compatible images
  • Icons are placed within the fields for a visual clue
  • Redundant field descriptions are removed
  • Page title is hidden and replaced within the forms
  • Placeholder text is displayed within the fields (this feature can be disabled)

There's also some other improvements below the surface:

  • User can now login with their email address as well as their username
  • A "caps lock" message is displayed if the user starts typing their password while caps lock is enabled
  • System messages, such as warning about missing or invalid info when submitting the forms are now displayed within the forms themselves
  • Autofocus is set to the appropriate fields on page load
  • The submit buttons are replaced with images

Just enabling the Super Login module instantly gives you a better looking and more functional Drupal login page. Almost all text strings and features can be changed or disabled with the module's configuration area.


Super Login only affects the login and password reset pages. It does not change the login block in anyway.

Page titles on login and password reset pages are attempted to be hidden, however, various theme may output the titles in different ways and may needed to be hidden manually through your theme's CSS

Your theme may already be applying changes to the login pages on your site. If you enable this module and have different results then your stylesheets and/or theme functions may already be altering your login page. If so, you can try modifying your theme or disabling the CSS from the Super Login module in its configuration.


This module may not be the perfect one size fits all solution but hopefully this will fit the needs for some Drupal website to de-drupalize the login pages. Please let us know if you have suggestions for improvements.

Jan 19 2015
Jan 19


Almost all Drupal websites will have multiple Views displays containing output of various content but your options to sort this content are usually limited. Most Views displays can only practically be sorted by creation date or node title. This will work well in many cases but if you need to implement user-friendly manual controlled sorting then you will need expand Views.

There’s a page on Drupal.org comparing various Node ordering Modules but our favorite is DraggbleViews and in this article we’ll show you how to use it to create a drag and drop sortable image gallery.


  • Install the latest 7.x.2.x branch of DraggableViews from Drupal.org. For Drush users the project name is 'draggableviews'
  • Module dependencies: Views, Chaos tools, Entity API


DraggableViews will allow you to make rows of a Drupal View "draggable" which means that they can be rearranged using Drag and Drop interface. For this example we've created a Content Type called Images that contains an Image Field that will be used for a photo gallery page on our website.

We then created multiple Image Nodes containing stock photography images. Our View is currently limited to a few sorting options like creation date and title but.we want to allow for our editors to easily reorder the images so now we’ll setup DraggableViews and create a sorting interface.

  1. Edit your existing View that you want to be sortable (in this example it’s our image page View).
  2. Add a new display to your existing View. This new display should normally be a Page display type and this is what will be used as the sorting interface.
    Drupal View for Drag Drop sorting
  3. Setup your new View's Display similar to the following (This will vary depending on your specific needs).
    • IMPORTANT: Be sure to override this sorting display for all applicable settings so you you’re not also changing the main View display when we edit the Sorting Display's options in the following steps.
    • Set Display and Title to reflect your sorting display. Example, “Sort Images”.
    • IMPORTANT: The display format must be set to Table.
    • Add only the minimal amount of fields needed to be visible for your node’s sorting purposes. For example, only display the node titles or, as in this example, small thumbnails of the node’s image.
      • Add a title, image thumbnail, or some other visual reference field.
      • Add a NID (Node ID) field and be sure to select ‘Exclude from Display’.
      • Add the “DraggableViews” field, leaving the default settings.
    • Remove any sorting criteria that may already be in your View and add the “DraggableViews Weight” field as the sort criteria for both this sorting View and the main display View. The parent View’s DraggableViews sort field needs to be set to use the new sorting View in its “Display Sort as” setting.
    • Give your sorting View a page path. I like to use something like “admin/content/sort/photos” so a menu link will be available in the administration menus. Make this a ‘Normal Menu Entry” and be sure to set the Views menu path to ‘Management’.
  4. Drupal DraggableViews Views Setup

    Once you save your View you should now have a page containing the content of your View with handles to the right of them for drag and drop sorting.

    drag drop sorting interface drupal views


    Be sure to the appropriate permissions for your sorting View. There is also a “Access draggable views” permission that must be granted. If a user has access to the sorting View but does not have the “Access draggable views” permission then they will see the View without the drag and drop handles.

    Drupal Draggable Views Permissions


    If you set your sortable View's path to something like '“admin/content/sort/photos' as described above and also set a "Normal menu entry" for the "Management" menu then you will now have a menu link to your sorting page from your administration menu.

    Your new sorting page will also be accessible by the View's Contextual Link, allowing for direct and quick access to sorting the View right from the main page.

    Draggable Views sort menu


    You should not rely on View's live preview as it may differ from the actual output.

    The reordering may not work if you have Caching turned on for your View. The drag and drop may work but upon saving your ordering it will revert back to the previous order. If you need caching then you will need to create a separate display for sorting and turn caching off for that View only.

Jan 17 2015
Jan 17


The Drupal Address Field Module is a great tool that we use often. There are, however, many times when the default output causes some issues for us. Be default, Address Field places all of its individual field components inside of a Feldset wrapper. This is usually a nice feature but there are times when you may want to remove this Fieldset wrapper for aesthetics. Or, perhaps, you'd like to place additional fields within the Address Field's Fieldset. We'll show you how to do both.


As usual, Drupal provides a handy Hook Function that allows us to override the Address Field's output to remove its Fieldset wrapper.

We can use hook_field_widget_WIDGET_TYPE_form_alter to alter widget forms for a specific widget provided by another module. To remove the Fieldset wrapper from all Address Field output we simply use this hook in our own custom module to change the element type from 'fieldset' to 'container'.


The Address Field's 'Widget Type' name is 'addressfield_standard'. This can be discovered by examining the module's code or using the dpm() function from the Dev Module to examine the $form output returned to a hook_form_alter() function.

Create a function similar to the following in your custom module to remove the Fieldsets from all address fields.

 * Implements hook_field_widget_WIDGET_TYPE_form_alter().
function MY_CUSTOM_MODULE_field_widget_addressfield_standard_form_alter(&$element, &$form_state, $context) { 
$element['#type'] = 'container'


If you'd like to remove the Fieldsets from specific Address Field output instead of all of them then we can simply use the $context variable that is provided to our hook to only act upon certain conditions. In the example below we're checking the $context array for a specific bundle to act upon.

function MY_CUSTOM_MODULE_field_widget_addressfield_standard_form_alter(&$element, &$form_state, $context) { 
  if (
$context['instance']['bundle'] == 'student_registration'){
$element['#type'] = 'container'


We often have a situation that requires an Address Field to have additional fields within its Fieldset, for example, email or phone number fields. To achieve this we use the method above to remove Address Field's default Fieldset wrapper and then simply add our own using Drupal's Field Group Module.

  1. Remove Address Field's Fieldset out from all or specific output using method above
  2. Create custom Drupal fields within your entity. For example, Phone Number or Email fields
  3. Create a custom Fieldset in your entity using the Field Group module's provided field groups
  4. Place the Address Field and your custom fields within the field group you created

Your output should now be similar to the 'after' image in the screenshot below.

Drupal Address Field Remove Fieldset</p>

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web