Good use of icons on a website can really lift its overall design. Of course, you can't just slap them on and expect a site to look brilliant. It's all about choosing the right type of icons to match the design.

Once your designer has chosen a font library like Font Awesome, or made their own, what is the best way of displaying them in Drupal? The quick and simple way is to get the designer to style them using CSS but this is not flexible.

What if an editor wants to choose which icon is displayed in a menu? If you've added them to the menu manually via CSS then the editor won't have the ability to change the icon in the future.

The Icon API module integrates common icon bundles like Font Awesome, Bootstrap and more within Drupal. The module offers integration with a suite of sub-modules. For example, if you want to add icons to menus then install the icon_menu module.

In this tutorial, we'll configure Icon API to allow an editor to add icons to menus and directly into content. We'll do this using the Font Awesome icon bundle.

If you've ever had to migrate a client from WordPress to Drupal, one of the first things they'll ask for is how to add shortcodes in Drupal.

Shortcodes in WordPress are macros that you can drop into content and have it render an object. For example, if you want to embed a gallery in WordPress you simply add [gallery id="123" size="medium"] into the content and when a post is displayed a gallery is rendered.

Implementing similar functionality in Drupal is very easy thanks to the Shortcode module. The module is not an exact copy of the Shortcode API but implements very similar functionality. If your clients are use to shortcodes in WordPress then they'll feel right at home using them in Drupal.

In this tutorial, you'll learn how to configure and use the Shortcode module in Drupal.

Now, you may be thinking to yourself, can't Token do this? The short answer is yes. You can implement similar functionality using Token Filter. The module implements a custom filter which can be added to text formats. If you add [site:name] into the body, it'll render the site name.

Frequently asked questions, or FAQ for short, are fairly common on websites these days. A good FAQ page can help in reducing the number of support requests for basic questions. Whenever I need help on a website, the first thing I look for is the FAQ page before I contact them.

In Drupal, a FAQ page can be created in a few ways. First, you could write the HTML and anchor tags by hand or you could use a module like FAQ Field.

The FAQ Field module comes with a custom field called "FAQ Field" which you can add to any type of entity. It also has a few handy formatters to display the FAQ.

I should also mention that you can use the FAQ module to create these pages. The biggest difference is that the FAQ module has its own content type, whereas, the FAQ Field is based around a field. This is useful for creating FAQs on a Product content type.

In this tutorial, you'll learn how to setup and use the FAQ Field module. We'll add the field to the "Basic page" content type that comes with the standard installation of Drupal.

The "Long text and summary" field has a pretty handy formatter called "Summary or trimmed". This will display a summary, if one is supplied, or Drupal will simply trim the text and display it.

The problem with this formatter is that you can't trim the summary. For example, if an editor adds three paragraphs into the summary section, then the whole summary is shown. But sometimes you may need control over how much of the summary is displayed. This is especially true if your design requires the teaser to have a consistent height.

What's the best way of offering a summary to your editors that also trims it? Enter Smart Trim.

The Smart Trim module is an improved version of the "Summary or Trimmed" formatter and a whole lot more. It does a lot of useful stuff, but the one we want to discuss is the ability to trim summaries.

Out of the box, Drupal offers only a single type of validation for fields; required or not required. For most use cases this is fine, however, it can be a little difficult to define your own custom validation logic. What if you need to validate a field value and make sure it's unique?

The Field validation module allows you to define custom validation rules using Drupal's administration interface. The module ships with a lot of its own validators: "Plain text", "Specific value(s)" and much more.

If none of the validators meet your requirement, you can write your own by implementing a validator plugin. Because validators are Ctools plugin, they are easy to maintain as each one gets its own file.

In this tutorial, we'll use Field validation to validate a field value and make sure it's unique.

Implementing breadcrumbs in Drupal can be difficult depending on your requirements. Drupal out of the box will generate a breadcrumb based off the menu structure, however, things start to get a little tricky when you want to modify breadcrumbs.

There are a lot of modules that allow you to control breadcrumbs in their own unique way. To name a few you have Crumbs, Custom Breadcrumbs and more.

The module that I've had the most success with is the Path Breadcrumbs. This module offers great flexibility with an easy to use interface. Path Breadcrumbs' configuration can also be exported using Features which is another huge win.

Machine names are all over the place in Drupal 7. When you create a content type or field it will appear next to the label. The concept of a machine name is simple. It's an alphanumeric value which shouldn't change once created and it must be unique.

A custom machine name can be implemented in two ways: as a field or form element. If you're creating a form you can implement one using machine_name form element. On content types, you can use the Machine name field.

In this tutorial, you'll learn how to setup and use the machine name field on an article content type.

Display Suite is one of the essential modules which I use on every project. It allows you to change the look and feel of entity bundles, i.e., content types, vocabularies, users and much more. Building custom layouts and adding fields is a breeze, but there's another feature you may not be aware of and that's custom field templates. Display Suite allows you to change the markup which is used to render individual fields.

The functionality to change field templates is off by default. To turn it on, you'll need to enable the "Display Suite Extras" sub-module and check the "Field Templates" on the Extras page.

In this tutorial, you'll learn how to enable "Field Templates" and how to use them.

Search API has been my go-to module for building search pages for the last two years. Even if the client doesn't ask for anything fancy, I still download and install Search API, use Database Search for the index and Views for the page.

If you start with Search API from the beginning, then it's easier to customise later on. The core Search module, on the other hand, is easy to setup but hard to modify.

Recently, I had to create a search page that highlighted the keywords in the results. If you search using a particular keyword, then the word is highlighted.

View modes allow site builders to display the same piece of content in various ways. Drupal ships with a bunch of them out of the box like Teaser, "Full content", RSS and much more. There is even one for the search result page called "Search result". However, the two most prominent are Teaser and "Full content".

The "Full content" view mode is the one used to display content on its "node/123" page. It's the one you'll customise the most. Teaser, on the other hand, is used to display a summarised or trimmed down version of an article.

You can create as many view modes as necessary. But like many things in Drupal, they can be created in a few ways. They can be implemented using code and with a module or two.

In this tutorial, you'll learn how to create view modes in three ways: using hook_entity_info_alter(), using Display Suite and Entity view modes.