Drupal Planet

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.

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.

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.

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.

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.

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).

• 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.

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.

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.

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.

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.

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.

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

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

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:

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.

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:

• Block Content Permissions
• Block Region Permissions
• Menu Admin per Menu
• Override Node Options
• Menu Item Role Access
• Protected Pages
• Administer Users by Role
• Custom Permissions
• Vocabulary Permissions Per Role
• Disable user 1 edit

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.

We just launched a new free demo on try.dxpr.com that lets you test drive the DXPR Drupal experience. Thanks to our 60+ new demo pages you will be guided to explore the many exciting elements and features that are offered in our DXPR Builder and DXPR Builder Enterprise modules for Drupal 9.

The new demo takes it to the next level: our demo site is based on Acquia Lightning and shows you the extent of Drupal integration of our front-end layout building application. Learn how our state-of-the-art visual authoring experience seamlessly integrates with Drupal’s multilingual features, workflow processes, and views.

Today we release a new minor version update for both our Drupal 7 and Drupal 9 branches of DXPR Builder. Most notably we now have improved native support for media entities in DXPR Builder.

Whether you are on Acquia Lightning or a completely custom Drupal 9 platform, if you upload or re-use images in the DXPR Builder editor our software will automatically detect if your site supports media entities or just file entities, and create media entities when this is supported.

The DXPR team is working hard to bring our products up to date with Bootstrap 4. This is a large migration for us since our Drupal layout builder is based on and built around Bootstrap 3.

We aim to have a release out that takes full advantage of Bootstrap 4's new features. We will also be able to improve the layout building experience by taking advantage of CSS flexbox technology, which is fully supported in Bootstrap 4.

The Drupal project uses the PEAR Archive_Tar library. The PEAR Archive_Tar library has released a security update that impacts Drupal. For more information please see:

• CVE-2020-28948
• CVE-2020-28949

Multiple vulnerabilities are possible if Drupal is configured to allow .tar, .tar.gz, .bz2 or .tlz file uploads and processes them.

To mitigate this issue, prevent untrusted users from uploading .tar, .tar.gz, .bz2 or .tlz files.

This is a different issue than SA-CORE-2019-12, similar configuration changes may mitigate the problem until you are able to patch.

Install the latest version:

• If you are using Drupal 9.0, update to Drupal 9.0.9
• If you are using Drupal 8.9, update to Drupal 8.9.10
• If you are using Drupal 8.8 or earlier, update to Drupal 8.8.12
• If you are using Drupal 7, update to Drupal 7.75

Versions of Drupal 8 prior to 8.8.x are end-of-life and do not receive security coverage.

According to the regular security release window schedule, November 25th would not typically be a core security window. However, this release is necessary because there are known exploits for one of core's dependencies and some configurations of Drupal are vulnerable.

• Luke Stewart

• Jess of the Drupal Security Team
• Drew Webber of the Drupal Security Team
• Michael Hess of the Drupal Security Team
• Neil Drumm of the Drupal Security Team
• Lee Rowlands of the Drupal Security Team

In my first blog post, I introduced the Custom Elements module: A solution for soft-decoupled Drupal! Following that, I want to put more emphasize on the frontend side of the stack in this blog post:

With the backend producing custom elements markup, we need a frontend framework that is able to work with that. While there are many frameworks that play nice with custom elements, we want to pick a well-established solution with a large user base. That way, it's more likely that the framework stays relevant and well maintained on the long term. Also, finding more integrated libraries, learning materials or developers knowing the framework becomes much easier.

According to The State of JavaScript 2019: Front End Frameworks the top 3 frameworks developers have used are React, Vue.js and Angular:

• Angular has been not liked much by developers that used it and won't be used again by the majority of them (see survey). Besides that, it's provided as a whole MVC framework with lots of things potentially not needed here. So not the best fit.

• React has a very strong user base, but does not play that well with custom elements. While there are solutions like react-slot, they are not as common and well maintained. Finally, personally I don't like the "Everything is Javascript" approach so much.

• Vue.js on the other hand, comes with template parsing built-in that is able to render custom elements data easily. Like React, it utilizes a virtual DOM and is well adopted and continuously growing. Finally, the Vue.js single file components are following a template based, web-standard oriented approach.

• Since web components build upon custom elements, they seem to be the perfect fit. However, they are not, since they are not well adopted and server-side rendering web components is not a well solved issue (yet?).

Thus, Vue.js turns out to be the ideal candidate for our decoupled Drupal stack built upon custom elements. Moreover, I like it for the following:

• It's approachable and easy to use. It has great documentation and sticks to web standard oriented notations.

• It comes with a set of incrementable adoptable companion libraries for further needs, like routing or state management.

• It's fast! It only weighs 20kB gzipped and scores well in rendering benchmarks.

• Just like Drupal, it's a community backed open-source project, not depending on a single large corporation. Check out the Vue.js team and its sponsors.

Once one decides for Vue.js, one quickly stumbles over Nuxt.js - the intuitive Vue framework. It comes with a set of useful conventions - inspirated by Next.js - that make it very easy and enjoyable to get started with development. It provides all necessary setup for Javascript transpilation, CSS processing and improves performance by handling route-based automatic code-spliting or link prefetching. Thankfully, it's following Vue.js principles, thus it emphasizes the ease of use and provides great documentation.

Finally, it's built upon a powerful, modular architecture and allows providing features as re-usable Nuxt.js modules - what makes it a great addition to Drupal. While the number of modules is nowhere comparable to Drupal, there are many useful modules available, like PWA generation, Google Analytics or Tag manager integration, or the usual frontend/CSS framework integrations with Bootstrap, Material UI or Tailwind CSS. Check out the module directory at modules.nuxtjs.org for more.

One of the nice features of Nuxt.js is that it's really easy to deploy your project using various ways, all from the same code-base - just by a different deployment configuration. The options are:

