Drupal 7: Empty Menu Link Titles

Create Drupal 7 menu links with empty titles! With Drupal’s hook_menu_link and <none>, create icon links & other styled links that have no text.

One of my biggest pet-peeves is creating Drupal 7 empty menu link titles since there’s no out-of-the-box solution. As a result it can be difficult to create stylized links, such as icons or background images. After many frustrating sessions I finally sat down to find a way to make this happen. Consequently, I began to think this was an impossibility and was unable to find a solution already in existence that did exactly what I needed it to do. However, Drupal 7 empty menu link titles are absolutely possible with just this one little snippet! Have no fear, theme_menu_link to the rescue! Continue reading “Drupal 7: Empty Menu Link Titles”

Simple Drupal 7 AJAX Implementation

Boost the performance of your Drupal 7 website, improve usability and help with SEO by making content load via AJAX in just a few steps.

Drupal AJAX is a cinch to implement—as it should be since core is loaded with it. In just a few of steps I’ll show you how to use jQuery and Drupal’s hook_menu() function to quickly build a AJAX function to return anything from HTML to a JSON array.

Continue reading “Simple Drupal 7 AJAX Implementation”

Salesforce with Drupal in Three Easy Steps

Salesforce Suite is an easy way to connect Drupal to Salesforce, which allows non-technical staff to create extensive reports — learn how to integrate it.

This article was originally published by Drupal Watchdog in the winter 2014 edition by Fabian Franz.

The Salesforce Suite of Drupal modules is an easy way to connect Drupal to Salesforce, a Customer Relationship Management system used by retailers and non-profits alike, which allows non-technical staff to create extensive reports — reports that would be difficult to create using Drupal alone.

Although entities can be synchronized to Salesforce objects — and custom mappings created — there is lots more that can be done with Salesforce. Let’s take a look.

Getting Started

For openers, you’ll need:

To get the Developer Edition, create a developer account at https://developer.salesforce.com/signup.

Once you’re in Salesforce, you’ll quickly notice that the site seems overwhelming. A complete overview is way beyond the scope of this article; the most important objects for our purposes are Campaigns, Leads, Contacts, and Cases.

There are many other extensions for Salesforce, extensions that provide new object types. Also, existing object types can be extended in much the same way as in Drupal.

As a best practice, always work in a sandbox environment when not working with a dev instance. It will help ensure that you can create a proper development -> testing -> production workflow.

To create a sandbox (Enterprise, Performance, Unlimited, and Database.com), go to Setup » Sandboxes » Create new Sandbox.

As the final step in this first part of the process, create an application to connect Drupal to Salesforce by going to Setup » Create » Apps and clicking on New application under Connected App. Enter the basic information (e.g. “Drupal Integration”) and activate oAuth. Enter a callback URL to your local instance. If your local development Drupal site resides at http://localhost/salesforce-test/, then your callback URL is http://localhost/salesforce-test/salesforce/oauth_callback. Select api and offline_access as scopes.

Be sure to keep your consumer key and consumer secret handy, and you’re ready to move on.

Next Steps

Download the ‘salesforce-7.x-3.x’ module and enable the salesforce_mapping and salesforce_push modules. In your Drupal site, go to Configuration » Salesforce » Authorize and enter your consumer key and secret.

If you are using a sandbox, you need to enter, under the advanced settings, https://test.salesforce.com/ as the Salesforce endpoint. After logging in, you will be prompted for the permissions specified earlier; after clicking ‘Allow’, you’ll be back at Drupal with the message “Salesforce OAUTH2 authorization successful.” At the bottom of the screen will be a list of resources.

Before mapping the user object, create field_first_name and field_last_name fields within Drupal for the user entity at Configuration » People » Account Settings » Manage Fields.

You’re now able to map the User account to a contact by going to Structure » Salesforce » Salesforce Mappings and adding a Salesforce module called “User Mapping”.

Fill out the fields as seen in the image below, and check the three action triggers (entity create / update / delete). Save, and edit your own user account at People » Edit. Add the first name and last name, and you’ll see that the user account has been synchronized with a Salesforce record (see below).

