User roles are one of the things that is usually dealt with only while developing the website from scratch or when adding new features. Since standardization is the key to consistent results and more streamlined development process, you should have some sort of a strategy when it comes to user roles.

The most potent Drupal module for creating very complex layouts is definitely Panels. It integrates with a lot of other parts of your Drupal site, so you can show views, nodes, webforms, blocks, and pretty much anything else you can think of. Page builder is very easy to use and allows administrators visual representation of complex pages.

Drupal's permissions system is at the same time easy to use and very powerful. It covers most of the cases where your module provides different functionality for various roles on the site.

In both versions of Drupal this is fairly straightforward to implement through code. There are two parts to this article: defining custom permissions (both static and dynamic), and performing checks to see if the current user has access to them.

When building more complex queries using db_select() you will often want to see the exact SQL being generated. This is helpful for understanding the query or simply debugging the results.

This article will show you how to see the exact query being generated with db_select() as well as getting how to get all values passed as arguments. The code in this article will be applicable for both Drupal 7 and Drupal 8.

Every website that displays user information on the front end will use profile fields such as first and last names for representing the members. By default Drupal shows only the username, which is definitely something you will want to change.

Modifying this is relatively simple. You could always choose which fields to use in Views, Rules and other modules, but the main problem is maintenance - the setup will be spread across many different pages and it's not the most optimal solution in the long run.

The right way is to change the way user display names are formatted by the system itself. This article will show you how to manage this for both Drupal 7 and Drupal 8 in your custom code.

One of the "late to the party" features of Drupal 8 is the ability to assign the same block to multiple locations in the theme. Drupal 7 still lacks this feature in the core, but it's easy to achieve it by using a contributed module such as MultiBlock.

Drupal.org encourages developers to host all of their Drupal-related Open Source code directly on Drupal.org. This is great, because all your OS code will be associated with your account and you will get a lot of extra features such as issue tracking, release publishing, ability to reference other issues and so on. However, current interface of DrupalCore.org website is not the most user friendly, especially when you want to have a quick look at the code of a contrib module.

That's where platforms such as Github, Gitlab, BitBucket and others can be helpful.

In certain odd cases you will find yourself needing to clean a string so you can use it in a URL. Even though writing such helper function is not hard, you will soon find out that there are edge cases in which maintaining your own code does not make much sense, such as filtering out and converting non-alphanumeric characters. That's where Pathauto module comes in.

Defaults shipped with Drupal Commerce should work fine for most stores. However, exactly because of this, some of the details can be annoying and unnecessary for a specific project. The way currencies are formatted is one of those things.

In many cases the Body field in Drupal's content types can be completely unnecessary. The best examples would be nodes used for sliders, galleries, panels and more complex types where textarea field has no place.