• Static generation
  Generate a static site and leverage the Jamstack approach for dynamic functionality and content previews.

• Server Side Rendering
  Render the markup using a Node.js server or Serverless functions.

• Single Page Application

  Just serve a pre-built Javascript application to users and let the user's browser take over rendering.

That way, one can choose the best suiting deployment target per project. Small sites without a large number of pages could be very easily statically generated and benefit from fast, cheap and secure hosting; e.g. via providers like Netlify, Amazon S3 or Github pages. If SEO is not required, running as a Single Page application does away the need for re-building after content changes and allows for highly dynamic, user-specific content and app-like UIs.

More demanding projects, requiring SEO and having a large number of content, can use server side rendering with any Node.js compatible hosting provider like Platform.sh or Heroku. Alternative options would be specialized hosting providers like Vercel, AWS amplify or deploying via the Serverless framework to various serverless cloud providers.

Finally, I'd like to mention we also developed a custom, more advanced approach that becomes possible with custom elements markup: The lupus-frontproxy is a small PHP-based script that serves content as custom element markup combined with a pre-generated app shell (site header and footer). That way, large, content-heavy sites can easily run without a node.js server driving the frontend, while still providing decent SEO based upon the custom element markup delivered (Google just ignores custom elements and indexes the contained markup). However, with the rise of easy and affordable hosting options for server side rendering, such a custom built, uncommon solution seems unnecessary and not really worth the efforts.

Nuxt.js is a great framework that makes it really easy to build a Vue.js based frontend application that renders the custom elements markup provided by the Drupal backend. Since each custom element is mapped to a Vue.js component, it's the perfect fit for building up component-based frontends, while keeping the editorial controls in the backend.

Thanks to its flexible deployments options, we can leverage static generation for smaller sites and use server-side rendering for larger, more content-heavy sites.

Since there are so many details more to talk about, I'll be following up with further blog posts in the coming weeks, covering the following topics:

• Authentication & related architecture variants. Custom Elements markup & json formats.

• A developer introduction: Creating components, adding Custom Element processors, the relationship to Drupal's render API, Custom routes and optimizing cache metadata.

• Handling blocks & layout builder, content previews, forms, caching & performance optimizations.

Finally, I'm going to talk more about this stack at the Drupalcon Europe 2020 in my session "Custom Elements: An alternate Render API for decoupled Drupal" at December 08 - 09:15 - so mark your calendars!

Building websites that are completely mistake proof is often considered to be a massive undertaking, which many-many times is not properly executed. Since there are so many parameters to fulfil and so many corners to oversee, mistakes tend to happen. You may not even realise that you have done something wrong in the development process, it could be much much later when you actually undergo a website audit that you come across the mistake that has been made.

Drupal websites are equally prone to mistakes. Despite the CMS being one of the best, there are still occurrences when things go wrong and the impact is felt on the engagement, conversions and consequently, the sales.

To not let that happen, I have compiled a list of mistakes that you need to steer clear of when building or working on a Drupal website. These are errors and oversights that many developers and content authors have experienced first-hand and you can certainly try to learn from their mistakes.

So here are the most common mistakes witnessed on Drupal websites.

A good website is often considered to be the one with outstanding content, since that is what keeps the audience engaged and leads to conversion. Therefore, content is crucial for a website, both for the front-end and the back-end, so content should be one of the priorities in the website designing process. Due to this fact, there are a number of areas where the developers can go wrong with the content. 

The first common mistake witnesses with the architecture of content is using too many content types that you actually do not use. The unused content types are just going to burden your database and I am certain, you would not want an additional table in your database for three content types that you do not even use. Having content types with no nodes will have the same effect. Performing an inventory will help you get the mistake resolved.

Moving on from the unused to the used, content structures are extremely valuable for your editors who are going to fill them up and if they end up confused, what will be the point of it all? Standardising your content types is going to help you a great deal. 

• Strike off the content types that are similar to each other, like news and articles;
• Do not add new fields for every content type;
• And most importantly, plan a structure prior to it, winging it may not work with your website content.

Content types have an effect on the performance of your website as well. So, if you do not want to drain the performance of your site by adding unnecessary complexity, you would be wise to avoid these mistakes.

After content comes its display and Drupal is best in that game. With many different features available for use, Drupal can make your display game strong as well, you capitalise it wisely.

Creating a view for every list is both impractical and a waste of time. Focus on reusing Views as much as possible along with parameter based rendering.

Do you use PHP code in your database? If so, avoid doing that, instead you must write all the codes in the modules or themes itself.

Planning, optimisation and segregation are essentially the building blocks of a great website display. 

• Planning to render the content types you need;
• Optimising the Views you already have;
• And segregating logic from presentation.

These three would have a visible effect on the display architecture.

The functionality of a Drupal site depends on the number of modules used and the way they interact with each other. Your code and how much of it you use is a major contributor in that. 

The most common mistake in this sense is the ignorance of code standards. This becomes more of a problem when there are more than one developers and everyone is using a different type of code. In such a situation, not only would the standard be lost,  but it would also become difficult for a developer to understand the other’s code. Therefore, the adherence to Drupal’s Coding Standards becomes a great help to uniformalise the code and make the functionality a breeze. 

Another obstacle in functionality are unorganised patches. Code modifications and bug fixes mandates the implementation of patches, however, they become a problem whenever there is an update. You can forget all about re-apply the patch or forget to change it in accordance with the new version. This can very well affect the functionality of your website, so organising them is essential. 

Having too many modules, too many roles and too much custom code, despite there being contrib modules for the same is bound to affect the functionality as well. Evaluate and re-evaluate your site for its needs to overcome these functionality hindrances.

User Experience is directly proportional to the performance of your website; the more streamlined the performance is, the richer would the UX be. 

