Upgrade Your Drupal Skills

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

See Advanced Courses NAH, I know Enough
Oct 24 2018
Oct 24

 Drupal Module Spotlight: Paragraphs

I really don’t like WYSIWYG editors. I know that I’m not alone, most developers and site builders feel this way too. Content creators always request a wysiwyg, but I am convinced that it is more of a necessary evil and they secretly dislike wysiwygs too. You all know what wysiwygs (What You See Is What You Get) are right? They are those nifty fields that allow you to format text with links, bolding, alignment, and other neat things. They also can have the ability to add tables, iframes, flash code, and other problematic HTML elements. With Drupal we have been able to move things out of a single wysiwyg body field into more discrete purpose-built fields that match the shape of the content being created and this has helped solve a lot of issues, but still didn’t cancel out the need for a versatile body field that a wysiwyg can provide.

Content creators yearn for the flexibility of creating a page that matches their vision for how they want the layout. Front-end developers and designers want to be able to rigidly style a site that always looks good, and that clashes with the unexpected markup that a WYSIWYG can produce. These differing priorities can resulting in a real mess of a page. It’s been a struggle as old as the CMS itself.

Solutions of the Past

As I mentioned above, the Drupal solution to runaway WYSIWYG markup is purpose-built fields to catch all specific sections of content that you can.Instead of allowing the whole page to be created in one WYSIWYG field, we would have a field for an image, a summary, some various highlight sections, etc. One problem still remains, content creators want to be creative and have various patterns of content depending on what they are writing about. This includes images floating in every which-way, videos in the middle of an article, quote blocks, content in columns, and the list goes on. You can’t just build a bunch of types of fields for this problem. In the past, I tried using Field Collections and custom form alters to build a user interface that allowed them to select and only see the relevant fields, but this still proved to be too rigid.

The Modern Solution

Enter Paragraphs, the Drupal contributed module that can ultimately solve this problem. I started using Paragraphs with Drupal 7 back around 2014 and it really changed the way I thought about editing and creating content on a Drupal site.

With Paragraphs you can define little entities of fields much like the Field Collection module but less static. The difference is that you can access all or some of the different paragraph entity types from a single field on your content type. This single Paragraph content field will replace your body content wysiwyg field entirely. The Paragraph content field will allow you to endlessly add in different paragraph types and provides a method to reorder after creation. Working with your content creators, you can determine an unlimited number of content patterns that they would like to use. For example, you can create paragraphs with the fields required to make a slideshow, embedded video block, accordion content, or another that is an entity reference field to related articles, and one more that is simply a text area field. With this toolkit of content patterns your content creators can build content in any array of patterns they wish.

Paragraphs will satisfy the creative control that the editors of your site desire and will make them finally admit that they too hate that weird little wysiwyg field. When the situation arises that they want to do something new, it’s just a small revision to create a new paragraph type. Your frontend developers and designers will also be happy that they can strictly control the visual aspects of the individual Paragraphs with specific template files and targeted SASS styling.

Extending the Concept

An overlooked but very powerful use of Paragraphs is using it without any fields at all. Let's say that you want to add a newsletter signup form in the middle of your article. Simply define a paragraph called Newsletter signup then with a bit of custom code write a signup form, you could even have it automatically pass the signup source of the article in a hidden field. Next, all the article writer needs to do is drop the Newsletter signup Paragraph wherever they want it to appear within the article content. Another example of a field-less paragraph that we have used in the past is an about the author section. There are no fields needed, just add the paragraph and write code to look up the article’s author and write a template file to display a bit of author info with a headshot, simple as that.

I could write on and on about the possibilities and use cases for paragraphs, but you should really just download it and give it a test drive. It’s like introducing a mini block system into an individual article of content. If you are planning a new build or have an existing Drupal site, don’t hesitate to add Paragraphs. Your content creators and editors will love you for it.

Oct 03 2018
Oct 03

drupal 8 logo in spotlights

Although it can sometimes be easy to forget about that little URL bar at the top of your browser, what it contains for each page can be surprisingly important. Creating good paths (the part of the URL after the domain name) for your site content can have numerous benefits, especially for SEO, but doing so can be a bit frustrating. Usually, you end up needing to re-type most of the page title into Drupal's URL alias field, which isn't necessarily too bad on its own, but it's still an extra step whenever you create content. And what about when you update the page and change the title? This is where it gets very easy to forget to change the path, which can lead not only to worse SEO but also to your site's visitors not ending up on a page with the content they expected it to have.

Fortunately, the Pathauto module makes all such worries a thing of the past.

This module adds a whole host of new options to how you can configure Drupal's paths, perhaps the most important of which is path "patterns". Patterns allow you specify what you want your paths to look like for different pieces of content; for instance, if you have a site where each of its users can have a blog, you could set up a pattern for Blog nodes such as "/blog/[node:author]/[node:title]". Then, whenever a user creates a blog post, it will automatically be given an alias which includes their username and the title of the post, and it will even update the alias if the user edits the post to change its title.

If you already have a site which has inconsistent aliases, Pathauto can also be used to bulk generate new aliases for your content, which is also quite helpful if you ever decide you want to change the structure of your paths. The module also offers plenty of settings to configure exactly what the paths it generates look like, including the ability to use a wide range of tokens provided by the Tokens module.

Finally, Pathauto also integrates with the excellent Redirect module. If you have both modules installed, changing the title of your content won't just change the path, it will also create a redirect from the old path to the new one so that any links already out there to the old URL will continue to function as expected. This is a rather important bit of functionality, and thanks to Drupal's great selection of contrib modules, it's just a few clicks away from being set up and working on your site.

New Call-to-action

Sep 19 2018
Sep 19

Spotlights shining on the Drupal 8 logo

Webform in Drupal 7 was always one of the top 10 must-haves on any Drupal site. Then Drupal 8 came along, and Webform wasn’t in the picture at first. Luckily, Drupal 8 came with the contact module in core that took care of most form needs, and we lived without the Webform module.

In the meantime, Drupal contributor Jacob Rockowitz had been working on the YAML Form module, which was a module used to define webforms in YAML files. At some point towards the end of 2017 YAML Form switched to the Webform namespace and Webform in D8 was born.

The Drupal 8 version of Webform will feel familiar to those with experience in the Drupal 7 version, but this is a completely new module and code base. It’s a really great tool for content creators to use, by giving them the ability to create complex forms without having to worry about code. However, as a developer, I found it tedious to create long forms through the Webform UI. Those days are in the past now, since Webform is a descendant of the YAML Form module, you still have the ability to define a form using YAML in the source tab of the build screen.

Screenshot showing direct editing in YAML

Direct editing in YAML really speeds things up for developers, and content creators can still use the UI to create and edit. It’s the best of both worlds.

The Webform module in Drupal 8 is such a powerful and fully featured form builder, that it could be reason enough alone for some site owners to switch to Drupal 8. If you run a site that is in need of new or dynamic forms on at least a monthly basis, then Drupal 8 + Webform would be a lifesaver and a budget saver. Personally, I find that Drupal 8 with Webform rivals any of the standalone form building tools available. There are dozens of features and settings that you get out of the box, and it’s easily extendible if you need to integrate with an outside service.

Like most things in Drupal 8, webforms created with Webform can be exported and synced as config. Webform also plays nice with Features if that’s your thing.

We still custom build many forms in Drupal 8 using the Form API, but Webform is a great tool to keep in mind when things need to be editable by administrators or when you just need a simple solution. It already deals with storage, email, and so many other things out of the box. If you have any webform needs, don’t hesitate giving Webform a shot.

Jul 25 2018
Jul 25

 image of spotlights focused on drupal logo

It is essential that content be well-categorized, especially on large websites. Drupal includes the Taxonomy module for doing just this, and it is able to account for most content tagging scenarios. However, when you actually go to categorize content, it can be a bit confusing.

Drupal offers a helpful autocomplete, but this doesn't always work as well as you might hope if you have a taxonomy tree which includes nested terms (for instance, "Cats" as a subtopic of "Pets"). In fact, the autocomplete doesn't show the hierarchy of these terms at all, which can get confusing if you have multiple terms with the same (or similar) names which are children of different terms. And although Drupal allows you to create new terms right from the content editing page, doing so always causes it to create the new term at the topmost level of the taxonomy, which often isn't where you actually want it.

What is Straw?

Enter Straw - the Super Term Reference Autocomplete Widget. We built Straw when we were working with a multilevel taxonomy and found that Drupal's default widgets just weren't cutting it. Now, we've made Straw available as a module for anyone else who might find themselves in a similar situation. Straw does two main things which make working with these taxonomies a breeze.

Find Matching Content Tags

First, both when displaying a selected term on the edit page and when searching to find matching tags based on what the editor is typing, the Straw widget shows the entire hierarchy of terms. That means that instead of simply showing "Cats", it will show "Pets >> Cats", and if you start typing "Pets" it will show both "Pets" and "Pets >> Cats", rather than only showing "Pets" like Drupal's default autocomplete would. This makes it much easier to see which exact term is being matched, and also makes it easier to find sub-terms if you don't quite remember their names.

screen shot of Drupal Straw Widget

Create New Terms

