Upgrade Your Drupal Skills

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

See Advanced Courses NAH, I know Enough
Nov 27 2020
Nov 27

Drupal is being chosen as a platform for building websites, among other things, due to its flexibility. If you want a system ideally suited to your business model and better than the competition's systems, Drupal will prove to be perfect. One of the areas you can customise in Drupal is the user permissions system. Take a few minutes to learn about the permission management abilities of Drupal.

General information

Drupal allows you to manage access from the admin panel and from the code level. In this post, I will present these two possibilities and the most common examples of their use.

Roles and permissions in the Drupal core

If this is your first time dealing with Drupal and its permission system, you should know that there are three elements used for granting permissions:

  1. User
  2. Role
  3. Permission

When installing Drupal, you create a root administrator account in the system (identifier 1 in the database). It can be compared to the root user in Unix systems. This user has access to all subpages and settings in the system.

You can add more users to the system. These could be, e.g. the editors responsible for creating the content, or the moderators deciding whether to post the added comments.

If you want to assign a permission to a given user, you do it indirectly by assigning a role to them. There is no association between a user and permissions in Drupal. There is a user-role association and a role-permission association.


How to add an editor role and assign the appropriate permissions to it

This is probably the most common issue encountered in Drupal. You need to let users into your system, but you want to limit their rights to the content management only. You do not want to give the rights to change the system configuration or to add new users.

In order to achieve this, follow these steps:

  1. Add a new role on the page "/admin/people/roles/add/".
  2. Assign the selected permissions to the role on the page "/admin/people/permissions/". For the content-related ones, check out the "Node" section. Below you can find more information on the permission list.
  3. Assign the selected user to the new role on the page "/admin/people/".

Then log-in into the account of the selected user and check out whether they have the appropriate permissions. Maybe you need to extend them or take them away. If you are unfamiliar with the Drupal's permission system, such a test with logging-in into the user account is always worth carrying out.

You do not need to know the password to the user account you want to log-in into. You just need to install the module Masquerade. Thanks to it, you can log-in into the account of any user.

Drupal core permissions overview

When entering the page "/admin/people/permissions/" for the first time, one can get a little scared. This is probably the longest configuration page in Drupal.

Let us start with the table header. You will always see the word "PERMISSION" in the first column. In the next cells of the first row, there will be the names of the roles. The more roles you add (you can add them on the page /admin/people/roles/add/), the more of them you will see in this table.

Then, looking at the first column in its entirety, you will see a long list of permissions. The permissions are divided into sections. The sections are the names of modules. The "Node" section mentioned earlier is named so because the permissions in this section are defined in the "node" module (you will find it on your disk in the core/modules/node directory).

Some sections have only one permission, e.g. the "Block" section has the "Administer blocks" permission only. Others have many more of them.

If this is your first time dealing with Drupal permission settings, I suggest that you read the names of all permissions. The names themselves explain what a given permission is for.

Anonymous & Authenticated

There are two system roles in Drupal that cannot be removed:

  1. Anonymous User
  2. Authenticated User

The first of these roles is responsible for all non-logged-in users. For example: if you want to add the ability to view user profiles for all non-logged-in for the "View user information" permission, tick the checkbox in the "Anonymous User" column.

"Authenticated User" is the role assigned to all logged-in users. It is important here to understand the permission inheritance. If you assign a permission to "Authenticated User", then all other roles (except anonymous) will be given this permission immediately.

Example: You have the "Editor" role in the system. You assign the "View user information" permission to the "Authenticated User" role. Everyone with the "Editor" role will also be given the permission because they are also considered to be logged-in users.

Moreover, keep in mind that if you select any permission for the Anonymous role (e.g. "View user information" again), but do not select it for the "Authenticated User", the logged-in users will not be able to access the selected section ("View user information" – they will not have access to user profiles).

Worth remembering

  • In Drupal, you can add an unlimited number of roles.
  • The list of permissions is defined by modules in modulename.permissions.yml files (more on this can be found further in the text). 
  • The "Authenticated" and "Anonymous" roles are separate – if you select something for "Anonymous" only, the logged-in users will not be given this permission.
  • To test permissions, it is good to use the Masquerade module.

Own permissions in the code

Sometimes there is a need to define your own permissions, e.g. to administration pages defined by new modules or to modify access to the pages defined by the Drupal core.

How to define a permission

You just need to add the modulename.permissions.yml file in the new module (or in the existing one, if you already have your own modules created). If you do not know how to create your own modules, I encourage you to visit the website.

The permission file is a file in the YML format. A simple example can be found in the Popup Message module, right here.