Here are three scenarios that can impact your performance in all the wrong ways.

• The foremost is improper JS/CSS aggregation settings. This is supposed to combine and compress JS and CSS files from the modules in the HTML, leading to lesser load times and higher performance. And you will be saying goodbye to that with the improper aggregation.
• The next mistake is that of inundating your site with too many modules. Drupal may have numerous modules to offer, but you can’t be using too many of them. Doing so would only slow you down and hamper your security as well. Only keep the modules that you would be using, messing up your code, performance, overheads and security is simply not worth it.
• A sound cache strategy also goes a long way in performance enhancement. Caching too soon, caching at lower levels and not knowing what and when to cache all contribute in a lowered performance.

Drupal websites can be scaled by millions of users within seconds and that is what makes these sites great. Drupal offers many modules to enhance the performance and scalability, Blazy, Content Delivery Network and Server Scaling, being just a few of them. Not installing these could be deemed as a mistake.

Security has become one of the major concerns amongst website builders. Therefore, protecting your business from the menace of hackers and all the havoc they can cause is paramount. 

You must have your security measures in place, however, there still may be certain areas where you may have become complacent and that just gives the break the hackers need. 

• Primarily, you need to keep your website updated, all the core and contrib modules, despite you using or not using them. Updating a module would mean that Drupal’s security protocols are being updated with them and you make yourself secure with that. You cannot have your projects falling behind on various levels of Drupal’s security advisories.
• Now, you can install the “ Update Manager” module to keep yourself updated. The “Available Updates” will give you a friendly reminder of applying the available security updates.
• Next on the list of security blunders is not giving the Input Filters in Drupal their due importance. You might have configured the full HTML Input Format to every user or you might have completely disabled the HTML filtering. Both of these instances can give malicious code to enter your website and you know what happens then.
• Continuing on similar lines, many sites also configure their servers improperly leading to unwanted access to them. On some occasions, servers are seen displaying their version numbers, which is like giving an open invitation to hackers. Server configuration and permissions should be a priority for every site builder.
• It is also important to ensure that all the users accessing your site by logging into it are the ones you want. By implementing a password policy, removing old users and updating staff roles, you will be taking a step towards better security.
• User roles are quite important in running a website, however, they can become overused quite quickly too, which not only slows down your website, but if they are misconfigured, it can lead to major security breaches.

Drupal has proven to be one of the best CMSs in terms of its security measures, it has you covered from every corner, but only if you let it. From granting secure access to providing granular user access control along with database encryption and preventing malicious data entry, Drupal will keep your site protected, provided you let it.

The infrastructure of your website is decided by the stacks you have, which includes the server, database and the software layers like Varnish. Going into development with a firm plan for your infrastructure is the only way to go, an oversight in this area can be quite damaging. 

The common mistakes in this area are;

• The size of the website’s stack is extremely large or extremely small.
• Not preparing for growth by consistently checking the logs for error and the identification of the weaklings.
• Having an ideal sized server, but not configuring it properly, which can make the traffic forego Varnish.
• Allowing remote connections to the server can make the website more vulnerable.

Misconfiguration can be avoided by simply using the right tools for it. MySQLTuner is one amongst many, its performance suggestions help in improving the infrastructure as well.

Maintenance of a website starts after the development is done and continues for the entirety of the life of the website. Considering this fact, you have to be very diligent with the maintenance process as making the wrong moves can be brutal.

Here are some of these wrong moves.

• Not following Drupal updates is a more common mistake than you would think. By doing this, you are going to be hampering security and making your site vulnerable to Drupalgeddon attacks.
• On the contrary, there are also times when we update the modules, but we forget to remove the older versions. This too happens a lot of the time and can cause many problems.
• It is not just the modules that need to be updated, the development environment should also be up-to-date and friendly for testing.
• Then there is the code, which is not using the Version Control System like Git, even the deployment of files should come directly from there. Also, using it, but not leaving messages for other developers related to the changes made can lead to chaos. It is, thereby important to always keep the VCS repository clean.

The crucial aspects of maintenance is time and consistency. When you do it timely, only then would it become a worthy practice. The review and assessment of your architecture in timely intervals along with all the logs, be it Apache or Drupal is a great headstart for the maintenance process.

Websites today need to transcend the parameters that used to confine them and their audience in the past. The sites and applications need to be built on a foundation that would make them fit for each and every user. Drupal has worked for the same, it aims to make websites accessible to all, including people with disabilities, by making itself an all-accessible tool. 

Web accessibility has become of the essence today, and persons with disabilities are at the core of it. Websites need to be designed keeping in mind their needs, be it a broken hand or a temporary sight loss. It isn't just me who believes this, World Wide Web Consortium’s guidelines agree with me as well. W3C two sets of guidelines are ardently followed by Drupal and your website should do the same, thus, support and foster inclusion. 

Despite its importance, many developers tend to overlook the accessibility features and that is where they go so very wrong. 

• Not focusing on balanced contrast levels that can work under sunlight;
• Not incorporating a form validation error verbiage to aid the visually impaired; 
• Not using buttons over CTAs.

These may seem like minor errors to you, but they can go a long way in making your Drupal site accessible to everyone.

Being SEO friendly is almost as important as building a website. Search engines bring in big numbers of traffic, so optimising them is crucial; yet we tend to forget to fine-tune the SEO details and focus on all the other aspects. At the end of the day, a website is an online business and business cannot survive without its clients and being SEO friendly is the way to go. Going wrong in this area can be extremely detrimental.

Look at the following aspects of a website and see how many you are and aren’t doing. 

Are your URLs user friendly?
Are your images small in size, with filled out alt texts?
Are you making your paragraphs short to make the text easy to scan through?
Are you using robots.txt for pages that you do not want crawled?
Are you creating an XML roadmap to help Google easily understand the structure of your website?
Are you researching your keywords?
Are you adding internal links to make your less popular pages gain attention through the more popular ones?