Straw makes it a breeze to create new terms on the fly. Say you're writing a new article for your site about a particular breed of dog, but so far your taxonomy only has terms related to cats. Without Straw, you could type in "Beagles" and it would create a new term of that name, but then you'd have to go to your taxonomy tree and create a "Dogs" term beneath the "Pets" term and then move "Beagles" into it. With Straw, this is much simpler… you just type in "Pets >> Dogs >> Beagles", and it creates all the necessary terms and puts them in the right place in the taxonomy relative to each other.

With Straw, tagging your content can be easier than ever before. It's easy to install (with only a little bit of configuration required) and then you'll be able to see right away how much of a difference it makes.

Offer for a free consultation with an Ashday expert

Jul 13 2018
Jul 13

Omeda and Drupal are a perfect match for managing customer relationships

As you may have figured out by now, Drupal is a great platform for 3rd party integrations. Whether it’s eSignatures with Hellosign, more sophisticated search with Solr, or a host of other options, Drupal works best when it’s not trying to reinvent every wheel and is instead used to leverage existing business tools by tying them all together into a robust and useful package. Today, we’re going to take a look at a new set of integration modules that Ashday has just contributed back to the Drupal community: Omeda, Omeda Subscriptions and Omeda Customers.

The Omeda Solution

If you haven’t heard of Omeda by now, let’s take care of that. They are a family-founded company who have been around for over 30 years and offer a host of Audience Relationship Management tools meant to properly leverage modern technology to properly segment and target your customer base. They are on top of their game and really know their stuff (they even collaborated on the brainstorming of these new modules). And best of all, they offer a very complete and well-documented API, which is key to any good integration.

While their API is extensive, much of it can be very tailored to a particular customer’s needs so we set out to build a contributable integration that covers some great typical use cases as well as allow for custom development where necessary. So far, this has taken the shape of three modules that potentially can be extended later on.

Omeda Base Module

The Omeda base module is meant to be a simple core module to get you wired up to Omeda so you can start doing things. It has settings to configure your connection to the API as well as a setting to work in testing mode. At its heart is a Drupal service that is meant to be injected into other contrib modules that can tackle specific Drupal solutions. This service provides the Comprehensive Brand Lookup, which the module uses to cache your Omeda brand config daily, as well as a generic utility for making API calls, which has the benefit of consolidating some basic error handling and formulation of HTTP requests. Here’s a little example of how simple it is to call the API using this service:


$brand_lookup = \Drupal::service('omeda')->brandComprehensiveLookup();


So that’s pretty easy, right? If anything is wrong with the API config or the service is down or something along those lines, the service throws an exception with a helpful message. Otherwise, it returns the Omeda API response to the caller. Again, it’s simple but provides the base functionality you need everytime you wish to connect with Omeda.

Omeda Subscriptions Module

The first module to leverage the Omeda base module is the Omeda Subscriptions module. This module adds a My Subscriptions tab to the user profile, for the roles you select, where users can manage their deployment subscriptions. You can also configure which Omeda deployments you wish to allow your users to manage. The available deployments come from the stored Comprehensive Brand Lookup data cached by the base Omeda module. This module includes a new Omeda Subscriptions service that adds functions to fetch a logged in user’s opt ins and opt outs as well as allow the user to opt in or opt out of a deployment. It’s a simple, specialized module (which is the best kind) to provide an out-of-the-box solution for the most common Omeda user subscription management needs.

Omeda Customers Module

The Omeda Customers module is another extension to the base Omeda module that allows you to map user fields to your Omeda customer entities and sync them on user updates. You can choose which roles will sync and which user fields will sync. Since field mapping can get quite hairy, we provide a solution for simple use cases where you need to simply tell Omeda that “this field = that field”. If it’s a standard base Omeda field like “First Name”, those are called base fields and are meant to be a simple hand off of the Drupal field value to Omeda. If it’s an email, phone number, or address field, you can choose that type and we will then ask you to determine which contact type it represents so that it gets into Omeda properly. It should be noted that for addresses, we only support Address fields from the Address module since mapping a bunch of individual Drupal fields to a single Address entity in Omeda is more complicated and likely needs a custom solution.

This mapping config also provides a simple solution for Omeda Demographic fields, which are more complex and dynamic fields that store IDs instead of literal values. It allows you to choose which demographic field a Drupal user field maps to and then create a mapping of possible Drupal field values with available Omeda field values. So if you have a field on the Drupal user called “Primary business role”, but you want to map it to the Omeda “Job Title” demographic field, you can do that. You would then hand enter a mapping that indicates that a Drupal field value of “President” maps to the Omeda value of “President / CEO” so that we can send Omeda it’s desired ID value of 5******* instead of the literal text of “President / CEO”, which would be invalid. Again, this is for more simple use cases; if your Omeda fields don’t map 1-to-1 to Drupal fields, the necessary business logic is wide-ranging and you will likely need custom programming. The great thing though is that we’ve included support for a custom hook (hook_omeda_customer_data_alter) to inject your own adjustments into the data mapping process and provide your own custom alterations.

In Conclusion

Hopefully these modules prove useful to you - especially if you’re already an Omeda client with a Drupal site - and the goal again is to provide some basic functionality that doesn’t require developer resources to integrate with some basic Omeda functionality. We ourselves have custom needs beyond what the modules can offer and find that it’s quite easy to extend them to do what we need for particular customer solutions, largely thanks to Drupal 8’s architecture. As always, if you need assistance please feel free to contact us and if you’d like to offer any module patches or report a bug, feel free to use the issue queues for each project and we’ll check it out!

 If you need to integrate Drupal with anything, talk to us! We can integrate just about anything with Drupal

Jul 11 2018
Jul 11

Coffee is a magical thing. It gets you going, clarifies your thoughts, makes you feel all warm inside. I don’t know what I’d do without it. So when we consider installing the Drupal module named after this irreplaceable daily beverage, we see that it has a similar effect. It just makes things better. Am I overstating things? Probably. But I haven’t had enough coffee yet today and I need to get this blog going with some pizzazz.

So simply put, the Coffee module gives you a Mac-like live search experience of the Drupal admin menu. It is triggered by the shortcut of Alt+D on the Mac, or Alt+ctrl+D in Windows IE. When the search bar pops up, just start typing and you can do an ajax live search of that deeply nested admin menu and get to things in a hurry! 

Screenshot of Coffee Drupal Module

Now, it’s not perfect. It can’t dig beyond certain levels, such as actually finding the settings of individual contact forms, but it gets nearly everywhere in the first couple of layers and can save you a lot of clicks when in development and site building mode. Even cooler - you can add your own custom coffee commands in your custom module to make your actions discoverable. That’s great flexibility. 

So there you have it! A simple module that shaves off a few seconds of time all day long. Pretty awesome!

Time to refill my mug.

May 08 2018
May 08

Jay Calicott DrupalCon Session

Welcome to the latest edition of the top modules for Drupal 8! Below I recap my newest list that I presented at Drupalcon, Nashville along with updated descriptions. I have also included labels to indicate which modules are best suited for intermediate users versus modules that are universally easy to install and configure.

As an added bonus I now have all of these modules and dependencies available through Github/Packagist for easy setup. 

Just run “composer create-project mediacurrent/mc_top_modules” to get started in minutes, enjoy!


  1. Admin Toolbar (Beginner) - The admin toolbar. It’s a module that you might think would just be in core. We use this on every project because navigating through menus in Drupal is a real pain without rollover menus.
  2. Component Libraries (Intermediate) - If you are doing any Twig theming this module is going to help you with your Twig file includes.
  3. Devel (Intermediate) - Devel can help you debug problems in Twig templates. Another feature that is handy is the ability to generate dummy content.
  4. Entity Browser / Media Entity Browser (Beginner) - The Media Entity Browser module gives you the ability to use a nice little library pop-up to upload, browse and search for different types of media.
  5. Field Group (Beginner) - This is a helpful module for cleaning up your content types. You can organize fields into tabs, accordions, etc. to give your content editors a better experience.
  6. Google Analytics (Beginner) - Google Analytics is a simple module that allows site admins the ability to easily add basic tracking.
  7. Linkit (Beginner) - This module gives you an autocomplete popup inside of Wysiwyg for adding links.
  8. Metatag (Beginner) - Maintained by Mediacurrent’s very own Damien McKenna, this module lets you configure all of your meta tags for SEO purpose.
  9. Panels / CTools / Page Manager (Intermediate) - Panels is a great site building tool for creating custom layouts with a drag and drop interface.
  10. Paragraphs / Entity Reference Revisions (Intermediate) - The paragraphs module is a Mediacurrent favorite for a couple of reasons. Paragraphs are like mini-content types that can handle a variety of use cases.
  11. Pathauto / Token (Beginner) - The pathauto module lets you set up clean alias patterns for all of your content. If you want all of your blogs to have the path /blog/[title of the blog with hyphens instead of spaces] - this will be the module that you use.
  12. Redirect (Beginner) - Almost every new site needs to incorporate 301 redirects for old page URLs. The redirect module gives site admins an easy interface for creating those redirects in Drupal.
  13. Search API (Intermediate) - The Search API suite of modules is a fantastic way to configure your site searches. By default this Search API DB is enabled but you can easily swap out for Apache Solr. The Search API Pages module is also handy for getting a site search up and running quickly.
  14. Simple Sitemap (Intermediate) - A pretty easy to configure module for creating XML sitemaps for search engines.
  15. Stage file proxy (Beginner) - A great module for downloading images to your local environment auto-magically rather than having to continually migrate those images manually.
  16. Webform (Beginner) - This module is awesome because it makes it easy to make any and all kinds of forms on your site. This is a must-have module if you plan on managing forms within Drupal.