A Ticket System for Authorized Users

A typical use case is to collect data in Drupal, and then process the data in Salesforce. But for this article, we will create a quick ticket system for authorized uses that will create cases within Salesforce, using the Entityform module, which allows creating forms that can be used for collecting data — similar to Webform, but using Drupal fields.

Download and enable the Entityform module and go to Structure » Entityform Types » Add Entityform Type. Enter Ticket as the name, and select authenticated user as the role. Save the form type and add a message-long text field to it.

Next, map the entityform submission entity with the ticket bundle to a Salesforce case object like the user account. Map the field_message field to the Case description; map the user who creates the case; select Related Entities » User; and map that to Contact ID (see below).

Save the mapping and go to the submit/ticket URL (available from the Structure » Entityform Types screen), enter a message, submit it, and — voila! — your ticket has been created as a case within Salesforce.

Tip: If you copy the Salesforce ID from the message, you can go directly to https://emea.salesforce.com/ID to see the newly created record. (The emea prefix is for the developer edition.)


While Entityform is quite pwerful, form variations are not easily workable because only one bundle can be mapped to one object type. But with the help of the Webform and Salesforce Webform Map modules, in combination with Entityform, it is possible to create a Salesforce mapping per object-type once, and potentially re-use it across hundreds of different web forms. In this scenario, one webform is represented by a campaign in Salesforce, and recursive object creation is enabled using different Salesforce mappings.


Salesforce and Drupal are a powerful combination. The Salesforce module allows you to map complex Drupal structures to Salesforce, and by using Entityform, simple data entry forms can easily be created.

Programmatically Create & Delete Image Styles in Drupal

Need to programmatically create or delete an image style in Drupal? Maybe you’re creating a module that needs to define a new style or looking to use an update handler to delete one. It’s a cinch to do with just a few lines of code.

I recently needed to delete a image style that was no longer being used with a update handler. Being that Drupal’s documentation is less than informative, I did some digging and finally figured it out. Check out how to create, flush and delete image styles below. Continue reading “Programmatically Create & Delete Image Styles in Drupal”

Drupal Custom Tokens: How to Easily Create Your Own

A feature I regularly use in WordPress development are shortcodes. I needed the same functionality in Drupal. Like most things I’ve found with Drupal, it’s not as easy or clear on how to go about it. No need to fret though, I’ll walk you through how to get ahead of the learning curve and easily create custom tokens.

A feature I regularly use in WordPress development are shortcodes. I needed the same functionality in Drupal. Like most things I’ve found with Drupal, it’s not as easy or clear on how to go about it. No need to fret though, I’ll walk you through how to get ahead of the learning curve and easily create custom tokens.

Drupal’s documentation — or lack of — and a lot of posts I found on how to create tokens had conflicting information. This was mainly due to portions of the Token module getting moved into the core beginning with D7. Though, it doesn’t due much good for typical users if there’s no interface or UI for defining custom tokens.

In the examples below, I’ll show you how to easily create custom tokens within a module.

Creating Custom Tokens in Drupal 7

To create custom tokens in D7, we’re going to use two hooks:

  • hook_token_info() – This is where you’ll create the token and define what they are.
  • hook_tokens() – This is where the magic happens, you’ll tell Drupal what to replace your tokens with.

Below, we’re going to create a custom token that holds the user’s session status (Logged In, Logged Out). You could use this token in conjunction with GA’s custom dimensions to gather more detailed analytics.

Step 1: Create & define the custom token.

In your module, add the following code:

The code above will return an associative array with your custom tokens data:

  • Name: The translated human-readable short name of the token.
  • Description: A translated longer description of the token.

It’s important to note the structure of the array: $info['tokens']['user']['session-status']. Where user is the token type, and session-status is the machine-friendly name.

If you have the Devel module installed, you can use dpm(token_get_info()) to view all available tokens and types.

Step 2: Replace the token.

In your module, after the code above, add the following:

That’s it! The session status token should now be available and appear in the list of tokens wherever tokens are available.