A positive answer to all of these means that your SEO game is strong and a contrary answer would let you know your mistakes.

To avoid the contrary from happening, Drupal provides a number of modules to help you capitalise on the SEO front. The SEO checklist module is a proof of that as it helps you by ensuring that you are following through on the latest SEO practices. Then there are the modules that aid your URL precision, like Redirect, Pathauo and Easy Breadcrumbs.From easing the process tags to helping in communication with search engines to providing the essentials for editing, Drupal has all the right SEO modules in its corner and not using these would be a colossal mistake on your part. Read our blog, The Ultimate Drupal SEO Guide 2020, to know more about these. 

Today, languages that are regionally spoken have started getting more prominence than ever before, especially in the international community. A french website would not be successful in India, if it is in French, not many people speak that language, so it would have to be in a locally accepted language. Being multilingual also opens the doors for many mistakes to occur. 

• Using the same URL for all of your multilingual websites; 
• Not giving the user a chance to avoid a redirect to the international website;
• Using an automated translator, instead of actually hiring content authors fluent in the language;
• Foregoing to translate the imbedded parts of the site like meta tags and descriptions;
• Not focusing on the foreign market trends and the keywords appropriate to it;
• And lastly, not writing the content in accordance with the local language and dialects. You can’t be calling ice lollies popsicles sticks in India.

You have to be totally attuned with the language of the region that you have followed for the multilingual project to work.

Depending on your business and its needs, having multiple sites can be a good solution for you. However, managing then can become a bit of a hassle and often lead to big blunders. 

Some examples of such blunders are;

• Traffic is one of the major concerns here. Running multiple sites means you have one codebase and many sites on it, so if one is inundated with traffic, all of them could slow down as a result.
• A mistake in the syntax of one site could mean a mistake in the syntax of all.
• Updates become a headache as well. For Drupal sites, you have to run an update.php in order to update the site and doing that on multiple sites is going to bring on the headache.
• And finally, if you do not use Aegir, you are going to regret going multisite.

Drupal offers an impressive front-end technology to make your presentation layer as good as you want, yet it does not include all the front end technologies there are on the market. Taking advantage of JavaScript and Static Site Generator would mean to decouple Drupal and separating the front-end from it. Even if you want to take on decoupling, it may not want to take on. The decoupled Drupal can bring more drawbacks then. 

• If you wish to capitalise Drupal’s in-built features, Decoupling would be a mistake, since you would end up parting with them.
• If your front-end requirements and Drupal’s front-end capabilities are aligned, taking on Decoupling would only be an unnecessary effort on your part.
• If you do not have either the budget or resources to tap into the hottest technologies, then even if you want them it is not going to be fruitful.
• If you are only publishing content at one place, you would have no need for decoupling.

For a detailed explanation, read our blog, When to Move From Monolithic to Decoupled Drupal Architecture.

Web hosting services that provide your website its own space on the internet are pretty common. There are far too many web hosts to count, yet the decision to choose one is not easy at all, since there are too many considerations to keep in mind. 

Some of the common mistakes to avoid which signing on a web host are;

• Testing web hosts is not uncommon, it is the right way to know whether they are valuable. However, testing on your website that is primarily bringing in the traffic could be unwise, especially if you are using a free service. Therefore, not registering with a different party can be colossal.
• Another mistake is trusting too easily without knowing the host for too long. Therefore, not partnering with one that has a long trial could be a mistake. The longer the trial period on offer is, the more reliable the host is going to be.
• Taking on a web host is a huge commitment, so you have to be sure that you are in the good. Not doing your due diligence before the commitment is not the right way, comparing the pricing and features along with checking if they have blacklisted IPs.
• Not tracking your hosting uptime and speed can also be a problem. Also not checking what guarantees for uptime are provided by the hosts for the same would not be wise. If there is a lapse between the guaranteed and actual uptime, keeping a track would give you the opportunity to ask for compensation.
• Lastly, you cannot afford to not have a backup of your site and that too regularly. You will only have the recent version of your files and assets, if you back them up.

Every aspect of your website is important, consequently, you have to be mindful of them all. If you are not, mistakes will happen and they will cost you your site’s performance, its security and your potential customers and sales. In order to keep that from happening, you have to avoid all of the aforementioned mistakes and ensure that your website is impeccably built and maintained on all platforms. 

Do you know the version number of the browser you’re using? What about the Operating System version you’re using? Chances are, you have no idea what the current version you’re using of any major software. And that’s the way it should be.

• Make sure your version of Drupal is up-to-date.
• Use Upgrade Status to see if your website is ready for upgrading
• If you have custom code, use Drupal Rector to identify code that needs to be updated

Throughout the software industry, there is a movement to more frequent, easier, updates. The reason behind more frequent updates is that everyone tends to keep software up to date and more secure, the easier and more frequent those updates come. Soon, you may not know the major or minor version of your website software, just that it is up-to-date and secure, which is the ultimate goal of any update, upgrade or version release.

Chances are if you’re using Drupal, you are using version 7 or 8. In June 2020, version 9 of Drupal was released and the last minor version of Drupal 8 was released. Both version 8 and 9 contain the same features and code. The only difference is that Drupal 9, or D9 as it is referred to in the industry, removed deprecated code and updated third-party dependencies.

(Source: Drupal.org - How to prepare for Drupal 9)

The image above shows the timeline for Drupal 8 and its version releases since 2019. The upgrade cycle in version 8 for minor releases was established to be a single release roughly twice a year. Now that Drupal 9 has been released, there will be an end-date for support for Drupal 8, but that is not scheduled until November 2, 2021. In fact, the upgrade from 8 to 9 is so painless, version 10 will be released in 2022, likely to even less fanfare, as it will also be the same as the most recent version 9.