Below are a list of notable mentions that didn’t make the essentials list but are still worth checking out.

  1. CKEditor Media Embed (Beginner) - A lot of content out there on the web includes social media callouts. This module makes it a lot to easier to include that content inside of your Wysiwyg.
  2. Colorbox (Beginner) - The Colorbox module integrates is a popular lightbox library of the same name with Drupal Views and fields. You will need to download the Colorbox library to your libraries folder, otherwise this module is very easy to set up.
  3. Commerce (Intermediate) - If you have done any e-Commerce you have probably heard about the Commerce suite of modules for Drupal. This allows you to add products to your site and checkouts, payment options and more.
  4. DropzoneJS (Intermediate) - Pretty much everywhere you go on the web you see a drag and drop upload option. So why not have that in your Drupal project? This module makes it relatively easy to do so but there is some configuration required along with the need to download the DropzoneJS library.
  5. Entity embed / Embed (Intermediate) - This module lets you embed any Drupal entity anywhere. The most common use case for this is embedding media within Wysiwyg. When paired with the Media Entity Browser, for example this gives editors a powerful tool for embedding media from a library. Both the Lightning & Thunder distributions have good examples of this implementation.
  6. External Links (Beginner) - Over the years we have seen that most clients want the option to force external links to open up in a new window or tab. This module makes that feature request very easy. All you do is check one checkbox and essentially you are done.
  7. Focal point / Crop (Intermediate) - The problem we are trying to solve with these modules is supporting different kinds of crops from the same source image. This solution is probably the easiest I’ve found both on the developer and the content editor. This module tries to crop around the focus of the image rather than just arbitrarily cropping from the center.
  8. Geolocation (Beginner) - I like that the Geolocation module makes it simple to add a point on a map and have that map render in a field. Easy to input and easy to format, with plenty of options for configuration.
  9. Honeypot (Beginner) - Do you ever get spam? While there are a lot of options for anti-spam measures (including captches) this solution has an algorithm that does not burden the end user and is pretty effective.
  10. Lightning Install Profile (Beginner) - Lightning is a general purpose Drupal distribution that focuses on the media and editorial enhancements. Not only is it a good started distribution for Drupal development, it is also a good learning tool. It often is easier to learn how to configure and use a module by examining how it’s implemented on a pre-configured distribution like Lightning.
  11. Scheduler (Beginner) - The scheduler module lets you schedule the publishing and unpublishing of your content. Note that it is going to use cron to make this happen so you need to verify that your cron is configured correctly.
  12. Slick / Slick views / Slick media (Intermediate) - The Slick suite of modules adds functionality to allow site builders to create slideshows and carousels. There are several related modules that integrate with every aspect of Drupal. The hardest part is the initial setup of library dependencies. Once that is done these modules are very easy to configure within the Drupal admin.
  13. Taxonomy Access Fix (Beginner) - This project addresses the fact that core doesn’t have granular enough permissions. The Taxonomy Access Fix module therefore adds in additional permissions to fill in the gaps.
  14. Viewsreference (Beginner) - Last but not least the Viewsreference module gives editors the ability to select a View from a field. At Mediacurrent we combine this field with a Paragraph type to give editors an easy, flexible interface for embedding Views onto a page.

Did I miss any modules you think should have made this list? Let me know on Twitter at @drupalninja!

Additional Resources
Top Drupal 7 Modules: Final Edition | Blog
Top Drupal Marketing Automation Modules | Blog
Top Reasons to Choose Drupal | Blog

Apr 12 2018
Apr 12
Learn more
Mar 02 2018
Mar 02

Drupal isn’t known as a particularly lightweight content management system and that is one of the reasons we love it, right? It is meant to handle large amounts of complex content. A problem occurs when you have a site that is just flush with content of different types, how do you get users to it? Navigation can only get you so far sometimes. We have personally seen this on everything from large-scale publishing sites to medical practice sites.

Having a site search of some sort can greatly improve user experience and has been a core part of the web for a long time now. It solves a few pain points that exist in sites from small to large. What are these pain points? Users don’t want to wade through navigation. You want to control what content is presented. (Meaning you aren’t leaving it to an external search engine like Google to get users to the right content) You want a pleasant experience for your users that they will actually use.

Don’t leave your content in a maze of navigation links

We can’t talk about search without getting into the search module that has been part of Drupal since version 4 ish. The vanilla search module in Drupal is a very passable solution for searching content and users in a Drupal site. It doesn’t take much to set it up either, so if you want to get to a working search experience very quickly, this might be your best bet.

The search page itself isn’t too configurable beyond that, but it does come with an advanced search built into the page. This gives users more control over how their search keywords are interpreted with things like changing the operator from contains to match their exact phrase. It will also allow them to search in whatever content types are configured on the site. If you want your users to have visibility of the different content types on the site and they have useful names, then this can be something that replaces a bunch of different search pages on the site. If that isn’t what you want, well, you are out of luck with the search module.

There are other search modules available for Drupal, of course. There are modules that can extend the usefulness of the search module, but they can’t change too much about the underlying architecture that has a few flaws that are difficult to overcome. It will slow down the site on large Drupal sites and it still won’t have a lot of configurability to the search. For a small site, the search module is a good fit, but it would be difficult to recommend it for larger sites or sites that want to have specific control over the search.

Using Solr for large sites can be a no brainer

So if having search on Drupal is a recipe for a slow site, what can you do? Drupal is known for being great at integrations and this is a good opportunity to leverage one of the more useful search technologies available. It would be a mistake to classify it as “easy-to-use”, but Apache Solr is powerful. It has a lot in common with Drupal if you think about it. It is meant for a large amount of content, has a steep learning curve, and incredibly scalable in the right hands.

Solr Logo


If you aren’t familiar with Solr, then this doesn’t mean too much other than a fluffy description. Solr is search engine software that can provide indexing and search from a variety of sources. It allows for more in-depth analysis of the content that is indexed. It can translate content, exclude html, search against spelling errors, be case-insensitive, determine likeness between content, and a whole lot more. Some hosting providers, like Pantheon, provide this service as part of the their hosting infrastructure. If you manage your own server, then you can install Solr on that server or another remote instance. There are also a few cloud solr instances that are available out there that work pretty well also.

One of the more powerful things that becomes available when you use Solr is the ability to search within documents. That means you can extend the search into uploaded pdfs to provide even better search results. We’ve used this on a variety of sites to get users to information that would otherwise be unavailable to other searches. Features like this make it hard to compare a basic search to Solr. The searching is just a small factor in how search results are generated and processed before you hand them over to a user.

The Verdict

This is going to sound like we are cheaping out a bit, but there isn’t a one-size-fits-all sort of answer for a topic like this. With all web projects there are variables to consider and specific requirements that will drive decisions, so it would be impossible to say generically that you should always use one thing or another. What we can do is present the things that impact the decision the most. If the site needs search and it isn’t going to have thousands of pieces of content, then the search module will suit that need just fine. If there are more complex search needs, constantly changing content, high quantity of content, and a desire to have specific handling for different fields and content types, then you should really consider a tool like Solr.

Up Next: A deep-dive into our recent Solr integration. 


May 31 2016
May 31

The Google Summer of Code 2016 (GSoC’ 16) coding period kicked off from last week, May 23rd. Each selected student had a one-month long community bonding period with their respective organisation. I had written my community bonding experience with Drupal in my previous blog post.

I am working on porting search configuration module to Drupal 8 under the mentorship of Naveen Valecha, Neetu Morwani and Karthik Kumar. I learnt the basics of Drupal, implementing Drupal forms and other fundamentals required for my project in the initial phase.

I was really thrilled to get into the coding rounds of GSoc’ 16. I was successful in making a good progress in the initial week. I could start the coding phase effectively by porting some important features. I had regular discussions with my mentors throughout the previous week. They were really helpful in guiding me in the proper way by reviewing the code and sharing their valuable feedback.

Here I would like to share with you some of the changes which I have come across in Drupal 8 from its preceding versions which I have worked out in the previous week for my project.

  • In D8, the .info files are replace by .info.yml files. The .info files contained the basic information regarding the respective module. The .info.yml generally contains the following attributes of the module:
    • name
    • description
    • core
  • The Drupal 7 variables have been converted to the Drupal 8 state system. The previous versions had variable_get and variable_set functions to store variables and their default configurations. They were used to store and retrieve data. They are presently removed in D8.
  • Moreover, we need to store the default configuration of the variables. While developing a new module, it comes in module/config/schema/ will contain the default variable configurations.
    • The default configuration is the default property of the system with its type and the corresponding default value linked to it.
  • Another transformation that has taken place is that the global $user has been substituted by the current_user service.
    • So, the previous definition,
      • global $user;
    • is replaced by
      • $user = \Drupal::currentUser();

These were some of the important concepts that I had to deal with in the previous week for the porting process. It was really a wonderful learning time for me. Hope to enjoy the coming weeks to learning new concepts and implementing it for my porting.

Hope all the selected students had a wonderful start to their coding period. All the best for the coming weeks.

Jul 30 2015
Jul 30