Helpful Drupal Token Modules

Here’s some helpful modules that will make working with tokens in Drupal easier:

  • Token – Provides a UI to view currently available tokens.
  • Token Filter – A very simple module to make token values available as an input filter.
  • Custom Tokens – Gives users the ability to create custom tokens for specific replacements.
  • Token Insert – Allows you to insert tokens into a textarea.

More Information on Drupal Tokens

How to Create a Patch for a Drupal Module

I recently downloaded the Drupal Security Kit module to implement a Content Security Policy on a site I’m working on. One of the drawbacks was the 128 character limit it has for the allowed source fields. That was a bit too restrictive for my needs due to the number of external scripts the site uses. The solution, create a patch for a Drupal module.

I recently downloaded the Drupal Security Kit module to implement a Content Security Policy on a site I’m working on. One of the drawbacks was the 128 character limit it has for the allowed source fields. That was a bit too restrictive for my needs due to the number of external scripts the site uses. The solution, create a patch for a Drupal module.

If you’re not familiar with what a CSP is, I recommend looking into adding one to increase your sites’ security. Mike West wrote a great introduction to CSPs.

After digging around for awhile trying to figure out how to create a patch for a Drupal module, most of the posts I found assumed that you already had a pretty good understanding of Drupal. Being fairly new to Drupal myself, this was a bit of a pain to figure out—a common theme I’ve found with all Drupal development. With some help from a fellow Drupal developer, after about 15 minutes, I got it figured out and submitted my first patch to Drupal.org (currently pending review).

In my experience, I’ve found documentation for Drupal development is a bit scarce and when you do find some, it’s usually written for Drupal veterans. So, I thought it would be a good idea to share my experience with others like me how are just getting started with the CMS.

Creating a Patch for a Drupal Module

For this post, I’m going to use the Security Kit module as an example. If you’re not familiar with what a patch is, check out Drupal’s patch page. Basically, patches are pieces of code that solve an existing issue. Once a patch has been applied, the issue should no longer exist.

Step 1: Clone the Drupal Module

The first step is cloning the module. If you don’t already have Git installed, you’re going to need to install it. Once you have, head over to the module’s project page (ex. https://drupal.org/project/seckit).

Security Kit

Click “Version Control” under the title (ex. https://drupal.org/project/seckit/git-instructions). Where it says, “Version to work from”, select the version of the module you’re wanting to patch. In this case, I want to patch 7.x-1.8, so selected “7.x-1.x” and then clicked “Show”.

Drupal Module Version

Now open up a terminal window with Git installed and clone the project’s repo. In this example:

This will copy the project’s files onto your system so you can make the updates needed.

Step 2: Update the Module

Since I needed to increase the maxlength limit for the allowed source fields, I opened: sites/all/modules/contrib/seckit/includes/seckit.form.inc which includes the admin form settings for that module’s configuration page. There I found that they weren’t defining the maxlength for the fields, so defaulted to the 128 character limit.

This is easily fixed by adding the #maxlength option to the fields array. See the example below:

For more information on how Drupal handles form fields, see their Form API Reference docs.

Step 3: Create the Patch

Now that you’ve made the changes to the module, you’ll need to create the patch for it. This is easily accomplished with Git. Open terminal and go into the module’s directory:

With this being a simple update, the following command will work for most improvements:

In my case, there hadn’t been an issue created for my problem yet, so I did:

For more complex improvements that require adding/removing files, work over the course of multiple days including Git commits, or collaboration with others, see the Advanced patch workflow.

This will create the patch file you need in the module’s directory. Pretty simple, huh? So, what about applying a patch?

Appyling a Patch to a Drupal Module

Applying a patch is as simple as adding the patch file to your module’s directory, then running the following command:

In my case, I did:

Once the patch has been applied, be sure to remove it so it doesn’t accidentally get included in future commits:

Pretty simple stuff!

I’d love to hear any feedback, suggestions or questions. Keep in mind, I’m fairly new to Drupal so would love to hear what the veterans think.