Upgrading between all minor versions of Drupal, including the jump to version 9 is advised, but is a much simpler process than version upgrades have been in the past. See what Drupal.org has to say about it here. However, if your website was recently created or released since 2016, it’s likely that you’re on Drupal 8, and the upgrade should be extremely straightforward and relatively painless.

If you find yourself on version 7 of Drupal, you can absolutely upgrade straight to D9 and skip D8 altogether. The rebuild would likely take the form of an entirely new website, but the benefits of going right to D9 are two-fold: avoiding end of life issues for D8 in 2022 and jumping on a platform that will enable to you go headless, adopt the best media, personalization, translation, and content creation tool that open source has to offer.

Running end-of-life platforms come with a set of problems that over time, will end up costing your company time and money. When official support for D7 runs out in 2022 (the same time as D8), security updates, bug fixes and creation of new modules for those versions will also go away. This opens your system to being more vulnerable to cyber attacks, potential downtime and a lack of up-to-date features that your customers would expect from your web presence.

Jumping right into a new build with D9, you benefit from having the long-term official support from the Drupal community including security releases that help protect your website from various vulnerabilities. D9 also removes outdated code and uses the new version of PHP, which is important in terms of security.

Other reasons to upgrade to D9, from Drupal.org:

• Easiest upgrade in a decade, and a commitment to easy upgrades in the future. Never replatform again.
• Continuous innovation, cutting-edge new features, reaching new digital channels while strengthening our foundation in content management.
• Dramatically easier tools, intuitive solutions that empower business users to take advantage of the power of Drupal.

Currently, we are on the cusp of the first minor release of Drupal 9, which is planned before the end of the year. Most large ecosystem modules in Drupal have complete support for Drupal 9, including Drupal Commerce version 2.

• Make sure your version of Drupal is up-to-date.
• Use Upgrade Status to see if your website is ready for upgrading (this module will flag modules that need to be upgraded to Drupal 9).
• If you have custom code, you can use Drupal Rector to identify code that needs to be updated and, in many cases, can be automatically upgraded.

Still not sure that the upgrade to Drupal 9 is right for your organization? Have questions about the best way to handle upgrading your Drupal site? Our team is here to help you answer those kinds of questions. Check out our Drupal and Drupal Commerce Development page for more details on our services, or contact our experts to get started on your Drupal upgrade today.

Josh has been creating websites since 2000, has been a Drupal community member since 2008, and is currently the Team Lead of the Investment Division at Acro Media. He spends most of his free time playing board games and yelling at his cat with his wife.

Much has been spoken about the importance and benefits of migrating to Drupal 8. Drupal migration is the most significant part of a development workflow. We need to ensure that content gets transferred seamlessly without losing out on any critical user information and data. Check this complete guide for a successful Drupal 7 to Drupal 8 migration.  

There are several ways to migrate to Drupal 8 using various sources. We have already written about how to migrate from CSV to Drupal 8. Other sources include SQL, XML, JSON, etc. In this blog, we will be discussing about migrating to Drupal 8 using SQL as a source.

While choosing the data source largely depends on the source of the existing data required to be migrated, some of the other common reasons for choosing SQL source for a Drupal 8 migration are:  

• It is easy to write queries to get the required data by connecting to the database.
• Migrating the data from one server to another will be quicker than any other method.
• Reduces the usage of many contributed modules.
• No need of views data export which is used for exporting views CSV data from Drupal 7 sites.
• We will not need the Views password field which is used for migrating sensitive information (passwords in hash), since we are using DB query.
• Migrate source CSV module is also not needed since we are using SQL source.

In this blog, we will be migrating users to a Drupal 8 site. Following are the steps we will take to migrate to Drupal 8 -
1.    Create a custom module for the migration.
2.    Reference the source database.
3.    Define the migration YML and map the identified Drupal fields.
4.    Create a source plugin for migration.
5.    Process single value, multi-value and address fields.
6.    Run migration using the drush command line tool.

First, let’s create a custom module as you create in Drupal 8. Check this detailed blog for creating custom modules in Drupal 8. Here we are creating a module called “company employee migrate”. The module structure is as follows:

company_employee_migrate.info.yml : Consists of basic information regarding the module and its dependencies.

company_employee_migrate.install : This will be used for writing PHP scripts that should trigger while installing and uninstalling the module. In our case, we are deleting the migration configuration when the module is uninstalled. See the below screenshot for the script.

company_employee_migrate.module : This will be used for defining the general hooks for the site. These are the initial things needed for the module. We will be explaining the remaining in the next steps.

Next, we need to set up the source database from where we are extracting the data. Update the settings.php file for your Drupal site by moving to webroot -> sites -> default - > settings.php. 

Add the new database connection below the default connection as shown in the below screenshot. “migrate” is key for the source database. 

Now, we need to identify the fields which we want to migrate and map those fields in the migration yml. In this example we are migrating User Id, User Name, Password, Email, Status, Created Timestamp, First Name, Last Name, Job Role, Mailing Address etc.

After the identification of fields, we need to define the migration at migrate_plus.migration.company_employee.yml. Now let’s have a closer look at migration yml and their mappings.
 

id: Unique id for the migration yml.

label: Display name for the migration.

migration_group: Migration group name.

source:  Annotation Name of the migration source plugin. This will be defined in the @MigrateSource annotation in src/Plugin/migrate/source/CompanyEmployee.php.

destination: Name of migration destination plugin. In this case, it's entity:user since we are migrating user entity.

process: In process, we will be mapping the Drupal fields with the source fields. The left-side values are field machine names and the right-side values are the field names which we pass from the source plugin.

migration_dependencies: This is an optional key. This will be used only if there is any dependency on other migrations.

Migration source plugin is the heart of the SQL migration. Below is the detailed explanation for the source plugin. 