Making themes and specially advanced ones for Drupal has never been an easy task, it requires considerable amount of Drupal knowledge and in most cases at least bit of programming. So it comes as no surprise that despite the popularity of Drupal, web designers are reluctant to create themes for Drupal. Hopefully by the release of Drupal 8, it becomes a bit easier, but there is still a lot of work to do. The module which i'm going to introduce, can considerably simplify theming and eliminate/reduce the required programming for making almost all sort of Drupal themes.

When we create themes in Drupal, there are great number of reoccurring tasks that we have to do like adding IE conditional comments, remove or replace some core or contributed modules CSS/JS files to prevent conflict with the theme, putting some JavaScript at the bottom of the page or even adding inline CSS or JS files.

Unfortunately we can't do any of these common tasks using Drupal's theme .info file. Surprisingly however we can do most of it using Drupal 7's JS/CSS API! But not easily and not without programming. So as a themer with no knowledge of programming or Drupal's API, we will have no choice but to work around Drupal and directly modify the HTML (as most Drupal themers do) and by doing so not only lose all the great features that Drupal's modularity brings like all sort of CSS/JS optimizations, CDN, etc., but also will have to manually resolve the problems that it causes for core and contributed modules' UI and functionality.

Wouldn't have been great if we had total control over CSS/JS files via theme .info without having to know programming? That's exactly the purpose of CSS JS Total Control module. It extends Drupal's theme .info and adds loads of new features for handling JavaScripts and Stylesheets and is fully compatible with core and all the related contributed modules. No more programming or working around Drupal for handling JavaScripts and Stylesheets.

Download this module from [here], and start using it right away :) don't forget to send feedbacks

So lets have a look at the supported features :

  • Full support for drupal_add_css and drupal_add_js parameters and even more!
    • Adding external files
    • Defining where to include it : header / footer
    • Adding inline css/js
    • Whether to display on all pages or not
    • Defining style/script group : theme / module / core
    • Weight (the order of adding to the page)
    • Supporting Defer parameter
    • Enable/Disable caching per style/script
    • Enable/Disable preprocessing
    • Enable/Disable using core
    • Adding attributes like id to stylesheet/javascript include tags
    • Support for IE conditional comments for both styles and scripts
    • Defining style media : print/all/screen
  • Manipulating existing styles/scripts
    • Creating a white-list or blacklist to decide which style/scripts should be added to the page
    • Possibility of replacing and overriding core and contributed modules styles and scripts using only the info file
  • Possibility of altering the scripts and styles (hook_js_alter and hook_css_alter support for Drupal 6)
  • Compatible with most of the style and a script manipulation modules
  • Adds theme_path variable to be used by template files and css_js_total_control_get_theme_path function

Some examples for demonstration : You can read the full document plus practical examples [here]

Replacing core jquery!

scripts-settings[filter][rules][0][function] = regular_expression
scripts-settings[filter][rules][0][pattern] = %misc/jquery|jquery_update%
scripts-settings[filter][type] = blacklist

scripts-extended[js/vendor/jquery.min.js][scope] = header
scripts-extended[js/vendor/jquery.min.js][weight] = 0
scripts-extended[js/vendor/jquery.min.js][group] = core

Adding an inline script at the bottom of the HTML!

scripts-extended[js/menu-effect.inline.js][scope] = footer
scripts-extended[js/menu-effect.inline.js][type] = inline

Adding a stylesheet only for IE 7

stylesheets-extended[css/font-awesome-ie7.min.css][condition-string] = if IE 7

Adding an id to a stylesheet's include html tag (usage is mostly for dynmically changing theme style via javascript)

stylesheets-extended[css/menu/styles/lblack.css][media] = all
stylesheets-extended[css/menu/styles/skins/lblack.css][attributes][id] = custom_menu

Moving an script before all the other scripts

scripts-extended[js/vendor/jquery.min.js][scope] = header
scripts-extended[js/vendor/jquery.min.js][weight] = 0
scripts-extended[js/vendor/jquery.min.js][group] = core

Adding an inline script at the bottom of the page, (prints the content of the file)

scripts-extended[js/menu-effect.inline.js][scope] = footer
scripts-extended[js/menu-effect.inline.js][type] = inline

Adds a javscript library. (Relied on libraries module's API to load it)

scripts-extended[easing][type] = library
scripts-extended[easing][version] = default

Add some settings to Drupal js variable, (we can use this settings later on in our custom js files)

scripts-extended[mythemename][type] = setting
scripts-extended[mythemename][setting][name] = special

Allowing only necessary stylesheets and removing the rest to prevent conflict with theme styles

stylesheets-settings[filter][rules][0][function] = regular_expression
stylesheets-settings[filter][rules][0][pattern] = %settings|admin|misc|jquery_update%
stylesheets-settings[filter][type] = whitelist

The END.

May 19 2013
May 19

In Drupal there are many different methods to turn long forms into multipage/multistep forms. The most known one is perhaps the great ctools module or even custom solutions using Drupal’s form API. However as you may agree with me none of these solutions are really that easy, specially when it comes to Ajax. Therefore many developers in Drupal community tried or still trying to find an even easier method. What I’m going to introduce to you is yet another magical method :).

Hopefully for content types (entity bundles) in Drupal we have Field Group module which can do lots of things including turning simple forms into multipage forms without a single line of code! However Field Group does not support Ajax and relies entirely on JavaScript.  It causes some very important limitation for advanced and complex forms. These forms usually have complex validations, fields on each page may require calculations based on fields from previous pages, or on some special cases it might be needed to have regular JavaScript less and Ajax less multipage form.

That would have been great if we could use the Field Group for all purposes, wouldn’t it? It was my idea for writing Field Group Ajaxified Multipage. Although the name of the module contains Ajax and Field Group, it works without Field Group module for custom forms and Ajax is also optional. I hope it makes life for you fellow developers easier J. Now let’s see how it works.

The first feature which enhances Field Group multipage feature just like Field Group module itself is extremely easy to use.

  • Setup your multipage field groups as usual for your entity/node
  • In your entity/node fields list , edit your multipage field group properties and check Ajaxify option
  • You can also enable only "Non JavaScript Multistep" option which does not require JavaScript to work. It's very useful for debugging purposes or very complex multistep forms. remember that the ajaxify should be disabled for this to work
  • Skip button : You can add skip button for any of the steps you like, simply clone the next button added by this module and change its title to t('Skip this step')

That’s it, but if you’re a developer you can do much more. The module adds several parameters to $form_state variable, you can use these parameters to decide what happens on the form considering the form step.

  • $form_state['field_group_ajaxified_multipage_enabled']
  • $form_state['field_group_ajaxified_multipage_group']

Here is a sample code :