Being defined in the file is a unique name for the permission (e.g. "popup message administration"), and then – the names being displayed on the page "/admin/people/permissions/". You can provide a title in the "title" parameter and additionally – a more detailed description in the "description" parameter.

This is enough to define new permissions. After creating the file and clearing the cache, you will see the new permissions on the "/admin/people/permissions/" page.

How to use a permission

Most often, permissions are being used when defining routing. Take a look at the file.

In the "requirements" section, you can add the "permission" parameter. In this way, you can define the users (or rather roles) with what permission can display the page defined in routing.

The second method is to check out the permissions in your code. User object in Drupal has the "hasPermission" method. In this way, you can check out whether a given user has the selected permission.

// Get the current user
$user = \Drupal::currentUser();
// Check for permission
if ($user->hasPermission('display popup message')) {
// Do something.

It is worth to take a look at the hasPermission method here. As you can see, the user ID is being checked there. If the id equals 1, the user gets access without further checking if they have selected roles.

How to check whether the user has a role

Drupal also offers a ready-made method to check whether a given user has a role with a specific name. Provided below is an example of how you can do it in the code.

// Get the current user
$user = \Drupal::currentUser();
// Check for permission
if ($user->hasRole('editor')) {
// Do something.

Additionally, there are also methods related to the Authenticated and Anonymous roles:

  • $user-> isAuthenticated();
  • $user-> isAnonymous();

How to check permissions for operations on an entity

In the application code, you can also check the permissions to operate on selected entities (e.g. Node or User). You can perform certain operations, e.g. depending on whether the user has the right to edit a given entity or to display an entity.

Entities in Drupal have the method access($operation = 'view', AccountInterface $account = NULL, $return_as_object = FALSE). A simple example of use is provided below:

$nid = 545;
$node = \Drupal\node\Entity\Node::load($nid);
$user = \Drupal::currentUser();
if ($node->access('edit', $user)) {
// Do something

Defining content permissions

Drupal allows you to manage access to display and edit at the level of a single entry (node). This topic was thoroughly described in our other blog post. Grzegorz Pietrzak described it in the article Drupal Node grants.

Ready-made modules for Drupal related to permissions

There are already many ready-made modules extending the capabilities of the Drupal core. You should check them out before you start writing your own permission-related modules.

Below is a list of a few selected modules that are worth checking out and testing:

Also, check the page and take a look at other modules. Maybe some of them you will find useful.


Drupal is a very flexible system. Just looking at the possibilities regarding permissions, you can see the multitude of configuration possibilities. If you are building a large website with many editor levels or an internal application (e.g. an intranet system) where the users must have limited permissions, Drupal will do the job very well.

If you need support from Drupal specialists on permissions or other issues, use the services of our Drupal developers.

Oct 28 2020
Oct 28

A Drupal multisite is an installation which allows us to use one codebase to serve multiple websites. In this post, I will explain in detail how Drupal multisite works, what approaches can be taken to set up a multisite installation. I will also explain some of the settings that may be important for a multisite which are not applicable when we build just one website on Drupal.

The basics of a default Drupal multisite

A Drupal website comprises a few major things:

  1. Drupal core
  2. Contrib and custom modules
  3. Theme
  4. Database
  5. Configuration

When a request from the browser is handled by Drupal, one of the first things Drupal does is bootstrapping the database and loading configuration. From the database and configuration the system knows:

  • which from the available modules and themes are enabled,
  • how everything is set up:
    • where are public and private files folders,
    • which blocks are where,
    • what content is available,
    • what is on the front page,
    • which menus are in which regions, what links are in which menus, 
    • pretty much everything else about how the website is configured. 

To connect to the database, Drupal reads the connection information which is held in the settings.php file (which typically sits in /sites/default folder).

Notice the default folder. It is called default because it is a fallback folder when no other folders are found. In a single Drupal install, typically no other folders are set up and most websites are run from the default folder.

In a multisite installation, however, we set up separate folders for separate websites.

For example:

  • /sites/example-one.com
  • /sites/example-two.com

If we create such folders, a new request will examine the base domain (base URL as Drupal calls it) and will try to match it to the correct folder. The order is as follows:

When a request with a base URL of www.example-one.com comes in, Drupal checks if there is:

  1. A folder named /sites/www.example-one.com and looks for settings.php there.
  2. If there is not, Drupal will check a higher-order domain folder - /sites/example-one.com in this case. 
  3. If it does not find settings.php there, it will move to the /sites/default.

We achieved a multisite - many websites on one codebase

If we have 2 folders for 2 different domains, we can have 2 separate settings.php files which connect Drupal to two separate databases, which load separate configurations and use various enabled modules and themes.

In essence, we end up with 2 different websites, which have their own databases, content, files and configurations, even though they sit on one Drupal code.

If we add additional folders, we get additional websites without the need to duplicate code.

Drupal can run hundreds of websites from one installation like this.

Sites.php file helps to map domains for folders

To help with the mappings of base URLs to folders, Drupal offers a sites.php file which can be used to assign base URLs to correct folders.

In the /sites/ folder we are offered a file which is called example.sites.php. Change its name to sites.php and Drupal will use it. The configuration of mappings is quite simple:

$sites['an-old-domain-to-map.coom'] = 'example-one.com;

This file allows us to map several domains to one website if we need to and helps a lot with development because development environments typically have different URLs than production ones.

$sites['localhost.example'] = 'example.com';

Some dev teams use this feature also to keep the sites folder clearer when there are hundreds of websites with various domains sometimes in foreign languages. The dev team can have short clear folder names.

'] = 'brand-x-fr;

This is also sometimes useful if the domain for one of the websites changes.

Which website can use which modules

Typically, we are used to a situation where

  • all modules are placed in the modules directory (or sites/all/modules in Drupal 7 and previous versions),
  • all themes are placed in the themes directory (or sites/all/themes in Drupal 7 and previous versions).

If we have one website on the system, there is no need for any other configuration. We add only the modules we need.

In a multisite installation, however, there might be a need to specify which websites can use which modules or themes. In a large system with hundreds of websites and administrators, such restrictions might be crucial to only allow such functionalities on each website which work well together.

We can control this in 2 ways:

1. Via installation profiles

Each website on Drupal is built on an installation profile. Typically this is the standard or minimal profile which is shipped by Drupal out of the box. You chose between these when you install Drupal and you can see them in the /core/profiles folder. None of these 2 profiles has any modules or themes but a profile can provide these.

Drupal for example ships with a demo_umami profile which is a demo profile and includes both: a demo_umami_content module and an umami theme. If you install a standard installation, you will not have access to the umami theme from the admin panel for example.

If you have to control which websites have access to which themes or modules you place these in your custom installation profiles. Only the websites installed on a particular installation profile will be able to access and use what it provides.

What is cool is that profiles allow for inheritance. You can, for example, create one profile with drupal commerce modules and then 2 additional child profiles which will then be able to access the Drupal commerce modules.

While performing Drupal services for our clients we have implemented various scenarios with different levels of granularity. You could even create a child profile for each website to be able to have very granular control. This might however be a bit of an overkill.

2. Per website modules via the website folder

Modules and themes can be also added to the website folder. In our example, we could put them into:

  • sites/example-one.com/modules
  • sites/example-one.com/themes

Modules and themes placed in these directories will only be available to website example-one.com.

As a rule of thumb, you should probably avoid having too many modules here since it probably goes against the concept of a multisite to have completely different code for each website, but sometimes there is a need to add a few per-website tweaks or create for each a subtheme for a website which overrides a few things in a shared base theme.

Updating code once, running update 100 times

One of the great things about a multisite is reduced maintenance. If you have 100 websites on one system and a new version of Drupal comes out, you only have to update the code once instead of 100 times.

That said, remember that settings and databases are separate for all 100 websites. You do have to run the update.php script for each one separately!


Above I explained in detail how Drupal multisite works under the hood. In essence, it is a very simple and yet a powerful feature of Drupal which allows companies to reduce maintenance and technical debt and keep maintainers sane if they have to maintain many websites.

Oct 23 2020
Oct 23

Nowadays we have social media everywhere, so having the ability to share content on your website is essential.

By default Drupal doesn’t provide social media sharing buttons out of the box. However, when delivering Drupal services, we use modules that can help with this. The most popular solution is the AddToAny module.

AddToAny module provides a huge number of share buttons including the universal (‘+’), Facebook, Twitter, Pinterest, Reddit and many more.

And popular AddToAny features list is also impressive:

  • Floating share bars for mobile, desktop, and various site layouts; 
  • Image share buttons to share your images; 
  • Share counts and share count recovery;
  • Google Analytics integration; 
  • Vector sharing icons made for mobile, Retina and high-PPI displays; 
  • Universal sharing button and smart menu; 
  • Visitor personalization; 
  • International support (i18n/localization); 
  • Accessibility and graceful degradation; 
  • Cross-browser and backward compatibility; 
  • Optimized performance and efficient loading via world-class CDNs; 
  • Complete control for publishers & developers of all sizes


The first version of the module was released on 15 April 2008, the latest update - 15 may 2020.

The module can be installed on:

  • Drupal 7 (7.x-4.16 stable release version); 
  • Drupal 8 (8.x-1.14 stable release version);
  • Since 8.x-1.13+ it supports Drupal 9 as well.

All stable releases for this project are covered by the security advisory policy.

Module popularity

According to the statistical data from the module's page, it is currently used by about 47.000 websites.

Module creators

The module is created and maintained by the only person - micropat (see his profile).

What is the module used for?

It is a highly customizable module, allowing to share content probably to any social media. It has a very friendly and excellent documentation with many examples.


To install AddToAny go to the webpage or do it via composer:

composer require drupal/addtoany

Configure placement

By default, share buttons are disabled and placed in Manage display section of each content type, e.g. Structure > Content types > Blog post > Manage display. Be sure it is enabled before we continue.

add2any placement

Configure AddToAny

To configure AddToAny options, go to Administration > Configuration > Web services > AddToAny.

addtoany config

Let's go through each section briefly.

Buttons section

buttons config

AddToAny uses SVG sharing icons that can be scaled to any size, the default value is 32x32 pixels. You can customize the share buttons by editing the "Service Buttons HTML Code" box. More details can be found in the official documentation, where you will find the additional feature examples, such as:

  • Share event handling & modifying; 
  • Templates & endpoint parameters; 
  • Link tracking & URL shorteners; 
  • Custom color buttons; 
  • Image share buttons; 
  • Share counters; 
  • Share count recovery; 
  • etc. 

Here are a few examples.

Like buttons:

like buttons

Share counts buttons:

counters buttons

Under the universal button section you can also customize the + button or even remove it:

no plus button

Additional Options section

Here you can add some custom JS or CSS code for AddToAny with no need to do it programmatically.

additional options section

As an option, you can for example set a custom color to perfectly match any design's color scheme. Just add the following JS code to your "Additional JavaScript" box on the Configuration page.

 a2a_config.icon_color = "#0166ff"; 

 buttons js adjusment

Entities section

In this section you can toggle the content entities where AddToAny will be available to interact with.

entities config section

Once the AddToAny Share Buttons module is installed and enabled, a few sharing buttons will appear on your page. Let’s check out how they look.

page with buttons

By default we have a “+” icon (called the “Universal Button”), next Facebook share is there, as well as Twitter, and email. Clicking the “Universal Button” you will see all available share buttons for other services.

expanded services

And here is an example of Twitter sharing popup. When a visitor clicks one of the buttons, a pre-populated post pops up.

twitter popup

Let’s dive into the documentation and see if we can adjust the template.

Voila, you can change the default message, by adding the following JavaScript code:

var a2a_config = a2a_config || {};
a2a_config.templates = a2a_config.templates || {};
a2a_config.templates.twitter = {
    text: "Reading: ${title} ${link} by me",
    hashtags: "sharing,social"

Hook & Templates

If you think that standard settings is not enough, you can try extending the addtoany-standard.html.twig template.

The default theme implementation to standard AddToAny buttons includes the following variables:

  • addtoany_html: HTML for AddToAny buttons;
  • button_image: URL for universal button;
  • button_setting: Setting of button;
  • button_size: Size of buttons;
  • universal_button_placement: Value of 'before' or 'after' to place button;
  • link_url: Value of URL to share;
  • link_title: Value of page title to share.

There is also one hook, allowing you to programmatically alter the entity types that the AddToAny pseudo-field is available for:

 * @param array $types
 *   The entity types.
function hook_addtoany_entity_types_alter(&$types) {
  // Add the "taxonomy_term" entity type.
  $types[] = 'taxonomy_term';

Alternative solutions

There are a few other options that you might want to investigate. Here is the list:

Has less settings options and services. According to the description this module delivers the most clean solution without making a lot of external calls, having tracker scripts, or even connecting to ad servers.


Now you have all the necessary information on how to add social links to your Drupal site on the example of the AddToAny module. However, if you want to know more about how to most effectively use this module for your website, please contact our Drupal consultants. Once you have installed this module, you will get a very customizable platform with many fine features, which makes your content easy to share.

Oct 02 2020
Oct 02

The Views Bulk Operations module is used when performing bulk operations on results to tables or other items created with Views. In this example, I will show you how to add your own action that will change the state (Workflows) of selected entries.


The action is performed on all selected entries and automatically performed in Batch queues so as not to overload the system and not to "crash" the page when the process takes too long. If you know what you are doing and you have reasons for it, you can turn off the queuing option in the field configuration.

VBO installation and configuration

The Views Bulk Operations module can be installed by downloading and unpacking the package in the modules/contrib directory or by using the composer command, which will download the latest stable version of the module.

composer require drupal/views_bulk_operations

After installation, the module does not need to be configured in any way, you just add the appropriate field to the page (or block) created by the Views module.

  • Add a new Content view that creates the page.
  • Set the display format to Table. It is not necessary, the checkboxes on the table simply look more natural
  • Add the title field
  • Add the Views bulk operations field


Action configuration for a VBO field

In the field configuration, you can mark which mass actions can be performed on the results. There are over a dozen predefined actions, such as:

  • deleting entries
  • publishing
  • sticking


The above list is compatible when the view displays Content. If you add the view that displays Users, you will notice that the list has different actions.

Adding own action to VBO

The goal is to add your own actions on entries (Content) that will change the state (Workflows) of the selected entries.

Entry states are not available immediately after Drupal installation. In order to do this, you need to enable two additional modules that are directly in Drupal, you do not need to additionally download anything.

Go to the page with modules - admin/modules

Enable the modules: Workflows and Content moderation


Workflows configuration

For the purposes of this post, I will use automatically-defined states for the Editorial type, which is available immediately after enabling the Content moderation module.

All you need to do is enable a given type of state transition for the selected content types.

  • On the page admin/config/workflow/workflows edit the Editorial type
  • Set the Article content type


This operation will add a new field to every add/edit article form.


To the view where the VBO field is, add

  • a field displaying the state of a given entry - Content: Moderation state
  • a filter that will limit the display of entries of the Article type

If added is a filter restricting entries to published only Content: Published (= Yes) then remove it. It will block the display of entries that have a state of e.g. Draftor Archived, which are not being published by definition.

Own action code

Create your own module end enable it. In my case, the module's name is d_workflows

In the module's directory create a directory structuresrc/Plugin/Action

Create in it a new class file for the action to change the state of the entry into Published.

Filename: PublishNodeAction.php

 * Content moderation publish node.
 * @Action(
 *   id = "d_workflows_publish_node_action",
 *   label = @Translation("Publish node (moderation_state)"),
 *   type = "node",
 *   confirm = TRUE
 * )

class PublishNodeAction extends ViewsBulkOperationsActionBase {

Class annotation is important here.

You set in it an id for the action – this can be any unique value. It is worth to include in its name the name of the module and what the given action is doing.

Label is the value that will appear in the VBO field configuration

Type is the type of entity, for which the new action will be available. In this case, it is node, but it can be, for example, user, taxonomy_term, or any other.

This class inherits from ViewsBulkOperationsActionBase

It requires declaring two methods:

  • execute() - what is to be executed for each record
  • access() - who can perform the action

Example of a code for the execute() method

 * {@inheritdoc}
public function execute(ContentEntityInterface $entity = NULL) {
  if (!$state = $entity->get('moderation_state')->getString()) {
    return $this->t(':title  - can\'t change state',
        ':title' => $entity->getTitle(),

  switch ($state) {
    case 'archived':
    case 'draft':
      $entity->set('moderation_state', 'published');

  return $this->t(':title state changed to :state',
      ':title' => $entity->getTitle(),
      ':state' => $entity->get('moderation_state')->getString(),

The first condition checks whether the given entity has the state setting option enabled.

In this case it is only Article. When the action is initiated on entries with no states enabled (empty $entity->get('moderation_state')->getString()) it will be interrupted and an information about it will be displayed.

The condition can be easily extended by e.g. checking the content type for the entity


Further down the code, the current status of the entry is being checked and if the condition is met, the code changes its status into Published.

$entity->set('moderation_state', 'published');

Example of a code for the access() method

   * {@inheritdoc}
  public function access($object, AccountInterface $account = NULL, $return_as_object = FALSE) {
    if ($object instanceof Node) {
      $can_update = $object->access('update', $account, TRUE);
      $can_edit = $object->access('edit', $account, TRUE);

      return $can_edit->andIf($can_update)->isAllowed();

    return FALSE;

In this simple condition, it is being checked whether you are operating on Node type objects and whether the user performing the action has the authorisation to edit and update it. Otherwise, the code will return a FALSE, and the action will not be executed.

The whole PublishNodeAction.php file looks like this:

get('moderation_state')->getString()) {
      return $this->t(':title  - can\'t change state',
          ':title' => $entity->getTitle(),

    switch ($state) {
      case 'archived':
      case 'draft':
        $entity->set('moderation_state', 'published');

    return $this->t(':title state changed to :state',
        ':title' => $entity->getTitle(),
        ':state' => $entity->get('moderation_state')->getString(),

   * {@inheritdoc}
  public function access($object, AccountInterface $account = NULL, $return_as_object = FALSE) {
    if ($object instanceof Node) {
      $can_update = $object->access('update', $account, TRUE);
      $can_edit = $object->access('edit', $account, TRUE);

      return $can_edit->andIf($can_update)->isAllowed();

    return FALSE;

A new action will be available in the VBO field edit



Experienced Drupal developers as well as Drupal consultants ensure that adding new actions to Views Bulk Operations is simple and comes down to creating an additional class with two methods. Based on this simple example, you can build more complex mass actions on entities of various types.

Oct 01 2020
Oct 01

Creating groups of users with access to selected content is one of the frequent requirements set out in specifications for web portals. The Group module allows saving hundreds of programming hours by providing ready-made and easily extensible mechanisms. Check how many useful functions you can find in this module.

Group was created as an alternative to Organic Groups (OG), in which relationship mechanisms are based on fields and content. Created in the group module, on the other hand, were full-fledged entities with their own fields that can be extended and exported. Every group can have its own users or uniquely configured permissions.


The origins of the module date back to the Drupal 7 version, for which the first dev version was released in 2010. The Drupal 8 version of the module was first released in March 2016 and is still being developed today. The latest stable version 1.2. was released on 4 August 2020.

Module's popularity

The Group module is quite popular and is currently used by over 9,000 websites. The vast majority, about 8,200, are projects based on Drupal 8.

Module's creators

The main keeper of the module is Kristiaan Van den Eynde (kristiaanvandeneynde), responsible for almost 900 commits to the module. The module is financially supported by Factorial GmbH and has been supported by other companies and organisations in the past. Of course, the development of the module and its sub-modules is also supported by a large crowd of Drupal developers.

So far, 56 developers have contributed to the development of the module; the full list can be found here: https://www.drupal.org/node/711148/committers

What is the module used for?

The Group module solves a problem that cannot be solved in Drupal with the help of built-in mechanisms. It allows you to divide users into groups within which you can both manage user rights and create content dedicated only to the group members.

It is an extremely complex project from the programming point of view. It has several classes and functions that provide key functionalities like permission support, cache, or integration with Drupal's core modules. There is a gnode sub-module in the module's repository that allows you to create relationships between content and groups. The Group module can also be extended with the functionality of creating subgroups, and this is possible with the use of Subgroup or Subgroup (Graph) modules.

Examples of using it:

  • classroom management at schools, where teachers function as administrators, students are members of a given group, and they all have access to common materials,
  • access to paid content by limiting the accessibility of materials for group members (an example can be found in our article Drupal Commerce - Sell electronic products)
  • portals for organisations/communities with a hierarchical structure (several co-dependent units, but with different members and administrators)
  • organisation and management of conferences (registration for lectures, access to materials, discussions). Group is therefore a great tool when you need to create closed user groups with access to specific content.

The Group is therefore a great tool that we use as part of Drupal services to create closed groups of users with access to specific content.


You can download the module at https://www.drupal.org/project/group

After installation, a new group will appear in the Groups (/admin/group) menu between the Configuration and Users tabs in the main system menu.

Group provides a new type of entity, so in the submenu, you will find links to pages such as group types or list. It also has a configuration page, where it is possible to set an administration skin for group-editing, group users pages, etc.

The Group module does not require any specific configuration to be able to use it.

Module's use

In order to create groups, you must first define at least one group type. To do this, go to "/admin/group/types" and create a new group type. This process is similar to creating a new content type or a vocabulary, but also has additional configuration fields related to the permissions of users in given groups.

create groupe type

After creating the group type, you can configure the group fields, as well as the associated form and group display views.


In order to define the rights, you also have the option of going to the Permissions tab, under which you can define basic permissions broken down into:

  • anonymous users,
  • group members,
  • users not being group members 
  • group members with a defined role in the group

Available is also an advanced configuration of the permissions of a user from outside the group with the use of system roles.


It is possible to define roles for a given group type (similarly to the roles defined in the Drupal's core). It is possible to do it in the Roles tab:


One of the most important tabs is Content, where you can install available extensions for a group, and these include content types, group membership or subgroups (after installing the previously mentioned modules).

content 0

After going through all the forms, creating new groups of as given type becomes very simple. You just go to the group list page (/admin/group) and add the groups you need.


As you can see, there are quite a lot of configuration options, especially regarding module permissions. However, they are necessary for its proper operation and it is easy to appreciate their advantages during the use of the module. You can find a very interesting application of the Group module in the Open Social distribution.

Hooks and integrations

The module has the ability to modify links with entity operations embedded in a block on the group's website using the hook_group_operations_alter hook, which in its arguments accepts a table of links and a group object.

Group provides integration with the following modules:

  • Views, offering plug-ins such as: access, argument, default argument, relationship.
  • Tokens - 21 tokens for group and its contents.


The Group module is very mature and programmatically complex. It adds a mechanism for creating groups and their related content that you cannot find in a clean CMS Drupal installation. It was written with due care for the high quality of the code, while at the same time ensuring its easy extension with new functionalities. If this module fits the needs of your project, our Drupal consultants recommend to use it without hesitation.

Jul 18 2018
Jul 18

Droptica helps clients from all over the world to complete and implement their projects. Each of these clients has already developed their way of working. Everyone is different. In this article, I have collected the most common ways and systems of cooperation between Droptica and our clients.

Why do we work a little differently with every client?

We are Agile. We always want to maximise the results of our work. Our development team always adjusts and adapts their way of working to the client’s needs.
The elements that are adapted and changed the most often include:

  • project implementation methods (SCRUM, Kanban, etc.);
  • number of people in the team;
  • roles in the team (backend developers, frontend developers, QA, UX/UI, etc.);
  • the method of communication; Tools: JIRA, Slack, telephone or video calls, meetings;
  • frequency of communications;
  • communication channels (who, with whom);
  • implementation standards (some clients consider application performance to be the most important, others focus on implementing and providing new functionalities on a regular basis, while another group focuses on aesthetics and want their application to look good).

On the basis of these factors, I have identified several models of cooperation with clients, which are used the most often at Droptica.

Model 1: Product Owner at the client, with the rest of the team at Droptica

This is probably the most popular model employed at Droptica. We use it mainly when the end client comes to us. In most cases, the client already has a web system based on Drupal, Symfony or React and needs developers to develop the system further. Product Owner has a vision of application development and looks for a team that can efficiently perform the envisioned tasks.

In this model, we have a great impact on the development of the system. Our team not only performs assigned programming tasks but also proposes directions of development of the system and suggests improvements. In addition to developing basic functionalities, we also design user interfaces (UX/UI) and often carry out A/B tests that show us the best solutions for the client.

We use this model to develop WydawnictwoWAM.pl website. This is what the client has to say about us and about working in this model: 

"We established cooperation with Droptica around two years ago to develop our online store available at http://www.wydawnictwowam.pl. Both the quality of all the works carried out, as well as our cooperation were stellar. The technical solutions suggested and implemented by Droptica were a great help and often improved the value of our system, often exceeding our initial expectations. Cooperation with Droptica is characterised by very friendly, direct and precise communication on their part. Thanks to that, we were – and constantly are – able to define and detail all the tasks related to the development of our sales platform. We also appreciate their very clear settlement system, which allows us to better plan and allocate funds for development. In other words, we definitely recommend working with Droptica".

Model 2: Product Owner, QA, PM on the client’s side, software developers provided by Droptica

In this model, we provide our customers with solid development support. Most of the project planning and management process is carried out by the client, while our experts carry out specific development tasks.
It is a kind of cooperation that we usually go for with large companies and corporations, expanding their Drupal, PHP and ReactJS teams.
As a rule, in such a model we work on servers and project management systems provided by the client. We adapt to their processes.

Mixed models

Other models are usually combinations of the two models presented above. For example, Droptica provides not only development team but also testers, while the entire project is managed by the client. We also sometimes work on projects where we collaborate with other software developers from the client's company, working not as an independent development team, but a part of a larger team.

We are Agile

We are flexible regarding the form of cooperation with our clients; however, we like the first model the most. In that model, we take on a great deal of responsibility for the project and we are able to influence the direction of development together with the client. This gives us great satisfaction, and we offer numerous ideas for improving the system, which allows our clients to better achieve their business goals.

Would you like to learn more about our work models? Contact us at [email protected] and we'll be happy to talk to you.


Jun 13 2018
Jun 13

The deadline is today. A remote development team have worked for several weeks on your software. You obtain the long-awaited access to the system. You check it and you are not satisfied with the achieved results.

All that was needed to avoid this problem is a team with experience in technology and working using SCRUM.

What is SCRUM

Wikipedia defines SCRUM as an agile framework for managing work. It is an approach used in many companies to develop software. The full definition can be found here https://en.wikipedia.org/wiki/Scrum

SCRUM solves most of the problems arising during software development

This is my opinion and many people agree with it. I have been developing commercial projects since 2008. I started as a programmer. Currently, I am supervising projects.

In Droptica, Drupal developers work in teams delivering complex projects. Introduction of the SCRUM method in Droptica solved most of the problems. Which ones exactly?
Here are the most important of them:

  • The client was not regularly informed about the progress of works – the client was not satisfied. Sprints, review, backlog refinement – all this compels a constant contact with the client
  • The tasks were not thought through before starting them, therefore they took a long time to finish – the client was not satisfied. Backlog refinement and planning – these events ensure that the team has to really ponder on completing each task.

SCRUM saves money

You can ask yourself: how is that possible if you do not know the exact duration and cost of the project at its beginning? The answer can be found in the previous paragraph:

  • Regular meetings with the client (Product Owner) force them to think about which tasks are actually needed and which can be rejected.
  • Analysis of tasks by the team together with the PO, often allows to come up with better ways to implement or reject them.

SCRUM is often called the art of maximising work not done. You maximise the rejection of the tasks that are unnecessary from the point of view of your business. You do only the things that bring particular value to the system. Everything else goes straight to the waste bin.

Why so many meetings?

Planning the sprint, daily scrum, retro, review, backlog refinement. The list of meetings is long. There is no doubt that they take time. The client often expects to pay for programming, not for conversations and meetings.

I used to think the same way. However, after a test implementation of SCRUM in one of the projects, I have changed my mind. Now I want to develop all our projects – for clients and internal – using SCRUM. I see that it saves great amount of time and money. The same can be confirmed by the clients with whom we now work using SCRUM, while we did not have a specific way of working before.

Abraham Lincoln once said, "If I had eight hours to chop down a tree, I'd spend six sharpening my ax."

The meetings guarantee a good rethinking of tasks, sticking to a common direction and pursuing the same business goals. It is definitely worth it.

How long will it take and how much will it cost?

Every client asks this question at the beginning. It is not easy to answer it. The pace of each programmer is different, there are different working conditions, holidays, leaves, the requirements change (from the client, legal requirements, etc.). A longer project also means a frequently changing specification. Such changes change the cost and time.

Story Points is a solution to the problem. It is a very good tool for estimating the number of tasks that can be performed in a sprint (stage). After just 2-4 sprints you can see the team's average pace. After such a time the team knows the project well, knows the client well and plans for the future. The team can very accurately estimate the tasks waiting in the Backlog. Product Owner, knowing the pace of the team can count the number of sprints and the total cost.

Compared to creating a detailed specification at the beginning of the project, such an approach gives better estimation results.

SCRUM is not enough if the team does not have the experience with the technology

If the team will work using SCRUM, but will not be familiar with the technology, it will not be able to provide good quality software within a reasonable time. Only the combination of SCRUM and the team experienced in using the given technology ensures significant effects. The customer will definitely be satisfied with such a combination.

Why a remote team is better?

What is the difference between a remote team and a local team? Actually – just their location. If you can have a local team, it is worth choosing this option. It will be more convenient.

However, in today's IT market it is difficult to complete a team of 2, 3 or more specialists in a short time for a larger project. That is why you should think about a remote SCRUM team. A team that already has the experience in working with a remote client. By expanding the options to the whole world, you have more choices.

How can I monitor what a team thousands of miles away is doing? 

SCRUM has a way to do it: Sprint Burndown Chart. It is a chart that is updated daily. It shows the regular peace of project development. It shows whether the team implements the sprint plan. It is the best tool for monitoring the progress of works. Using Waterfall, you usually find out about delays at the end of a larger stage. With SCRUM, the client can check every day what progress the team has made. They can be sure that the team works and delivers consecutive parts of the software.

How to communicate with the team?

At Droptica we have 3 ways to do that:
- Jira - it is the main communication system; here we have all User Stories and tasks
- Slack - for short text questions, used practically every day
- Skype/Google Hangouts/Zoom - for video calls with screen sharing

These three forms of communication in 100% ensure very good communication between the team and the Product Owner.

If possible, once in a while, the development team meets with the Product Owner at our office or in the client's office. Our offices are located close to the airport, we eagerly invite our clients to visit them.

How can I check if a remote SCRUM team will work in my case?

If you have a project for a minimum of 2-3 people for a few sprints, a well-conducted SCRUM will provide you with very good results.

If you are not sure if SCRUM will work for you, test it. Order 2-3 sprints and see what results you will get. It is a small cost within the scale of projects taking several months, and such an approach will provide an unambiguous answer to the question of whether it is worth using SCRUM.

If you still have doubts about a remote SCRUM team, I will be happy to answer your questions and share my experiences. Contact me at [email protected] or write your question in the comment.

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