• The source plugin can be created at src/Plugin/migrate/source/CompanyEmployee.php 
• The namespace will be Drupal\company_employee_migrate\Plugin\migrate\source.
• The @MigrateSource annotations include the source plugin id that we map in the migration definition.
• Here we are extending the Abstract SqlBase class provided by the core migrate module.

See the below screenshot for reference.

The source plugin must implement the following three methods –

query() : This will return the source fields data by connecting to the source database. See the below screenshot which will return the field data where the user id is greater than 0 and user mail is ending with “@phyins.com”.

fields() : This method will return the available fields in the source. Below, I have added the code snippet for the list of available fields along with the baseFields().

getIds() : This method will return a unique ID for the source row. The below code will return a user ID of type integer since uid will be unique for each user.
 

Apart from these above-mentioned methods we also have:

prepareRow() : This method will be called once for each row. We are loading the data here from different tables and processes according to the requirement. Any property we create using $row->setSourceProperty will be available in the process step. We will be using the Drupal 8 DB query to get the data in prepareRow().

baseFields() : This will contain an array of basic fields from “users_field_data” that can be used by the query() method. Find the code in the below image.

In Drupal, we have different types of fields and processing some fields can get a little tricky for developers while migrating content. I have added the code snippets for some fields below:

Single value fields : These fields include text fields, boolean fields, email, etc. Find the code snippet below for getting a single value field; here the field_first_name can be set as below.

Multi Value fields: These fields include user roles, job roles, multi value select fields, checkboxes, etc. For a multi value field we need to return an associative array. Find below the code snippet for the “roles” field.

Address Fields: Migrating the address field provided by the address module will be little different from migrating other fields. We need to preprocess the queried data into an associative array with the proper keys as shown below for field_mailing_address.

Now all set to run the migration by installing the company_employee_migrate module in the Drupal 8 site.

Finally, we are ready for our SQL migration. To run the migration, we need to install drush (if you are not already using it).

List of useful drush commands for Drupal migration:

$drush migrate-status : This will return the status of migration with details.

$drush migrate-import migration_id : This will import the data from source to the site.

$drush migrate-reset-status migration_id : If the execution of the script has stopped or paused, the migration status will display as “Importing”. This command will reset the migration status to “Idle” so that we can proceed with the migration import.

$drush migrate-rollback migration_id : This will be used for rolling back to its previous state.

When you migrate to Drupal 8, you aren’t just upgrading to a better version of Drupal but a version that is open to a simpler future. All further upgrades (to Drupal 9 and higher) will be just a simple upgrade. The recent Drupal 9 release is a living proof for an easy upgrade. You have various options and sources to migrate to Drupal 8 depending on your requirements. In this article, we have demonstrated a migration to Drupal 8 using SQL as the source. Need help migrating your website to Drupal 8? Contact our Drupal experts now!

Leave us a Comment

Know more about our technology driven approach to recreate the content management workflow for [24]7.ai

Find out how we transformed the digital image of world’s largest healthcare provider, an attribute that defined their global presence in the medical world.

Discover how a Drupal powered internal portal encouraged the sellers at Flipkart to obtain the latest insights with respect to a particular domain.

VIEW ALL CASE STUDIES

Maybe you have banged your head against the wall trying to figure out why if you add an Ajax button (or any other element) inside a table, it just doesn’t work. I have.

I was building a complex form that needed to render some table rows, nicely formatted and have some operations buttons to the right to edit/delete the rows. All this via Ajax. You know when you estimate things and you go like: yeah, simple form, we render table, add buttons, Ajax, replace with text fields, Save, done. Right? Wrong. You render the table, put the Ajax buttons in the last column and BAM! Hours later, you wanna punch someone. When Drupal renders tables, it doesn’t process the #ajax definition if you pass an element in the column data key.

Well, here’s a neat little trick to help you out in this case: #pre_render.

What we can do is add our buttons outside the table and use a #pre_render callback to move the buttons back into the table where we want them. Because by that time, the form is processed and Drupal doesn’t really care where the buttons are. As long as everything else is correct as well.

So here’s what a very basic buildForm() method can look like. Remember, it doesn’t do anything just ensures we can get our Ajax callback triggered.

First, we ensure we have an ID on our form so we have something to replace via Ajax. Then we create a row with two columns: a simple text and an empty column (where the button should go, in fact).

Outside the form, we create a series of buttons (1 in this case), matching literally the rows in the table. So here I hardcode the crap out of things but you’d probably loop the same loop as for generating the rows. On top of the regular Ajax shizzle, we also add a submit callback just so we can properly capture which button gets pressed. This is so that on form rebuild, we can do something with it (up to you to do that).

Finally, we have the table element and a general form pre_render callback defined.

And here are the two referenced callback methods:

First we have the submit callback which stores information about the button that was pressed, as well as rebuilds the form. This allows us to manipulate the form however we want in the rebuild. And second, we have a very simple loop of the declared buttons which we move into the table. And that’s it.

Of course, our form should implement Drupal\Core\Security\TrustedCallbackInterface and its method trustedCallbacks() so Drupal knows our pre_render callback is secure:

And that’s pretty much it. Now the Edit button will trigger the Ajax, rebuild the form and you are able to repurpose the row to show something else: perhaps a textfield to change the hardcoded label we did? Up to you.

Hope this helps.

Acquia Engage is over, but its great lessons and content live on. You can access all of the Engage session recordings on the event site. Here are our top six can’t-miss sessions to catch up on if you couldn’t make it to Engage.

Do you own an existing drupal.org project that does not yet have a Drupal 9 compatible release? This week would be a good time to take that step and make a Drupal 9 compatible release! I am paying for two tickets to DrupalCon Europe for new Drupal 9 compatible releases. Read on for exact rules!