function hook_form_alter(&$form, &$form_state, $form_id) {
  if (isset($form_state['field_group_ajaxified_multipage_enabled']))
  if ($form_state['field_group_ajaxified_multipage_enabled']) {
    $step = empty($form_state['storage']['field_group_ajaxified_multipage_step']) ? 1 : $form_state['storage']['field_group_ajaxified_multipage_step'];
    $page_group = $form_state['field_group_ajaxified_multipage_group'];

    //Best practive for accessing variables, it works even when this ajax grouping is disabled
    if (isset($form_state['values'])) {
      $values = $form_state['values'];
      if (isset($form_state['field_group_ajaxified_multipage_enabled']) && isset($form_state['storage']['all']['values'])) {
        $values = $form_state['storage']['all']['values'];

    if ($page_group['children'][$step-1] == 'group_two') {
      $form['actions']['skip'] = $form['actions']['next'];
      $form['actions']['skip']['#value'] = t('Skip this step');
      $form['actions']['skip']['#limit_validation_errors'] = array();

    if ($step == count($page_group['children'])) {

In some cases you may want to alter the form after this module, for those cases there is new hook introduced by this module to use, it's similar to hook_form_alter :

  • hook_field_group_ajaxified_multipage_form_alter();
  • hook_field_group_ajaxified_multipage_form_BASE_FORM_ID_alter();
  • hook_field_group_ajaxified_multipage_form_FORM_ID_alter();
 * Implementation of hook field_group_ajaxified_multipage_form
function mymodule_field_group_ajaxified_multipage_form_alter(&$form, &$form_state, $form_id) {

So what about custom forms? The only difference is that instead of using Field UI to define form pages, an special paramter in $form can be used for form array. Just like this :

function myform() {
    $form['#groups_custom'] = array (
      'group_measurements' => array(
        'group_name' => 'group_measurements',
        'label' => 'Measurements',
        'format_type' => 'multipage',
        'children' => array (
      'group_goal' => array(
        'group_name' => 'group_goal',
        'label' => 'Goal',
        'format_type' => 'multipage',
        'children' => array (
      'group_steps' => array(
        'group_name' => 'group_steps',
        'label' => 'Steps',
        'format_type' => 'multipage-group',
        'children' => array (
        'format_settings' => array (
          'label' => 'Steps',
          'instance_settings' => array (
            'ajaxify' => '1',
            'nonjs_multistep' => '0',
            'classes' => ' group-steps field-group-multipage-group',
            'page_header' => '3',
            'page_counter' => '1',
            'move_button' => '1',
            'move_additional' => '1',

And the last thing is, unfortunately due to a bug in Drupal core, this method does not work well for registration form (admin/people/create), however a patch is proposed that fixes the problem. If you're interested please join the issue and help in making it ready (RTBC)

#208790: Changing "Create new account" button text breaks admin/user/user/create form

Nov 19 2012
Nov 19

Drupal's highly granular permissions system allows site builders to control who can create, edit, and delete each type of content on the site. Third-party modules can add additional permissions to that mix as well, paving the way for extremely focused role-based permission setups. The interface for configuring all of those permissions, however, is more than a bit cumbersome. Thankfully, the Permissions Grid module offers a solution: a consolidated permissions page that only includes node and entity type specific options.

Screenshot of administration screen

Installing the module doesn't alter the operation of Drupal's standard permission forms. Rather, it adds an additional "Permissions Grid" page that exposes just node and entity related permissions. Because Drupal 7's entity system includes Taxonomy terms, Drupal Commerce products, Flag module flag types, and more. Because the permissions are organized by content and entity type rather than by name (the normal Permission screen's default), it's quite a bit simpler to set them up or skim them to review their current state.

Permissions Grid is a simple module, but if you're frustrated by the complexity of node type permissions, it's a quick and painless solution.

Nov 05 2012
Nov 05

How to Tidy URLs and Relative Links When Moving From Dev to Go-Live (for Drupal 6 and 7)

Few things are as annoying as building something that works perfectly when you create it, but fails when you take it out of the lab. That's how site owners can often feel when content editors create piles and piles of Drupal nodes full of relative URLs in images and links. They look fine on the site, but if the content is syndicated via RSS or Atom, sent out in an email, or otherwise repurposed in another location, the links break. Even worse, hand-made links and images entered while the site is under development can easily point to the outdated "beta" URL. Who can save the day? Pathologic module, that's who.

Pathologic module's configuration options

Pathologic is an input filter -- to install it, you drop the module into your Drupal site and add it to one of your text formats -- Full HTML and Filtered HTML, for example. Whenever content is posted in a format configured to use Pathologic, it will scan the content for URLs and tidy them up. Relative URLs like /node/1 get turned into absolute ones like http://example.com/node/1, URLs pointing to alternative versions of your site like dev.example.com are replaced with your public URL, and so on.

Pathologic can also standardize the protocol of links inside your site's content. If users edit content over a secure connection, for example, it's easy to mix links using the http:// and https:// protocols -- something that can lead to annoying warnings on some users' machines. For developers with exacting URL-correcting needs, it also supports custom URL modification hooks. Using those hooks, your site's custom fixes (replacing MP3 links with a URL on a different server, for example) can piggyback on Pathologic's configuration and logic.

Pathologic is an efficient workhorse of a module that solves an annoying problem efficiently. If you've run into problems with relative links and staging-server URLs breaking links and images on your RSS feeds, you owe it to yourself to check it out!

Oct 22 2012
Oct 22

Anyone who's ever talked shop about Search Engine Optimization has heard of meta tags. Those bits of extra data jammed in an HTML document's HEAD section provide search engines, browsers, and other software with important information about a document's contents, related links and media, and more. There are quite a few ways to jam meta tags into a Drupal site, and there are even APIs to set the contents of a page's meta tags yourself, if you're a module developer. Thankfully, you don't have to sling code thanks to the excellent Meta Tags module.

Screenshot of administration screen

Maintained by prolific Drupal developer Dave Reid, Meta Tags provides a centralized configuration screen where common meta tags can be edited sitewide, for specific types of pages, and even for pages belonging to specific entity bundles. Need one set of tags for photo galleries and another for user profile pages? No sweat. Meta Tags uses standard Drupal tokens to build the contents of its tags, and the configuration options themselves can be exported and saved in Feature modules for easier deployment.

Screenshot of advanced options

Third-party modules can add new meta tags to the mix, and add new types of URL paths that need to receive custom tags. The Panels Meta Tags and Views Meta Tags projects, for example, allow each view and panel to have custom, token-driven meta tags just like nodes, users, and so on. Meta Tags is already a popular solution to the thorny problem of sitewide meta tag customization -- check it out if you need more than Drupal core's auto-generated ones.

Oct 15 2012
Oct 15

Almost a year ago, Module Monday featured the Views Datasource module, a tool for exposing custom XML and JSON feeds from a Drupal site. It's a great tool, but what if you need something a bit more... human-readable? A .doc file, or a spreadsheet for example? That's where the similarly-named but differently-focused Views Data Export module comes in.

Screenshot of administration screen

Views Data Export provides a custom View display type optimized for producing downloadable files in a variety of formats. Need a Microsoft Excel file with a list of the latest 100 posts on your site? Looking for a Microsoft Word .doc file that collects the text of the site's top-rated articles? No problem. The module supports XLS, DOC, TXT, CVS, and XML exports with format-appropriate configure options for each one. In addition, it uses Drupal's batch processing system when it's asked to generate extremely large export files, rather than timing out or giving out-of-memory errors.

Screenshot of resulting change to site

Whether you're putting together reports, giving users an easy way to download product data sheets, or conducting a quick, ad-hoc audit of your site's content, Views Data Export is a handy tool to have around. Its batch processing support makes it more reliable on large sites, and its support for a variety of "day to day" file formats means you'll spend less time juggling your data and more time making use of it.

Oct 14 2012
Oct 14

When I was unable to post to Twitter from my blog tonight, I found a very new thread on drupal.org discussing the issue: the Twitter API changed again!

I am only using the Twitter module on Drupal 6 sites right n   ow, I took two of the fixes and combined them in a patch for the 6.x-3.0-beta9 version. Then MinhH submitted new code that only requires a change in one place.

here's my latest patch for the 6.x-3.0-beta9 version

since the Twitter API is constantly changing, and the module is not very stable, always read the thread carefully to make sure you are applying the latest patch! Others have cleaned up the code I added from MinhH, and created a patch for the 6.x-3.x-dev branch which makes sense (however I suspect that 6.x-3.0-beta9 may be ahead of the -dev branch, and it's not a branch provided in the project's Github). Anyway, Open Source rocks, Murray!

and because my Twitter RSS feed URL was also broken, I found this post


which provides an update to the URL format:


Oct 09 2012
Oct 09

With Drupal's custom content types, custom fields, and the addition of the popular Entity Reference module, site builders can whip up complex content models without a line of code. Editing those complex inter-related content types isn't always easy for content creators, though. The "Create a node, save it, then create its parent, then link the two" workflow is frustrating and error-prone. Fortunately, the Inline Entity Form module can help.

Screenshot of administration screen

Like many of the nifty Drupal tricks these days, Inline Entity Form is a custom field editing widget. On any content type with an Entity Reference field, choose it as the field's editing widget, and the rest is magic. When you create a new piece of content, you'll get the form to create the referenced entity on the same form. It works smoothly with multi-value fields, and can use a simple autocomplete picker to link existing entities if they already exist.

Screenshot of resulting change to site

The challenge of creating and populating complex nested content relationships has always been a tricky one in Drupal. Inline Entity Form was created by the Drupal Commerce team to simplify the management of complex product collections, and it solves the problem quite nicely.

Oct 01 2012
Oct 01

Setting up geo-location data on a Drupal site is startlingly straightforward these days: pop in Geofield or Geolocation module and start adding latitude and longitude data to your nodes. Once you have the data, setting up maps and other complex geographically-aware content listings is easy. Unfortunately, it's that "getting the data" part that can be thorny. If users are willing to type in exact street addresses or latitude/longitude pairs themselves, there are more than a few options. If you need to transform other kinds of data into useful location data, though, Geocoder might just do the trick.

Geocoder Google options

Geocoder provides as a custom field editing widget for several popular location storage fields (Geofield, Geolocation, and Location module). Rather than offering a custom input form, however, it lets the site administrator pick another field on the content type that contains some geographical information.

Are you creating nodes whose titles are city names? Tell Geocoder to send that title to Google's geocoding service and store the resulting data in the Geofield. Are your site's users uploading photos with location information from a camera phone? Tell Geocoder to use the image field as its source, and the location data will be extracted automatically. The actual location storage fields -- the ones that hold latitude and longitude values -- are kept hidden from users and editors entirely.

Geocoder EXIF data extraction

Geocoder supports an impressive array of encoding APIs and data extraction mechanisms, from uploaded .KML files to Mapquest-parsed street addresses. It's an excellent swiss army knife for sites that need user-entered geo data, and a great addition to any site builder's arsenal.

Sep 24 2012
Sep 24

Drupal's built-in support for generating RSS feeds has long been an easy selling point. Do you have content? If so, Drupal will generate a feed of it, easy-peasy! Unfortunately, that RSS support hasn't kept up with the flexibility of Drupal's FieldAPI. The RSS format supports extensions to handle data types like file attachments, location data, and so on. By default, though, Drupal, jams all of your custom field data into the body of the RSS feed as simple text. That's where RSS Field Formatters comes in.

Screenshot of administration screen

RSS Field Formatters is a collection of slick formatters for Date, Geo Location, User Reference, Taxonomy, File Upload, and Media fields. Just set up your content type with the fields you'd normally use -- then, for the content type's "RSS" build mode, select the RSS-specific formatters for the fields you'd like to appear in proper feed elements.

Screenshot of the RSS feed

The results aren't flashy, unless you're an XML aficionado, but the improvement is important. If you're using RSS your RSS feed to move content from one site to another, the properly-formatted data fields can be imported more efficiently. In addition, geolocation and media attachments can be parsed and presented to users by many news feed readers: it's always better to pass along the data in a format they can work with.

RSS Field Formatters is smooth, easy to set up, and does a great job of sprucing up your RSS feeds with complex data that would otherwise go to waste.

Sep 17 2012
Sep 17

Drupal's Form API allows developers to easily integrate complex validation code into the workflow of a user input form. Unfortunately, the actual feedback from that form validation code is often a bit clunky by modern web standards. Fill out a form, submit it, and wait for a new page to load: only then do you discover that your cat's zip code was required. Providing speedy, immediate feedback on the client side is commonplace on modern web sites; fortunately, the Clientside Validation module makes it easy to implement on Drupal sites as well.

Screenshot of administration screen

Clientside Validation serves as a wrapper around the existing jQuery Validate plugin. It allows site administrators to set up the basic parameters for the plugin's work, like when validation actions should be triggered, where they should be displayed, and so on. Most of the display options look a bit clunky out of the box, but with some CSS styling to position them (positioned next to an invalid field, hovering contemptuously above an incorrect Zip code, etc.) they can be made to fit most designs.

Once the module is activated, basic FormAPI validations (required fields, for example) appear instantly on the client side without the need to submit the form. Even better, the module integrates with a host of additional modules like FormAPI Validation, Field Validation, and WebForm Validation. Custom validation rules added by those modules can be handled on the client-side, as well.

Screenshot of resulting change to site

If you're trying to smooth the rough edges off of complex input forms, providing better validation cues is a great place to start. The Clientside Validation module does a great job of integrating a slick jQuery library with a pile of other validation-related modules. Give it a try!

Sep 10 2012
Sep 10

Drupal's Node Reference and Entity Reference fields do a lot of heavy lifting for complex sites with tangly content models. They allow one piece of content to point at another one, and those relationships can be leveraged when building Views of content, formatting individual piece of content for display, and so on. Unfortunately, when it comes time to display the output of a reference field, "Print the title of the referenced entity" is usually the only option. What if you want something else -- like its description, or the bio of its author? Sure, you could crack open a text editor, build a custom module, and write your own FieldAPI formatter plugin. Or, of course, install the Token Formatters module.

Screenshot of administration screen

With the module installed on your site, one subtle but important new addition appears: a "Token Formatter" for any FieldAPI node, user, or entity reference fields. Customizing the formatter's settings for a given field lets you use tokens to specify the text that will be printed and (optionally) the URL that the formatted output will link to. Want to print out a node along with the name of its author? Want to display a user reference with a link to the user's home page, instead of their Drupal user profile page? Just use the appropriate tokens, and the module does the rest.

Screenshot of resulting change to site

The only serious downside to the module is the difficulty of extracting complex field values (like formatted images) using the token system. While it's possible, the module is better suited for textual values and links. In addition, there's no token reference for site builders to look at when filling out the formatter's settings. Because there are so many tokens, it's a real challenge to guess the right ones. Token module provides a standalone page with just such a list, but if you're not familiar with it, this module's configuration screen can be a bit of a stumper. Those two issues aside, Token Formatters is a quick way of tweaking a reference field's output without writing any custom code.

Sep 03 2012
Sep 03

There comes a time in every Drupal site builder's life when a content type must redirect to another page. Perhaps your site contains a collection of links, and you'd like visitors to see the destination site itself rather than the node that describes it. Perhaps your site features small chunks of promotional content that point to other nodes, and shouldn't be treated as primary content themselves. Wouldn't it be handy to redirect to the destination content automatically when the promotional node is visited? It certainly would -- and that's precisely what the Field Redirection module delivers.

The heart of the module is a well-implemented field formatter. If you have a content type that uses a Link field, a Node or User reference field, or an Entity Reference field, you can assign it the Field Redirection formatter. When the node (or any other entity with fields using this module) is viewed, Field Redirection doesn't render the field as HTML -- instead, it redirects the user's browser to the referenced user profile page, node page, link URL, and so on.

Screenshot of Field Redirection configuration screen

Because Field Redirection sidesteps the normal FieldAPI behavior of 'Building HTML for Display,' there are important caveats. The formatter should only be used on the Full Content build mode for an entity. If it's used for teasers, RSS feeds, Search indexing, Views listings, or other modes where it could be unintentionally triggered, your site will be redirecting itself to new URLs instead of executing important code. That warning aside, the module is an elegant and easily customizable solution to a common problem. If you're building lightweight "linking" content types that point at other elements or other URLs, Field Redirection can make life quite a bit easier.

Aug 27 2012
Aug 27

One of the basic building blocks of a functioning publishing tool is the ability to view, edit, and preview content before it's published. In older versions of Drupal, that was an all-or-nothing affair: either you gave people the dangerously overpowered "Administer Content" permission, or you downloaded a comprehensive access control module and started building a custom permissions system of your own. In Drupal 7, it improved: roles can be given permission to view their own unpublished content, or given the ability to bypass all content access control, but it's still a bit clunky for a lot of very common use cases. Thankfully, there's the aptly-named View Unpublished module. It brings juuuuust enough control without requiring a complex permission matrix.

Screenshot of administration screen

Once you've installed View Unpublished, a set of new permissions becomes available. You can grant individual roles the ability to view other users' unpublished content on a per-content-type basis. With that one addition, it becomes much easier to build simple editorial dashboards that give editors or contributors limited access to other writers' work before publishing, or for all the members of a team to see what the site will look like once content goes live.

Normally, we'd include a screenshot of the module 'in action,' but the simplicity of the tool makes that a bit tough. When View Unpublished is working, most users don't see anything at all! There are a few limitations to the module's streamlined approach, of course. Permission to publish and unpublish content is still handled by other tools, and it's up to you or another site builder to construct a functional "dashboard" for unpublished content if it isn't already listed on the front page or another easy-to-find location. For quick and simple access permissions on limited publishing workflows, however, View Unpublished is a great tool.

Aug 20 2012
Aug 20

Managing user roles in Drupal is easy -- at least, technically easy. It's a bit trickier if you have a large user base and need to manage a steady stream of people requesting access to specific privileges, new roles, or additional responsibilities. If you're in that situation, get ready for some quality time with your email client, and set up a regular appointment with Drupal's User Management screen. Fortunately, the Apply For Role module can simplify the process.

Screenshot of Apply for Role management screen

With Apply For Role, users can visit a new tab on their user account page and request access to a new role on the site. The request is queued up for an administrator, who can review, approve, or deny requests from a central management page. Requests can also be deleted -- allowing the original user to re-submit their request later -- or denied, ensuring that they can't send in more requests for the same role.

Screenshot of Apply for Role configuration form

The module allows site builders to set up which roles can be applied for (to prevent users from getting a glimpse at roles they should never have access to), prevent or allow multiple simultaneous role requests, and so on. For site builders who want extra control, the module also provides full Views integration, as well as integration with Trigger module. You can easily build a custom administration screen to manage role applications, complete with notification emails.

There are a few noticeable gaps in Apply For Role's functionality. The application form that users fill out is spartan and lacks any explanatory text; giving administrators a way to add more help text to that page would go a long way. In addition, it would be great to customize the names of the roles that are presented to applicants. Most sites' roles are never shown to normal users, so they're often named for brevity rather than clarity. Both of those oversights can be remedied with some minor hook_form_alter() work in a custom module, but it would be great to see them integrated. Even without those wish-list items, Apply For Role is a slick solution to the problem of processing large numbers of permission-change requests. If your site's user management workflow is a good match, you should definitely check it out.

Aug 14 2012
Aug 14

Drupal's standard node options cover quite a bit of ground: content editors can control the publication date, author name, revision status, revision log message, "sticky" flag, published status, and front page promotion status of every piece of content! Of course, there's no way to give content editors access to just one of those options. If you want an editor to control the "published" flag but none of the others, you're out of luck. It's all or nothing, and the resulting array of checkboxes and form elements can easily overwhelm users who are new to Drupal. Unless, of course, you install the Override Node Options module...

Screenshot of administration screen

Setting up the module couldn't be simpler; a new set of permissions to control access to each of the standard node options, on a per-content-type basis. That means a site builder can give specific user roles access to a restricted content type's options without affecting the others. In addition, there's no need to bring out the sledgehammer option of Drupal's "Administer Nodes" permission for most content creators.

Screenshot of resulting change to site

While it's possible to achieve some of the same results using custom hook_form_alter() code, the full suite of node options requires quite a bit of special logic to override effectively. Override Node Options is a quick, simple solution to the problem, and it makes a great addition to a site builder's toolbox.

Aug 06 2012
Aug 06

The popular Features module is the current king of the hill when it comes to bundling up Content Types, Views, and other custom configuration data for reuse on Drupal projects. Sometimes, though, a Feature needs site-specific tweaks before it's ready for prime time. Changing the API keys for external web services like Google Analytics and Disqus, for example, can be done using those modules' native configuration screen. But if your Feature module is consolidating the configuration work, wouldn't it be great to consolidate the settings forms, too? That's where Configuration Builder comes in. It allows you to build custom Drupal settings screens that can be exported and stored in a standard Feature module.

Screenshot of the Config Builder in action

Creating a new configuration screen, or altering an existing one, is clean and simple. Site builders can choose what URL their config screen will live at, as well as what permission or role will be necessary to access it. Config Builder leverages the powerful but little-known Form Builder module for the meat and potatoes work of designing the config form itself. Drag and drop addition of new form elements and re-ordering of existing ones makes things fairly straightforward; if you've ever used the WebForm module, it's leveraging the same interface tools.

By default, the forms that you've created will simply save their settings like a standard Drupal system settings form. It's up to you to write code that does something with the values. However, if you manually set the names of the different form fields to match the names of existing settings fields on other Drupal configuration pages? Voila! Your custom configuration form will begin loading and editing the same values. This means that you can create consolidated configuration forms that control specific important settings, like the Site Name or the Google Analytics API Key, without forcing users to hop from one screen to the next.

Once that's done, the custom settings forms can be saved and exported into a Feature just like your content types, Views, or custom site variables. If you'd rather bypass all the importing and exporting, Configuration Builder can also output the form you've designed as a standard set of Drupal hook implementations that can be pasted into a custom module, with no outside dependencies.

Screenshot of a configuration builder screen, exported to code

Configuration Builder may be overkill for developers who are used to slinging around custom settings forms and are comfortable embedding them in Feature modules. For site builders who want to tide up their own features, or developers working on larger multi-site platforms that need cleanly encapsulated and overridable settings forms, this module could be just what the doctor ordered.

Aug 06 2012
Aug 06
Blog Drupal

Drupal has a very powerful image manipulation UI, so why write code when we can easily use that forany purpose?! The problem is we can't! The reason is image manipulation UI only accepts one argument which is the source image. All other parameters and options are static. For example if you want to put the source image behind a frame you can, but if you want to dynamically change frame's image you either have to make new preset/style for each different frame or write a custom special action.

Another example is rendering texts dynamically, you can pass any text you want to the image style and have it rendered without writing any custom action

I've written a new module image_style_argument  (Latest version is also attached) to address this limitation by letting you pass any argument to image module, parameters pass via query string and using them you can override any style parameters on the fly.

Although this solution works but it's only a workaround and we need proper implementation , i've opened-up a new issue for this feature, join in if you're interested : http://drupal.org/node/1715300

From Module's README.txt

//Use the following code to see the style's parameters
  $style = image_style_load('style_name');
//Use the following code override style parameters and generate image url (effects index numbers are actually their ids , so they will not change when you add/remove effects or even when you rearrange them) : 
  $style_override = array('effects' => array(
    9 => array ( //Overlay (watermark)
          'data' => array (
            'path' => 'public://my_frame.jpg'
  image_style_argument_url('style_name', 'public://myimage.jpg', $style_override);
//You can also use theme_image_style_argument() as an alternative to theme_image_style()
  theme_image_style_argument(array('data') => $style_override)
//By default it does not support image caching since Drupal bypasses caching whenever url has query string, to fix this problem and also shortening the url length you can define 
//your own special logic simply by implementing two hooks.
//- mymodule_image_style_argument_url_override(&$uri, &$url, &$style_name, &$path, &$data)
//- mymodule_image_style_argument_override(&$image_uri, &$derivative_uri, &$style, &$scheme)
Attachment Size image_style_argument.zip 26.5 KB
Jul 23 2012
Jul 23

Yes, yes -- Drupal's FieldAPI gives us powerful tools for modeling content, displaying it, and customizing the administrative interface for content editors. That's all well and good, but have you seen the markup that FieldAPI generates? Setting up custom content types may be a pleasure, but the tangle of deeply-nested DIV tags that results is anything but awesome. While it's possible to override that clunky markup in a custom theme, the new Fences module eliminates heavy field markup with just a few clicks.

Screenshot of Fences field options

Installing Fences results in one simple change: when you go to edit a field, you're given and opportunity to choose what sort of markup element should wrap a field's contents. Want one field's text to appear in an <h3> while another's shows up in a <cite>? No problem. If you want to change fields globally, you can also switch all of your fields to a smart, <div>-based default until you have time to manually tweak them all. The results are impressive:

Default Drupal node markup

<div class="field field-name-body field-type-text-with-summary field-label-hidden">
  <div class="field-items">
    <div class="field-item even" property="content:encoded">
      <p>Body text goes here!</p>
</div><div class="field field-name-field-announce-date field-type-datetime field-label-above">
  <div class="field-label">Announce Date:</div>
    <div class="field-items">
      <div class="field-item even">
        <span class="date-display-single">Monday, June 18, 2012</span>

Node markup with Fences module

<div class="field-body">
  <p>Body text goes here!</p>
</div><h3 class="field-label">Announce Date:</h3>
<div class="field-announce-date">
  <span class="date-display-single">Monday, June 18, 2012</span>

Impressed? I know that I am. There are a handful of missing features that would be handy, like adding a custom wrapper tag around a field in addition to controlling the field's own markup. As it stands, though, Fences is a great tool for simplifying markup and avoiding piles of theming grunt work.

Jul 09 2012
Jul 09

For Humans and Androids

Out of the box, Drupal includes many useful features that are helpful for sites where one person wears the developer, site builder, and content administrator hats all at the same time. However, some of these features could be considered dangerous when a broader group of individuals are administering a Drupal site. The Paranoia module aims to help keep your site secure by disabling places where PHP code might be executed or important data might be changed.

Installing Paranoia follows the usual steps for any other Drupal module; download to sites/all/modules, and enable it from the modules page. If the PHP module is enabled on your site, you will be warned that such content will now be "plain text" and should be audited.

PHP module and text filter is disabled

Other changes that the Paranoia module makes include:

  • Only letting user 1 (the site administrator) edit the user 1 account
  • Disabling using PHP for block visibility
  • Prevents disabling Paranoia without direct database access (or using Drush)

By default, Drupal 7 permissions tagged as being "restricted access" are prevented from accidentally being added to anonymous or authenticated users. As well, permissions exposed by other modules can be hidden entirely by implementing hook_paranoia_hide_permissions().

Paranoia is a great example of a short and simple module that gets the job done. If you're running a site where you're sharing administrative duties, consider installing it to increase your site's security.

Jul 02 2012
Jul 02

Thanks to the tireless efforts of Karen Stevenson, Drupal's Date and Calendar modules can be used to build slick agendas, calendars, to-do lists, and more. One client of ours, for example, has set up a handy view of upcoming faculty trips and outings for their university. Unfortunately, one of the most useful calendar applications can remain elusive: sending users an email when something is about to happen. That's where the Node Announce module comes in. It can use date fields on a node as cues to send out email to specified addresses -- notifying authors when their nodes will be published, attendees when events are about to occur, and so on.

Screenshot of administration screen

Setting up the module is relatively simple. Each "announcement" you set up can be associated with one content type, and one Date field attached to that content type. On that date -- or a certain number of days before it, a canned email can be fired off to the address of your choice. When combined with Drupal 7's dynamic tokens, you can also create emails that include content from the nodes themselves or other site data.

Screenshot of resulting email

It's possible to wire up similar systems (and more flexible ones) using tools like Rules or custom code. In addition, it would be great if the the module supported more flexible date options: for example, sending out messages based on the publication or creation date of a node, or the "scheduled publishing" date added by Scheduler module. Those requests aside, Node Announce is straightforward module with an active maintainer and a useful feature list.

Jun 25 2012
Jun 25

Out of the box, Drupal provides highly granular permissions for administration and user tasks like creating content types, posting comments, viewing user profiles, and much more. With hundreds of discrete permissions to control out of the box, it's hard to believe that there are some things administrators can't control by default. Shocking, though, it's true: quite a few of Drupal's built-in administrative pages fall under the umbrella "Administer Site Configuration" permission. If you're looking for more granular access control, you'll need to write a custom module and cosy up to the hook_menu_alter() function... or download the Custom Permissions module.

Screenshot of custom permissions administration screen

As one might expect from its name, Custom Permissions doesn't hard-code an explicit list of permissions when it's enabled. Instead, it provides a settings screen where administrators can enter the paths individual pages (or groups of pages) that they want to limit access to. You can enter the name of the permission, a list of paths (including wildcards if you'd like to control a path and all of its sub-pages), and... that's it! Once you've configured your list of permissions and the paths they control, the permission names appear on the normal Drupal permissions administration page.

Screenshot of resulting change to site

Custom Permissions is a simple, streamlined module that does what it says on the tin. While it's possible to use hook_menu_alter() in your own custom module to accomplish the same goal, it's another option to eliminate custom code with minimal overhead.

Jun 18 2012
Jun 18

Drupal's user account system may not be flashy, but it gets the job done. User logins, email notifications, secure password resets... It covers all the basics, and third-party modules like Mollom can even add CAPTCHAs during account creation. What happens, though, if you want to add a bit of extra security to the user login process and the critical "password reset" function? That's where Security Questions comes in. It adds user-selectable security questions to each user account, and uses them to provide an additional layer of authentication.

Screenshot of administration screen

Setting up Security Questions is pretty simple. It comes pre-populated with a list of a dozen or so standard security questions like "Mother's maiden name" and "Your first pet." Administrators can choose how many security questions a user has to choose and fill out when creating their account. In addition, administrators can choose when the security questions are used. You can require that users answer their security questions when resetting their account password, for example, or go all-out and require that they answer at least one of them every time they log in. It even supports an optional "remember me" checkbox: when that feature is turned on, users only have to answer their security questions every n days or weeks, rather than every time they log in.

Screenshot of the user's edit form

They may not be the flashiest feature on a web site, but simple tools like good security questions can help keep user accounts secure. The Security Questions module makes adding and tweaking the operation of them extremely simple; if you're considering adding them to your site, check it out!

Jun 11 2012
Jun 11

Drupal's comment module gracefully handles anonymous posters when they want to leave messages. Administrators can choose whether those comments are left unattributed, whether anonymous commenters must leave personal information like a name and an email address, and so on. When it comes to full-fledged Node content, though, Drupal's a lot less flexible: the authors of anonymously written posts show up as "Anonymous," and you'd better like it. Fortunately, fixing that problem is the purpose of the Anonymous Posting module!

Screenshot of admin page

Setting up the module is painless; just visit its settings page, choose which content types should use its expanded Anonymous Posting options, and double-check to make sure anonymous users have permissions to create those content types. Once you've done that, a special set of options will appear on that content type's settings form. They're the same options that normally apply to comments, transplanted into the world of nodes.

Once you've set it up, usage is a no-brainer. Authenticated users will be able to create nodes just as they did before, but anonymous users preparing to author a post will see a Comment-module style list of personal information fields. Name, email, and home page are all supported. The result? Easy anonymous posting, complete with "Unverified" next to the author's name to prevent visitors from impersonating registered users of the site.

Screenshot of an anonymously authored node

Anonymous Posting is available for Drupal 6 and 7. It's simple, streamlined, and because it still relies on Drupal's normal content authoring permissions it doesn't complicate the site permissions and security unnecessarily. Considering the potential for abuse of anonymous content creation, it's probably a good idea to combine this module with an anti-spam tool or a content moderation system.

May 28 2012
May 28

Drupal's content modeling tools are unmatched in the open source CMS world: CCK and Drupal 7's FieldAPI give site builders a remarkable amount of control over every content type, its fields and properties, and how they're edited and displayed. Except, that is, for the Title field. Some content types, like links to other web sites or quotations, don't lend themselves to catchy titles; displaying the primary content underneath an additional title can sometimes dull the impact of the node's the primary information. That's where the Exclude Node Title module comes in.

Screenshot of administration screen

Once the module is enabled, it adds a centralized settings form that allows you to configure each content type on the site. For each one, you can choose whether to hide or show the title, which display modes should keep it hidden, and whether the display option should be controlled on a node-by-node basis by the author of each piece of content. When the affected nodes appear in listings like the front page or standard Views, voila: no node titles!

Screenshot of resulting change to site

If you've ever performed this trick yourself using theme preprocessing hooks, you'll recognize what's going on: Exclude Node Title module module is just removing the 'title' element from the rendered output of a node, and when it hits the node HTML template, there's nothing to print. The difference, of course, is that using a dedicated module allows you to drive the behavior entirely using configuration settings, rather than custom code in your theme or a site-specific module.

The only hitch I could find is that the option to hide a node's title on the edit form doesn't seem to work. The title is hidden on teasers, full node views, and more -- but the Title field stubbornly appears on the edit form itself. If you want to make sure your nodes have some kind of title for administration screens, the Auto Node Title module would make a good companion. It can hide the Title field and populate it with a default value.

May 21 2012
May 21

Fixing unserialize() woes

Ever run into errors like the following on your Drupal sites?

Notice: unserialize() [function.unserialize]: Error at offset 74 of 75 bytes in variable_initialize() (line 749 of /srv/www/<sitename>/includes/bootstrap.inc).

This is a symptom of an invalid variable in the {variables} table. When the Drupal cache is cleared (or variable_set() is called), Drupal queries the variable table for all site settings and saves them in your cache for quick access. If you're getting errors like the above, odds are your variable table contains a corrupted or unserialized value.

So now that you know what the problem is, how do you solve it? For larger sites there can be hundreds, if not thousands of variables in the {variables} table. Finding the broken value can be time consuming and difficult.

Once the Variable Check module is installed, a new report is added to the Reports section in the site administration.

Invalid Variables administration screen

As we can see, Variable Check is correctly identifying an invalid string length, an unserialized value, and a missing quote from a string value.

Variable Check also adds an entry to the site status report, alerting site administrators if any invalid variables are ever added to the site. Note that Variable Check will only find variables that fail to unserialize; it can't detect variables that are syntactically correct but logically incorrect (such as a string that a module expects to be an array, or a TRUE that should be FALSE for your site).

Once a broken variable has been identified, the variable can be deleted in the user interface or with drush vdel. Or, drush can be used to correctly reset variables.

$ drush vset site_name "Kitten Emporium"

May 07 2012
May 07

It's the little details about a web site that make you smile when you're finished building it: the subtle CSS effects, the way it intelligently pre-populates forms for you, the great organization of a complex content model, and the just-so text copy that makes things feel "right." That's why little details can be annoying, too. Take, for example, the names of multi-value FieldAPI fields on a Drupal content type. You can label a field 'Photos,' for example, but what if an editor only enters one? Somewhere, a copyeditor is grinding their molars over that one, but a convenient little Drupal module can save the day: Field Label Plurals.

Screenshot of administration screen

Setting up the module is, as one might expect, pretty straightforward: turn it on, then visit an existing FieldAPI field configuration screen. You'll see a new option just below the field's normal Label: a Single-Value label. Set up both labels to match the proper pluralization rules, and the module handles the rest.

Screenshot of resulting change to site

When a multi-value field is displayed to a site visitor, the label will change intelligently based on how many values have been added to the content item. There is a hitch, of course: in some languages, there are multiple "plural forms" of a given word rather than just one. If you plan to translate your site into one of those languages (like Arabic and Polish), this module won't be able to account for all of those forms. If you're comfortable sticking with a boring old language like English, though, Field Label Plurals can definitely add an extra bit of verbal polish.

Apr 30 2012
Apr 30

In a perfect world, every Drupal module would come with online documentation and support Earl Miles' Advanced Help module for in-depth instructions. In that same perfect world, ever site builder and administrator would read the INSTALL.txt and README.txt files that ship with complex modules before trying to install them. Alas, neither of those dreams is likely to become a reality anytime soon. In the meantime, there's Module Instructions -- a simple one-trick-pony that puts the contents of Readme and Install files right on Drupal's module administration page.

Module Instructions additions to the module administration form

There's not much to say about the interface: when you visit the module administration page, Module Instructions scans each module's directory, hunting for install or readme files. if it finds them, it adds links to that module's line on the administration form. It's simple, it's effective, and while it isn't of much use on a production web site, it's a great tool to have when you're experimenting with new modules or sorting out the installed modules for an in-progress site. (The editor of Module Monday, for example, feels the acute pain of installing dozens of modules for testing purposes. Anything that consolidates their documentation is a good thing...)

Module instructions displayed inside of an Overlay window

If you're a developer interested in customizing Drupal 7's module administration form, Module Instructions is also a useful example of how to alter and bend that notoriously complex administration page. It doesn't interfere with the normal documentation or configuration links used by Drupal core, and plays nicely with other administration-page tweaks like Module Filter.

Apr 23 2012
Apr 23

Building a 'Frequently Asked Questions' page in Drupal is simple -- once you've picked the approach you want to take. Give content editors a simple 'Page' node, and hope for the best? Drop in a pre-fabricated 'FAQ' module and configure it? Add a 'FAQ Entry' content type and build a view to list them? All have been done, and all can work -- but now there's one more way to tackle the problem... FAQ Field module.

FAQ Field administration screen

Like most FieldAPI based tools, configuring the module is simple. Just add a 'FAQ Field' to the content type of your choice, and remember to specify 'Unlimited Values' for the field. When editing nodes of that content type, content creators will be able to add any number of FAQ entries, each with its own 'Question' and 'Answer' text. The module also ships with a handful of custom formatters to display the FAQ information. The simplest lists each FAQ as a header and paragraph; the 'Accordion' style displays questions, expanding each one to display the answer when it's clicked.

Screenshot of FAQ fields in action

Should you use the FAQ Field module? If your site has a single, simple FAQ page it's probably overkill. If you need to display FAQ-style documents in numerous places (for example, maintaining one for each product in a site's catalog), this module's approach really shines. Check it out, and consider adding it to your site-building toolbox!

Apr 17 2012
Apr 17

Oh, scrolling multi-select form elements. Does anyone really like them? Picking multiple items from one of these widgets often requires option-control-alt-clicking your way through a long list, hoping you don't accidentally deselect the options you've carefully chosen. Drupal's default Select Widget allows you to use convenient dropdown select menus to choose the contents of single-value fields, but if you have a multi-value field, you're out of luck. Wouldn't it be great to give content editors a list of several single-select dropdowns, rather than the unruly multi-select box? It would, and that's precisely what the Multi Selects module does.

Screenshot of Multiple Selects being added

Like many cool Drupal 7 tricks, Multiple Selects is a field editing widget that can be used with multi-value list fields like Text and number lists, as well as taxonomy term references. No configuration is necessary -- just set the field's widget to "Multiple Selects," and you're ready to go. Rather than a single scrolling multi-select box, content editors will see single-select dropdowns, with the traditional FieldAPI 'Add another item' button below.

Screenshot of Multiple Selects in action

In addition to providing a slightly cleaner editing interface, this approach allows editors to choose the order in which their field values appear. Adding five taxonomy terms and then dragging them into the correct order is impossible with a multi-select box, but works fine once Multiple Selects is enabled. The only downside is that it doesn't support node, user, or entity reference fields yet. That addition is a minor change, though, and a patch to add it has already been posted. If you're looking for a simple multi-value select widget that also gives your editors control over the order of the values entered, look no farther than the Multiple Selects module.



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