In Drupal 8 there is only one unified way of translating content to different languages. However, in Drupal 7, there were two different ways to do it:

• Using core's Content Translation module: this will create separate nodes per language.
• Using the contributed Entity Translation module: this maintains a single node and the translation happens at a field level.

Entity Translation is what is closer to Drupal 8's implementation of translation. Evolving Web has written blog posts about both methods in the past: content translation and entity translation.

However, that was a while ago, and there are updated ways to do proceed with entity translation migration. We'll go over those updated methods in this article.

• If you are new to migrations in Drupal 8, you may want to read about migrating basic data to Drupal 8 first.
• You can follow the sample code for this tutorial: Migrate example: Entity Translation module on GitHub.
• You need to have migrate_tools and migrate_plus modules to follow this tutorial.
• You need to have Drush installed to run migrations as described in this article.

Our imaginary client has provided a database dump for their Drupal 7 site containing some nodes. These nodes might have translations in English, Spanish and French, but there could also be some non-translatable nodes. We need to migrate those nodes to Drupal 8 while preserving the translations.

We need to create a module for our migrations. In this example, we're naming it migrate_example_entity_translation. 

We then need to add the following modules as dependencies in the module declaration:

• Migrate Tools
• Migrate Plus

To group the migrations, we also need to create a migration group. To do so, we’ll create a fairly simple configuration file so that the group gets created when the module is installed. The file’s contents should be as follows:

Next, you need to load the Drupal 7 database into your Drupal 8 installation. To do so, you need to define a new database connection in your settings.php file like this:

And then you can import the database dump into this new database connection using your preferred method.

Next thing to do is to write the actual migrations. Per our requirements, we need to write two different migrations: one for the base nodes and one for the translations.

Since Drupal 8.1.x, migrations are plugins that should be stored in a migrations folder inside any module. You can still make them configuration entities as part of the migrate_plus module but I personally prefer to follow the core recommendation because it's easier to develop (you can make an edit and just rebuild cache to update it).

The first migration to write is the base nodes migration. This will be just a simple migration without anything special related to entity translation.

The full migration file will look like this:

Now we should write the translations migration. We start by creating the migration file. In this case, we'll name it example_creature_translations.yml. The source section of this migration will look like this:

In the plugin, we're using d7_node_entity_translation; this is a plugin already included in core to handle this type of migration.

The destination for this plugin will be pretty similar to the destination for the base migration. It will look like this:

Now it's time to write the process section for this migration. It will be pretty similar to the base migration. You only need to keep in mind that you need to migrate two new properties: content_translation_source and content_translation_outdated. So, your process section will look like this:

Finally you can setup migration dependencies to ensure your migrations run in the right order:

You can look at the full migration file in the code samples repo.

Since we have set dependencies, we can instruct Drupal to run the migration group and it will run the migrations in the right order.

To do so, execute drush mim --group=entity_translation and the output will look like this:

You can also run drush ms to see current migration status:

• Check out the code for the migrate_example_entity_translation module on GitHub.
• Read about migrating basic data to Drupal 8.
• Learn more about migrations in our blog

You must be familiar with words like intermediary, middleman and mediator. What do these words mean? Could they possibly denote a job profile? I think they can. An intermediary, a middleman and a mediator, all constitute a connection between two parties, they provide a line of communication that makes one access the other with ease; like a store manager, he allows the consumer to access the products of the manufacturer. Without him, sales would be pretty difficult to do. 

Bringing the conversation back to the topic at hand, an API is essentially an intermediary, a middleman or a mediator. The Application Programming Interface provides access to your users and clients to the information they are seeking from you. The information provider uses an API to hand the information over to the information user through a set of definitions and protocols. 

In decoupled Drupal, the API layer provides the connection between the separated front-end and back-end layers. Without it, decoupling would not be possible, since there won’t be a way to transmit content from the backend to the presentation layer. 

There are quite a few APIs that perform impressive functions, but today we would only be enunciating REST API. So, let’s delve right in.

REST API, RESTful API or Representational State Transfer is built on the constraints of the REST architecture. It is renowned to make development easy by supporting HTTP methods, handling errors along with other RESTful conventions. Since REST capitalises on HTTP, there isn’t a need for installing a separate library or software to capitalise REST’s design, making development all the more easy.

A representation of the state of the resource is transferred to the requestor, when REST API is used to make a request. It could be done in numerous formats, namely JSON, HTML, XLT or your plain old text, through HTTP. 

If you asked me what the best things about REST is, I would have to say it is its flexibility. The REST API is designed to be flexible because it is not tied to certain methods and resources. Therefore, it can handle multiple types of calls, transform structurally and return data formats as well. Such versatility makes REST competent to provide for all the diverse needs your consumers may have. 

REST cannot be defined as a protocol or a standard, rather a set of architectural principles would be a more accurate description. These principles make an API become a RESTful API. So, let us understand these constraints to understand REST API better. 

This principle states that the client and the server are to be independent of each other leading to more opportunities for growth and efficiency. Since the separation of concerns would allow a mobile app to make changes without those changes affecting the server and vice-versa, the organisation would grow far more quickly and efficiently.

A call made using REST API is just that, one call; it has all the potential data for completing a task in and by itself. If a REST API has to be dependent on the data stored on a server for each individual call, it would not be very effective in its job. It has all the necessary data with itself, making REST API very reliable. This principle is known as the state of being stateless.

Now you would think that since REST API stores such massive amounts of data in itself, it would increase your overheads. However, this is a misconception. REST was built to work with cache, meaning it can store cacheable data. This ability helps in reducing the number of API interactions drastically leading to reduced server usage and consequently faster apps. 

Decoupling mandates the implementation of an interface that is not tightly connected to the API providing uniformity to application development. This can be achieved by using HTTP along with URI resources, CRUD and JSON.

REST API works with a layered system; what this means is that each server, be it security or load-balancing, is set into a hierarchy. This constraints the component behaviour so that one cannot see beyond its layer. 

Finally, there is the Code on Demand, this principle that gives you the option to transmit code or applets through the API layer and this code or applet would actually be used in the application. This principle allows you to build applications that do not just rely on their own code. However, the security concerns have made it the least used of them all.

All of these are essentially the guiding principles of REST API, along with that they also lay emphasis on the work REST can do for you and your application; this, highlighting its importance.

Now that you know the importance and principles of REST API, it is time to move one to its exploration. REST API can be explored in Drupal through a number of modules, all you have to know is where to look and what to exactly look for. For the same reason, here is the list that would make consuming REST API seem like a walk in the park.  

There are certain REST modules that are so popular that they have become a part of Drupal core. These are;

RESTful web services

RESTful Web Services is a module that takes advantage of Entity API to provide you the information of all entity types, be it nodes, comments, taxonomy terms or your users. Being built over the Serialization module, it gives you customisation and extension of the RESTful API. It also has the ability to expose additional resources along with adding authentication mechanisms, which can be applied to any of the resources. 

Serialization and Serialization API

The primary purpose of the serialization module is to de-serialize data to and from formats such as JSON and XML. You can simply call it a service provider for the same. 

The Serialization API is based on the Symfony Serializer Component. Its numerous features have made it quite advantageous to the users. 

• For one, it can serialize and deserialize data;
• It helps in encoding and decoding to and from new serialization formats respectively, you can read data and also write it;
• It can also normalize and denormalize data and set it into a new normalization format. 

HAL

HAL is an acronym for Hypertext Application Language. This module uses its namesake to serialise entities. With features similar to the Serialization module, it is often regarded as an extension of the same. The HAL hypermedia format has the potential of being encoded in JSON as well as XML. Being a part of Drupal Core, it is the most sought after format.

This is a module that lets you test drive as well. Yes, once it is installed and configured, you can test drive your site through the HAL browser by simply providing JSON data.

HTTP Basic Authentication 

You must be familiar with the term authentication, the working of HTTP Basic Auth is similar to that. What it does is takes a request, identifies the username and the password of the user and authenticates them against Drupal. It does so by implementing the HTTP Basic protocol, which essentially encodes the username and the password and adds the same in an Authorization header; and all of this done within a request. 

It is to be noted that this module does not use an interface, it acts as a support for Drupal’s Authentication Manager. 

Basic Auth is an important module in the REST API, therefore, certain alternatives are also available to be used in its place. 

OAuth 1.0

The OAuth 1.0 standards are implemented by OAuth 1.0 module to be used in Drupal. It provides a foundation to the modules that want to use the OAuth. 

In Drupal 8, this module achieves the feat of leveraging the OAuth PECL Extension, leading to the implementation of the authentication provider. 

Simple OAuth(Oauth2) & OpenID Connect

Simple OAuth can be described as the implementation of OAuth 2.0 Authorization Framework RFC. In Drupal, it is a module that makes use of the PHP library OAuth 2.0 Server, which is a part of The League of Extraordinary Packages. Let me tell you something about this library so you know how valuable it is, it has actually become a standard for the modern PHP. With it being thoroughly tested, you can’t go wrong; still you would need to check your options at the time of deciding a project to use. 

Coming to OpenID Connect, it comes along with OAuth 2.0, being an identity layer on top of its protocol. It helps you verify the identity of the end users along with fetching their basic profile information.

OAuth2 JWT SSO 

The name OAuth2 JWT SSO does clear up notions of what it actually does, all three acronyms are at work. It can work with Drupal's very own OAuth 2.0. The reason being its ability to configure Drupal so that both centralized and remote authentication services can be used. 

Like its name suggests, it also works with JWT and SSO, which is short for Single Sign On. It can capitalise on any SSO, provided that it uses OAuth2 as its authentication framework, and JWT as its Bearer token. 

Cookie Based Authentication

If you have ever used a website, you would then know what a cookie actually is. Was it just today when you declined that ‘accept cookies’ request? These help a website to recognise users so that they do not have to log in again. 

Now, web applications tend to use cookie-based authentication, which they implement differently. However, at the end of each day, they will have some cookies set up that would represent an authenticated user. A cookie is transmitted along with every request and the session is deserialized from a store. 

More than 20,000  sites have been reported to use this very module. It is known to be fully feature-packed, its maintainers have the same thoughts. 

Coming to its abilities, REST UI provides an interface to configure Drupal 8’s REST module. Due to its handy configuration, you won’t find a need to play with Drupal’s configuration import page. This fact not only benefits the novice Drupal users, but also expedites your configuration by a substantial time margin. You can simply install it by using the default approach, Drush or the Drupal Console. 

REST API is pretty versatile in its features and Drupal has all the necessary modules to consume it in an optimised manner. If you had to choose a thread to hold your front and backend together, I would say that REST API would not let you down. However, that would only be possible, if you know how to capitalise it using Drupal. I hope I would have enlightened you about the same through this blog. To learn about other web services available in Drupal in addition to REST, read about GraphQL and JSON:API.

Every year, Annertech is actively involved with DrupalCon, and this year is no different. Here are some of the ways we are contributing this year.

If you haven't heard of MailHog, it is an email testing tool for developers. Lando has native support for MailHog, you just need to add it as a service to your .lando.yml file. You can just copy the example I leave below, which also has some cool extras, like enabling and disabling Xdebug on the fly. There's a second file .lando.php.ini that .lando.yml references with some custom settings, like changing the default xdebug.remote_port to 9001 (I need that on my Mac).

On the Drupal side, you'll obviously need to enable the Swift Mailer module. If you haven't done it already, you should enable your settings.local.php file so you can have your local development overrides.

By José Fernandes