Jun 21 2019
Jun 21

This is no news anymore: preparing to upgrade to Drupal 9 is just a matter of... cleaning your website of all deprecated code. 

No major disruption from Drupal 8. No more compatibility issues to expect (with dread)...

“Ok, but how do I know if my website's using any deprecated APIs or functions? How do I check for deprecations, identify them and then... update my code?”

2 legitimate questions that must be “haunting” you these days, whether you're a:
 

  • Drupal 8 website owner
  • developer currently working on a Drupal project
     

Since the great news of this smooth Drupal upgrade ships with the answer to your “What” question (“What do I do to get my website ready for Drupal 9?”), but leaves the “How” question open:

“How precisely do I check my website for deprecated code?”

Are there any analysis tools available? Tools that you could run to get a thorough and accurate deprecated code report? 

Luckily, there are. And I'll be focusing on 2 of the most effective ones that you should consider integrating into your workflow: Drupal Check and the Upgrade Status module.
 

1. But What Is Deprecated Code? And What Website Elements Should You Audit?

A piece of code is considered deprecated if:
 

  • there's an upgraded alternative for it already available
  • it's no longer in use
     

With this real “dilemma” now solved, there comes another one:

“What parts of my website should I check for deprecated code?”

Make sure you scan your:
 

  • Drupal core
  • Drupal modules
  • theme
     

Note: pay special attention to the contributed modules enabled on your Drupal 8 website; run a deep-scan and, if you get any deprecation warnings, make sure to alert those modules' maintainers to clean them up.
 

2. Drupal Check: Scan Your Database for Any Deprecations 

A handy PHP analysis tool to grab and to run whenever you need to look for deprecated code in your database. 

A command-line tool that Dries Buytaert recommends running the... automated way,  closely integrated into your own workflow. What it'll do is track down instances of deprecated code for you.

Then, all there's left for you to do is to... remove them. And, depending on the context, to replace them with their upgraded alternatives.
 

3. The Upgrade Status Module: Determine Your Site's Readiness to Upgrade to Drupal 9

If the idea of working with a command line doesn't sound too... “tempting” to you, how about adding a user-friendly graphical interface to the equation?

The Upgrade Status module, delivered to us by the Aquia team, lead by Gábor Hojtsy, makes checking for deprecated code a lot more enojyable and intituive, thanks to its admin dashboard.

It's particularly handy if you're a Drupal site owner and not a senior Drupal developer highly familiar with CLIs.

Install it, enable it and use it to evalute your website and to assess to what degree it is ready (meaning up to date) for the Drupal 9 upgrade.

But let's delve head first into details on:
 

  • what it takes to install it properly
  • what parts of your website it will deep scan
  • how you can narrow down its analysis to specific projects only
     

3.1. Use the Composer Package Manager to Install It

Since it ships with its whole collection of third-party PHP dependencies...

Another key requirement to set the stage for the Update Status module is to enable the Update Manager and the Git Deploy modules on your Drupal 8 website.

Once installed, you can access its user interface at /admin/reports/upgrade.
 

3.2. Check Up Your Codebase, Modules and Themes

The great thing about this module is that you get to run your checks right in your admin UI and get a full report.

Another great aspect is that, when it comes to contributed modules, it will provide you any available updates... inline. 

Once it's completed its scan it'll display either an “Errors found” or a “No known errors” message. To localizae the identified deprecations on your website, just click “View errors”.
 

3.3. Run It on Specific Individual Projects, Too

Maybe you don't always need a full check. Maybe you'd like to scan only a specific project that you might be working on, to ensure that it's ready to upgrade to Drupal 9 when due time.

You can do that. The module allows you to cut down the time you'd spend on an uneccessary full-scan by focusing on one target project only. 

Furthermore, to streamline things even more, it enables you to export each deprecated code report individually...
 

4. So,You'Ve Identified Your Deprecated Code: What Next?

In most cases, keeping your codebase up to date once you've detected the deprecated parts is just a matter of replacing those deprecations.

For the other few cases left, you'll need to carry out a more complex refactoring process.

Now that you know which are the tools to use for:
 

… your website's smooth upgrade to Drupal 9 depends on you exclusively. 

On sticking to your own routine of checking up your Drupal core, modules and theme and keeping them up to date.

Image by fajar budiman from Pixabay

Jun 20 2019
Jun 20

What does Drupal 8 do that Laravel does not? What key functionalities, that Drupal ships with, do you need to build from scratch in Laravel? And how would opting for Laravel benefit your specific type of project? In short: Laravel or Drupal 8?

“It's like comparing apples to oranges” some might say since one's a framework and the other one a CMS.

Even so, if it's unclear to you what are their particular use cases and their built-in features, you can't know whether it's a CMS or a framework that best suits your project type, right? That best serves your project-specific needs:
 

  • to be super fast
  • to leverage a solid, off-the-shelf content management system for publishing different pieces of content on the website
  • to feature an easy to scale database
  • to support multisite
  • to tap into robust user and content management features that are already implemented
  • to be built on top of a solid framework acting as a reliable back-end application
  • to leverage a highly intuitive admin user interface
  • to be 101% secure
  • to leverage a mixture of server and client-side logic
     

Now, keep your list of project requirements and constraints at hand to evaluate these 2 technologies' pros and cons against it:
 

1. Drupal 8: Top Benefits, Main Drawbacks, and Specific Use Cases

If a robust user and content management system is critical for your project, then Drupal 8 makes the smartest choice. It's that “thing” that Drupal excels at that, which would take you a whole lot more time to do in Laravel.

And it's not just its robustness that might “lure you in”, but the level of convenience that it provides: a lot of the essential features and functionalities that you might need are already built-in.

Moreover, you can easily manage them and custom-tune them via your admin interface...

By comparison, you'd need to build these functionalities, from the ground up, if you chose to go with Laravel.
 

Top benefits:
 

  • you can rest assured that your website runs on a particularly robust, Symfony-based CMS
  • there's a huge, dedicated community backing it up
  • you get to create various content types, for different parts of your website, assigned with different roles; unlike basic CMSs, that only enable you to write... posts and to create new web pages
  • you can set up different editorial workflows and assign specific user roles, with fine-grained access control
  • you can always further extend its CMS-specific functionalities: extensibility is one of the strongest Drupal 8 benefits
     

Main drawbacks:
 

  • you do need a team of Drupal experts (senior-level preferably) to keep an eye on your Drupal 8 website/app and keep everything properly maintained
  • you can't get away with a “get it up and running and... move on” type of philosophy; Drupal 8 is a more of a long-term commitment: there's always a newly launched promising module to consider adding on, a new update to run...
     

Specific Use Cases for Drupal 8:
 

  • large-scale projects that depend on a robust and reliable content management system; one that withstands an intense, ongoing process of creating, editing and publishing lots of fresh content
  • Laravel or Drupal 8? Definitely the later if it's a multi-site, multi-language web project that you plan to develop; not only that it streamlines content publishing  across your whole network, but it significantly speeds up localization thanks to its server-side caching capabilities
     

It means that no matter the place on the globe where that your users might be located, they get to access your web pages and have them loaded... instantly.
 

2. Laravel: Pros, Cons, and Project Types that It's Best Suited For

Laravel stands out as a highly reputed, powerful PHP framework

If:
 

  • maintainability is one of your biggest concerns
  • you're looking for a robust framework
  • you need to carry out your project fast enough
  • you need a framework that ships with all the latest functionalities
     

... then Laravel is what you need.
 

Top Benefits:
 

  • a fast-growing, devoted community
  • you can easily integrate LDAP authentication 
  • it leverages the Model-View-Controller architecture
  • it's just... fast
  • provides you with a great admin user interfaces
  • it “spoils” you with intiutive, beautifully written code
  • it ships with a heavy “toolbox”: scan through and pick the most suitable one(s) for your project
  • in-built code for social login and sending out emails
  • everything you might need to set up during the development process is right there, already integrated into your code: cron jobs, database queries, routes...
     

Main drawbacks:
 

  • more often than not identifying performance issues isn't that straightforward
  • upgrading to the latest version of Laravel can turn out to be quite a challenge: be prepared for “buggy scenarios” and for the need to rewrite code
  • you can't just jump straight to Laravel: learning the basics of OOPS first things first is a must
     

Specific Use Cases:
 

  • your project needs a back-end application (rather than an off-the-shelf CMS)
  • when the benefits of the MVC architecture (faster development process, suitable for large-scale projects, multiple views, etc.) are critical for the given project 
  • whenever you need to mix the client-side with server logic
  • whenever time factor is the main concern for you: you just need your project developed super fast
     

3. So... Laravel or Drupal 8? 

Now, I'm sure that you already anticipate my answer:

The choice depends strictly on your project requirement and objectives.

On your own hierarchy of priorities in terms of features and functionalities.

And depending on these key aspects, that should be clearly defined, one technology will benefit you over the other.

So... what type of project are you looking to build?

Photo by Raquel Martínez on Unsplash 

Jun 06 2019
Jun 06

“Can I use Drupal for project management?” Definitely. 

Given all its content-oriented baked-in capabilities — file management, version control, easy content creation, and editing — Drupal makes the perfect software for:
 

  • managing your projects the easy and the... smart way
  • streamlining communication among your team members and with your contractors
     

In this respect, Drupal provides its own feature-rich distributions to help you put together your robust setup in no time. “Distributions” that come already packed with a set of useful sub-modules and themes, that all support the core functionality: project management (and smooth collaboration).

And without further ado, here the 2 most popular Drupal distributions for project management and team collaboration for you to evaluate first: RedHen and Open Atrium.
 

Loaded with robust and modern features, this Drupal-native CRM is designed with flexibility in mind. Meaning that it integrates seamlessly with the enterprise solution that you're using (Blackboud, Salesforce) and it supports a wide range of use cases...

And speaking of its functionalities:
 

  • engagement tracking and monitoring
  • data mangement: information about your contacts, the relationships among them and with your own company (e.g. memberships)
  • event registration integration
  • one-page donation forms to custom-tune to your liking
     

As for those many use cases that this Drupal distribution's built to accommodate, let's pick just a few real-world examples:

  • It's the best choice if smoothly integrating your CRM with your other enterprise solutions is critical for you
     
  • It streamlines tracking interactions with your contacts and organizations. Furthermore, since you can easily integrate it with your website, you get to leverage the provided data in order to adjutst the user experience accordingly...
     
  • It allows you to customize it and thus to give it a Drupal-like look and feel: to integrate it with modules like Rules or Views, to go for the same field creation UI etc.
     
  • Is your contacts list a huge one? This CRM comes to your rescue with some powerful baked-in tools: an efficient find-and-dedupe interface, an automated filter built in the UI, that you can use to filter your contacts by specific fields etc.
     
  • It automatically syncronizes data in your Contacts list with any newly updated data on your Drupal Users list
     


In short: RedHen CRM makes one of the top choices when you consider using Drupal for project management purposes. It's a lightwright, self-contained framework, more of a “cluster” of multiple specialized modules:
 

  • Organization
  • Activity
  • Fields
  • Organization Group
  • Dedupe
  • Registration
  • and a few more...
     

Looking for a Drupal-native distribution built around the team collaboration functionality?

One that should be:
 

  • convenientyly extensible
  • “loaded” with robust collaboration and information sharing features?
     

Then Open Atrium fits the profile in the slightest detail.

Built on top of the Organic Groups and Panopoly modules, it's a framewrok flexible enough to support discussion configurations by key criteria like team, project, organization...

And here are some more powerful features worth considering when you're still thinking whether you should use Drupal for project management:
 

  • an access control system, that grants granular control to certain sections of your project
  • a drag and drop layout with plenty of widgets to select from for customizing your landing pages and dashboard
  • file storing and sharing features
  • built-in Events, Files, Discussions, Issue Tracking, Document Wiki
  • an easy to customise, responsive theme
     

The END!

These are but 2 viable answers to your “Can I use Drupal for project management and team collaboration?” type of question. 2 of the options available that best meet some of your main requirements when looking for a project management software:
 

  • to be easy to use
  • to ship with an entire collection of file management and communication features
  • to be flexible enough and allow quick customization and seamless integrations
     

Have you tried other Drupal modules/distributions built around this functionality so far? 

Image by jessica45 from Pixabay

May 29 2019
May 29

May has been most generous with us, no doubt about it: it has "spoiled" us with a heavy load of both useful and usable Drupal content. The community has been altruistic enough to share their “enlightening” experiences of working with Drupal, their discoveries and latest contributions. As for us, we "feasted" on their articles and tutorials, even managed to sync all our personal tops and to come up a unique "best Drupal blog posts” list for this month.
 

Ranging from valuable tutorials to overviews of the latest Drupal releases, to glimpses of these Drupal contributors' hard work, our selection is as varied as it is valuable.
 

Now, in the name of open source we're ready to share our selection with you, OPTASY team's 5 most appreciated Drupal blog posts in May:
 

Drupal 8.7 had just been "taken out of the oven", it was still steamy fresh when the Srijan team published their inventory on its new features and newsworthy updates.

From:
 

  • JSON:API now in Drupal 8 core
  • to the Media Libray module, that grew from experimental to stable 
  • to the "rockstar" Drupal 8 module, the Layout Builder, that turned stable
  • to the newly improved configuration management system
     

... and other upgrades, updates, and newly added features, they managed to include in their post all the "highlights" of this Drupal minor release.

And, most of all, to do it promptly enough to be among the first (if not the first) to share their overview on the release with the world/the Drupal community...
 

Another piece of content that made it to our “best Drupal blog posts” list this month has been Matt Oliveira's tutorial on how to use Laravel's Homestead for Drupal local development.

He first adds some sort of context to justify his choice (since he used to go with Vagrant for his Drupal projects), then he explains, step by step:
 

  • what software you need to install, first things first ( VMWare, a VM provider, Hyper-V, Vagrant, etc.)
  • how to install and setup Homestead using Composer, but only after you've first cloned your Composer Drupal project
  • the command to enter for... launching it, after you've run all the due configurations
     

And his clearly formulated and practical tutorial goes all the way to the cool features that Homestead will provide you with and some useful warnings to keep in mind.

Have you used Homestead for your local development when working on your Drupal projects before?
 

Did the “secure Drupal” frenzy get you, too, last year? Particularly after the Drupalgeddon attacks?

Then you must have rushed to:
 

  • implement all the security best practices out there
  • put up a thick security shield around your Drupal modules and your Drupal theme
     

But did you know how insecure Drupal code even looked like?

And it's precisely this rhetorical question that generated the ThinkShout team's blog post.

They point out that:
 

  • way too many Drupal developers risk to “host” insecure code under their websites' hoods without even knowing it
  • most of us genuinely assume that all Drupal APIs are safe
     

Next, once they point out the issue(s), they enlist several exploitable holes that you could identify in your code, grouped in 3 main categories:
 

  • XSS vulnerabilities when rendering HTML
  • SQL injection risks
  • PHP code issues
     

A priceless resource to keep at hand and to tap into whenever we run our own code review sessions here, at OPTASY. One that we're most grateful for. 
 

It's useful, it's enjoyable, it's packed with helpful tips on both:
 

  • what optimizing images for the web really means; take it as a helpful checklist
  • what Drupal tools to use to... automate the whole process
     

And I'm talking here about the “Configure image styles” feature that enables you to define some sort of “pattern” to apply on all the future images on your website. One already incorporating all the due properties, the right width and height.

About the “Image toolkit” feature, that enables you to easily improve your image's quality. And the list goes on (with the Responsive Images module and so on...)

A way too valuable piece of content not to include it in our “best Drupal blog posts” list.
 

The real challenge highlighted by the Duo team in their post? Drupal site search in case of large organizations.

And their real struggle to look for a solution that:
 

  • would allow users to query across an entire ecosystem of websites and platforms
  • wouldn't put too much pressure on Drupal
     

In this respect, they bring to our attention a solution architected and developed by the Palantir team: the federated search.

Next, they back up their choice with strong arguments:
 

  • it's a robust enough search solution to meet large organizations' needs
  • being a decoupled solution, it leverages Drupal's powerful back-end without putting a strain on its front-end, as well
     

In short: for us, the OPTASY team, this post opened a world of possibilities. What if search in Drupal could be way more flexible, yet powerful enough to meet enterprise-level requirements?

And I'm thinking here of all our clients “juggling” with multiples websites...

 
The END!

These are the best Drupal blog posts on our monthly list. And we have to admit: picking just 5 pieces of content on Drupal was one hell of a challenge.

Photo by Daniel McCullough on Unsplash

May 24 2019
May 24

What makes the Cache API in Drupal 8 any better than Drupal 7's cache system? What's so revolutionary about it? Which of the old limitations does it remove? What are those new concepts and terminology that you should learn about?

And, most of all: how complex is it to set up a cache in Drupal 8 for a specific use case?

You might have already bumped into terms like “max-age”, "context cache" or "cache tags".
 

But how precisely do these new concepts, part of Drupal 8's cache system, refine and streamline the way you cache data on your website?
 

Let's try to demystify the terminology of Drupal 8's Cache API and to translate its new “fancy” terminology into... crystal-clear benefits for you:
 

1. What Is Caching More Precisely? Why Do We Cache Data?

To your “What” question I'd answer:
 

Caching is a... strategy (or layer) for storing data from your website. Or: it's a software or hardware component where you store your data. 
 

Both definitions are equally accurate.

Why would you want to store your data?
 

Because this will streamline the way your website serves all future requests for that cached data.
 

And it goes without saying that reading data straight from the cache takes less time than... retrieving it from a slower data container or fully recreating the result.

In short: caching data translates into faster page load time.


2. Cache API in Drupal 8: The Automatic Cache System

A brief, yet accurate definition of cache in Drupal 8 would be:
 

Storing data that takes too long to load.
 

And if I am to detail it a bit I'd have to add that:
 

Caching can be either permanent or time-limited you'ree to cache any type of data on your website.
 

Now, talking about Drupal 8's cache API, what everyone points out is that: it is much improved. That it's so different from the cache systems of the previous Drupal versions that... you even risk turning your website uncachable if you're not familiar with its new concepts.

“But how different/sophisticated can it be?” you might ask yourself.

Before we delve deep into details let me add just one thing:
 

We're talking about an... automated cache system. Basically, your Drupal 8 website retrieves cache data for both anonymous and logged in users with no configuration whatsoever. All by default...
 

And now, let's shed some light on all these new fancy concepts that the Cache API in Drupal 8 is based on:
 

2.1.The Cache Tags

We all do agree that “invalidating cache” is one of the most challenging tasks of any cache system.

Luckily, not anymore. At least not in Drupal 8, where you now have the concept of “cache tags” that you can use for tagging:
 

  • specific pages
  • specific page elements
  • various types of content
     

… and thus invalidate them all. Improved efficiency and high accuracy through... basic tagging.

Basically, using these cache tags you can easily identify outdated data stored in multiple cache bins and... invalidate it.

This way, you no longer run the risk of invalidating “still green” cache items, in bulk, not knowing which data to invalidate.
 

2.2. The Context Cache

Here's an all too common scenario:
 

You're faced with multiple variants of the same data; only one of them should be cached, based on a specific criterion like language, user, country, content access permission...
 

Well, how do you automate targetting the right variant to be cached? And how do you automate caching the other left variants, as well, depending on the... context.

You use “cache contexts”, that's how...

They're one of those new remarkable features that the Cache API in Drupal 8 ships with, that allow you to specify the criteria to be used for the cached content on a page to vary. By user, by language, by country, by path...
 

2.3. The Max-Age (The Cache Duration)

Maybe you don't want certain data to be forever cached. Maybe you need it stored for a certain period of time only.

In this respect, the “max-age” property in Drupal 8's cache system allows you to define that time limit. To invalidate data that will have run... out of time.
 

2.4. The Bubbleable Cache Metadata

What does this even mean “cache metadata... bubbling”?

Let's take this example: 
 

You have a parent item with its own “family” of... children items. In this context, “bubbled tags” makes it possible for the parent item in this render array to receive cacheability metadata from its children.
 

Bubble cache metadata streamlines the whole process of invalidating... outdated cached data. As simple as that...
 

The END!

Is it any clearer for you now what makes the Cache API in Drupal 8 so... powerful? How its new features come to remove most of the limitations that you've already faced in Drupal 7?

And how you can use them to refine and automate caching on your own Drupal 8 website?

Image by Pexels from Pixabay  

May 07 2019
May 07

Looking for a Drupal 8 rating module that should be:
 

  • easy to install
  • easy to configure
  • easy to use
  • conveniently flexible
  • and user-friendly?
     

And maybe you “crave” for some nice-to-have features, as well:
 

  • enabling users to add a short review
  • multiple ratings: enabling users to vote on several aspects of your product/service, such as price, quality, ease of use?
     

What are your options? What working (and stable) modules for rating and reviewing are there in Drupal 8? 

We've done the research for you, evaluated all the modules for rating in Drupal 8 and come up with a list of 6 best... rated ones:
 

Keep in mind that this Drupal 8 rating module doesn't provide a voting mechanism, packed with all the key voting features. Instead, it structures the voting data for other rating modules to leverage.

What it does provide you with is a standardized API and voting data storing schema. Therefore, it streamlines the whole process of retrieving and organizing the voting results for various pieces of content on your Drupal 8 website.

Top features:
 

  • multi-criteria voting
  • caching the voting results (and it does that in a highly efficient manner, with no need to recalculate them...)
  • enables users to rate any type of content on your Drupal site (users, comments, nodes)
  • automatic tabulating of the voting results
     

Note: keep in mind that, for now, we only have a pre-release version of the module for Drupal 8...
 

2. Flag Rating, A Highly Popular Drupal 8 Rating Module 

An extension of the Flag module, that allows you to either:
 

  • use the default SVG icon 
  • upload your own icon (jpg, SVG or PNG) for each flag
     

Drupal 8 Rating Modules- Flag Rating

Furthermore, you even get 2 templates to override to your liking:
 

  • flag-rating.html.twig
  • flag-rating-icon.html.twig
     

A Drupal 8 rating module that you can use to turn the “select tag” option of the Star Rating module into a more user-friendly, clickable icon.

Drupal 8 Rating Modules: Star Rating Form Display

To “unlock” its functionality just:
 

  • navigate to Structure > Content type
  • select the “Manage form display” option
  • scroll down to your star rating field
  • click “Star rating clickable”
  • in the Settings screen, configure the custom display to perfectly fit your needs

If you're looking to integrate a voting functionality exclusively for the authors of the articles submitted on your website (hence, not for the end users), Flag Rating is the module you're looking for.

Drupal 8 Rating Modules: Star Rating

Take it as a simple, yet useful module that provides you with a display formatter and a star rating field. In short: with the “bare necessities” for the authors to be able to rate the uploaded articles.

Say you have a review website — a hotel review website — and you want to add multiple star ratings to a node:
 

  • customer service
  • en suite and private facilities
  • food, etc.
     

... with a different icon for each node. Then, you just need to use the star rating field that this module provides...

Top features:
 

  • built-in support for the Views module
  • it doesn't require other modules (e.g. the voting API module) to work
  • it allows you to add a different icon type per field and per view mode
     

The Drupal 8 rating module that simplifies the entire voting process: it encourages users to express their votes through an intuitive thumb illustration.

Drupal 8 Rating Modules: Vote Up/Down

Top features:
 

  • code voting support for your pre-defined products/services
  • interchangeable themes for your voting widget
  • the possibility to set up your own custom widgets using ctools plugins
     

The END!

These are your 5 best options when it comes to working Drupal 8 rating modules that should be both easy to configure and easy to use. 

Have you discovered another way of integrating a reviews feature to your Drupal 8 website?

Image by mohamed Hassan from Pixabay  

Apr 26 2019
Apr 26

April's been unexpectedly generous with us. It has spoiled us with plenty of high-quality content on Drupal. From “enlightening” tutorials to articles raising awareness of certain limitations, to useful tips and actionable advice, to blog posts announcing life-saving module releases... reading our way through the pile of Drupal blog posts this month has been a true dare.

Then, trimming down our bulky list to just 5 posts has been an even bigger challenge...

Nevertheless, we did manage to make our selection. Here's what we kept:
 

The WishDesk team share their experience with leveraging the Drupal 8 Views contextul filters via a well-structured, easy to follow tutorial.

That we're highly grateful for...

Why has it drawn our attention? 
 

  • because we had already been excited about the unmatched flexbility that the contextual filters in Drupal 8 offer
  • it clearly outlines the main differences between regular and contextual filters
  • it presents a specific use of these filters: setting up a task tracker in Drupal 8 using Views 
     

With Views already providing us with an UI for putting together data collections based on certain criteria, now having contextual filters, as well, to fine-tune the results come as an... unexpected “present”.

Their key benefit and advantage over the “standard” filters? They accept dynamic values...

Another one of our top favorite Drupal blog posts this month has been this piece of content raising awareness of the Layout Builder's limitation:

The code generating the image element markup doesn't “store” information about the specific sizes of the column that the image will be placed in.

In other words: there's no way for Drupal site builders to enter an accurate value for the “sizes” attribute when using the Layout Builder...

And the author, Brian K Osborne, draws attention on this issue after first highligthing the main “dilemma” of using responsive image styles:

Providing just one high resolution, high-quality, oversized image vs providing a suitably sized image for efery screen resolution...
 

We couldn't leave out Dries' blog post on the due preparations for upgrading to Drupal 9.

The reassuring aspect that he reveals is that all these preparations revolve around one common best practice: detecting and removing deprecated code from our Drupal 8 websites.

He goes on giving straight answers to all those legitimate questions that we might ask ourselves in relation to these preparations for Drupal 9:
 

  • What is deprecated code?
  • How do we identify it on our websites?
  • How challenging and time-consuming is it to remove it/update it?
     

This has been, by far, one of the best rated Drupal blog posts in April here, at OPTASY.

We can no longer imagine our (work) lives without the Paragraphs module in our toolbox. So, upon hearing about the Paragraphs Editor Enhancements module we dropped evewrytging and looked for this blog post.

Which comes as an inventory of both:
 

  • users' (content editors) main improvement suggestions for the Paragraphs module
  • undpaul team's solutions to editors' complaints/suggestions, turned into enhancements for this module
     

From the:
 

  • well-known “dread” of having to drag the content elements to their right positions after you've added them
  • to the need to be enabled to add those content elements preferiantially (since most editors add pretty much the same elements, over and over again)
  • to the overwhelmingly high number of buttons and the overcrowded dialogs
     

 
… the Paragraphs Editor Enhancements ships with a solution to each one of these drawbacks.

We can't but predict that it will hugely influence the editorial experience in Drupal...

We could never thank enough the OSTraining team for their clear, concise and most useful tutorials. 

One of their April's Drupal blog posts has been this step-by-step guide on how to add webforms to content types. And the scenarios where you'd might find this kind of knowldge “life saving” vary from:
 

  • having to add a contact form to a “business” content type on your Drupal website
  • to having to add a contact form to your “Events” content type
     

Easy to follow, clearly explained, uncluttered, filled with relevant screenshots, their tutorial has been truly “enlightening” for us.

Especially since adding various types of forms is one of those recurring tasks in our Drupal projects...


The END! 

These have been our favorite Drupal blog posts this month. How does your own top 5 look like?

Photo by Bernard Hermant on Unsplash 

Apr 25 2019
Apr 25

Do you need to set up a custom image carousel? Or maybe one slider with a teaser, displaying content from your website? What are the best Drupal 8 slideshow modules to consider for implementing and maintaining your slideshow?

And out of the box options are... out of question, right? Your requirements are too specific for that.
Maybe you need:
 

  • a certain number of slider items
  • different arrow designs
  • to display the image slideshow on other pages, too, not just on your homepage
     

With such flexibility and customization requirements in mind, we started digging into the “pile” of Drupal 8 image slider modules.

And here are the 4 ones that we've selected, those with the best reviews in the Drupal community:
 

If it's a fully customized slideshow that you want to implement, Views Slideshow's the module you need.

It'll “spoil” you with tons of add-ons to select from and give your unmatched flexibility. From:
 

  • titles
  • to images
  • to teasers of the last X blog posts on your website
     

… you get to include any type of items in your carousel.

Furthermore, it's jQuery-powered and it allows you to configure different settings for each one of the views that you'll create.

Note: oh, yes, you'll need to be pretty comfortable using Views in order to leverage this module at its full capacity.

Some of its key features:
 

  • your slider can include and display the latest products added to your eCommerce website 
  • you can set up a news item slideshow (the latest X news articles published on your Drupal 8 website)
  • from the latest X blog entries to the latest videos, testimonials, forum posts etc., you're free to include any type of content in your slider...
     

Now, here's a very brief step-by-step on how you can set it up and use it to create your slideshow:
 

1.1. Install and enable the module

Once you've downloaded it from Drupal.org, installed and enabled it, make sure to download its corresponding ZIP folder on Github, as well.

Give your folder a new name  — /jquery.cycle/ — then start uploading all its files to the 
/libraries/ folder in the root of your Drupal website.
 

1.2. Set up your view

Time to create your slideshow now. For this, just go to Structure> Views>Add new view 
 

1.3. Publish your slideshow block

For this, go to Structure>Block layout and select the region on your website that you want your slider to get displayed on.
 

1.4. Create a new image style

As you can see, the images included in your slideshow are currently of different sizes. Therefore, they're not perfectly adjusted to fit the block region that you've chosen for your slider.

To solve this inconvenience, just go to Configuration>Image styles>Add Image style. 

There, you can create a new style, that will be shared by all the images included in your slideshow.
 

2. Slick Slider, One of the Most Popular Drupal 8 Slideshow Modules

Another one of Drupal's modules for creating custom image slideshows, that ships with a heavy load of options. Powerful and flexible... what more could you ask for from your slider solution?

Capitalizing on Ken Wheeler's Slick carousel, working perfectly with Views and fields, the Slick Slider module:
 

  • enables you to set up a slider including multiple views, value fields and paragraph types
  • comes with image, audio and video support
  • supports complex layouts, as well
     

Some of its key features:
 

  • you're free to enable/disable the swipe functionality
  • it's responsive (scales along with its container)
  • some of its layouts are CSS-built
  • it's designed to work with Field collection, Media, Views, Image (and also to work perfectly fine with none of these modules)|
  • it allows you to configure your own “slide selecting” dots, the arrow keys and your slider's navigation, as well
  • it provides modular and extensible skins
  • you get to choose how you want your slideshow to be scrolled: swipe, desktop mouse dragging, auto scroll, mouse wheel scroll...
     

Another one of those Drupal 8 slideshow modules that gets the best reviews.

Here's why:
 

  • it leverages the Owl Carousel slider built by OwlFonk.   
  • it, too, empowers you to customize your image slideshow; in this respect, it ships with a myriad of customization settings
  • it's responsive
  • it capitalizes on a small ecosystem of submodules: Administration UI, Views Style, Field Formatter
     

Some of its key features:
 

  • from customizing your events to styling your controls, it allows you to tailor your image slider to suit all your needs
  • it supports multiple sliders
  • touch events
     

A simple module to consider each time you need to display a group of images in a compact way on your website. It even allows you to set the number of items to be included in your carousel...

Speaking of which, you should know that jCarousel, as its name says it, allows you to leverage the jCarousel jQuery plugin.

For this, it ships with a developer API for other modules to access. Furthermore, it integrates with Views, so you can easily turn any list of images (or other type of content) into a slideshow...

Some of its key features:
 

  • jCarousel field formater
  • out-of-the-box Views support
  • API for using jCarousel without Views
  • a collection of modern skins to choose from
  • Carousel pager that enable users to jump between multiple sliders
     

The END!

These are the first Drupal 8 slideshow modules to consider when looking for the best method for setting up your custom image/content slider.

Packed with tons of customization options, feature-rich and powerful, these 4 solutions for creating image carousels in Drupal 8 should be on your short list when you start looking beyond the out-of-the-box options for putting together a slider...

Apr 24 2019
Apr 24

Simple or custom-made? Is it a quick-to-assemble, rather “prototypical” form that you need for your website? Or a more complex, custom-made one? In a Drupal 8 Contact Forms vs Webform “debate”, which Drupal form builder best suits your data collection requirements?

On one hand, you have the convenience of creating your web forms in no time: simple, straightforward, “conventional” web forms. On the other hand, you get to scan through a never-ending list of advanced options and come up with a complex, fully custom-made web form.

That, of course, if you don't mind the time you need to invest in going through all those different form elements and available features and the risk of getting... overwhelmed by tons of field customization options.

Ease of use vs unlimited capabilities...

The convenience of getting your forms up and ready to collect user data in no time vs the chance to tailor some more advanced forms, ideally customized, carrying lots of different field values.

Decisions, decision...

Now, to help you decide here's a more detailed Drupal 8 Contact Forms vs Webform comparison. Weigh each one of the 2 form modules' benefits and drawbacks, set them against your own needs and... make the choice:


1. The Contact Forms Module 

Being part of Drupal core, there's no need to download and install the module.

Just go to Structure>Contact forms. Next, choose either to opt for the default form or to set up a new one: click the “Add contact form” button.

Drupal 8 Contact Forms vs Webform: Add Contact Form


Once in the form creation screen, enter your form's values in the predefined fields that you have there:
 

  • give the form a name in the “Label” field
  • enter the email address where all the form submission will be sent to (most probably your site admin address) in the “Recipients” field
  • enter your “Thank you” text in the “Message” field there; this will be the “thank you” text line your users will see once they hit the “submit/send” button 
  • in the “Redirect path”, enter the URL to the page that you want them to get forwarded to after they've submitted the forms (that if you don't want them to be redirected back to the homepage, by default)
  • click “Save” and there you have it: a simple form, with all the basic, must-have field values, built in no time
     

Of course, that doesn't mean that you can't further explore the given features and maybe add a few more fields and even styling options.

For instance, you could “Edit” your newly created form. Just select it in the “Contact Forms” screen and, scrolling down the options in the drop-down menu opening up, click the “Manage fields” option.

Click “Add field”, then “select a field type” – Text(plain), let's say – enter the “Label” and configure its settings.

Furthermore, if you want to style your form a bit, hit the “Manage form display” tab and... opt for a placeholder, for example. Next, explore the options available in the “Manage display” screen. For instance, you get to decide if you want your field label to be hidden, inline or visually hidden...

In short: in a Drupal 8 Contact Forms vs Webform comparison, the first form builder will always outshine the latter when it comes to ease of use.

It empowers you to set up a simple form quick and easy...
 

2. The Webform Module

Now, if Contact Forms is a rather minimalist form builder, the Webform module is a feature-rich, powerful one.

The customization features that it ships with go from email notifications to fine-grained access, from statistic collection of data to delivering results in a CSV format. From exporting data in various formats to... conditional sorting and filtering.

In other words, with Webform sky is the limit when it comes to the contact form that you can create.

It can go from a basic one to a highly complex, multi-page form. One made of lots of elements, advanced options for the user to select from, settings and features for you to leverage in the back-end...

But, let's keep in mind that it's contributed module so you'll first need to download it from Drupal.org.

Next, go to “Structure” and hit the “Webforms” tab. Then, click the “Add webform” button and, in the next screen popping up, give your new form a name (enter it in the “Title” field).

You'll be automatically forwarded to the “Build” tab, which is where all the “magic happens”. Once you click the “Add element” button, you'll get to “swim through” a sea of lots and lots... and lots of form elements (known as “fields” in Contact forms) to choose from. Ranging from basic to really advanced ones...

Webform: Select an Element Screen


Let's assume that you'll want to add a “Text field” element. Click the “Add Element” button corresponding it, then scan through all the new customization options listed up in the “Add Text field element” screen opening up next...

Feel free to add other elements to your webform: a “text area” maybe, an “email” element, as well... 

Note: do keep in mind that, once you've settled for the final fields/elements to be included in your web form, you can always change the order to get them displayed in. Just drag and drop them till they fit that predefined order in your mind...

Also, you can check/mark them as “Required” and turn them into “must fill in" fields, as opposed to optional form fields.

Note: feel free to edit that “Thank you” page that your webform will automatically forward users to. How? By clicking “Back to form”>"Settings”>"Confirmation” and selecting from the different options that you have there:
 

  • enter your own Confirmation title (e.g. “Thank you!”)
  • customize your Confirmation message
     

3. Drupal 8 Contact Forms vs Webform: Key Differences

Now that we've run our spotlight over each one of these 2 form building tools, let's make an inventory of the differences that we've identified:
 

  • first of all, it's obvious that the Webform module gives you more control over your web forms' design
     
  • also, unlike Contact Forms, it supports conditional emails; you get to send an email to a specific user in your list based on conditions associated with the value of certain elements in your form
     
  • Webform enables you to add basic logic to your web forms
     
  • … it comes packed with tons of advanced options, ranging from JS effects to conditional logic, to submission handling, etc.
     
  • Contact Forms, on the other hand, allows you to set up a simple contact form in the blink of an eye; you skip the tedious process of scanning through lots and lots of options, settings, and complex features
     
  • Webform allows you to create your forms either in a YAML file or in its the admin-friendly UI
     
  • also, Webform comes as a “cluster” of submodules – Webform REST, Honeypot, Webform Views, SMTP, Webform Encrypt, etc. – which are “responsible for” its multiple capabilities
     

4. In Conclusion...

The conclusion of this Drupal 8 Contact Forms vs Webform “debate” is quite simple: 

If you need a basic form on your website and you need it built fast, go with Contact Forms. Being included in Drupal 8 adds convenience...

But if you want to customize your form (and you have the time), to style it to your liking and “turbocharge” with advanced features and options, then go with Webform.
 

It's a much more powerful and feature-rich form builder, perfectly suited for your complex requirements...


Image by Tumisu from Pixabay

Apr 17 2019
Apr 17

What makes Drupal a great choice from a UX standpoint? What features are responsible for the enhanced end-user experience in Drupal 8? Those features that enable you to easily create an intuitive and enjoyable visitor experience on your own Drupal-based website/application.

And to constantly improve it...

Is it all those performance enhancements that it ships with? Or maybe its “responsive out-of-the-box” nature? Or rather its multilingual capabilities?
 

1. But First: 7 Evergreen Ways to Improve Your Website's UX

It goes without saying that, in order to create an enjoyable, rich user experience on your Drupal 8 website, you'll need to:
 

  • put together a solid UX strategy
  • run extensive user research and map the user's journey
  • come up with an effective, well-planned UX design, paying attention to all the latest design trends (and now decoupled Drupal empowers you to tap into a whole range of new possibilities...)
     

And while carrying out all these phases of the UX design process, make sure to apply the following evergreen techniques for enhancing the visitor's experience:
 

1.1. Optimize the page loading time

For speed will always be the factor with the biggest influence on the user's experience on your Drupal site.

In this respect, there are tons of performance enhancements that you can implement, ranging from aggregating your JS and CSS files to properly configuring your cache to opting for a CDN, to...
 

2.2. Use bullets to structure your text

Bulleted lists are the “holy grail” of neatly structured, easy to read content.

For, in vain you invest time and effort in providing content that delivers real value to your website's visitors if you display it as an... “impenetrable” block of text.

In this respect, bullets help you break down the information. The result: users will see the key product or service benefits/will go through all of the presented features a lot quicker.
 

2.3. Use white space strategically

Speaking of easy to read content: there's no better way to enhance readability and to draw attention to specific elements on a page than... by using the white space itself.

It will automatically direct their attention to the text/image emphasized by all the white space surrounding it.
 

2.4. UX design is consistent Design

From color palette to button styles, from the size of the headings in your text to the chosen font, from the used photos to various design elements... keep consistency across all the pages on your Drupal website.

Otherwise, you risk to confuse and eventually... tire its visitors.
 

2.5. Go for visible, attractive CTAs

Always use action words for your calls to action and make sure they're easily recognizable. CTAs play a crucial role in setting up an intuitive, efficient navigation structure on your website...
 

2.6. Use images wisely

As images are always well-deserved “breaks” for the eye, especially when it's a long text that it's challenged to go through.

And yet, if you fail in using the relevant images, those that perfectly team up with your text... the user experience that you'll deliver will be anything but compelling...
 

2.7. Make your headings a high priority 

Remember to write your headings around some of the main keywords.

Also, strategically design them so that they're highly visible and help users to quickly scan through the content.
 

2. 4 Features Responsible for the Superior End-User Experience in Drupal 8

Gluing together all the design best practices that make a great user experience does call for a flexible and dynamic web platform.

Drupal 8 is that platform. It comes packed with some powerful features that make it easy for you to create the best visitor experience on your website.

Here are the ones with a huge influence on your website's UX:
 

2.1. Drupal 8 is responsive right out-of-the-box

And responsiveness, along with top page loading speed, still is one of those factors with a great influence on visitors' experience with your Drupal website.

With:
 

  • all the available base themes now being responsive
  • the convenience of adapting your images to various screen sizes right from their display properties
     

… creating a compelling end-user experience in Drupal 8 is dead-simple.


2.2. Enhanced performance

From a performance standpoint, Dries Buytaert's post on Drupal 8's performance optimizations is still one of the most relevant sources.

If Drupal was already built to “inject” enterprise-level performance into static pages, Drupal 8, with all its caching enhancements, is designed to speed up dynamic web pages, as well...


2.3. Multilingual capabilities

Remember the user experience's main facets, ranging from useful to findable, to valuable, to credible to... accessible?

Well, Drupal 8 provides you with multilingual capabilities right out of the box. You get to translate your website's UI, content, configuration, etc.

Meaning that, with this multilingual system at hand, you can easily create an accessible user experience on your website.


2.4. Content personalization (by segment, login time, device, language...)

In this respect, the Aqua Lift Connector module is your most reliable tool.

What it does is bring together customer data and content, so that you can deliver targeted content experiences across multiple channels and devices.
 

The END!

And these are those robust features that stand behind the superior end-user experience in Drupal 8. The very reasons why this platform, and particularly this version of Drupal, makes your best ally in creating the most compelling UX on your website.

Photo by Lucian Novosel on Unsplash

Apr 11 2019
Apr 11

With the Twig templates replacing the old PHP templates, Drupal has been brought to a whole new “era”. We can now leverage the advantages of a component-based development in Drupal 8. But what does that mean, more precisely?

How does this (not so) new approach in software development benefit you? Your own team of developers...

And everyone's talking about tones of flexibility being unlocked and about the Twig templates' extensibility. About how front-end developers, even those with little knowledge of Drupal, specialized in various languages, can now... “come right on board”. Since they're already familiar with the Twig engine...

Also, we can't ignore all the hype around the advantage of the streamlined development cycles in Drupal and of the consistent user experience across a whole portfolio of Drupal apps/websites.

But let's take all these tempting advantages of component-based UI development in Drupal 8 and point out how they benefit your team precisely.
 

1. But First: What Is a Component?

It's a standalone piece of software that can appear in multiple places across your Drupal website/application.

One of the most relevant examples is that of a content hub. One displaying teasers of the latest blog posts, events... You could set up a component that would determine how each item in that content hub should look like.

In short:
 

  • one single component can be used by several types of content
  • any update to its template/style would automatically reflect on all those content types, as well
     

Accessible via an API, this independent piece of software explicitly defines all its application dependencies.|

Your team could then easily architect a new interface by just scanning through and selecting from the library of components.
 

2. What Is Component-Driven Development? What Problems Does It Solve?

A succinct definition of component-based software engineering would be:

A software development technique where you'd select off-the-shelf, reusable components and put them together according to a pre-defined software architecture.

“And what challenges does it address?”

It streamlines and lowers the level of complexity of otherwise intricate, time-consuming development and design processes. As the author of given components, your role is to get it implemented.

No need to worry about how they'll get “assembled”; this is what the well-defined external structure is there for.

Word of caution: mind you don't get too... engrossed in putting together the right components, in architecting the best component-based structure for you then risk investing too little time in... building them properly.
 

3. Component-Based Development in Drupal 8

Now, if we are to focus our attention on the component-based UI approach in relation to Drupal 8 software development, here are the key aspects worth outlining:

  • with the Twig engine in Drupal 8, you're free to “joggle with” extensible templates; once you've defined a Twig template in one place, we get to reuse it across the whole Drupal website/app
     
  • the Component Libraries module allows you to set up template files (storing all their needed JS and CS), assign a namespace for them and place them pretty much anywhere on your Drupal filespace (not just in your themes' “templates” directory)
     
  • you then get to use the KSS Node library and define a living style guide; it's where you'll store all the component templates built for your Drupal website (styles, markup, JS behaviors, etc.)

By filling in your toolboxes with all these tools — the results of a joint effort of the Drupal and the front-end communities  —  you're empowered to design themes that are more modular. And, therefore, more efficient...


4. The Top 6 Benefits of the Component-Based UI Approach
 

4.1. It Ensures UX Consistency Across All Your Drupal 8 Websites

Take your library of components as the “headquarters” for all the teams involved in your Drupal project: QA, business, development, design teams...

It's there that they can find the pre-defined standards they need to keep the consistency of the features they implement or of other tasks they carry out across multiple projects.

A consistency that will bubble up to the user experience itself, across your whole portfolio of Drupal 8 websites/applications...
 

4.2. It Accelerates the Process of Turning Your Visual Design into a UI 

Embracing the component-based development in Drupal 8 you'd avoid those unwanted, yet so frequent scenarios where the front-end developer gets tangled up in the wireframe he receives and:
 

  • he/she translates parts of it the... wrong way
  • he digs up all types of “surprise” issues  
     

By using a component-driven UI approach translating a visual design into a user interface gets much more... event-less. 

With:
 

  • a pre-defined component architecture to rely on
  • well-established standards to follow
  • a whole library of component templates at hand
     

… there are fewer chances of discrepancies between the UX defined in the visual design and the one delivered via the resulting user interface.

Not to mention the reduced delivery timelines...
 

4.3. It Streamlines the Whole Development Process 

“Sustainability” is the best word to define this approach to Drupal software development.

Just think about it:

  • whether it's a particular grid, navigation or layout that your front-end developer needs when working on a new project, he/she can pull it right from the component library at hand
     
  • … and “inject” it into the app/website he's working on
     
  • in case that element needs further updating, the developer will already have the baseline to start with
     
  • … there's no need for new components to be designed, from the ground up, with every single project: the already existing ones can always get further extended

And that can only translate into significant savings of both time and money.
 

4.4. It Reduces the Time Spent on Setting Up the Functionality & Defining the UX

And this is one of the key benefits of using component-based development in Drupal 8. Your various teams would no longer need to define the UX requirements and the functionality every single time during the design process.

With an easily accessible library of components, they can always pull a component standing for a specific requirement (display of complex data, filtering, pagination in grids, etc.) and just define its extensions. And the business logic, as well.
 

4.5. It Enables You to Systematically Reuse Your Components

And “reusability” goes hand in hand with “sustainability”. I would even say that it's a synonym for “future-proofing”, as well...

Just think about it: having a Drupal 8 website in a component-based format you can always rearrange components as technologies grow outdated and new ones emerge...

In short, embracing a component-based development in Drupal 8 enables you to remove the need of rebuilding your website every time its underlying technologies “grow out of fashion”.

With your component library at hand, you'll be able to swap your guidelines, design patterns and various content templates in and out, keeping your Drupal app or website up to date.
 

4.6. It Integrates Seamlessly into the Development Process 

By leveraging a component-based development in Drupal 8, you'd also gain better control over the whole development cycle. The update process here included...

Since you'd then build your components and manage your production quality user interface code in a repository like GitHub, every update that you'd make will be displayed in there. And be easily accessible to everyone in your team.

In short, your developers get to pull pieces of code from the repository to further extend them, then re-submit them to GitHub (or to another source code repository) for review.

With the ability to version your component library, your team can keep a close track of all your Drupal applications with their corresponding versions of the approved UX.
 

The END!

This how the component-based development in Drupal 8 would benefit you and your team. Have we left out other key advantages of using this approach?

Image by Arek Socha from Pixabay

Apr 03 2019
Apr 03

Why would you still want to opt for a Drupal multisite setup? What strong reasons are there for using this Drupal 8 feature?

I mean when there are so many other tempting options, as well:
 

  • you could use Git, for instance, and still have full control of all your different websites, via a single codebase
  • you could go with a Composer workflow for managing your different websites
     

One one hand, everyone's talking about the savings you'd make — of both time and money — for keeping your “cluster” of websites properly updated. And yet, this convenience comes bundled with certain security risks that are far from negligible.

Just think single point of failure...

Now, to lend you a hand with solving your dilemma, let's go over the key Drupal multisite pros and cons. So that, depending on your:
 

  • developers' skill level
  • current infrastructure 
  • project budget
  • hierarchy of priorities
  • host capabilities
  • multi-site infrastructure's specific needs
     

… you can decide for yourself whether a Drupal multisite setup does suit your situation or you'd better off with one of its valid alternatives.

And whether you agree that it should eventually get removed from Drupal 9.x or not.
 

1. Drawbacks for Using the Multisite Feature/Arguments for Removing It

Now, let us expose this built-in Drupal feature's main limitations. Those that might just make you think twice before using it:

  • there's no way to update the core of just one Drupal website from your setup; you're constrained to update them all at once, every single time
     
  • it becomes quite challenging to assign a team with working on one (or some) of your websites only
     
  • it's not as richly documented as other built-in features (especially if we consider its “age”)
     
  • it exposes your Drupal multisite setup to security vulnerabilities; it's enough for one website from the “cluster” to get corrupted (accidentally or intentionally) for all the other ones to get infected
     
  • reviewing code becomes a major challenge: you can't “get away with” writing code for one website only; instead, you'll need to rewrite code on all your websites included in the setup, to test it against all breakpoints and so on...
     
  • putting together test and state environments gets a bit more cumbersome
     
  • in order to efficiently manage such an infrastructure of websites strong technical skills are required; are there any command-line experts in your team?
     
  • having a single codebase for all your Drupal websites works fine if and only if they all use the same settings, same modules; if not, things get a bit... chaotic when, for instance, there's a security issue with one module, used on all your websites, that affects your entire ecosystem
     
  • also, since your hypothetical shared database is made of a wide range of tables when you need to migrate one site only, you'll have... “the time of your life” trying to identify those tables that belong to some websites and those that they all share

2. Top 3 Reasons to Go With a Drupal Multisite Setup

Now that we've taken stock of the main drawbacks for leveraging this Drupal feature, let's try to identify the main reasons for still using it:
 

  1. A heavy-weighing reason is given by the time and money you'd save on updating your “cluster” of sites. With the right experience in using the command-line you can run the due updates in just one codebase and have them run across all your websites simultaneously
     
  2. It's an approach that becomes particularly convenient if you need self-hosting for your setup (e.g. take the case of a university hosting all its different websites or a Drupal distribution provider...)
     
  3. You'd be using less memory for OpCache and this benefit becomes particularly tempting if you're dealing with RAM constraints on your servers
     

3. In Conclusion...

There still are solid reasons to opt for a Drupal multisite setup. Reasons that could easily turn into strong arguments for not having it removed in Drupal 9.x...

But there are also equally strong reasons for getting discouraged by the idea of leveraging this age-old feature. Where do you add that from Docker to Composer and GIT, you're not running out of options for managing your “cluster” of websites.

In the end, the decision depends on your situation, that's made of specific factors like budget, hosting capabilities, whether your websites are using the same modules, etc.

The answer to your “Are there any valid reasons for using the Drupal multisite feature?” cannot be but:
 

“Yes there are, but counterbalanced by certain disadvantages to consider.”

Image by Arek Socha from Pixabay

Mar 27 2019
Mar 27

A handful of “life-saving” module releases, enlightening tutorials, well-curated  Drupal theme selections... This month has “spoiled” us with lots of valuable Drupal blog posts. Therefore, coming up with a shortlist of 5 Drupal blog posts has been quite a challenge for us here, at OPTASY.

But, in the end, we did manage to trim our bulky lists of favorites. To focus on our common preferences and keep only the following truly valuable pieces of content on Drupal in our final selection:
 

Since keeping consistency across the websites that we develop is an ever-present challenge and priority for us, this post on building pattern libraries in Drupal came in handy...

While reading it we were already:
 

  • counting just how much time we would save for creating new functionalities and setting up new pages
  • anticipating how easy it would be to maintain our future Drupal websites once we've integrated pattern libraries that anyone could tap into and streamline the creation of new features
  • imagining how convenient it would be to just reuse design elements and functionality stored in those libraries
     

Overall: we couldn't stop thinking how streamlined the whole Drupal development process would be, for all our future projects. And to what extent the end user's experience would get improved by means of... consistency.

The solution the OpsenSense Labs presents there is an effective formula: Pattern Lab + Drupal 8= Emulsify.

Then, they get into details on:
 

  • what Emulsify is: a prototyping tool leveraging atomic design that you could rely on for setting up a living style guide
  • how Emulsify works: by integrating Pattern Lab it enables you to easily put together and manage components and thus streamline your entire development process in Drupal 8
     

The team from InternetDevels have surprised us with a present in the form of a new module that has the potential to become the newest tool in our Drupal development “essential toolkit”.

One including other valuable performance optimization Drupal modules...

It's called Quicklink and here's what makes it so... “tempting”: it uses link prefetching to boost up page loading time on Drupal 8 websites.

Take this example take from their blog post: a visitor lands on a specific page on your website with the intention of accessing other links as well. Once the used browser goes idle, the module tracks down his/her viewports and caches the content corresponding to the links in that viewport.

Once he/she clicks on any of those links, the content will have already been safely stored in the cache and thus it gets displayed much quicker. That is what link prefetching is all about...

Next, the blog post's author goes on delivering details on the underlying library, the API and method this module uses for link detection and respectively waiting for the browser to go idle. Then, it gets into specific details on how to install and configure the module.
 

Why have we included Vardot's piece of content on our favorite Drupal blog posts list: March edition? 

Because versatility has been one of their key criteria when selecting those specific 7 themes. They anticipated website owners' and development teams' requirements in terms of customization and flexibility — not just look & style — when picking their Drupal themes.

In this respect, their collection included Drupal themes ranging from Progressive to Winnex, from OWL to... Edmix.
 

Dries' post is a long-time awaited news: Drupal now ships with JSON:API support.

According to his predictions, in just a few months all Drupal 8 websites will get support for this module.

What does this mean?
 

  • it means that the once far-to-reach future where Drupal would be API-first is now... closer than ever 
  • Drupal teams get empowered to create content models with no coding required, straight in the Drupal UI
  • we're being provided with a web service API that pulls that content into JS apps, voice assistants, chatbots...
     

Just imagine: with this module in core, all your comments, blog posts, tags, and other Drupal entities will get easily accessed via JSON:API web service API. This way, you can serve your content across an entire ecosystem of platforms and devices...
 

We ran over this article the other day and we know just had to add it to our top 5 favorite Drupal blog posts of the month.

It presents a solution to a too frequent challenge: handling those scenarios where you're not 100% happy with the search results provided by Search API Solr and you need to... tweak them. 

To tailor them to your specific needs, so that they're fully relevant for your end users...

Now you have the option to trigger the Drupal module Search Overrides' power. It's designed to enable website admins to override the generated search results. Manually...

Say you're one of these Drupal site admins: you choose the nodes to be placed at the top of the search results generated when entering specific search terms and remove those nodes that shouldn't get displayed. As easy as that! The module will provide you with a method to leverage whenever you need to override search results on a Drupal website.

Note: the Echidna team's now working on integrating functionality that would allow for search result overrides to be... role-specific. For instance, a Drupal back-end team would get different results compared to the end users, for the very same search term.


The END!

These pieces of content have been our top favorite Drupal blog posts this month. How about yours?

Photo by Franck V. on Unsplash

Mar 16 2019
Mar 16

Planning to build a social network with Drupal? A business community maybe? A team or department collaborating on an intranet or portal? Or a network grouping multiple registered users that should be able to create and edit their own content and share their knowledge? What are those key Drupal 8 modules that would help you get started?

That would help you lay the groundwork...

And there are lots of social networking apps in Drupal core and powerful third-party modules that you could leverage, but first you need to set up your essential kit.

To give you a hand with that, we've selected:

5 modules in Drupal 8, plus a Drupal distribution, that you'll need to start a perfectly functional social networking website, with all the must-have content management features and knowledge sharing tools.
 

Before You Get Started: A Few Things to Take Care Of

First of all, let me guess the features on your must-have list:
 

  • articles
  • groups
  • photos
  • user profiles
  • groups
  • forums
     

It should feature pages with dynamic content leveraging a fine-grained access system and social media hubs, right?

Well, now that we've agreed on this, here are the preliminary steps to take before you get actually started, installing your key modules and so on:
 

  • configure your “Taxonomy” categories after you've installed the Forum module
  • set up a custom content type for Blog posts 
  • set up your thumbnail settings for the Article nodes
  • create your key user roles (admin, content author, paid subscriptions)
  • use the PathAuto module to define your URL path structure
  • define your Article nodes' thumbnail settings and remember to upload an anchor image, as well
     

Panels and Views make a “power team” to rely on for setting up pages with dynamic content for your social networking site.

What makes it a must-have module to add to your essential kit when you build a social network with Drupal? 

It enables you to create custom layouts for multiple uses.

You get to use it to set up your website's homepage, one featuring multiple Views blocks with dynamic content retrieved from forums, articles, blogs...

Feel free to add a top slideshow image, to go for multiple-tiled stacked layout, including views from forum, blog and article posts...

In short: the Panels module empowers you to get as creative as possible when setting up fine-tuned layouts for your landing pages displaying dynamic content.
 

Not only that it enables you to present content to your social network's registered users in pretty much any form you might think of — tables, lists, blocks, forum posts, galleries, reports, graphs — but it also:
 

  • enables you to display related content (e.g. display a list of the community members along with their pieces of content)
  • enables you to use contextual filters
     

It'll turn out to be one of the handiest Drupal 8 modules in your toolbox when you need to create and display dynamic content from:
 

  • forums
  • blocks
  • blogs
     

Yet, maybe one of the most common use cases for the Views module on a social networking website is that of:

Setting up a (Views) page listing all the article posts.
 

Another module you'll most certainly want to add to your social networking website as it:
 

  • enables both single and multi-user blogs
  • empowers authorized site members to maintain it
     

Speaking of which, blog entries can be either public or private for a specific user, depending on the role he/she's assigned with.

And it's precisely that system of user roles and corresponding permissions set up on your website that will determine whether a member can:
 

  • access the “Create Content” link or not
  • access a “My Blog” section or... not
     

You can further leverage this Blog module to add a “Recent blog posts” block to your webpages, in addition to the “Blogs” navigation link on your main navigation menu.
 

4. Profile, a Must-Have Module to Build a Social Network with Drupal

You just imagine that you could build a social network with Drupal without a module enabling you to create registration page fields, now can you?

Well, here it is: the Profile module.

And here are its “superpowers”:
 

  • it enables configurable user profiles
  • it enables expanded fields on the user registration page
  • it provides social network members with two different links, one for their account settings, one for their user profiles
  • it provides private profile fields (that only the admin and that specific user can access)
  • it enables you to set up different profile types for different user roles with... different permissions granted 
     

The sky is the limit in terms of what the Group module enables you to do when you build a social network with Drupal:
 

  • it powers pretty much any scenario you can think of, from subgroups to specific per-group behavior, to access permissions...
  • it enables you to put together content collections on your website and grant access to it based on your user roles and permissions policy
  • it enables you to easily add relevant metadata to define the group & content relationships on your site
  • it enables you to control all your settings via a user-friendly admin UI; no need to write custom code to determine what each group is allowed and not allowed to do on your social network
     

I just couldn't help it...

Even though this was supposed to be a roundup of those essential modules you'll need to build a social network with Drupal, I had to add this Drupal distribution, as well.

Open Social is that out-of-the-box solution that you can leverage to get your online user community up and running in no time.

An open source software with all the needed features and functionality already pre-built, so that you can enable members on your network to:
 

  • work together
  • share knowledge
  • organize events
     

Convenience at its best when you want to start a social networking website without worrying much about:
 

  • installing a whole collection of modules
  • doing custom work in the “backstage”. 
     

The END!

This is the minimal kit you'll need to build your online community website with Drupal.

Would you have added other essential modules to the list?

Mar 06 2019
Mar 06

“Should I stay or should I go?” Should you stick to an all-too-familiar traditional CMS and “reap” the benefit of getting loads of much-needed functionality out-of-the-box? Or should you bid on flexibility, top speed, and versatility instead? In a headless CMS vs traditional CMS “debate”, which system best suits your specific needs?

Now, let me try and “guess” some of the CMS requirements on your wishlist:
 

  • to have all the needed functionality “under the same hood” (a predefined theme, robust database, a user-friendly admin dashboard...)
  • to be developer friendly
  • to integrate easily and seamlessly with any modern JS front-end of your choice
  • to “fuel” your website/app with high speed
     

Needless to add that:

You can't have them all in one CMS, either traditional or headless.

What you can actually do is:
 

  • set up a hierarchy with all your feature needs and requirements
  • set it against each of these two types of CMSs' advantages and limitations 
     

Just see which one of them “checks off” the most requirements on your list.

Then, you'd have yourself a “winner”.

So, let's do precisely that:

A headless CMS vs traditional CMS comparison to help you determine which one's... a better fit for you.
 

1. Traditional CMS: Benefits and Challenges

Everything in one place...

That would be a concise, yet fully comprehensive definition for the traditional CMS.

Just imagine a content management system that provides you with all the critical features and functionality, all the needed elements straight from the box:
 

  • a generic theme
  • a dashboard for easily managing your own content
  • a predefined database
  • PHP code for retrieving the requested content from your database and serving it to the theme layout
     

The back-end and front-end, meaning the code, database, and the layout/design, are “under the same hood”, strongly coupled. 

It's all there, pre-built, at hand... “Convenience” must be another word for “traditional CMS”.
 

Security & Performance: A Few Challenges to Consider 

Getting all that critical functionality out-of-the-box does translate into... code. Lots and lots of code, lots and lots of files.

Which also means lots and lots of potential vulnerabilities to be exploited.

There could be an error in any of the files in that heavy load of files that you get. Or a query string parameter that could be turned into “free access” into your database...

Therefore, the convenience of built-in functionality does come with its own security risks. 

Also, whenever you make a “headless CMS vs traditional CMS” comparison, always be mindful of the maintenance aspect:

Of the upgrading that you'll need to perform with every new security patch that gets released.

Now, as regards the performance “pumped” into your traditional CMS-based website/application, just think: compiling files.

That's right! Consider all those custom files, in addition to the pre-defined ones that you'll be provided with, that you'll pile up for... customizing your website. 

All these files, all the new libraries that you'll want to integrate, will need to get compiled. Which can only mean:
 

  • more stress put on your server memory 
  • copying code of functionalities that you might not even use
  • a poor page loading time, with an impact on the user experience provided on your website
     

2. A Traditional CMS Is the Best Choice for You If...

Now, you must be asking yourself: “How do I know if a traditional CMS is the best fit for my own use case?”

My answer is:

You go through the here listed “scenarios” and see if any of them matches your own.
 

  • you already have a team of PHP experts with hands-on experience working with a particular CMS (Drupal, WordPress...)
  • it's a stand-alone website that you need; no other applications and tech stack that might depend on a CMS's provided functionality
  • you're not opinionated on the technology that your website will get built on
     

3. Headless CMS: What Is an API-Based Website, More Precisely?

“It's a CMS that gives you the flexibility and freedom to build your own front-end — Angular, Rails, Node.js-based, you name it — and integrate it with content management tools via an API."

In short: your headless CMS can then serve raw content —  images, text values —  via an API, to a whole “ecosystem” of internet-connected devices: wearables, websites, mobile apps. 

And it'll be those content-consuming devices' responsibility to provide the layout and design of the content delivered to the end-users.

What's in it for you?
 

  • it dramatically streamlines the development cycle of your API-based website; you can get a new project up and running in no time
  • there's no need to pile up lots and lots of files and the code of out-of-the-box functionalities that you might not even need
  • if there's a particular service that you need — store form submissions or a weather forecast —  there's always a specific service with an API that you could integrate to have that particular content served on your website
     

A headless approach gives you the freedom to integrate exclusively the functionalities that you need into your website.

Moreover, you still get a dashboard for easily managing your content. Your headless CMS will have got you covered on this.

With no code being “forced” into your website/mobile app or need to perform a performance “routine” for this. You get it by default.
 

Security and Performance: Main Considerations

In terms of security, a short sentence could sum all the advantages that you can “reap” from having an API-based website:

There's no database...

Therefore, there are no database vulnerabilities, no unknown gateway that a hacker could exploit. 

Furthermore, in a “headless CMS vs traditional CMS” debate, it's important to outline that the first one doesn't call for an administration service. 

Meaning that you get to configure all those components delivering content to your website as you're building it. Except for that, the rest of the dynamic content gets safely stored and managed in your headless CMS.

“But can't anyone just query the service endpoints delivering content on my API-based website?”

True. And yet, there are ways that you can secure those channels:
 

  • use double-authentication for sensitive content 
  • be extra cautious when handling sensitive data; be mindful of the fact that anyone can query the JS implementation 
     

Now, when it comes to performance, keep in mind that:

It's just assets that your web server will provide. As for the content coming from all those third-party services that your headless CMS is connected with, it will get delivered... asynchronously.

Now, considering that:
 

  • most of those endpoints are hosted in the cloud and highly flexible 
  • the first response — the first static HTML file that gets served  — is instant
  • you could go with a headless CMS that leverages a CDN for delivery
  • in a traditional CMS scenario the website visitor has to wait until the server has finished ALL the transactions (so, there is a bit of waiting involved in there)
     

… you can't but conclude that in a “headless CMS vs traditional CMS” debate, the first one's way faster.
 

4. Use a Headless Approach If...
 

  • you already have your existing website built on a specific modern tech stack (Django, React, Node.js, Ruby on Rails) and you need to integrate it with a content management system, quick and easy
  • you don't your team to spend too much time “force-fitting” your existing tech stack into the traditional CMS's technology (React with... WordPress, for instance)
  • you need your content to load quickly, but you don't want a heavy codebase, specific to traditional CMSs, as well
  • you want full control over where and how your content gets displayed across the whole ecosystem of devices (tablets, phones, any device connected to the IoT...)
  • you don't want to handle all the hassle that traditional CMS-based websites involve: scaling, hosting, continuous maintenance 
     

5. Headless CMS vs Traditional CMS: Final Countdown

Now, if we are to sum it up, the two types of CMSs' pros and cons, here's what we'd get:
 

Traditional CMS

It comes with a repository for your content, as well as a UI for editing it and a theme/app for displaying it to your website visitors.

While being more resource-demanding than a headless CMS, it provides you with more built-in functionality.
 

Headless CMS

It, too, provides you with a way to store content and an admin dashboard for managing it, but no front-end. No presentation layer for displaying it to the end user.

Its main “luring” points?
 

  • it's faster
  • it's more secure
  • more cost-effective (no hosting costs)
  • it helps you deliver a better user experience (you get to choose whatever modern JS framework you want for your website's/app's “storefront”)
     

It's true, though, that you don't get all that functionality, right out-of-the-box, as you do when you opt for a traditional CMS and that you still need to invest in building your front-end.

In the end, in a “headless CMS vs traditional CMS” debate, it's:
 

  • your own functionality/feature needs
  • your versatility requirements 
  • the level of control that you wish to have over your CMS
  • your development's team familiarity with particular technologies
     

… that will influence your final choice.

Photo by rawpixel on Unsplash

Mar 01 2019
Mar 01

Which of those Drupal modules that are crucial for almost any project make you want to... pull your hair out? 

For, let's face it, with all the “improving the developer experience” initiatives in Drupal 8:
 

  • BigPipe enabled by default
  • the Layout Builder
  • Public Media API
  • and so on
     

… there still are modules of the “can't-live-without-type” that are well-known among Drupal 8 developers for the headaches that they cause.

And their drawbacks, with a negative impact on the developer experience, go from:
 

  • lack of/poor interface
  • to a bad UI for configuration
  • to hard-to-read-code
  • too much boilerplate code, verbosity
  • to a discouragingly high learning curve for just one-time operations
     

Now, we've conducted our research and come up with 4 of the commonly used Drupal modules that developers have a... love/hate relationship with:
 

1. Paragraphs, One of the Heavily Used Drupal Modules 

It's one of the “rock star” modules in Drupal 8, a dream come true for content editors, yet, there are 2 issues that affect developer experience:
 

Developers are dreaming of a... better translation support for the Paragraphs module. And of that day when the deleted pieces of content with paragraphs data don't remain visible in their databases.
 

2. Views

Here's another module with its own star on Drupal modules' “hall of fame” that...  well... is still causing developers a bit of frustration:

You might want to write a query yourself, to provide a custom report. In short, to go beyond the simple Views lists or joins. It's then that the module starts to show its limitations.

And things to get a bit more challenging than expected. 

It all depends on how “sophisticated” your solution for setting up/modifying your custom query is and on the very structure of the Drupal data.

Luckily, there's hope.

One of the scheduled sessions for the DrupalCon Seattle 2019 promises to tackle precisely this issue: how to create big, custom reports in Drupal without getting your MySQL to... freeze.
 

3. Migrate 

There are plenty of Drupal developers who find this module perfectly fit for small, simple website migration projects. And yet, they would also tell you that it's not so developer friendly when it comes to migrating heavier, more complex websites.

Would you agree on this or not quite?


4. Rules 

Another popular Drupal module, highly appreciated for its flexibility and robustness, yet some developers still have a thing or two against it:

It doesn't enable them to add their own documentation: comments, naming etc.

And the list could go on since there are plenty of developers frustrated with the core or with the Commerce Drupal module...

The END!

What do you think of this list of Drupal modules that give developers the most headaches? Would you have added other ones, as well?

What modules do you find critical for your projects, yet... far from perfect to work with?

Feb 26 2019
Feb 26

Kind of stuck here? One one hand, you have all these software development technologies that are gaining momentum these days —  API, serverless computing, microservices — while on the other hand, you have a bulky "wishlist" of functionalities and expectations from your future CMS.  So, what are those types of content management systems that are and will be relevant many years to come and that cover all your feature requirements?

And your list of expectations for this "ideal" enterprise-ready content infrastructure sure isn't a short one:
 

  • to enable you to build content-centric apps quick and easy
  • multi-languages support
  • user role management
  • a whole ecosystem of plugins
  • inline content editing
  • to be both user and developer friendly
  • personalization based on visitors' search history
  • to support business agility
  • search functions in site
     

... and so on.

Now, we've done our research.

We've weighed their pros and cons, their loads of pre-built features and plugins ecosystems, we've set them against their “rivaling” technologies and selected the 3 content management systems worth your attention in 2019:
 

But What Is a Content Management System (CMS)? A Brief Overview

To put it simply:

Everything that goes into your website's content —  from text to graphics — gets stored in a single system. This way, you get to manage your content — both written and graphical — from a single source.

With no need for you to write code or to create new pages. Convenience at its best.
 

1. Traditional CMS, One of the Popular Types of Content Management Systems

Take it as a... monolith. One containing and connecting the front-end and back-end of your website: both the database needed for your content and your website's presentation layer.

Now, just turn back the hands of time and try to remember the before-the-CMSs “era”. Then, you would update your HTML pages manually, then upload them on the website via FTP and so on...

Those were the “dark ages” of web development for any developer...

By comparison, the very reason why content management systems — like Drupal, WordPress, Joomla — have grown so popular so quickly is precisely this empowerment that they've “tempted” us with:

To have both the CMS and the website's design in one place; easy to manage, quick to update.
 

Main benefits:
 

  • your whole website database and front-end is served from a single storage system
  • they provide you with whole collections of themes and templates to craft your own presentation layer
  • quick and easy to manage all your content
  • there are large, active communities backing you up
     

Main drawbacks:
 

  • they do call for developers with hands-on experienced working with that a specific CMS
  • except for Drupal, with its heavy ecosystem modules, content management systems scale don't scale well
  • they require more resources —  both time and budget — for further maintenance and enhancement
     

A traditional CMS solution would fit:
 

  • a small business' website
  • a website that you build... for yourself
  • an enterprise-level website
     

… if and only if you do not need it to share content with other digital devices and platforms.

You get to set up your website and have it running in no time, then manage every aspect of it from a single storage system.

Note: although more often than not a traditional CMS is used to power a single website, many of these content infrastructures come with their own plugins that fit into multi-site scenarios or API access for sharing content with external apps.
 

2. Headless CMS (or API-First Pattern)

The headless CMS “movement” has empowered non-developers to create and edit content without having to get tangled up in the build's complexities, as well. Or worrying about the content presentation layer: how it's going to get displayed and what external system will be “consuming” it.

A brief definition would be:

A headless CMS has no presentation layer. It deals exclusively with the content, that it serves, as APIs, to external clients.

And it's those clients that will be fully responsible with the presentation layer.

Speaking of which, let me give you the most common examples of external clients using APIs content:
 

  • static page application (SPA)
  • client-side UI frameworks, like Vue.js or React
  • a Drupal website, a native mobile app, an IoT device
  • static site generators like Gatsby, Jekyll or Hugo
     

A traditional CMS vs headless CMS comparison in a few words would be:

The first one's a “monolith” solution for both the front-end and the back-end, whereas the second one deals with content only.

When opting for a headless CMS, one of the increasingly popular types of content management systems, you create/edit your website content and... that's it. It has no impact on the content presentation layer whatsoever.

And this can only translate as “unmatched flexibility”:

You can have your content displayed in as many ways and “consumed” by as many devices as possible.
 

Main benefits:
 

  • front-end developers will get to focus on the presentation layer only and worry less about how the content gets created/managed
  • content's served, as APIs, to any device
  • as a publisher you get to focus on content only
  • it's front-end agnostic: you're free to use the framework/tools of choice for displaying it/serving it to the end-user
     

Main drawbacks:
 

  • no content preview 
  • you'd still need to develop your output: the CMS's “head”, the one “in charge” with displaying your content (whether it's a mobile app, a website, and so on)
  • additional upfront overhead: you'd need to integrate the front-end “head” with your CMS
     

In short: the headless CMS fits any scenario where you'd need to publish content on multiple platforms, all at once.
 

3. Static Site Generators (Or Static Builders)

Why are SSGs some of the future-proofed content management systems? 

Because they're the ideal intermediary between:
 

  • a modular CMS solution
  • a hand-coded HTML site
     

Now, if we are to briefly define it:

A static site generator will enable you to decouple the build phase of your website from its hosting via an JAMstack architectural pattern.

It takes in raw content and configures it (as JSON files, Markdown, YAML data structures), stores it in a “posts” or “content” folder and, templating an SSG engine (Hugo, Jekyll, Gatsby etc.), it generates a static HTML website with no need of a CMS.

How? By transpiling content into JSON blobs for the front-end system to use. A front-end system that can be any modern front-end workflow.

And that's the beauty and the main reason why static site generators are still, even after all these years, one of the most commonly used types of content management systems:

They easily integrate with React, for instance, and enable you to work with modern front-end development paradigms such as componentization and code splitting. 

They might be called “static”, yet since they're designed to integrate seamlessly with various front-end systems, they turn out to be surprisingly flexible and customizable.
 

Main benefits:
 

  • they're not specialized on a specific theme or database, so they can be easily adapted to a project's needs
  • Jamstack sites generally rely on a content delivery network for managing requests, which removes all performance, scaling and security limitations 
  • content and templates get version controlled with right out of the box (as opposed to the CMS-powered workflows)
  • since it uses templates, an SSG-based website is a modular one
     

And, in addition to their current strengths, SSGs seem to be securing their position among the most popular types of content management systems of the future with their 2 emerging new features:
 

  • the improvement of their interface for non-developers (joining the “empower the non-technical user” movement that the headless CMS has embraced); a user-friendly GUI is sure to future-proof their popularity
  • the integrated serverless functions; by connecting your JAMstack website with third-party services and APIs, you get to go beyond its static limitation and turbocharge it with dynamic functionality 
     

To sum up: since they enable you to get your website up and running in no time and to easily integrate it with modern front-end frameworks like Vue and React, static site generators are those types of content management systems of the future.

The END!

What do you think now? Which one of these CMS solutions manages to check off most of the feature and functionality requirements on your wishlist?

Feb 14 2019
Feb 14

How do you run a page speed audit from a user experience standpoint? For, let's face it: website performance is user experience! 

What are the easiest and most effective ways to measure your Drupal website's performance? What auditing tools should you be using? How do you identify the critical metrics to focus your audit on?

And, once identified, how do you turn the collected data into speed optimization decisions? Into targeted performance improvement solutions...

Also, how fast is “ideally fast”, in the context of your competition's highest scores and of your users' expectations?

Here are the easiest steps of an effective page performance audit, with a focus on the prompt actions you could take for improving it.
 

1. Front-End vs Back-End Performance

They both have their share of impact on the overall user experience:

Long response times will discourage, frustrate and eventually get your website visitors to switch over to your competition.
 

Front-End Performance 

It's made of all those elements included in the page loading process, as being executed by the browser: images, HTML, CSS and JavaScript files, third-party scrips...

The whole process boils down to:

Downloading all these elements and putting them together to render the web page that the user will interact with.
 

Back-End Performance 

It covers all those operations performed by your server to build page content.

And here, the key metrics to measure is TTFB (Time To First Byte).

It's made of 3 main elements:
 

  1. connection latency
  2. connection speed
  3. the time needed for the server to render and serve the content
     

2. What Should You Measure More Precisely? 5 Most Important Metrics

What metrics should you focus your page speed audit on? Here's a list of the 5 most relevant ones:
 

a. Speed index

The essential indicator that will help you determine the perceived performance on your Drupal website:

How long does it take for the content within the viewport to become fully visible?

When it comes to optimization techniques targeting the speed index, “battle-tested” techniques, like lazyloading and Critical CSS, are still the most effective ones.
 

b. Time to first byte

As previously mentioned, the back-end performance:

Measures the time passed from the user's HTTP request to the first byte of the page being received by the browser.
 

c. Start render

The time requested for rendering the first non-white content on the client's browser.

Note: the subsequent requests are “the usual suspects” here, so you'd better ask yourself how you can reduce, defer or relocate them. Maybe you'd consider a service worker?
 

d. Load time

How long does it take for the browser to trigger the window load event? For the content on the requested page to get loaded?

Note: consider enabling HTTP/2, with a dramatic impact on individual page requests.
 

e. Fully loaded

It measures the time of... zero network activity. When even the JavaScript files have all been already fired.

Note: make sure your third-party scripts are “tamed” enough. They're the main “responsible” factors for high fully loaded times.
 

3. How to Perform a Page Speed Audit: 5 Useful Tools

Now that you know what precisely to analyze and evaluate, the next question is:

“How do I measure these key metrics?”

And here are some of the easiest to use and most effective tools to rely on when running your page performance audit:
 

Use them to:
 

  • collect your valuable data on all the above-mentioned metrics
  • get an insight into the page rendering process performed by the browser
  • identify the “sore spots” to work on
  • automate repeated page speed tests
  • keep monitoring your website (SpeedCurve) across multiple devices and in relation to your competition's performance 
  • get a peek into your web page's structure and into the process of downloading resources over the network (Chrome DevTools)


4. 3 Key Benchmarks to Evaluate Your Website's Performance

So, now that you've got your “target metrics” and your toolbox ready, you wonder: 

“What should I measure those metrics against?”

And here, there are 3 major benchmark-setting processes to include in your page speed audit:
 

  • determine your competition: your current production site before its rebuild, your direct and indirect “rivaling” websites
  • determine the key pages on your Drupal website: homepage, product listing page, product detail page etc.
  • measure your competition's web page performance
     

5. Most Common Performance Bottlenecks & Handiest Solutions

Here are the most “predictable” culprits that you'll identify during your page speed audit, along with the targeted performance-boosting measures to take:
 

Factors Impacting the Front-End Performance & Solutions

a. Too many embedded resources

Too many embedded stylesheets, JavaScript and images are an extra challenge for your page loading time. They'll just block the rendering of the page.

Each connection setup, DNS lookup and queuing translates into... overhead, with an impact on your site's perceived performance.

The solution: consider caching, minification, aggregation, compression...
 

b. Oversized files

And images (stylesheets and JavaScript) sure are the main “culprits” for long response times on any Drupal website. 

The solution: consider aggregating/compressing them, turning on caching, lazyloading, resizing etc.
 

c. Wrongly configured cache

Is your website properly cached? Have you optimized your cache settings? Or is it possible that your Drupal cache could be broken? 

If so, then it will have no power to reduce latency, to eliminate unnecessary rendering.

The solution: look into your response headers, URL/pattern configuration, expiration and fix the problem cache settings.
 

d. Non-optimized fonts

Your heavy fonts, too, might play their part in dragging down your website.

The solution: consider caching, delivery, compression, and character sets.
 

In conclusion: do re-evaluate all your modal windows, third-party scripts and image carousels. Is their positive impact on the user experience worth the price you pay: a negative impact on your page loading time?  
     

Word of caution on caching:

Mind you don't overuse caching as a performance boosting technique. If there are serious back-end performance issues on your website, address them; using caching as the solution to mask them is not the answer. It works as a performance improvement technique on already working systems only.
 

Factors Impacting the Back-End Performance & Solutions

And there are some handy, straightforward measures that you could take for addressing back-end performance issues, as well:

  • Consider optimizing the page rendering process directly in the CMS.
     
  • Upgrade your server's hardware infrastructure (e.g. load balancing, RAM, disk space, MySQL tuning, moving to PHP7).
     
  • Keep the number of redirects to a minimum (since each one of them would only add another round trip, which bubbles up to the TTFB).
     
  • Reconfigure those software components that are lower in the server stack (caching back-end, application container).
     
  • Consider using a CDN; it won't serve everything, plus it will lower the distance of a round trip.
     
  • Consider using Redis, Varnish.
     

6. Final Word(s) of Advice

Here are some... extra tips, if you wish, to perform a page speed audit easily and effectively:
 

  • remember to run your audit both before and after you will have applied your targeted performance improving techniques
  • grow a habit of tracking weekly results
  • define the goal of your Drupal website performance test: what precisely should it test and measure and under which circumstances?
  • … for instance, you could be analyzing your site's back-end performance only: the time requested for generating the most popular web pages, under a load of 700 concurrent visitors, let's say (so, you won't be testing connection speed or the browser rendering process)
  • pay great attention to the way you configure your page speed audit system if you aim for accurate and representative results
     

The END!

This is the easy, yet effective way of performing a website speed and optimization audit. What other tools and techniques have you been using so far?

Photo by Veri Ivanova on Unsplash

Feb 06 2019
Feb 06

API first, responsive Bartik, headless and decoupled Drupal, Layout Builder, React admin UI... Drupal's evolved tremendously over these 18 years! Yet: the emails that we send out via its otherwise robust email sending system aren't different from those we used to send a... decade ago. And customers expect rich experiences outside your Drupal website or app. While website administrators expect to be enabled to easily manage, via the admin UI, their email content templates. So: how do you send HTML emails in Drupal 8?

Without relying on external services, of course...

And who could blame customers for expecting 2019-specific user experiences? Experiences that HTML-enabled emails deliver through their great features.

Features that support Drupal editors' marketing efforts, as well:
 

  • traffic-driving hyperlinks; you get to link to your landing page right from the email
  • visually attractive custom design; emails that look just like some... microsites
  • all sorts of design details that reinforce your brand: buttons over cryptic links, responsive design, templated footers and headers
  • web fonts
  • QR codes 
  • hierarchical display of content, that enhances readability and draws attention to key pieces of content and links in your email
  • images and attachments
  • tracking for monitoring opens
     

And speaking of admin and/or editors, the questions they ask themselves are:

“How can I easily theme the emails to be sent out?”

“How can I change their content templates right from the admin UI?”

And these are the questions that I'll be answering to in this post.

Here are your current options at hand — 3 useful Drupal 8 modules — for easily crafting and sending out HTML emails that appeal and engage.
 

It does exactly what you'd expect:

It enables you to configure HTML emails from Drupal 8.

It's the Drupal 7 go-to option whenever you want to go from plain text emails to HTML-formatted ones. A module available for Drupal 8 in alpha version.

Furthermore, it integrates superbly with the Echo and the Mail MIME modules.
 

2. The Swift Mailer Module, The Best Way to Send HTML Emails in Drupal 8

Swift Mailer is the highly recommended method for configuring Drupal 8 to send out visually-arresting, HTML emails.

Since you can't (yet) send them right out of the box with Drupal...

The module stands out as the best option at hand with some heavy-weighing features:
 

  • it supports file attachments
  • it supports inline images, as well
  • it enables admins to send HTML (MIME) emails
  • … to send them out via an SMTP server, the PHP-provided mail sending functionality or via a locally installed MTA agent
     

Note: you even get to use this module in tandem with Commerce to send out your HTML-enabled emails. There's even an initiative underway for replacing Drupal's deprecated core mail system with the Swift Mailer library.

And now, here are the major configuration steps to take to... unleash and explore this module's capabilities:
 

  • first, set up the Swift Mailer message (/admin/config/swiftmailer/messages) settings to use HTML
  • next, configure the Swift Mailer transport settings (/admin/config/swiftmailer/transport) to your transport method of choice 
  • and finally, configure the core mail system settings to use this module for the formatter and the sender plugins
     

And if you're not yet 100% convinced that the Swift Mailer module is significantly superior to Drupal's default mail system, here are some more arguments:
 

  • it enables you to send... mixed emails: both plain text and HTML-enabled
  • it provides HTML content types
  • it supports various transport methods: Sendmail, PHP, SMTP (the current mail system supports but one method)
  • it enables you to integrate key services with Drupal —  like Mandrill, SendGrid —  right out of the box
  • it incorporates a pluggable system, allowing you to further extend its functionality
     

How about now? Are these strong enough arguments that Swit Mailer's the way to send HTML emails in Drupal 8?
 

Another option for configuring Drupal 8 to send out HTML emails is the PHPMailer module.

How does it perform compared to Swift Mailer?
 

  • It's not pluggable
  • it's not as easily customizable as Swift Mailer 
  • it's already embedded in the SMTP module (in fact, in Drupal 8 the default mail interface class is named “PHPMail” instead of DefaultMailSystem)
     

What features does it share with Swift Mailer?
 

  • it enables you to send out HTML-enabled emails with Drupal
  • it enables you to add attachments to your emails
  • it, too, enables you to send out mixed emails
  • it, too, supports external SMTP servers
     

Moreover, you can extend its core functionality by integrating it with the Mime Mail component module (currently in alpha 2 version for Drupal 8).
 

4. The Mime Mail Component Module

Briefly, just a few words about Mime Mail:
 

  • as already mentioned, it's a “component module”, that can be used for boosting other modules' functionality
  • it enables you to send out HTML emails with Drupal: your mail would then incorporate a mime-encoded HTML message body
  • it enables you to set up custom email templates: just go to your mimemail/theme directory, copy the mimemail-message.tpl.php file and paste it into your default theme's folder; this way, your email will take over your website's design style 
  • any embedded graphics gets Mime-encoded, as well, and added as an attachment to your HTML email
  • do some of your recipients prefer plain text over richly formatted HTML emails? Mime Mail enables you to switch your email content over to plain text to meet their specific preferences
     

The END!

Now that you know your options, it's time to step out from the (too) long era of rudimentary, plain emails sent out with Drupal.

... and into the era of richly formatted HTML emails, that will:
 

  • enrich your customers' experiences
  • enhance Drupal 8 site admins' experience
Feb 01 2019
Feb 01

Just imagine it: Drupal 8's robust features as a CMS, the flexible e-commerce functionality of the Drupal Commerce ecosystem and a JavaScript framework for the front-end! All in the same native mobile app! You can easily achieve this “combo” — a reliable content repository & a JS-based front-end providing a fantastic shopping cart experience — if you just... decouple Drupal Commerce.

For why should you trade Drupal's battle-tested content authoring and administration tools for a more interactive user experience? 

And why should you give up on your goal to deliver richer cart experiences just because Drupal 8 can't rival the JavaScript in terms of advanced native mobile app functionality?
 

  • push notifications
  • complex shopping options
  • enabling users to manage their own delivery times and places
  • ... to configure various aspects of their orders and so on
     

Just leverage a decoupled Drupal Commerce strategy in your shopping app project and you can have both:
 

  • Drupal as your secure content service 
  • the front-end framework of your choice “in charge” with the user experience 
     

In this respect, these are the most useful Drupal tools at hand for implementing an API-based headless architecture:
 

1. Headless Commerce Comes Down to...

… separating your commerce stack (back-end content handling area, data store etc.) from the user interface.

Or the “head”, if you wish.

The presentation layer would “retrieve” content from the back-end content storage area and is the one fully “responsible” with delivering fantastic user experience.

This way, you're free to choose your own front-end tools.

Now, why would you consider choosing a decoupled architecture for your e-commerce solution? The benefits are quite obvious and not at all negligible:
 

  • higher flexibility and scalability (that JS frameworks are “famous” for)
  • freedom to customize your app to your liking (for every platform or/and device)
  • richer, more interactive shopping experiences 
     

2. Decoupled Drupal Commerce... Out of the Box? The Commerce Demo 

Narrowing our focus down to... Drupal, to Drupal Commerce, more specifically, the question's still there:

“How do I decouple Drupal Commerce?”

Considering that:
 

  • there are specific challenges that such a decoupled front-end architecture poses
  • Drupal solutions like Forms API and Views won't fit your specific (probably quite complex) design implementation requirements
     

Luckily, the Commerce Guys team has already faced and solved these challenges.

First of all, they've put together the Commerce Demo project, a store providing default content to be “injected” into Drupal.

Secondly, their attempt at integrating a design meant to support advanced functionality, for richer shopping cart experiences, resulted in 2 new modules:
 

  • Commerce Cart API
  • Commerce Cart Flyout
     

More about them, here below...
 

3. Useful Modules to Decouple Drupal Commerce 

Here's a collection of the most... relevant modules that you could use in your headless Drupal Commerce project:
 

3.1. The Commerce Cart API Module

It's no less than a handy Drupal tool that enables you to custom build your shopping cart widget. 
 

3.2. The Cart Flayout Module

The go-to module when you need to ajaxify the “Add to cart” form in your shopping app.

Basically, what it does is:

Provide a sidebar that “flies out” once the user clicks the “Add to cart” button or the cart block.

If I were to dive into details a bit, I'd add that the flyout enables users to:
 

  • view the products in their shopping carts
  • remove all the items there
  • update the quantity of a specific item
     

Should I add also that Cart Layout comes with no less than 9 different Twig templates, for various parts of the module? By leveraging Drupal's library management feature you can easily override these JS segments of the module.

And not only that you get to customize it to suit your needs entirely, but:
 

  • it comes with a well structured JS logic
  • it's built on top of Backbone
     

… which translates into an efficient models-views separation.
 

3.3. Commerce 2

Use Drupal Commerce 2 as the core structure of your e-commerce project.

Being an ecosystem of Drupal 8 modules and “spoiling” you with unmatched extensibility via its APIs, Drupal Commerce empowers you to implement all kinds of headless commerce scenarios.

It enables you to use Drupal as your content/data (user and order-related info) repository and to easily serve this content to your mobile app. To your end-users.
 

3.4. The Commerce Recurring Framework Module

Some of its handy charging & billing features include:
 

  • configurable billing cycles
  • configurable retries in case of payment declines
  • both prepaid and postpaid billing systems
     

3.5 The JSON API & JSON API Extras Modules   

Need to decouple Drupal Commerce, to enable a full REST API in JSON format? 

It's as easy as... enabling a module (or 2 at most): the JSON API module.

What it does is:
 

Expose the API so you can vizualize the data in JSON format.

And Drupal's built and perfectly adapted to support JSON API, which turns it into the go-to option when you need a back-end content repository for your headless shopping app.

In addition to this module, feel free to enable JSON API Extras, as well. It comes particularly handy if you need to customize the generated API. 

It allows you to:
 

  • override the name of your resources
  • change their path...
     

You'll then have a specific place in your app's user interface where you can visualize your content paths.

Once you have your data in JSON format, safely stored in your back-end content creation & moderation Drupal area, you're free to... serve it to your mobile shopping app!
 

The END!

And these are some of the already tested tools and techniques to decouple Drupal Commerce so that you can deliver richer, more interactive cart experiences.

Have you tried other modules/methods? Writing custom JavaScript code... maybe?

Jan 25 2019
Jan 25

Let's say you've been working on this contributed project for a few months now. It has gone from Beta 1 to Beta 2 to Beta... Now, how long till its final release? How do you know when it's ready for the Drupal community to see and use? And this is precisely why the Drupal quality initiative was launched in the first place.

So that can we finally have some sort of a checklist at hand to use whenever we need to assess our code's level of quality:
 

  • the standards that we should evaluate our contributed projects by 
  • the specific elements that go into the quality of our projects, such as contributed Drupal modules
  • a certain hierarchy of quality that we could rate our own projects by
     

And so on...

For, let's admit it now:

Except for our own personal methodologies for self-assessment, there's no standardized benchmark that could help us evaluate our contributed Drupal projects. There's no way of knowing for sure when our projects are 100% ready to go from beta to... full release.

Now, here are the legitimate questions that this initiative brings forward, along with some of the suggested paths to take:
 

1. What Drupal-Specific Quality Metrics Should We Use to Evaluate Our Code?

How do you know when your contributed project is efficient enough to... be used by other members of the Drupal community?

You need some sort of criteria for measuring its level of quality, right? 
 

2. The Drupal Quality Initiative: A Checklist for Project Quality Assessment

And this is how the “Big Checklist” for Drupal modules has been put together. One outlining all those areas of a contributed Drupal project that you should carefully evaluate when assessing its quality.

Areas such as:
 

  • team management
  • documentation
  • testing
  • code
  • design
  • requirements
  • DevOps
     

All those factors and Drupal-specific elements that go into the quality of a contributed project.


3. Introducing the Idea of a Multi-Leveled Quality Hierarchy

What if we had multiple levels of quality to rate our Drupal projects?

Imagine some sort of hierarchy of quality that would challenge us to keep improving the way we write code for Drupal. To keep growing as teams working with Drupal.

Your project might be rated “level 1”, from a quality standpoint, on its first release. But it would still stand stand the chance to get a higher score for if you strove to meet all the other criteria on the checklist.


4. You'll Be Particularly Interested in The Drupal Quality Initiative If You're A...
 

  1. Site builder, scanning through the pile of contributed Drupal modules in search of the ones that perfectly suit your project's specific needs
  2. Drupal contributor in need of some sort of checklist that would include all those standards of quality and best practices to help you assess your own code's value
     

5. What About Non-Drupal Software Projects? How Is Their Quality Assessed?

In other words: how do other communities assess their projects' levels of quality?

What metrics do they use?

And here, the Drupal quality initiative's... initiator gives the “The Capability Maturity Level”, set up by the Software Engineering Institute, as an example.

The process model highlights 5 levels of “maturity” that a project can reach throughout its different development phases.They range from:
 

  • the“initial chaos”
  • to planning and collecting project requirements
  • … all the way to continuous process improvement
     

Now, just imagine a similar multi-level evolutionary benchmark that we could use to assess our own Drupal projects' levels of... maturity.
 

6. A Few Quality Indicators and Suggested Tools

And the whole Drupal Quality Initiative comes down to identifying the key endpoints for assessing a project's quality, right?

Here are just some of the suggested questions to use during this evaluation process:
 

  • Is it easy to use?
  • Does it perform the intended functions?
  • Is it efficient enough?
  • How many detected bugs are there per 1000 lines of code
  • How secure is it?
     

Now, for giving the most accurate answers to these quality assessing questions, you'll need the right toolbox, right?

All those powerful tools to help you:
 

  • check whether your code is spell checked
  • monitor the status of specific operations
  • check whether all strings use translation
  • see whether your code has been properly formatted
     

The END! And this is just a brief overview of the Drupal Quality Initiative.

What do you think now, does the suggested checklist stand the chance to turn into a standardized Drupal benchmark for assessing quality?

How do you currently determine your contributed projects' value?

Jan 23 2019
Jan 23

Progressively decoupled Drupal has gone from concept to buzzword. Until recently, when we've started to witness sustained efforts being made to set up a standard workflow for implementing this architecture.

New dedicated modules have been developed to fit those use cases where just a few particular blocks, affecting the website's overall performance, need to be decoupled. All while preserving Drupal's standard robust features.

Features too famous among content editors and site builders to be sacrificed in the name of high speed and rich UX. 

We've gradually shifted focus from “Why would I choose progressive decoupling over a headless CMS?” to:

“How precisely do I implement the progressive approach into my own decoupled Drupal project? Is there a standardized process, based on a set of dedicated modules, that I can leverage?”

And this is what I'll be focusing on in this post here.

More precisely, on the efforts for standardizing the whole workflow: see Decoupled Blocks and the SPALP module!
 

1. Progressively Decoupled Drupal: Compromise or Viable Alternative to an All-In Transition?

Is this approach nothing but a compromise between:
 

  • content editors — and all Drupal users working in the site assembly —  who depend on key features like content workflow, layout management, site preview, seamless administrative experience
  • and front-end developers, who're “dying” to “inject” application-like interactivity and high-speed front-end technologies into certain portions of the Drupal web pages?
     

Progressively decoupling blocks in Drupal is, indeed, the best compromise you could get between:
 

  1. your editorial team's “fear” of losing familiar Drupal features critical for their workflow
  2. front-end developers willing to experiment with new technologies promising top speed and richer user experiences
     

Developers get to leverage the JavaScript framework of their choice without interfering with the site assemblers' workflow. Flexibility at its best!

But does being a viable compromise makes it also a worthy alternative to the fully decoupling option?

It does.

Specifically because:
 

  1. it caters to all those who haven't been won over by the “headless CM movement” 
  2. it removes the risk of trading vital Drupal functionality for the benefits of a powerful front-end framework
     

In other words:

For all those Drupal projects requiring that only certain components should be decoupled, an all-in transition would be simply... redundant and unnecessarily risky.

For all those projects there's the progressively decoupled Drupal alternative.
 

2. Why Has this Approach to Decoupling Drupal Been So Unpopular?

How come the progressively decoupled Drupal strategy gained so little traction?

It seems that despite its drawbacks — the need to reinvent some of the lost “Drupal wheels” and its higher costs — the fully decoupled approach has been more popular.

And there are 3 main causes for this, that Dries Buytaert identified and exposed in his blog post on “How to Decouple Drupal in 2018”:
 

  1. progressive decoupling doesn't leverage server-side rendering via Node.js
  2. modern JavaScript cohabits with old-school PHP
  3. JavaScript's ascension is not going to stop any time soon; therefore, the risk of sacrificing some of Drupal's popular capabilities might still seem insignificant compared to the JS advantages at a front-end level
     

3. The SPALP Module: Towards a Standard Workflow for Implementing Progressive Decoupling

Now, back to this blog post's main topic:

Clear pieces of evidence that we're finally heading towards a standardized process for implementing this type of decoupled system.  

And one such evidence is the SPALP module: Single Page Application Landing Page. 

Here's a specific use case, so you can get an idea of its role in the entire workflow of a progressively decoupled Drupal project:

Let's say that you need to integrate a couple of JavaScript-based one-page apps into your Drupal website. The CMS will continue to be “in charge” of the page rendering, access control routing and navigation, while the JS apps would be developed independently, outside of Drupal. How would you configure these JS apps as Drupal web pages?

You'd use the SPALP module to configure each one of them so that:
 

  1. you stay consistent and “joggle with” the same configuration every time you need to add a new app to your Drupal website
  2. you make its easy for your content team to manage this entire ecosystem of single-page JavaScript apps
     

“And how does this module work?”

Here's the whole “back-stage” mechanism:
 

  1. the SPALP module helps you to set up a new “app landing page" content type, the one providing the URL for the app about to be integrated
  2. each one of these applications must have its own module that would declare a dependency on SPALP, include its JSON configuration and define its library
  3. once a module meeting all these requirements is enabled, SPALP will create a landing page node for it, which will store the initial configuration
  4. the SPALP module will add the pre-defined library and a link to an endpoint serving JSON each time that node is viewed
     

Note: speaking of the efforts made to create a “Drupal way” of implementing this decoupled architecture, you might want to check out Decoupled Blocks, as well. It's designed to empower front-end developers to use the JS framework of their choice to develop individual custom blocks that would be later on integrated into Drupal. No Drupal API knowledge required!


The END!

What do you think: will the community continue their efforts to build a standard workflow for the progressively decoupled Drupal approach? Or will it remain a conceptual alternative to headless Drupal?

Jan 16 2019
Jan 16

Accidentally creating duplicate content in Drupal is like... a cold: 

Catching it is as easy as falling off a log.

All it takes is to:
 

  • further submit your valuable content on other websites, as well, and thus challenging Google with 2 or more identical pieces of content
  • move your website from HTTP to HTTPs, but skip some key steps in the process, so that the HTTP version of your Drupal is still there, “lurking in the dark”
  • have printer-friendly versions of your Drupal site and thus dare Google to face another duplicate content “dilemma”
     

So, what are the “lifebelts” or prevention tools that Drupal “arms” you with for handling this thorny issue?

Here are the 4 modules to use for boosting your site's immunity system against duplicate content.

And for getting it fixed, once the harm has already been made:
 

1. But How Does It Crawl into Your Website? Main Sources of Duplicate Content 

Let's get down to the nitty-gritty of how Drupal 8 duplicate content “infiltrates” into your website.

But first, here are the 2 major categories that these sources fall into:
 

  • malicious
  • non-malicious
     

The first ones include all those scenarios where spammers post content from your website without your consent.

The non-malicious duplicate content can come from:
 

  • discussion forums that create both standard and stripped-down pages (for mobile devices)
  • printer-only web page versions, as already mentioned
  • items displayed on multiple pages of the same e-commerce site
     

Also, duplicate content in Drupal can be either:
 

  • identical
  • or similar

And since it comes in “many stripes and colors”, here are the 7 most common types of duplicate content:
 

1.1. Scraped Content

Has someone copied content from your website and further published it? Do not expect Google to distinguish the copy from its source.

That said, it's your job and yours only to stay diligent and protect the content on your Drupal site from scrapers.
 

1.2. WWW and non-WWW Versions of Your Website

Are there 2 identical version of your Drupal website available? A www and a non-www one?

Now, that's enough to ring Google's “duplicate content in Drupal” alarm.
 

1.3. Widely Syndicated Content 

So, you've painstakingly put together a list of article submission sites to give your valuable content (blog post, video, article etc.) more exposure.

And now what? Should you just cancel promoting it?

Not at all! Widely syndicated content risks to get on Google's “Drupal 8 duplicate content” radar only if you set no guidelines for those third-party websites.

That is when these publishers don't place any canonical tags in your submitted content pointing out to its original source.

What happens when you overlook such a content syndication agreement? You leave it entirely to Google to track down the source. To scan through all those websites and blogs that your piece of content gets republished on.

And often times it fails to tell the original from its copy.
 

1.4. Printed-Friendly Versions

This is probably one of the sources of duplicate content in Drupal that seems most... harmless to you, right?

And yet, for search engines multiple printer-friendly versions of the same content translates as: duplicate pages.
 

1.5. HTTP and HTTPs Pages

Have you made the switch from HTTP to HTTPs?

Entirely?

Or are there:
 

  • backlinks from other websites still leading to the HTTP version of your website?
  • internal links on your current HTTPs website still carrying the old protocol?
     

Make sure you detect all these less obvious sources of identical URLs on your Drupal website.
 

1.6. Appreciably Similar Content 

Your site's vulnerable to this type of duplicate content “threat” particularly if it's an e-commerce one.

Just think of all those too common scenarios where you display highly similar product descriptions on several different pages on your eStore. 
 

1.7. User Session IDs 

Users themselves can non-deliberately generate duplicate content on your Drupal site. 
How? They might have different session IDs that generate new and new URLs.


2. 4 Modules at Hand to Identify and Fix Duplicate Content in Drupal

What are the tools that Drupal puts at your disposal to detect and eliminate all duplicate content?
 

2.1. Redirect Module

Imagine all the functionality of the former Global Redirect module (Drupal 7) “injected” into this Drupal 8 module!

In fact, you can still define your Global Redirect features by just:
 

  1. accessing the Redirect module's configuration page
  2. clicking on “URL redirects” 
     

How to Deal with Duplicate Content in Drupal: Global Redirect features
Image Source: WEBWASH.net

What this SEO-friendly module does is provide you with a user-friendly interface for managing your URL path redirects:
 

  • create new redirects
  • identify broken URL paths (you'll need to enable the “Redirect 4040” sub-module for that)
  • set up domain level redirects (use the “Redirect Domain” sub-module)
  • import redirects
     

Summing up: when it comes to handling duplicate content in Drupal, this module helps you redirect all your URLs to the new paths that you will have set up.

This way, you avoid the risk of having the very same content displayed on multiple URL paths.
 

2.2. Taxonomy Unique Module  

How about “fighting” duplicate content on your website at a vocabulary level?

In this respect, this Drupal 8 module:
 

  • prevents you from saving a taxonomy term that already exists in that vocabulary
  • is configurable for every vocabulary on your Drupal site
  • allows you to set custom error messages that would pop up whenever a duplicate taxonomy term is detected in the same vocabulary
     

2.3. PathAuto Module  

Just admit it now:

How much do you hate the /node125 type of URL path aliases?

They're anything but user-friendly.

And this is precisely the role that Pathauto's been invested with:

To automatically generate content friendly path aliases (e.g. /blog/my-node-title) for a whole variety of content.

Let's say that you want to modify the current “path scheme” on your website with no impact on the URLs (you don't want the change to affect user's bookmarks or to “intrigue” the search engines).

The Pathauto module will automatically redirect those URLs to the new paths using any HTTP redirect status.
 

2.4. Intelligent Content Tools      

Personalization is key when you strive to prevent duplicate content in Drupal, right? 

And this is precisely what this module here does: it helps you personalize content on your website.

How? Through its 3 main functionalities delivered to you as sub-modules:
 

  • auto tagging
  • text summarizing 
  • detecting plagiarized content 
     

Leveraging Natural Language Processing, this last sub-module scans content on your website and alerts you of any signs of duplicity detected.

Word of caution: keep in mind that the module is not yet covered by Drupal's security advisory policy!
 

3. To Sum Up

Setting a goal to ensure 100% unique content on your website is as realistic as... learning a new language in a week. 

Instead, you should consider setting up a solid strategy ”fueled” by (at least) these 4 modules “exposed” here. One that would help you avoid specific scenarios where entire pages or clusters of pages get duplicated.

Now, that's a far less utopian goal to set, don't you think?

Dec 10 2018
Dec 10

It's a fact: “the next generation” of web apps aren't just extremely fast, they're highly scalable, as well. Which brings us to the next question: “How do you scale a web application in Drupal?”

What tools, best practices, and latest techniques do you use for leveraging Drupal 8's scalability capabilities?

For ensuring that your custom web app will keep on scaling to:
 

  • handle sudden spikes in traffic
  • avoid downtime 
  • withstand “surprise” content overloads
     

Well, here they come:
 

1. But Is Drupal Scalable? How Scalable? 

Let's just say that:

Drupal's built with scalability in mind and that Drupal 8 is... extremely scalable.

It's powering some of the world's most trafficked and content-rich websites (Weather, Grammy, Princess Cruises...). Therefore, it's designed to cope with heavy infrastructures of thousand content contributors, Drupal users and site/app visitors...

And when gauging Drupal 8's scalability you need to go beyond Drupal's unmatched modularity: +30,000 free modules.

Instead, just think of:
 

  • Drupal turned into a central API 
  • all the improvements brought to Drupal 8's scalability till this day
  • Drupal 8 enabling you, right out of the box, to integrate it with a wide range of third-party apps, software, and systems
  • RESTful API now in core!!!
     

… and how all that empowers you, the Drupal web app developer, to easily serve JSON or HTML code.

And Drupal 8's unparalleled scalability comes down to this:

Empowering developers to create content and send it to any third-party app via JSON.

Of course, its out-of-the-box scalability can get further optimized via:
 

  • an established set of best practices
  • additional support from various tools and technologies
     

2. How to Scale a Web Application in Drupal: Server Scaling Techniques

Let's say that... “it's time”:

You've applied all the optimization techniques on your web application so that it should seamlessly “accommodate” the increasing influxes of traffic and content load. And still, its server hardware has started to show its limitations.

So, it's time to scale your server hardware. And you have 2 options at hand:
 

2.1. You scale up your server vertically 

This is the handiest method, so to say. That “emergency” technique to go for when:
 

  1. you don't have time to install a caching module
  2. there's no one in your team with the needed expertise for adding more servers
     

So, what do you do? You increase your existing server size. 

You boost its performance by adding more resources.

This way, it could keep up with all those new traffic challenges calling for more memory, more CPU cores...

Word of caution: there' no such thing as “sky is the limit” here; you'll still reach the limit of the hardware at some point when you scale up a web app in Drupal using this method.
 

2.2. You scale up your server horizontally

The second best practice for scaling up your server is a bit more complex.

And it involves 2 approaches, actually:
 

a. You separate your database from your Drupal web app

Basically, your database will have its own server and thus you get to split the load in 2. Then, you can vertically scale each one of the 2 servers.
 

b. You add multiple servers and distribute the load between them.

This is the most complex way to scale a web app in Drupal. 

Just think about it:

How will the servers included in this whole “ecosystem” “know” which users to take over?

It goes without saying that you'll need a load balancer for properly “splitting up” the traffic load. And a database server, as well.

See? It already gets more complex compared to the other 2 above-mentioned server scaling techniques.

Nevertheless, this is the method which, when done properly, will reduce dramatically the load that each server must handle.
 

3. “Juggling with” Multiple App Servers for Drupal

Let's say that you've opted for the last method of scaling up your server, so:

Now you find yourself facing the challenge of handling multiple app servers.

How will you deploy code to each of them simultaneously? That is the biggest question when you scale a web app in Drupal.

The best practice is to keep all your servers on the same local network. 

Having one single data center will speed up the data transfer compared to having it traveling through the internet.
 

The END! This how you can leverage Drupal 8's scalability capabilities and easily “adjust” your web app to withstand unexpected surges of traffic.

Have you tried other techniques and best practices? 

Nov 14 2018
Nov 14

"A Drupal 8 initiative to improve Drupal's content workflow", this is how Dries Buytaert first defined the Workflow Initiative, back in 2016. Now, coming back to 2018, you must be asking yourself a legitimate question: “How do I set up a content workflow in Drupal 8?”

“How do I manage, extend and customize an editorial workflow to fit my Drupal 8 website's publishing needs? One including multiple users, with different permissions, that manages the workflow status of... different content types.”

Which are the (not so) new content management features and functionality implemented to Drupal core by now? Those aimed at improving the user experience (editors, content authors...)?
 
Let's get you some answers:
 

1. Introducing: The Content Moderation Drupal 8 Module

Content Moderation has reached stable version in Drupal 8.5. 

Why should you care? What makes this core module of critical importance for creating your content publication workflow?
 

  • because otherwise, you'd have only two built-in states to “juggle with”: published and unpublished
  • because it enables you to build a simple workflow for drafts, too
  • … to set up new custom editorial workflows, as well, in addition to the default one
     

In short, what this module does is that it enables you to create a flexible content workflow process where:
 

  • one of the editors in your team stags a “Draft” content
  • and another user on your Drupal 8 website, with a different permission, reviews/updates it
     

It comes as a powerful tool for you to leverage when your workflow needs are more complex than “ON/OFF”.
 

2. How to Set Up a Simple Content Workflow in Drupal 8

You'll only need 2 modules for putting together the workflow for a basic content publishing scenario:
 

  • Workflows, that will provide just the framework needed for managing the states and transitions included in the process
  • Content Moderation, which will add the “Draft” state, a “Draft to Published” content workflow, and an admin view for handling all the drafts
     

And here's setting up a basic content publishing workflow in 4 simple steps:
 

  1. Enable the “Content Moderation” core module
  2. Go to “Configuration” and click the “Workflow” tab; it's the last one in the unfolding drop-down menu
  3. Open the “Workflows” page
  4. Tada! You've just turned on your default “Editorial workflow”
     

For now, you should be having 3 major states in your workflow:
 

  • draft
  • published
  • archived
     

Note: use permissions to grant content contributors the right to edit/create drafts, editors the “Transition drafts to published” permission, admins the right to “restore to draft transitions” and so on...

And voila! Your default editorial workflow, with the Content Moderation module ON, should suit your basic state tracking needs. It should fit any standard use case.

Now, if your workflow needs are a bit more complex and website-specific... keep on reading:
 

3. Content Revisions in Drupal 8

One of the most powerful features that Content Moderation will “turbocharge” your editorial workflow with is: 

Saving each change as a content revision in the database. 

It stores all revisions in the system.

But let's take a common scenario, shall we?

Let's say that a second editor decides to make an update to a piece of content (either a content type or a custom block type). He/she updates it, then saves it as a “Draft”. You'll then still have the published version of the content, that's live, on your Drupal website, as well as this Draft (or several of them), stored, as a revision, in your database.

A crucial functionality for any complex content publishing workflow:
 

  • with content revisions, you get to keep track of who's updated what and when
  • … to trigger log messages regarding those changes, informing other content authors that a given content has been edited
  • and you can also revert to the oldest revisions if needed
     

4. How to Extend and Customize Your Content Publishing Workflow 

Rest assured: there's no need for custom code writing, even if your content publishing needs are a bit more complex.

Here's what it takes to extend and to custom-tune your default content workflow in Drupal 8:
 

  1. While on your “Workflow” page, just click the “Add a new state” button and add more workflow states: “Needs Review” or “Second Review” etc.
  2. Next, make sure you adjust your transitions to support your newly added state(s). For instance, a “Second Review” state would require a “Move to Second Review” transition. 
  3. Then, apply your extended workflow to either a specific content type or to a custom block type
  4. You can also create new separate content publishing workflows to have a different one for your press releases, a separate publishing workflow, an editorial workflow for your blog posts, a warehouse workflow etc.
     

Defining multiple workflows in Drupal 8, each one with its specific “ecosystem” of states and transitions, is now possible.

How to Create and Manage a Content Workflow in Drupal 8: Set Up a Custom Content Workflow

Notes:

  • the transitions in your workflow will stand for the permissions that you'll assign to different Drupal roles in your team
  • use clear, descriptive verbs to name them
  • remember to grant editors the permission to undo transitions, as well (they might need to revert a piece of content to “Needs Work” once they've reviewed it, for instance)

In short:

By defining multiple states for your piece of content (Published, Pending Review, Ready for Review, Ready for Second Review, Unpublished, Draft etc.) and managing the permissions corresponding to the state transitions you can build a content workflow in Drupal 8 capable to support even the most complex publishing scenarios.

Now, another common scenario where a custom content workflow in Drupal 8 is needed is when you have a website publishing content to multiple platforms. 

You have a Drupal 8 website, a native application and an internal portal, let's say...

Your publishing workflow would look something like this:
 

  • first, content gets moderated to be published on the front-facing Drupal website
  • then, it gets put in the queue for review before it gets published (or declined) on each one of the other 2 platforms
     

Note: if you need to further extend your editorial workflow and to apply it to a custom entity, for example, you can always write a WorkflowType plugin that meets your specific needs.

Then, you can apply your custom workflow to... steps in ordering in a resto app, steps in a manufacturing process and to pretty much any entity (think beyond content) that needs to change its workflow states...
 

5. How Do You Know If You Really Need an Editorial Workflow?

Do you really need to use content moderation? To set up a whole workflow for your publishing scenario?

You do, if and only if:
 

  • there are multiple content authors uploading content on your website, content that needs to be reviewed before it gets published
  • you're managing a team of multiple admins, with different user roles
  • each moderator knows his/her role in the publishing chain
     

But if the content authors in your team have the very same type of permission as the admins and they just push content through, a content moderation workflow is useless.

It would only slow down the publishing process.

So, just because you have the option to set up a content workflow in Drupal 8, doesn't mean that you should rush to implement it on your own website, too... Maybe you just don't need a workflow.

The END! 

What do you think about these content management capabilities in Drupal 8? Are they powerful and diverse enough to suit your workflow needs? 

Nov 08 2018
Nov 08

What do you get when you put together: Drupal 8 + AI + UX? Drupal8's content management features and integration capabilities, AI, for storing and interpreting data and building a predictive model and UX for anticipating user behavior while adding a “human touch” to the equation? You get predictive UX in Drupal!

Is it possible? Can we implement predictive UX in Drupal and thus create anticipated user experiences that:
 

  • help you deliver meaningful content only    
  • simplify user choice
  • simplify users'... lives?
     

But how does machine learning actually power these predictive user experiences? What's the whole mechanism behind?

And how is predictive analytics UX any different from... personalization? 

Are there any “traps” to be avoided when using the same event data to make informed decisions on the customer's behalf? 

And last but not least: what makes Drupal 8 the best fit for predictively serving content?
 

1. What Is Predictive UX More Precisely?

“Less choice, more automation.”

Or: Anticipating users' needs and delivering them precisely and exclusively the content they need (when they need it). In other words: creating those predictive user experiences that anticipate and meet your customers' needs...

Which one of these 2 possible definitions do you prefer?

Or maybe you'd like a more “elaborate” one:

Predictive UX means leveraging machine learning and statistical analysis to make informed decisions for the customer.

And if we are to turn this definition into a mathematical equation, it would go something like this:

machine learning (predicting) + UX design (anticipating)= predictive UX (based on a predictive or anticipatory design)
 

2. But Isn't This Just Another Word for “Personalization”?

As compared to personalization, predictive UX goes beyond tailoring content to users' past choices:

It actually makes decisions on their behalf.

It's not limited to leveraging data in order to deliver dynamic content. Which would automatically call for heavy manual work.

Instead, predictive UX is AI-driven, thus automating decision making on the user's behalf.
 

3. How Does Predictive Analytics Benefit You and Your Customers?

Here's an empathy exercise for you:

You're a mobile app user who's being constantly “flooded” by heavy streams of disruptive information through push notification, by text or by email. Or you're an online customer faced with a discouragingly “beefy” set of options as you're about to order food for lunch. There are so, so many irrelevant options that you're striving to make your way through till you find the dish that really suits your preferences... that you just feel like closing the app and hitting the closest resto instead...

So, what if:

  • your app could... tell what you want to have for lunch and display the most relevant options only?
  • you would receive app alerts or push notifications in precisely the most appropriate moments (time of the day, of the month)?

It would:

  1. make your life so much easier
  2. improve your overall user experience 

As a company, by leveraging predictive analytics to deliver relevant user experiences only, you're winning your customers' loyalty.

You're simplifying their lives, after all...
 

4. Leveraging Machine Learning to Create Predictive User Experiences

What's the whole mechanism behind the creation of predictive user experiences?

How is the machine learning technology/tool leveraged to predict user behavior?

It's no more than a 3-step sequence:
 

  1. you first define the problem (using machine learning terms)
  2. gather data in a suitable format
  3. put together a model 
     

For instance, here's a machine-learning-based recommendation system deconstructed:
 

  • content-based recommendation: recommending items based on similar characteristics
  • collaborative filtering: recommending items/services based on other customers' preferences (customers with similar past choices)
     

Note: more often than not it's a mix of these 2 types of recommendation systems that you'll find.
 

5. Predictive UX: 4 Common Sense Principles to Consider
 

5.1. Simplify the UI: keep the most relevant design elements and meaningful content only.

Instead of forcing customers to make too many choices, to scan through chunks of content, go for a minimal interface! Trim down the “irrelevant fat” and keep the essential.

Leveraging machine learning and statistical techniques, you should know by then what's essential and meaningful in terms of information and functionality for your users.
 

5.2. Disrupt the all-too-familiar patterns now and then.

In other words: don't get trapped in the “experience bubble”, where you keep recommending the same familiar options and encourage the user to make the very same choices over and over again.

Consider adding disruptive layers, now and then, “tempting” them to try something new.
 

5.3. Avoid forcing those most relevant options on the user.

OK, so you have the data at hand, you're leveraging that machine learning algorithm that anticipates:
 

  • what the user needs
  • what the user wants
  • what the user's going to do next
     

That doesn't mean you should overlook that:

It's always the customer who makes the final choice!

So give them enough options to choose from! Put him/her in full control of the final decision-making process!
 

5.4. Create predictive user experiences that are helpful, not annoying

In other words: when it comes to push notifications, choose the most appropriate time (if you're a retailer, you can't possibly anticipate that anyone would read about your promotion during work hours).
 

6. Predictive UX in Drupal: What Makes Drupal 8 the Perfect Fit?

There are some particular characteristics that make Drupal the perfect “teammate” for a machine learning tool:
 

  • its content management features and (huge amounts of) data storing and maintaining capabilities
  • its API-first approach, which makes third-party integrations conveniently easy; you can integrate Drupal with any system providing an API and an interface 
  • the “decoupled architecture” approach, which enables Drupal to serve content in various ways
     

Now, just think about it:

Analyzing that huge volume of data, stored on your Drupal website, and leveraging it, using a machine learning tool, to create anticipated user experiences! Think of all the emerging possibilities of implementing predictive UX in Drupal!
 

7. And How Do You Implement Predictive UX in Drupal?

First of all: choose your machine learning tool.

Let's say you will have chosen to go with Apache PredictionIO for obvious reasons:
 

  • it's open source
  • it “spoils” you with a set of customizable templates
  • a full machine learning stack
  • the tool's also conveniently easy to deploy as a web service
     

Now, let's have a close look at the Drupal & machine learning tool interaction:

The Event Server collects data from your Drupal app/website — provides it to the Engine —this one reads it — it uses it to put together a predictive model, by leveraging machine learning​​​​ — one that it then sends over to your Drupal app/website — upon a query via REST

Et voila! A predictive result is sent to your Drupal website or application, one that will power a predictive user experience.

Now, since we've been talking about the event data that's being sent from Drupal to the machine learning tool and further “exploited” for building that predictive model, you should know that it comes in “2 flavors”:
 

  1. explicit: the user will have already rated or bought an item, so you have explicit information about his/her preferences 
  2. implicit: the already available information is being leveraged, since there's no past choice or user feedback to analyze for anticipating his/her needs
     

The END! What do you... predict:

Will we be witnessing more and more Drupal 8 websites leveraging predictive UX and, implicitly, machine learning technology, to create anticipated user experiences?
 

Photo by David Travis on Unsplash.

Nov 02 2018
Nov 02

What's your favorite tool for creating content layouts in Drupal? Paragraphs, Display Suite, Panelizer or maybe Panels? Or CKEditor styles & templates? How about the much talked about and yet still experimental Drupal 8 Layout Builder module?

Have you "played” with it yet?

As Drupal site builders, we all agree that a good page layout builder should be:
 

  1. flexible; it should empower you to easily and fully customize every single node/content item on your website (not just blocks)
  2. intuitive, super easy to use (unlike "Paragraphs", for instance, where building a complex "layout", then attempting to move something within it, turns into a major challenge)
     

And it's precisely these 2 features that stand for the key goals of the Layout Initiative for Drupal

To turn the resulting module into that user-friendly, powerful and empowering page builder that all Drupal site builders had been expecting.

Now, let's see how the module manages to “check” these must-have strengths off the list. And why it revolutionizes the way we put together pages, how we create, customize and further edit layouts.

How we build websites in Drupal...
 

1. The Context: A Good Page Builder Was (Desperately) Needed in Drupal

It had been a shared opinion in the open source community:

A good page builder was needed in Drupal.

For, even if we had a toolbox full of content layout creation tools, none of them was “the One”. That flexible, easy to use, “all-features-in-one” website builder that would enable us to:
 

  • build complex pages, carrying a lot of mixed content, quick and easy (with no coding expertise)
  • fully customize every little content item on our websites and not just entire blocks of content site-wide
  • easily edit each content layout by dragging and dropping images, video content, multiple columns of text and so on, the way we want to
     

Therefore, the Drupal 8 Layout Builder module was launched! And it's been moved to core upon the release of Drupal 8.6.

Although it still wears its “experimental, do no use on production sites!” type of “warning tag”, the module has already leveled up from an “alpha” to a more “beta” phase.

With a more stable architecture now, in Drupal 8.6, significant improvements and a highly intuitive UI (combined with Drupal's well-known content management features) it stands all the chances to turn into a powerful website builder.

That great page builder that the whole Drupal community had been “craving” for.
 

2. The Drupal 8 Layout Builder Module: Quick Overview

First of all, we should get one thing straight:

The Drupal 8.6. Layout Builder module is Panelizer in core!

What does it do?

It enables you, the Drupal site builder, to configure layouts on different sections on your website.

From selecting a predefined layout to adding new blocks, managing the display, swapping the content elements and so on, creating content layouts in Drupal is as (fun and) intuitive as putting Lego pieces together.

Also, the “content hierarchy” is more than logical:
 

  • you have multiple content sections
  • you get to choose a predefined layout or a custom-design one for each section
  • you can place your blocks of choice (field blocks, custom blocks) within that selected layout
     

Note: moving blocks from one section to another is unexpectedly easy when using Layout Builder!
 

3. Configuring the Layout of a Content Type on Your Website

Now, let's imagine the Drupal 8 Layout Module “in action”.

But first, I should point out that there are 2 ways that you could use it:
 

  1. to create and edit a layout for every content type on your Drupal website
  2. to create and edit a layout for specific, individual nodes/ pieces of content
     

It's the first use case of the module that we'll focus on for the moment.

So, first things first: in order to use it, there are some modules that you should enable — Layout Builder and Layout Discovery. Also, remember to install the Layout Library, as well!

Next, let's delve into the steps required for configuring your content type's (“Article”, let's say) display:
 

  • go to Admin > Structure > Content types > Article > Manage Display
  • hit the “Manage layout” button
     

… and you'll instantly access the layout page for the content type in question (in our case, “Article”).

It's there that you can configure your content type's layout, which is made of:
 

  • sections of content (display in 1,2, 3... columns and other content elements)
  • display blocks: tabs, page title...
  • fields: tags, body, title
     

While you're on that screen... get as creative as you want:
 

  • choose a predefined layout for your section —  “Add section” —  from the Settings tab opening up on the right side of the screen
  • add some blocks —  “Add block”; you'll then notice the “Configure” and “Remove” options “neighboring” each block
  • drag and drop the layout elements, arranging them to your liking; then you can click on either “Save Layout” or “Cancel Layout” to save or cancel your layout configuration
     

And since we're highly visual creatures, here, you may want to have a look at this Drupal 8 Layout Builder tutorial made by Lee Rowlands, one of the core contributors.

In short: this page builder tool enables you to customize the layout of your content to your liking. Put together multiple sections — each one with its own different layout —  and build website pages, carrying mixed content and multiple layouts, that fit your design requirements exactly.
 

4. Configuring and Fully Customizing the Layout of a Specific Node...

This second use case of the Drupal 8 Layout Builder module makes it perfect for building landing pages.

Now, here's how you use it for customizing a single content type:
 

  • go to Structure>Content types (choose a specific content type)
  • click “Manage display” on the drop-down menu 
  • then click the “Allow each content item to have its layout customized” checkbox
  • and hit “Save”
     

Next, just:
 

  • click the “Content” tab in your admin panel
  • choose that particular article that you'd like to customize
  • click the “Layout” tab
     

… and you'll then access the very same layout builder UI.

The only difference is that now you're about to customize the display of one particular article only.

Note: basically, each piece of content has its own “Layout” tab that allows you to add sections, to choose layouts. 

Each content item becomes fully customizable when using Drupal 8 Layout Builder.
 

5. The Drupal 8.6. Layout Builder vs Paragraphs

“Why not do everything in Paragraphs?" has been the shared opinion in the Drupal community for a long time.

And yet, since the Layout Builder tool was launched, the Paragraphs “supremacy” has started to lose ground. Here's why:
 

  • the Layout builder enables you to customize every fieldable entity's layout
  • it makes combining multiple sections of content on a page and moving blocks around as easy as... moving around Lego pieces 
     

By comparison, just try to move... anything within a complex layout using Paragraphs:
 

  • you'll either need to keep your fingers crossed so that everything lands in the right place once you've dragged and dropped your blocks
  • or... rebuild the whole page layout from scratch
     

The END!

What do you think:
 

Does Drupal 8 Layout Builder stand the chance to compete with WordPress' popular page builders?


To “dethrone” Paragraphs and become THAT page layout builder that we've all been expected for? Or do you think there's still plenty of work ahead to turn it into that content layout builder we've all been looking forward to?

Sep 28 2018
Sep 28

Just imagine... automatic updates in Drupal core.

Such a feature would put an end to all those never-ending debates and ongoing discussions taking place in the Drupal community about the expectations and concerns with implementing such an auto-update system.

Moreover, it would be a much-awaited upgrade for all those users who've been looking for (not to say “longing for") ways to automate Drupal core and modules for... years now. Who've been legitimately asking themselves:

“Why doesn't Drupal offer an auto-update feature like WordPress?”

And how did we get this far? From idea to a steady-growing initiative?
 

  1. first, it was the need to automate Drupal module and security updates
  2. then, the issues queues filled with opinions grounded in skepticism, valid concerns and high hopes started to “pile up” on Drupal.org,
  3. then, there was Dries' keynote presentation at Drupalcon Vienna in 2017, raising awareness around the need to re-structure Drupal core in order to support a secure auto-update system
  4. … which grew into the current Auto Update Initiative
  5. that echoed, recently, at Drupal Europe 2018, during the “Hackers Automate, but the Drupal Community still Downloads Modules from Drupal.org” session
     

Many concerns and issues have been pointed out. Many questions have been added to the long list.

Yet, one thing's for sure:

There still is a pressing, ever-growing need for an auto-update feature in Drupal...

So, let me try to answer my best to some of your questions regarding this much-awaited addition to Drupal core:
 

  • What's in it for you precisely? How will an auto-update pre-built feature benefit you? 
  • Does the user persona profile suit you, too? Is it exclusively low-end websites that such a feature would benefit? Or are enterprise-level, company websites targeted, as well?
  • What are the main concerns about this implementation?
     

1. The Automatic Updates Initiative: Goal & Main Challenges 

Let's shift focus instead and pass in review the inconveniences of manually installing updates in Drupal:
 

  • it's time-consuming
  • it's can get risky if you don't know what you're doing
  • it can be an intimidatingly complex process if you have no dedicated Drupal support & maintenance team to rely on
  • it can get quite expensive, especially for a small site or blog owner
     

See where I'm heading at?

This initiative's main objective is to spare Drupal users of all these... inconveniences when it comes to updating and maintaining their websites. Inconveniences that can easily grow into reasons why some might get too discouraged to adopt Drupal in the first place.

The goal is to develop an auto-update mechanism for Drupal core conceptually similar to those already implemented on other platforms (e.g. WordPress).

And now, let's dig up and expose the key challenges in meeting this goal:
 

  • enabling update automation in Drupal core demands a complete re-engineering of the codebase; it calls for a reconstructing of its architecture and code layout in order to support a perfectly secure auto-update system 
  • such an implementation will have a major impact on the development cycle itself, causing unwanted disruption
  • such a built-in auto-update feature could get exploited for distributing and injecting malware into a whole mass of Drupal websites
     

2. Automatic Updates in Drupal: Basic Implementation Requirements 

What would be the ideal context for implementing such a perfectly secure auto-update system? 

Well, its implementation would call for:
 

  • multiple (up to date) environments
  • released updates to be detected automatically and instantly
  • an update pipeline for quality assurance
  • existing automate tests with full coverage
  • a development team to review any changes applied during the update process 
     

3. How Would These Auto-Updates Benefit You, the Drupal User?

Let's see, maybe answering these key questions would help you identify the benefits that you'd reap (if any):
 

  • is your Drupal website currently maintained by a professional team?
  • has it been a... breeze for you so far to cope with Drupal 8's release cycle (one new patch each month and a new minor release every 6 months sure claim for a lot of your time)?
  • have you ever got tangled up in Composer's complexities and a whole load of third-party libraries when trying to update your Drupal 8 website?
  • did you run the Drupalgeddon update fast enough?
  • have you been secretly “fancying” about a functionality that would just update Drupal core and modules, by default, right on the live server?
     

To sum up: having automatic updates in Drupal core would keep your website secured and properly maintained without you having to invest time or money for this.
 

4. Drupal Updating Itself: Main Concerns

And concerns increase exponentially as the need for an update automation in Drupal rises (along with the expectations).

Now, let's outline some of the most frequently expressed ones:
 

  • there is no control over the update process, no quality assurance pipeline; basically, there's no time schedule system enabling you to test any given update, in a development environment, before pushing it live
  • there's no clearly defined policy on what updates (security updates only, all updates, highly critical updates etc.) should be pushed
  • with Drupal updating itself, rolling back changes wouldn't be possible anymore (or discouragingly difficult) with no GIT for version control
  • again: automatic updates in Drupal could turn into a vulnerability for hackers to exploit for a mass malware attack 
  • there's no clear policy regarding NodeJS, PHP and all the JS libraries in Drupal 8, all carrying their own vulnerabilities, too
  • it's too risky with all those core and module conflicts and bugs that could break through
  • such a feature should be disabled by default; thus, it would be every site owner's decision whether to turn it on or not
  • could this auto-update system cater to all the possible update workflows and specific behaviors out there? Could it meet all the different security requirements?
     

So, you get the point: no control over the update pipeline and no policy for handling updates are the aspects that concern developers the most.
 

6. Does It Cater for Both Small & Enterprise-Level Websites' Needs? 

There is this shared consensus that implementing automatic updates in Drupal core would:
 

  1. not meet large company websites' security requirements; that it would not fit their specific update workflows
  2. benefit exclusively small, low-end websites that don't benefit from professional maintenance services
     

Even the team behind the automatic updates initiative have prioritized low-end websites in their roadmap.

But, is that really the case?

Should this initiative target small websites, with simple needs and writable systems, that rarely update and to overlook enterprise-level websites by default?

Or should this much-wanted functionality be adjusted so that it meets the latter's needs, as well? 

In this case, the first step would be building an update pipeline that would ensure quality.

What do you think?
 

7. How About Now?"What Are My Options for Automating Updates in Drupal?"

In other words: what are the currently available solutions if you want to automate the Drupal module and security updates? 
 

7.1. You Can Use Custom Scripts to Automate Updates

… one that's executed by Jerkins or another CI platform. 

Note: do bear in mind that properly maintaining a heavy load of scrips and keeping up with all the new libraries, tools, and DevOp changes won't be precisely a “child's play”. Also, with no workflow and no integrated tools, ensuring quality's going to be a challenge to consider.
 

7.2. You Can Opt for a Drupal Hosting Provider's Built-In Solution

“Teaming up” with a Drupal hosting provider that offers you automated updates services, too, is another option at hand.

In this respect, solutions for auto-updating, such as those provided by Pantheon or Acquia, could fit your specific requirements. 

Note: again, you'll need to consider that these built-in solutions do not integrate with your specific DevOps workflows and tools.
 

And my monologue on automatic updates in Drupal ends here, but I do hope that it will grow into a discussion/debate in the comments here below:

Would you turn it on, if such a feature already existed in Drupal core?

  1. Definitely yes
  2. No way
  3. It depends on whether...
Sep 21 2018
Sep 21

The media management experience had been one of the well-known sources of frustration for Drupal content editors for a long time. For, let's face it: Drupal's out-of-the-box media support was just... basic. But not anymore: there are new exciting features for media handling in Drupal 8.6.0 that will dramatically change the way you manage your media assets on your Drupal website!

Now, let's take a sneak peek at these most-anticipated media handling features that Drupal 8.6.0 comes equipped with:
 

  • adding media from a remote source
  • adding various types of media
  • embedding Youtube and Vimeo videos in the content (via URL)
  • easily accessing and reusing the existing media
  • uploading new media types right out of the box
     

And this is almost... overwhelming:

From almost no built-in media support in Drupal, for so many years, to a whole set of modern, powerful media management options now in Drupal 8.6.0.

But let's not ramble about this topic anymore and dive right in! Into the pile of new features meant to enhance the whole media management experience in Drupal:
 

But First: An Update on The Progress of the Media in Drupal 8 Initiative

The main goal of this media initiative was to:

Add a rich media support to Drupal 8.

One that would empower the content editors to easily reuse existing media assets, add new media entities and to overall gain more control (and meta information) over their media.

And there are 3 core milestones that we can trace while tracking the progress of this initiative for Drupal 8:
 

  1. adding the experimental Media module to Drupal 8.4 in late 2017
  2. leveling up this module from experimental to stable phase in Drupal 8.5.0
  3. turning it into the standard way of storing media in Drupal 
     

Moreover, starting with Drupal 8.6.0 a new key module for handling media has been added to core — Media Library — along with a few more exciting options:
 

  • quick access to the existing media assets
  • oEmbed support
  • a new media type: remote video content
     

Quite a “leap” forward, to a great media management experience in Drupal, I would say...
 

2. Welcome a New Media Type in Drupal 8: Remote Video

Let us list the 4 media types that you could add to your site's content up to Drupal 8.6.0:
 

  1. file
  2. image
  3. video
  4. audio
     

OK, now it's time you welcomed a new media type to the group: remote video!

Basically, as a content editor you're now able to add videos from remote sources, as well — Vimeo and Youtube — via their URLs.

Handling Media in Drupal 8.6.0- New Media Type: Remote Video

In short: you're no longer constrained to settle for the default media types in Drupal 8. No sir, now you get to create new custom ones mentioning their media sources.

Summing up: embedding new media to your website content is nothing but a two-step process: Content-Add Media.

Handling Media in Drupal 8.6.0- Add New Media Type


3. Reusing Media Is Now Possible: Media Library

One of the much-awaited features for media handling in Drupal 8.6.0 had been reusable media.

Well, here it is now: Media Library! It's where you can save and store all your media assets to be further reused whenever needed.

Note: do keep in mind that this an experimental module and that you'll also need to enable the Media module first things first.

“And how does it work more precisely?”
 

  1. while in your content edit screen
  2. just browse through all the media assets stored in your Media Library
  3. select the one you need
  4. and simply “inject” it into your page
     

Note: it's the “Media library” widget, added to the Media field, that enables you to scan through all your media entities straight from the content edit screen.

Handling Media in Drupal 8.6.0- Media Library Widget


4. The New “Media” Field: A Quick Way to Embed Media in Your Content

Handling media in Drupal 8.6.0 is as simple as... adding a new field — “Media” —  to the content type in question (be it news, blog post, article and so on).

Handling Media in Drupal 8.6.0- Add a New Media Field

Once the new field is added on, just go through the 5 media types available in Drupal 8.6.0 and select the one you need to embed.

Next, you can simply integrate it into your content, while in your edit screen, positioning it to your liking.
 

5. New Media Handling in Drupal 8.6.0: Youtube & Vimeo Embeds

A new media management tool that significantly improves the whole content editing experience in Drupal.

You're able to embed remote videos from Youtube and Vimeo via URL, thanks to the now added oEmbed media support.

“How precisely?” Basically, you simply:
 

  1. add that new “Media” field to your content type, as previously stated
  2. select the “Remote Video” option from the “Media Type” drop-down menu
  3. enter your video's URL in the “Video URL” field, while in your “Add Remote Video” screen
  4. and click “Save”
     

And voila: you'll have your remote video integrated into your content!

The END!

As Steve Burge from OSTraining would say:

“Finally we're getting somewhere with media in Drupal!”  

What do you think about the new features for media handling in Drupal 8.6.0? What other options and tools are there on your wishlist?

To be able to embed remote videos right from the node create page, maybe? Or to have other video platforms, as well, supported in Drupal?

Aug 30 2018
Aug 30


We all love Drupal's granular permission and access control system! And yet: its life-saving hierarchy of user roles and permission levels is strictly for creating/editing content. Since Drupal wrongly assumes that all site visitors should be able to visualize all published content, right? But what if this default assumption doesn't suit your specific use case? What if you need to restrict access to content in Drupal 8?

… to limit users' access to certain content on your website? So that not all visitors should be able to see all published nodes.

In this case, Drupal's typical access control system for creating and editing content is not precisely the functionality that you need.

But there's hope!

And it comes in the form of 6 Drupal 8 access control modules that enable you to give content access of different levels, ranging from “average” to “more refined”.
 

But First: An Overview of Drupal's Typical Access Control System 

Now, we can't just jump straight to the “more sophisticated” content access solutions in Drupal 8, not until we've understood how its basic access control system works, right?

As you can see, in the screenshot here below, the logic behind it is pretty straightforward:

Restrict Access to Content in Drupal 8- Typical Access Control in Drupal

  • while in your admin panel, you need to access the People menu > Permissions
  • and there, you just assign different user types (authenticated, admin or anonymous) with specific sets of permissions (to administer blocks, to post/edit comments, to modify menus on your Drupal site etc.)

As you can see, Drupal's typical access control system is not configured so as to enable you to restrict visitors' access to specific content on your website.

Or to limit user access to a more granular level other than the standard “logged in/not logged in user”.
 

If you're not looking for anything “too fancy”, just a straightforward functionality for controlling access to view/edit/delete content entities, then this module's THE one.

And here are 2 of its most common use cases:
 

  • you define some access-restricted premium content areas on your Drupal site, for “privileged” user roles only
  • you grant publish/edit permissions to certain groups on your website, having specific predefined user roles
     

Definitely a go-to module when you need to restrict access to content — to specific content types — in Drupal 8.

It enables you to:
 

  • set up specific access control roles
  • define custom granular restrictions based on different user permissions (you could, for instance, limit access to certain content on your website for non-authenticated users only...)
  • set up content types with restricted access 
     

Note: do bear in mind that, once you've enabled Content Access, you'll need to rebuild your entire “collection” of access content permissions. The module is going to alter the way they work, that's why.

Restrict Access to Content in Drupal 8- Rebuild Permissions when Using Content Access module

Tip: if you need to control access to content nodes on your Drupal 8 site, this module's built to help you “refine” your restriction; for that you'll just need to define some more detailed permissions in People menu >  Permissions tab.
 

A lightweight solution to restrict access to content in Drupal 8. One that enables you to set up access-restricted content sections on your website.

Now, what makes it stand out from the other 5 modules in my list here is:

The refined, taxonomy term-based restrictions that it allows you to create for specific nodes on your Drupal site.

You can limit access to these nodes for:
 

  • specific user roles
  • certain individual user accounts
     

Restrict Access to Content in Drupal 8- Permission by Term module

How do you set everything up?
 

  1. first, you enable the module
  2. then, on the term edit page, you define a specific role access for each taxonomy term 


And there's more to look forward to! 

Unlike Organic Groups and Group, the Permissions by Term module comes with very little overhead, in the form of light contributed code.

In other words: for the taxonomy terms-based access control that it enables you to set up, it adds a new field to your current content types. That's all!
 

When it comes to Drupal role-based access control (to content types or nodes) this module's simple, straightforward approach is exactly what you need.

Not as “sophisticated” as Content Acess, yet conveniently easy to configure and to maintain.

And also, the perfect choice if it's just a basic kind of content type access restriction that you need to set up.

Summing up its functionality now, what you should know is that Node View Permissions enables you to define 2 types of... permissions:
 

  • “View any content”
  • “View own content”
     

… for every content type listed on your Drupal site's Permissions page. 
 

5. Group         

It enables you, as the site admin, to structure content into... groups.

Different group types, with their own hierarchies of group roles:
 

  • anonymous
  • member
  • outsider (a logged in user, but not a group member)
  • other group roles that, as an administrator, you'll need to create
     

Needless to add that with Group you'll restrict access to content in Drupal 8 based precisely on these group roles that you'll set up.

Furthermore, it allows you to define:
 

  • the most suitable permissions (view/edit/delete) for specific content types
  • the most appropriate group roles
     

… per group type. 

And the best is yet to come:

All group types, group roles, group/content relationships are set up as entities. Meaning that they're fully fieldable, exportable, extendable!
 

It's a restricted access to nodes, based on taxonomy terms, users and roles, that you get to define using this module:

A user role-based access control...

Note: mind you don't forget that, in order to restrict access to viewing/editing nodes on your Drupal website, you'll first need to reconfigure the existing user permissions.


The END! 

A bit curious now: which one of these solutions, ranging from straightforwardly simple to most refined, would you go for to restrict access to content in Drupal 8?

Aug 27 2018
Aug 27

You've put so much effort into crafting and polishing the content on your Drupal website and it just won't... rank? Why is it that search engines' web crawlers won't index its “juicy” content? Why they won't give your site a big push right to first-position rankings? As it clearly deserves... Could it be because you're making these 10 Drupal SEO mistakes? 

Knowingly or just recklessly...

And with the first 5 of them already exposed in the first part of this blog post, I'm keeping my promise and here I am now, with 5 more SEO mistakes that you don't want to make on your Drupal website, ranging from:
 

  • embarrassing gaffes
  • to faux pas
  • to catastrophes...
     

1. Underrating Meta Tags: One of (Too) Common, Yet Costly Drupal SEO Mistakes 

And let me just say it: forgetting (or choosing not to) to check those 3 on-page ranking factors:
 

  1. description
  2. page title
  3. tags
     

... is one rookie SEO mistake. 

And one costly neglect, too...

Why? Because by simply checking your meta tags, making sure that the content entered there:
 

  • contains all the relevant keywords
  • is user-friendly and engaging
     

you hit 2 birds with just one stone:
 

  1. search engines' crawlers will just know whether specific web pages on your site are relevant for specific search queries or not; whether the keywords that you will have added to your meta elements are precisely those that online visitors use
  2. users will get a “teaser” of what the page is about, helping them decide whether it matches their searches and expectations or not
     

Note: Drupal's got your back with a dedicated Metatag module that you should install even before you “release your website out into the wild".
 

2. Ignoring the Slow Page Loading Speed 

If it takes more than 2 seconds to load... then you'll lose them. Visitors on your Drupal site will lose all interest in accessing that given page.

And could you blame them? 

Instead, you'd better:
 

  • blame yourself for accepting this status quo and refusing (or just postponing or not putting enough effort into it) to optimize your site for high speed
  • rush to address this major UX issue risking to grow into a critical SEO issue
     

How? By:
 

  • compressing all JS and CSS files using a dedicated tool of your choice (and thank God there are plenty of those to choose from!)
  • compressing all overly large pages
  • reducing images, graphics, and videos to reasonable sizes
  • disabling all those Drupal modules that you haven't used in ages (or maybe never...)
  • enabling caching (and luckily there are Drupal cache modules — like Memcache, for instance — that can help you with that)
  • upgrading your server or even moving to a new hosting company
  • optimizing your site's current theme

See? Improving your Drupal site's load time is no rocket science and it doesn't require overly complex measures, either. They're no more than... “common sense” techniques.

Assess the resources that implementing them would require and... just do it:
 

  • the user experience on your Drupal website will improve significantly
  • search engines will “detect” this increase in user satisfaction
  • … which will translate into a higher ranking 
     

3. Overlooking to Redirect From Its HTTP to Its Secure HTTPs Version

Migrating your Drupal site to HTTPS is a must these days. Just face it and deal with it or... be ready to face the consequences!

Yet, if you overlook to redirect your site to its new HTTPS version, thus sending its visitors out to... nowhere — to error pages — then... it's all but wasted effort and resources.

One of those SEO Drupal mistakes with long-term consequences on your website's ranking.
 

4. Broken Internal Images

Leaving broken internal images and missing ALT attributes behind is a clear sign of SEO sloppiness...

And now, here's what we would call a “broken image”:
 

  • an image that has an invalid file path
  • an image with a misspelled URL
     

The result(s)?
 

  1. first, a broken image has an impact on the overall user experience; your site visitor gets discouraged and quits the page in question
  2. next, search engines rate your site's content as “of poor quality”
  3. and finally, all these lead to an inevitable drop in Google search rankings
     

5. Underestimating (or Just Ignoring) the Importance of an XML Sitemap for SEO

Not generating an XML sitemap of your Drupal site is more than just one of those Drupal SEO mistakes that you should avoid: it's a missed opportunity! A huge one!

Here's why:
 

  • an XML sitemap would include all the URLs on your website
  • … as well as information (via heading tags) about your site's infrastructure of web pages, for search engine crawlers to use
  • … “alerts” about which pages they should be indexing first
  • an XML sitemap provides an early index of your website
  • all the pages on your website get submitted to the search engine database even before they get indexed in their own database
     

Note: the sitemap.xml file not only that communicates with and informs search engines about the current content ecosystem on your Drupal site, but will “keep them posted” on any updates of your site's content, as well.

So, what an XML sitemap provides is a prioritized, conveniently detailed and easily crawlable map of your Drupal website meant to ease web crawlers' indexing job.

And the easier it gets for them to crawl through your site's content, the faster your site's indexing process will be.

In short: if the robots.txt file alerts search engines about those pages that they shouldn't crawl into, the sitemap.xml file lets them know what pages they should index first!

Tip: discouraged by the thought of manually building your site's sitemap? Well, why should you, when there are Drupal modules built especially for this?
 

From taxonomy terms, menu links, nodes, useful entities, to custom links, these modules will automatically generate all the entities that you'd need to include in a detailed sitemap of your Drupal site.

The END! 

Just face it now: you'll inevitably continue to make gaffes influencing your site's SEO, no matter how many precautions you might take...

Yet, these10 Drupal SEO mistakes here, ranked from least to most damaging, are the ones that you should strive to avoid at all costs...

Aug 24 2018
Aug 24

You have made, are currently making and will continue to make various Drupal SEO mistakes. From those easy to overlook gaffes to (truly) dumb neglects, to critical mistakes severely impacting your site's ranking... 

Just face it and... fix it! 

And what better way of becoming aware of their impact on your site than by... getting them exposed, right? By bringing them into the spotlight...

Therefore, here are the 10 SEO mistakes you really don't want to make on your website: the “culprits” for your site's poor ranking.

Take note of them, assess their occurrence/risks for your Drupal site's SEO and strive to avoid them:
 

1. Overlooking or Misusing Header Tags

Do it for the crawlers or do it for your site visitors.

For whichever reason you decide to structure the content on your web pages using H1, H2, H3 tags, Google will take note of your efforts...

And it all comes down to setting up an SEO-valuable hierarchy on each page on your Drupal site. One that:
 

  • crawlers will painlessly scan through, which translates your website getting indexed more quickly
  • users will find conveniently “readable”, which bubbles up to the overall user experience
     

Note: one of the worst SEO gaffes that you could make —  one that would confuse the crawlers and intrigue the site users — would be to use multiple H1 tags on the very same page. 

It's one of those silly, yet harmful rookie Drupal SEO mistakes that you don't want to make!
 

2. Duplicate Content: It's Literally Killing Your SEO

Now, speaking of running the risk to confuse the crawlers in your Drupal site, duplicate content makes the "ultimate source of confusion” for search engines.

And how does this show on your site's SEO? 

Basically, since the crawler can't identify the right page to show for a specific query, it either:
 

  1. "refuses" to rank any of them
  2. or applies specific algorithms to recognize the "suitable" page for that search query
     

Needless to add that the second decision is discouragingly time-consuming, while the first is simply... disastrous for your site's ranking.

"But how did I end up with duplicate content on my website in the first place?" you might ask yourself.

Here are 3 of the most common causes:
 

  • HTTP vs HTTPS 
  • URL variants
  • WWW and non-www pages
     

Now, since an identified and acknowledged mistake is already a half-solved one, here's how you can get it fixed:
 

  • just set up a 301 redirect from that web page's primary URL to the new one
  • set up a rel=canonical attribute on the old URL, one that would let search engines know that they should handle the new URL as a duplicate of the original one
     

Note: It goes without saying that all metric records and all the links that search engines will have monitored on these two duplicate pages will then be automatically attributed to the original URL.
 

3. Optimizing for the Wrong Keywords

And this sure is one of the most frequent Drupal SEO mistakes, that goes back to:

Not investing enough resources (of time mostly) in a proper keyword research strategy.

And no, trying to rank for the prime keywords isn't a foolproof action plan!

The result(s)?
 

  • you end up targeting all the wrong keywords
  • you optimize your site's content for all the wrong terms, that your target audience isn't actually searching for
     

Wasted efforts for putting together non-targeted (or not properly targeted) content...

Instead, invest time in identifying and then ranking for the right search terms.

For yes, it will take longer to carry out a proper keyword process and for your site to start ranking for those keywords. But it won't be wasted time...
 

4. Having Pages with Duplicate Title Tags on Your Drupal Site

Here's another way of confusing crawlers even more:

Faced with two separate web pages having the same <title> tags, search engines won't know which one of them stands for a specific search query.

And their confusion only risks to lead to your Drupal site's getting banned...

Moreover, it's not just search engines that will get discouraged by the duplicate titles, but site visitors, too. They won't know which is the “right” page to access.

“OK, but how can I get it fixed?”
 

  • you install and turn the Metatag module on
  • you craft and give each page on your Drupal site a unique title 
     

5. Ignoring Robots.txt: One of the Common Drupal SEO Mistakes

Now, before answering your otherwise valid question:

“Why do I even need Robots.txt file on my Drupal website?”

… we'd better see what this protocol brings, right?

Take it as a standard that websites use to communicate with crawlers and web robots “in charge” with indexing their content. It's this file that points out what web pages should be crawled and indexed and which ones should be skipped.

Now, if it's a blog that you own, ignoring this protocol isn't one of the biggest Drupal SEO mistakes that you could do. But if it's a larger Drupal site, with a heavy infrastructure of web pages, that you're trying to optimize, then having Robots.txt file makes all the difference...

Tip: do consider installing the Robots.txt module for streamlining the efforts of making your site “crawling-friendly”.

END of Part 1! Stay tuned for I'll be back with 5 more Drupal SEO mistakes — ranking from seemingly harmless to critical — that you definitely don't want to make on your website.

Aug 24 2018
Aug 24

With the Drupalgeddon2 "trauma" still “haunting” us all — both Drupal developers and Drupal end-users — we've convinced ourselves that prevention is, indeed, (way) better than recovery. And, after we've put together, here on this blog, a basic security checklist for Drupal websites and revealed to you the 10 post-hack “emergency” steps to take, we've decided to dig a bit deeper. To answer a legitimate question: “What are some good ways to write secure Drupal code?”

For, in vain you:
 

  • build a “shield” of the best Drupal security modules and plugins around your website
  • enforce a rigid workplace security policy 
     

… if you leave its code vulnerable to various types of cyber attacks, right?

  • But how do I know how unsecured code looks like, to begin with?
  • What are the site configuration gotchas that I should pay attention to?
  • What are the most common vulnerabilities that I risk exposing my Drupal site to?
  • And how can I test it for security issues that might be lurking in its code?

But most of all: What top secure coding practices should I and my Drupal development team follow?

Now, let's get you some answers:
 

1. SQL Injection Vulnerabilities: How You Can Fix & Prevent Them 

SQL injections sure make one of the most “banal”, nonetheless dreadful types of attacks. Once such vulnerabilities are exploited, the attacker gets access to sensitive data on your Drupal site.
 

1.1. Prevent SQL Injection Attacks Using The Database Abstraction Layer

In other words: the proper use of a database layer makes the best shield against any SQL injection exploit attempts.

Now, let's talk... code.

For instance, linking together data right into the SQL queries does not stand for a secure coding practice:

db_query('SELECT foo FROM {table} t WHERE t.name = '. $_GET['user']);

In this case here, this is how you write secure Drupal code:

db_query("SELECT foo FROM {table} t WHERE t.name = :name", [':name' => $_GET['user']]);

Notice the usage of the proper argument substitution with db_query. The database abstraction layer uses a whole range of named placeholders and works on top of the PHP PDO.

Now, as for a scenario requesting a variable number of arguments, you can use either db_select() or an array of arguments:

$users = ['joe', 'poe', $_GET['user']];
db_query("SELECT t.s FROM {table} t WHERE t.field IN (:users)",  [':users' => $users]);
$users = ['joe', 'poe', $_GET['user']];
$result = db_select('table', 't')
  ->fields('t', ['s'])
  ->condition('t.field', $users, 'IN')
  ->execute();

1.2. Have You Detected an SQL Injection Vulnerability? Here's How You Can Fix It

There are some key Drupal security best practices to follow for addressing SQL injection issues:
 

  • always stick to the well-known Drupal database API
  • always filter the parameters that you get (be twice as vigilant and cautious about those who can type anything on your Drupal site)
  • always use placeholders: db_query with :placeholder
  • always check the queries in the code: db_like()
     

Tip: remember to follow these coding practices for addressing and preventing SQL injections on your contrib modules, as well.
 

2. How to Protect Your Drupal Site Against Cross-Site Scripting (XSS) Attacks

We could easily say that XSS attacks “rival” SQL injection attacks in “popularity”:

Drupal's highly vulnerable to cross-site scripting.

All it takes is some wrong settings — input, comment, full HTML — as you configure your website, to make it vulnerable to this type of attacks:

They make a convenient gateway into your website for remote attackers to use to inject HTML or arbitrary web.
 

2.1. Check Functions to Rely on for Sanitizing the User Input (in Drupal 7)

Securing your Drupal 7 site against cross-site scripting attacks always starts with:

Identifying the very “source” of that submitted data/text.

Now, if the “culprit” is a user-submitted piece of content, depending on its type you have several check functions at hand to use for sanitizing it:
 

  • check_url
  • check_plain (for plain text)
  • filter_xss (when dealing with pure HTML)
  • filter_xss_admin (if it's an admin user that entered the “trouble-making” text)
  • check_markup
     

Note: always remember never to enter the user input as-is into HTML!

Tip: a good way to write secure Drupal code is to use t() with % or @ placeholders for putting together translatable, safe strings.
 

2.3. Cross-Site Scripting In Drupal 8: Twig & 3 Useful Sanitization Methods

In Drupal 8, handling cross-site scripting attacks gets significantly easier.

Here's why:
 

  • you have TWIG, with its autoescaping and “sanitize all” HTML mechanism!!!
  • no SQL queries
  • no access to Drupal APIs
     

Now, besides Twig, you have 3 more sanitizing methods at hand for fixing cross-site scripting issues in Drupal 8:
 

  1. HTML: :escape(), for plain text
  2. Xss: :filterAdmin(), for admin-submitted content
  3. Xss: :filter(), where HTML can be used
     

2.4. Testing Your Code Against XSS

In order to check whether certain user inputs are vulnerable, all you need to do is:
 

  • take the “suspicious” user input as a field, as an input HTML
  • enter them both (or just one of them) in your test
     

Note: feel free to user Behat or another framework of choice to automate the whole process.

2 clear signs that you've detected an XSS vulnerability are:
 

  1. you get this pop up alert: <script>altert ('xss') </script>
  2. or this error message close to the IMG tag: img src="https://www.optasy.com/blog/what-are-some-good-ways-write-secure-drupal-..." onerror="alert ('title')"
     

3. Use Twig Templates: They Sanitize All Output...  Automatically 

Did you know that a lot of the Drupal security issues on your website occur precisely because you've skipped sanitizing the user-submitted content before displaying it?

And someone's neglect quickly turns into another one's opportunity...

By skipping to clean up that text beforehand, you lend the attacker a “helping hand” with exploiting your own Drupal site.

Now, getting back to why using Twig templates is one of the best ways to write secure Drupal code:
 

  • they sanitize the user input and output (all HTML, basically) by default; you can write your custom code without worrying about it risking to break up your website
  • you won't run the risk of having safe markup escaped


In short: securing your Drupal 8 website is also about having all HTML outputted from Twig templates.
 

4. How to Write Secure Drupal Code for Finding & Fixing Access Bypass Issues

One of Drupal's strongest “selling points” is precisely its granular permission system. Its whole infrastructure of user roles with different levels of permissions assigned to them.

Furthermore, there are all kinds of access controls that you can “juggle with”:
 

  • Node access system
  • field access
  • Views access control
  • Entity access
     

In short: you're free to empower users to access different sections/carry out different operations on your Drupal site.
 

4.1. How You Can Check for Access Bypass Issues

How do you know whether there are access bypass flaws on your website, that could be easily exploited?

It's easy:
 

  • you simply visit some nid/node and other URL on your site 
  • and just run your Behat automated tests
     

4.2. And How You Can Fix the Identified Access Bypass Issues

Do keep in mind that there are quite a few access callbacks to consider:
 

  • entity_access
  • user_access for  permissions
  • Squery – addTag ('node_access')
  • Menu definitions (make sure you set those correctly)
  • node_access

All you need to do is write automated tests to address any detected problems related to access bypass.
 

5. 3 Ways Deal With Cross-Site Request Forgery (CSRF) in Drupal 

What does it take to write secure Drupal code? 

Writing it... strategically, so that it should prevent any possible cross-site request forgery attack...

Now, here are 3 ways to safeguard it from such exploits:
 

  1. sending and properly validating the token
  2. using Form API
  3. using the built-in csrf_token in Drupal 8
     

In conclusion: a trio of good practices keeps the CSRF attacks away...
 

6. 7 Best Contrib Security Modules to Back Up Your Coding With

Now, after we've gone through some of the best ways to write secure Drupal code, let's see which are the most reliable contrib security modules to strengthen your site's shield with:

  1. Hacked!      
  2. Permission report  
  3. Encrypt      
  4. Composer Security Checker        
  5. Security Review          
  6. Paranoia      
  7. Text Formats Report
     

The END! This is how your solid Drupal security “battle plan” could look like. It includes:
 

  • some of the most frequent types of attacks and security issues to pay attention to
  • most effective preventive measures
  • vulnerability detecting methods
  • post-attack emergency actions and sanitization mechanisms
     

What ways to write secure Drupal code would you have added or removed from this list?

Aug 21 2018
Aug 21

Let me guess: you're a Drupal developer (temporarily) turned into a... Drupal project manager! Or maybe a PM new to Drupal, facing the challenge of your first Drupal project management assignment?

Have I guessed it?

Now the questions roaming in your head right now must be:
 

  • What Drupal project-specific challenges should I expect?
  • How should I address them?
  • How should I approach the Drupal developers, site builders and themers involved?
  • What questions should I ask them at each phase of the project?
  • And which are the stages of a Drupal project management process more precisely?
  • How do I collect accurate and explicit requirements for my Drupal project?
     

“Spoiler alert”: managing a Drupal project the right way isn't so much about using the right project management modules and “heavy-lifting” tools. It's about:
 

  • understanding the specific challenges that Drupal projects pose
  • understanding the specific phases of the process
  • empowering the people in your team to capitalize on their Drupal expertise within the given time frames and according to your client's objectives
     

Now, here's an insight into the process of managing a Drupal project. One shaped as a list of predictable challenges and their most suitable solutions:
 

1. Proper Planning: Get The Whole Team Involved

In other words: defining objectives and setting up a final time frame with the client without getting your team, too, involved in the process is like:

Throwing spaghetti at a wall and hoping that it would just... stick somehow.

They're the Drupal experts, you know...

Therefore, getting the Drupal developers, themers and site builders engaged at this stage of the project is no more than... common sense.

They're the (only) ones able to:
 

  • give you an accurate time estimate for developing and implementing each functionality/feature
  • tell if certain of the requested features can't be delivered
  • identify interdependencies and conditions
  • provide you vital information about the Drupal-specific architecture and the project-specific development process
  • … information on what components to take, whether new contrib modules need to be developed to support certain functionalities etc.
     

Get your Drupal team involved in the planning and preparation process and strike a balance between their valuable input, the client's objectives, and time frames.
 

2. Tempted to... Micromanage? Empower Your Team Instead

Yet, resisting temptation won't be easy. Especially if you're a former Drupal developer now turned into a Drupal project manager.

You'd just die to get your hands dirty with code, wouldn't you? To supervise, closely, how every single line of code is being written.

Refrain yourself from that...

Instead, do keep your focus on the bigger picture! And, moreover, empower each member of your team to... shine. To excel at what he/she's doing. 

That instead of obsessing over details, getting everyone on their nerves and making them doubt their own skills:

By focusing on each one of the small steering wheels, you'd just lose sight of the larger mechanism that's a Drupal project.
 

3. To Tell or Not to Tell: Do Encourage Your Team Members to... Tell

Hiding the dirt under the carpet, from the stakeholders' eyes/ears and having members of your team remain silent over certain bottlenecks in the project will only act as 2 “Trojan horses”.

They'll lead your Drupal project to... failure.

Instead:
 

  • dare be honest with the client and inform him/her if you run the risk of a delay 
  • encourage your team to be open with you and with their teammates when they hit sudden challenges, unexpected issues
     

By:
 

  • hiding
  • ignoring
  • “genuinely” underrating
     

... issues detected in the development process — instead of getting them “exposed” and dealt with —  you're only sabotaging the Drupal project.

And now speaking of encouraging good communication within your team, how about creating a dedicated open forum for them to use? This could be the “place” where they'd share any issues that they will have detected in the project.

Or challenges that they face and can't address by themselves.
 

4. Juggling with Resources, Timeline, and Unforeseen Events

I'm not going to lie to you about this one: keeping the balance between staying flexible and being capable to assess risks is not going to be easy...

Unplanned issues will strike, new requirements will come to “jeopardize” this balance, unexpected changes will need to be accommodated under the same time frame...

Should you keep yourself rigid and inflexible to all changes, sticking to the initial plan?

Or should you “assimilate” all the incoming requirements and additions to scope with the risk of a project delay?

And that of overburdening your team with unscheduled tasks...

Can't help you with a universal answer here, one that would apply to all Drupal project management scenarios. It's you, together with your Drupal team, who should be able to estimate:
 

  • the changes' level of complexity
  • the project delay (if it's the case)
  • the chances for these additional tweaks to turn into contractual changes
     

5. Drupal Project Management Is 90% Good Time Management

And it all comes down to:

Breaking your Drupal project down into small, manageable tasks. 

Tasks that can be easily turned into goals and objectives:
 

  • daily objectives
  • weekly objectives
  • and so on...
     

Efficient Drupal project management, even if we're talking about truly complex ones, is all about making it... manageable.

About ensuring that the lists of tasks are logically structured and (most of all) time framed!

Needless to add that this strategy acts as a motivation-booster for your team: 

Just think about it: with every ticked off task, each team member can visualize the project's progress in... real-time. A progress that he/she, too, will have contributed to.

The END! These are the Drupal project-specific challenges that any project manager dealing with this CMS faces, accompanied by their life (reputation)-saving solutions.
 

Aug 17 2018
Aug 17

It's a robust, flexible and admin feature-packed CMS, there's no point in denying it. And yet: Drupal (still) lacks a modern UI that would make building rich web content —  such as landing pages — a breeze. But there is hope: the Gutenberg editor has been ported over, promising a better editing experience in Drupal 8.

The team behind this daring project? Frontkom, a Norwegian digital services agency that:
 

  • refused to just sit and wait (for a year or two) for the in-progress initiative of modernizing Drupal's admin UI to grow into a core solution
  • decided to capitalize on their experience in working with the Gutenberg page builder 
  • … and on this content editor's open source nature, too
  • … to bring it over to Drupal 8
     

Now, if you're determined to improve the editorial UX on your Drupal site, to “spoil” your editors with a modern, intuitive and flexible admin UI, keep on reading...
 

1. The Drupal Gutenberg Project: Aiming for a Modern Admin UI in Drupal 8

And by “modern” I do mean the opposite of the Panels & Paragraphs & Layout combo solutions currently available for editing text in Drupal.

Solutions which only manage to make the entire workflow... discouragingly complex.

Especially if it's rich web content that editors need to create via the Drupal admin UI.

And this is precisely the context where the Drupal Gutenberg project was born: Drupal desperately needed/needs a modern, JavaScript-based admin UI.

With WordPress 5 users already enjoying this fancy content editor and the Frontkom team's having gained experience in using it, the idea of porting it to Drupal started to form:

"Why wouldn't we make it possible for Drupal users, too, to benefit from this content editor?" 

And here are some of the original Gutenberg project's features that lead them into thinking that, once ported, the editor would significantly improve the editing experience in Drupal 8:
 

  • it's (highly) decoupled
  • it's open source
  • it's React.js-based 
  • it provides a simplified, smooth and cool functionality-packed admin UI
  • it's Medium and Squarespace's inspired
  • it turns the creation of complex landing pages into a breeze
     

Page editing in Drupal 8 wasn't going to be the same again!

Their initiative turned into a Drupal 8 module —  Gutenberg Editor —  currently still an experimental one. 

Curious enough?

The first step to satisfy your curiosity is to take a look at their live demo: an interactive glimpse into the Gutenberg text editor implemented in Drupal 8.
 

2. The New Gutenberg for Drupal: Top Features Improving the Editing Experience in Drupal 8
 

2.1. All the Page Elements Are... Content Blocks

That's right, the team behind this project capitalized on the “everything is a block” Drupal 8 concept when adapting the Gutenberg UI to Drupal.

The result?

Both the Drupal core blocks and 20+ Gutenberg blocks are available in the resulting admin UI.

Basically, a Drupal 8 editor can insert into the web page that he/she's creating any of the core Drupal blocks and of the Gutenberg blocks of choice.

Speaking of which, let me point out just a few:
 

  • Heading
  • Image gallery
  • Auto embedded social posts
  • Buttons
  • Custom Drupal blocks
  • Layout blocks
     

Needless to add that you're free to enrich this list with your own custom blocks, too.
 

2.2. Easy Switch from Visual to Code Editor

That's right, the Gutenberg UI enables you/your editors to quickly switch to code editor —  opening up a neat markup —  and to apply any needed tweaks on the output.
 

2.3. Positioning Content Is Straightforwardly Intuitive

Editors get to select precisely where they want to position different types of content on a page.

And the very same results that they generate while in the Gutenberg admin UI get instantly reflected on the live web page, as well.

And there's more! More great admin features improving editing experience in Drupal. For instance:

Full control over font sizes and colors; tweaking them becomes a breeze with the new editor.
 

2.4. There's a Blocks Search Box

And not only that:
 

  1. using this search box you can track down precisely those content blocks that you need to add to your page
  2. but you can access them inline, as well, using “/”.
     

2.5. Full Control of the Layout

Another great thing about the content blocks available in the Gutenberg UI is that: they can have child blocks, too!

This way, it'll get unexpectedly easy for your editors to split their used blocks into columns on a grid.
 

2.6. Auto Embedded Social Posts/Videos

And all it takes is pasting their URL.
 

The Story of a Real Challenge: Making Gutenberg CMS-Agnostic

Open source, but not fully CMS-agnostic... 

The team behind the Drupal Gutenberg project had to come up with a suitable solution for this challenge. And they did come up with a multi-step solution to make the fancy text editor work in Drupal 8, as well:
 

  • first, they created a fork and removed the WordPress specific features
  • they used the Gutenberg editor as a dependency 
  • next, they set up a standalone NPM package
  • then they built the Gutenberg Editor module
     

In short: a fork of the initial Gutenberg project is still maintained while being used as a dependency of the new Drupal 8 module. Therefore, each time Gutenberg gets an update, the corresponding Drupal module, too, gets a new release.

Now, digging deeper into the project's architectural design, we discover 2 elements that the team had to re-write for Drupal:
 

  1. the URL defining the editor routes (edit page route, new page route, preview page route)
  2. the api-request, now configured to “talk to” Drupal (instead of the WordPress API)
     

How does the new module work?
 

  • as a text editor, which can be easily enabled for each content type
  • all it takes is a long text field for it to work: it replaces the node edit UI for that specific content type
     

Note: the Frontkom team also “promises” us to re-use many of the Drupal-specific styling for the editor's UI elements in order to add a familiar Drupal feeling to it.
 

What Next? What's The Project Roadmap

Ok, so what we know for sure now, regarding this ambitious initiative turned into a Drupal module is that:
 

  1. the Drupal Gutenberg module is downloadable, yet still experimental (for developer use only)
  2. the team's still working on the project, implementing new features and functionalities aimed at making it feel more... Drupal native
  3. the final version will be presented to the eager/intrigued/curious/skeptical Drupal users and developers in the coming months
     

The END! Can't hide that I'm more than curious what you think about this contrib solution for improving the editing experience in Drupal 8:
 

  1. Are you looking forward to using it, hoping that this editor would make up for the inconveniences of working with Drupal's current admin UI?
  2. Are you skeptical about the perspective of being tied up to a WordPress page builder?
Aug 13 2018
Aug 13

Just imagine: putting together the powerful UI creation tools of a static site generator — more of a modern front-end framework rather —  built for high speed, like Gatsby.js, with Drupal 8's content modeling and access system! Putting their powers together into a blazing-fast website! But how to get Gatsby to work with Drupal?

How do you build a plugin that fetches data from API-first Drupal? In short: a static, conveniently simple, yet robust Gatsby site powered by a powerful, decoupled Drupal back-end?

You've got the questions, we've got the answers...

And we've grouped all our answers to your questions regarding “API-first and decoupled Drupal in connection with Gatsby” in a straightforward 4-step tutorial. One on building a high-speed Gatsby website backed by a versatile headless Drupal CMS.

Shall we dig in?
 

1. But What Is Gatsby.js More Precisely?

The standard, rather rigid definition would be:

“It is a GraphQL-fueled, React-based static site generator.”

Now if the words “static site generator” just make you... cringe, here's a more nuanced definition for you:

“Gatsby's more of a modern front-end framework —  one pulling together the best parts of GraphQL, React, webpack, react-router — built with the developer experience in mind.”

In short: it's a static site that this “more than just a static site generator” helps you build, leveraging its out-of-the-box front-end tools. A website geared to reach fast page loads while pulling data from a decoupled Drupal CMS.

And there are 2 basic steps for getting started with Gatsby. You simply write your site's code structure and let Gatsby handle the rest:
 

  1. turn it into a directory with a single HTML file
  2. … along with all your static assets


2. 3 Reasons Why You'd Want to Use Gatsby

… instead of Jekyll, your webpack config or create-react-app.
 

a. Because of the richness of the Gatsby ecosystem

With rich documentation at hand and backed by an already large community of starters, you'll get your Gatsby site up and running in no time.
 

b. Because it leverages GraphQL' power to build its data layer.

And this is one of those heavy-weighting reasons for using Gatsby over other competing alternatives:

Gatbsy's built to fetch data from... pretty much anywhere — your CMS of choice, Markdown, third-party APIs, Markdown — using “source” plugins. When creating its data layer, it relies on GraphQL, which builds an internal server of all this pulled data.

In short: when questioning yourself “how to get Gatsby to work with Drupal”, do keep in mind that in your future Gatsby & decoupled Drupal setup data gets queried from the same place, in the same way, via GraphQL.
 

c. Because it's built for high speed.

And this is one of Gatsby's hardest-to-resist-to advantage:

It's just... fast.

And that gets reflected in your final Gatsby & decoupled Drupal site while bubbling up to the user experience, as well.

Summing up, these are the 3 strongest reasons why you would be tempted to use Gatsby with Drupal CMS. 

I'm not going to engage in dynamic sites vs static sites debate now. The internet's already overcrowded with such comparisons.

I'll just end this “pledge” on using Gatsby with a non-debatable statement:

Since a static site generator pre-generates the pages of your website, scales of performance vs maintenance costs gets unbalanced. And guess which one's going up and which one down!
 

3. And Why Would Pair Gatsby with Drupal?

If there are strong reasons why you should be getting started with Gatsby, why is there any need to consider decoupled Drupal CMS for its back-end?

Because static site generators don't “care” much for the authoring experience. Content editors have to get themselves tangled up in Markdown for creating content.

True story!

And this is where powerful CMSs, such as Drupal, step in, “luring” you with their:

  • WYSIWYG editors
  • content types 
  • content modeling capabilities
  • access workflow capabilities

… to make your content team's lives easier!

And now your “How to get Gatsby to work with Drupal” dilemma turns into a new legitimate one:

How to make your Gatsby website cope with a decoupled Drupal setup without adding the “dread” of a database and web server to the equation? 2 elements that “pave the path” for performance and security issues...

Well, this is precisely what this “decoupling Drupal with Gatsby scenario means to avoid:

  • you'll get to host your Drupal CMS in-house
  • … and thus take full advantage of the robustness and versatility of a decoupled Drupal CMS back-end
  • your Gatsby website will fetch data from its Drupal back-end and generate content “the static way” (which translates into “incredibility fast page loads”)
     

4. How to Get Gatsby to Work with Drupal More Precisely

Or simply put: how to pull data/content from Drupal into your Gatsby website?

Here's a straightforward tutorial in 4 steps on how to integrate Drupal with Gatsby:
 

4.1. First, Build Your Drupal Server 

Assuming that you have a Drupal 8 website installed, the very first step to take is to:
 

a. Create a new content type 

For this exercise, it's a blog — including all its blog posts — that we'll try to transfer from Drupal to Gatsby. So, we'll name our content type: “Blog”.

It will include 3 basic fields:

  • title
  • body
  • image

Just navigate to Home>Administration>Structure>Content Types.
 

b. Turn Drupal into an API Server 

And there are 2 key modules that you'll need to install:
 

  1. jsonapi_extras: for gaining more control over the API (to disable resources, to change the default endpoint, to enhance field output etc.)
  2.  jsonapi, which will turn your Drupal website into an API server (one having a default endpoint)
     

c. Grant Anonymous User Permission to Access the JSON API resource list

If you overlook this step, you'll end up with an “Error 406” message, which will just sabotage your whole “decoupling Drupal with Gatsby” mission.
 

d. Check How Your Drupal API Server Works 

You can do this by navigating to http://[your-site]/jsonapi logged in as an Anonymous user.

If the page that you'll get displays all the information regarding your API server, then you'll know you're on the right track.
 

4.2. Then, Create a New Gatsby Site

But before you jump to building your new static website, check whether you have npm and node installed on your PC. 

How? By entering “npm  -v” and “node  -v” into your terminal.

Next, you'll need to install Gatsby's CLI:
 

npm install --global gatsby-cli 

Then, just build and get your Gatsby site up and running.

Note: by default, it will be accessible at localhost:8000.

How to Get Gatsby to Work with Drupal: building a new Gatsby site

4.3. Decouple Drupal with Gatsby: Pulling Data from the API Server
 

a. Set up the (/blog) page

Solving your “How to get Gatsby to work with Drupal”  type of dilemma starts with... the creation of a new page on your Gatsby website.

And is as simple as... setting up a new JS file.

Note: all your Gatsby pages will get stored under /src/pages.

Now here are the basic steps to take:
 

  1. create the blog.js in /src/pages
  2. then add this code: import React from "react" const BlogPage = () => ( <div> <h1>Latest from our bog</h1> </div> ) export default BlogPage 
     

Voila! You've just created a new page at /blog.
 

b. Pull Content from the Drupal 8 site using GraphQL

The “gatsby-source-drupal” plugin, to be more specific.

It's this source plugin that will be “in charge” with all the data (images here included) pulling from decoupled Drupal back-end and pushing into your Gatsby site.

Note: do keep in mind that, in this case, the JSON API module plays a crucial role.

And here's how you install your “power” plugin:
 

// in your blog.gatsby folder npm install --save gatsby-source-drupal 

Next, just configure your newly installed plugin:
 

// In gatsby-config.js plugins: [ ... { resolve: 'gatsby-source-drupal', options: { baseUrl: 'https://goo.gl/Cc5Jd3 apiBase: 'jsonapi', // endpoint of Drupal server }, } ], 


Tada! Now your site should be functioning properly.

If... not quite, here are the causes of the 2 most common error messages that you could get:
 

  • “405 error”, check whether the jsonapi_extras module is enabled
  • “ 406 error”, have a closer look at the permission on your Drupal site
     

c. Configure GraphQL to Pull Specific Pieces of Content from Drupal

In other words: to query all the “blog” nodes from Drupal and request specific data from the API server.

Another strong reason for using Drupal CMS with Gatsby is that the latter provides an in-browser tool for testing GraphQL queries names, for writing and validating them. You can access it at localhost:[port]/___graphql, whereas in our particular case here at: localhost:8000/___graphql.

Now, as you're solving this “How to get Gatsby to work with Drupal” type of puzzle, just try to query all the blog nodes.

Next, navigate back to your blog.js file and run this query:
 

export const query = graphql` query allNodeBlog { allNodeBlog { edges { node { id title body { value format processed summary } } } } } ` 


Then, update your const BlogPage so that it should display the body, content, and title:

const BlogPage = ({data}) => ( <div> <h1>Latest from our blog</h1> { data.allNodeBlog.edges.map(({ node }) => ( <div> <h3>{ node.title }</h3> <div dangerouslySetInnerHTML={{ __html: node.body.value }} /> </div> ))} </div> ) 


Next, save your file and... “jump for joy” at the sight of the result:

All your blog posts, nicely displayed, pulled from Drupal and published on your Gatsby site!
 

4.3. Finally, Just Go Ahead and Publish Your New Gatsby Site

And here you are now, ready to carry out the last task of your “How to get Gatsby to work with Drupal” kind of “mission”. 

This final task is no more than a command that will get your Gatsby website running:

gatsby build 

Next, just run through your /public folder to see the “fruits of your work”.

At this point, all there's left for you to do is to copy/push content in /public to the server and... deploy your new website using Gatsby with Drupal CMS.

The END! This is how you do it: how you use Gatsby.js in a decoupled Drupal setup so you can benefit both from:

  1. a modern static site generator's robustness and high performance, built with developer experience in mind 
  2. a powerful CMS's content managing capabilities, built with the editorial experience in mind 
Jul 20 2018
Jul 20

So, you've installed your version of Drupal and you're now ready to actually start building your website. What essential tools should you keep close at hand, as a site builder? Which are those both flexible and powerful must-have modules to start building your Drupal site from scratch?

The ones guaranteeing you a website that:
 

  1. integrates easily with all the most popular third-party services and apps
  2. is interactive and visually-appealing, irrespective of the user's device
  3. is a safe place for users to hang on, interact with, shop on, network on...
  4. is conveniently easy for content managers and admins to handle
     

Luckily, there are plenty of modules, themes and plugins to overload your toolbox with:

Long gone are the code-centric webmaster's “glory days”! Nowadays, as a Drupal site builder, you have a whole array of tools at your disposal to just start building and getting a Drupal site up and running in no time.

Sometimes without the need to write a single line of code!

But, let's not beat around the bush any longer and have a close look at these 10 essential modules that you'll need for your “Drupal 8 site building” project:
 

Definitely a must-have module:

Just consider that Drupal accepts ANY user password, be it a... one-letter password!

So, in order to set up your own stricter and safer password policy, you need to install this module here.

Then, you can easily define:
 

  • the minimal (and maximal) no. of characters that any user password on your Drupal site should include
  • the no. of special characters that it has to include
  • specific restrictions Like: "one can't use his/her email address as his/her password"
     

Why should this module, too, be in your essential toolkit of modules to start building your Drupal site with?

Because it implements the functionality to get notified — you, the admin or content manager —  as soon as a user posts a comment on the website.

Note: you can get “alerts” about both the logged in and the anonymous visitors' comments.
 

3. Breakpoints, One of the Must-Have Modules to Start Building Your Drupal Site 

It goes without saying that one of the Drupal site building best practices is providing it with a responsive web design.

And this is precisely what this module here facilitates:

Setting the proper media queries, once you've defined your own breakpoints.
 

A module whose functionality bubbles up to the content manager's experience.

Whenever he/she will have to make a selection involving both categories and subcategories, this hierarchical type of selection will prove to be more than useful:

Practically, once you/they select the “main” option, a new drop-down menu/widget including the subcategories to select from, pops up, as well. Like in the image here below:

Essential Modules to Start Building Your Drupal Site With: Simple Hierarchical Select

And complying with this EU notification is mandatory. 

So, this is why EU Cookie Compliance is another one of the essential modules to start building your Drupal site with:

It displays the given notification — providing visitors with the option to agree or/and to read more information about your cookie policy —  in the footer of your website.
 

6. Shield              

Any Drupal site building guide would advise you to install a module that shields your website from anonymous users and search engines when running your test environments.

And this is what Shield is built for:

To screen your site from the rest of the world —  except for you and the logged in users — when you deploy it in a test environment.

A more than convenient method, as compared to manually setting up a .htpasswd and then integrating it with .htaccess.
 

If you're not just another Drupal site builder, but a user experience-centric one, you must consider also those modules to build your Drupal site with that boost the level of user interactivity.

Like Beauty Tips here.

It displays balloon-help style tooltips whenever a user hovers over a certain text or page element on your website.

Pretty much like Bootstrap tooltip does.
 

Another one of the Drupal site building best practices is to turn it into a safe place for your users to be. 

In short: to protect their privacy.

And if you're building a website that's available on both HTTP and HTTPS, the Secure Login module comes in handy as it makes sure that:
 

  1. the user login form
  2. all the other fill-in forms that you'll configure for extra security
     

… get submitted via HTTPS.

It locks them down, enforcing secure authenticated session cookies, so that user passwords and other critical user data don't get exposed all over the internet.
 

It's another one of those essential modules to start building your Drupal site with if you're determined to provide the best user experience there.

What does it do?

It enables particular visitors on your site — those granted permission to edit and to add new menu items — to choose whether they open menu items in new windows or in the current ones.
 

A module that makes up for the “Remember me” feature that's missing from the user login screen in Drupal:

It comes to implement this missing option, one independent from the PHP session settings.

So, we're not talking about the conventional, too long “PHP session time” here, but about a more secure and user-friendly “Remember me” feature added to the login form.

Furthermore, the module enables you to define some extra security policies, too:
 

  • the no. of persistent sessions that a Drupal user can enjoy at the same time
  • specific pages where users still have to log in again
  • after how long the logged-in users will need to re-enter their credentials once again
     

And 2 “Extra” Modules to Consider When Building Your Drupal Site

By “extra” I mean that they're not really essential modules to start building your Drupal site with. Yet, they're the first 2 ones to consider right after you've put together your “survival” toolkit as a site builder:
 

1. Site Settings & Labels    

Take this common scenario:

You need to display a social network URL on multiples pages on your Drupal site. 

What do you do?
 

  1. you hard coding this single setting in the source
  2. you start building a custom Drupal module for handling this variable
  3. you install the Site Settings & Labels module and thus display a checkbox to render page elements through a template conditional
     

The “c” variant's undoubtedly the winner here. 

A win-win for you, in fact:
 

  1. you save the time you'd otherwise have spent coding
  2. you improve the user experience on your Drupal site
     

2. Slick/Slick Views/Slick Media          

It's actually a suite of modules to start building your Drupal site with. One “injecting” the needed functionality so that you can easily set up:
 

  • carousels
  • slideshows
     

… on your freshly built website.

Note!

I won't lie to you: setting up the library dependencies is not exactly a child's play. Yet, once you've succeeded it, configuring the modules in this suite, right in your Drupal admin, is piece of cake.

The END! These are the 10 must-have modules to start building your Drupal site from scratch with. Would you have added some more? 

Or maybe you wouldn't have included some of the modules listed here, as you don't consider them “essential”?

A penny for your thoughts!

Jul 18 2018
Jul 18

Let's say that it's a WhatsApp-like, a decoupled, Drupal 8-backed, real-time chat platform that you're building. One using Node.js. In this case, implementing field autocomplete functionality becomes a must, doesn't it? But how do you add autocomplete to text fields in Drupal 8?

Needless to add that such otherwise "basic" functionality — implemented on fields like node reference and user/tags — would instantly:
 

  1. improve the user experience 
  2. increase the level of user interactivity and engagement
     

Users would group around different "channels" and be able to easily add new members. The auto-complete text fields will make the whole “new member coopting” process conveniently easy:

Users would only need to start typing and an array of name suggestions (of the already existing team members) would spring up.

But let's see, specifically, what are the steps to take to implement autocomplete functionality in Drupal 8:
 

1. The Drupal Autocomplete Form Element: Adding Properties to the Text Field

The first basic step to take is to define your form element. The one that will enable your app's users, on the front-end, to select from the suggested team members' names. For this:
 

  1. navigate to “Form” (you'll find it under “Entity”)
  2. scroll the menu down to ”NewChannelForm.php”
     

Note: using “#autocomplete_route_name element”, when defining your form element, will let Drupal know that it should ignore it on the front-end.

And now, let's go ahead and assign specific properties to your form's text field! For this:
 

  1. define “#autocomplete_route_name”, so that the autocomplete JavaScript library uses the route name of callback URL
  2. define “#autocomplete_route_parameters”, so that an array of arguments gets passed to autocomplete handler
     
$form['name'] = array(
    '#type' => 'textfield',
    '#autocomplete_route_name' => 'my_module.autocomplete',
    '#autocomplete_route_parameters' => array('field_name' => 'name', 'count' => 5),
);


And this is how you add #autocomplete callback to your fill-in form's text field in Drupal 8!

Note: in certain cases — where you have additional data or different response in JSON —  the core-provided routes might just not be enough. Then, you'll need to write an autocomplete callback using the “my_module. autocomplete“ route and the proper arguments (“name” for the field name and “5” as count, let's say).

And here's specifically how you write a custom route:
 

2. Add Autocomplete to Text Fields in Drupal 8: Define a Custom Route

How? By simply adding the reference to the route — where data will get retrieved from — to your “my_module.routing.yml file”:
 

my_module.autocomplete: path: '/my-module-autocomplete/{field_name}/{count}' defaults: _controller: '\Drupal\my_module\Controller\AutocompleteController::handleAutocomplete' _format: json requirements: _access: 'TRUE' 


Note: remember to use the same names in the curly braces (those that you inserted when you defined your “autocomplete_route_parameters”) when you pass parameters to the controller!
 

3. Add Controller with Custom Query Parameters

In the custom route that you will have defined, you'll have a custom controller AutocompleteController, with the handleAutocomplete method.

Well, it's precisely this method that makes sure that the proper data gets collected and properly formatted once served.

But let's delve deeper into details and see how precisely we can generate the specific JSON response for our text field element.

For this, we'll need to:
 

  • set up a AutoCompleteController class file under “my_module>src>Controller > AutocompleteController.php"
     
  • then, extend the ControllerBase class and set up our handle method (the one “responsible” for displaying the proper results)
     
  • it's the Request object and those arguments already defined in your routing.yml.file (“name” for the field name and “5” for the count, remember?) that will pass for your handler's parameters
     
  • the Request object will be the one returning the typed string from URL, whereas the “field_name” and the “count” route parameters will be the ones providing the results array.
     

Note: once you get to this step here, as you add autocomplete to text fields in Drupal 8, remember that you should be having data in “value” and “label” key-value, as well:

Next, you'll set up a new JsonResponse object and pass $results, thus generating a return JsonResponse.
 

Summing Up

That's pretty much all the “hocus pocus” that you need to do to add autocomplete to text fields in Drupal 8. Now the proper data results should be generated.

Just reload your app's form page and run a quick test:

Try to create a brand new channel in your app and to add some of the already existing team members.

Does the text field have autocomplete functionality added to?

Jul 10 2018
Jul 10

Let's say that you need to spin up a new Drupal environment in... minutes. To quickly test a new patch to Drupal core, maybe, or to switch between 2 or more clients on the same day and thus to run multiple copies on several websites... In this case, how about taking the quick and easy way and set up a local Drupal site with Lando?

"What is Lando?" you might legitimately ask yourself.

A DevOps tool and Docker container-based technology enabling you to spin up all the services and tools that you need to develop a new Drupal project in no time.

"Why would I choose Lando as a method to set up a local Drupal site?"

Let me list here some of the strongest reasons:
 

  • it makes setting up a local Drupal site unexpectedly easy (and I'm talking about "minutes" here)
  • it makes getting started with Docker container technology a whole lot easier
  • it enables you to share your Drupal site's configuration within your team right on your Git repository (taking the form of a YAML file)
  • it puts several development environments (LEMP, MEAN, LAMP) at your disposal
     

Are these reasons strong enough for you?

If so, here's a quick step-by-step guide on how precisely to set up a Drupal site with Lando:
 

Step 1: First, Make Sure You Meet the System Requirements

If, as a web developer, you're not efficient with using the command line... well... then there are high chances that you find this tutorial here a bit discouraging.

And if being more than just familiar with the command line is not a strict requirement, then the following system requirements () are:
 

  • macOS 10.10+
  • Linux (with kernel version 4.x or higher)
  • Windows 10 Pro+ (or equivalent) with Hyper-V running
     

These are the 3 operating systems that Lando's currently compatible with. Now, let's move on...
 

Step 2: Download and Install Lando and Docker 

Go to Lando releases on Github and download the latest version for your OS. Just run the installer and let it "do the job" for you:
 

  • install Docker for Windows, Docker for Mac, Docker CE
  • install Lando: for Mac run brew cask install Lando and for other OS download the .rpm, .dmg, .exe or .deb
     

Step 3: Create a New Drupal Project

Luckily for you, there are several ways to get a Drupal codebase. Pick the one that you're most comfortable with as you set up a local Drupal site with Lando:
 

  1. install Drupal 8 the standard way (the first step there being "Get the Code"); next, grab the latest version of Drupal 8 navigating to "Download & Extend"
  2. or use Composer to create your new Drupal project: drupal-composer/drupal-project:8.x-dev my_drupal_project --stability dev –no-interaction
  3. or just navigate somewhere on your PC and use GIT to clone it: git clone --branch 8.6.x https://goo.gl/Q3MoVu lando-d8
     

Step 4: Set Up a Local Drupal Site with Lando: Extract Drupal

To extract Drupal just:

  1. open up your terminal window
  2. enter the commands here below:
cd Sites
tar xzf /tmp/drupal-8.5.1.tar.gz
mv drupal-8.5.1 drupal-lando
cd drupal-lando

And thus set up the Sites/drupal-lando/ directory inside your home directory


Step 5: Set Up Lando   

Now's time to initialize Lando and enable it to create a basic configuration file for you.

And, again, you have more than just one option at hand:
 

  1. while still in your terminal window, run the following command and specify the Drupal 8 recipe and your web root as web, next name it "drupal-lando": lando init --recipe drupal8 --webroot=. --name="drupal-lando"
  2. or just launch the interactive session: run "lando init" interactively
     

Next, it's the following YAML file/ ".lando.yml", that it will create:

name: drupal-lando
recipe: drupal8
config:
  webroot: .

Note: feel free to ignore the "lando init" step and to jump straight to copying and pasting this file here.
 

Step 6: Start Your Environment & Wait for Your Docker Containers to Get Set Up

And here you are now, at that step from the whole process where you set up a local Drupal site with Lando where you start your Docker engine.

For this, just run the following command in your terminal window:

lando start 

If everything goes according to plan, this is where Lando starts Docker and sets up 2 containers.

Next, feel free to run:

lando composter install

It's going to use PHP/Composer inside the newly created Docker container for building Drupal's Composer dependencies.
 

Step 7: Browse to Your Site's URL and Walk Through the Drupal Installation Process

Time to install your new clean Drupal 8 site now.

Just visit your local site in the web browser and walk through the Drupal wizard install process (since your new site starts with an empty database, you will be automatically directed to the Install page)

Set Up a Local Drupal Site with Lando- Drupal Installation

Once you reach the step where you need to configure your database, enter these options here:
 

  • Database host: database
  • Database name, username, password: drupal 8
     

Next, unfold the "Advanced Options" drop-down menu and:
 

  1. replace "localhost", currently showing up in the "Host" field, with "database"
  2. hit the "Save and continue" button and let the Drupal installation process carry out
     

You'll set up a local Drupal site with Lando in... minutes! A brand new website that you can then easily:
 

  • test
  • debug
  • manage with Composer
     

Optionally, you can add a new service of your liking (e.g. MailHog, for catching outbound mails) and custom tune your setup right from your .lando.yml.file.

Set Up a Local Drupal Site with Lando- Welcome to Drupal Lando

The END! And this is how you do it... Told you it was just a matter of a few easy steps! 

Jul 04 2018
Jul 04

I'm a woman of my word, as you can see: here I am now, as promised in my previous post on the most effective ways to secure a Drupal website, ready to run a “magnifying glass” over the best Drupal security modules. To pinpoint their main characteristics and most powerful features and thus to reveal why they've made it to this list.

And why you should put them at the top of your own Drupal security checklist.

So, shall we dig in?
 

It's only but predictable that since the login page/form is the entry to your Drupal site, it is also the most vulnerable page there, as well.

Therefore, secure it!

In this respect, what this module enables site admins to do is :

  • define a certain number of login attempts; too many invalid authentication attempts will automatically block that account
  • block/limit access for specific IPs
     

Moreover, you get notified by email or via Nagios notifications when someone is just username/password guessing or using other kinds of brute force techniques to log into your Drupal site.

In short: the Login Security module, through its variety of options that it “spoils” you with, empowers you to set up a custom login policy on your site. To define your own restrictions and exceptions.

As already mentioned here, on this blog, when we've tackled the topic of Drupal security:

Keeping your Drupal core updated is that easily underrated, yet most powerful security measure that you could implement!

Now what this module here does is assisting you in keeping your Drupal codebase up to date: safely patched and having all the crucial upgrades.

And I don't need to remind you the security risk(s) that all those site owners ignoring the latest patches to Drupal core expose their websites to, right? 
 

Captcha is one of the best Drupal security modules since it's one of the most used ones.

And no wonder: could you imagine submission forms on your website with no Captcha? The age-old system is one of the handiest ways to keep spammers and spambots away.

So, having this module “plugged in”, providing you with the needed captcha support, becomes wisely convenient.
 

The module enables you, as your Drupal site's admin, to define specific rules for “wannabe users” to follow when they set up their account passwords.

From constraints related to:
 

  • special symbols that those passwords should include, to ramp up both the given account's and your own site's security
  • to uppercase letters
  • to numbers...
     

… once you plug in this Drupal security module in, it's you who gets to set up the policy for creating account passwords.
 

5. Security Review, One of the Best Drupal Security Modules

The Security Review module is that “Swiss knife” that you need for hardening your site's shield.

Meaning that it's an all-in-one tool. One that comes with its own Drupal security checklist that it regularly goes through and sets against your website, detecting any missing or improperly implemented security measures.

Moreover, it automates a whole series of tests for tracking down any signs of exploits and brute-force attacks:
 

  • arbitrary PHP execution
  • XSS exploits
  • SQL injection
  • suspicious PHP or JavaScript activity in content nodes
     

Once it identifies the vulnerabilities, it “alerts” you and gives you the best recommendations for mitigating those security risks. All you need to do is follow the suggestions.
 

Another module that “empowers” you to take full control over the security strategy on your Drupal site. To set up specific options for minimizing the chances of exploitable “cracks” showing up in its security shield:

For instance, it could recommend you to set up HTTP headers on your Drupal site.
 

Here's another one of those best Drupal security modules that's also one of the widely used ones.

Why is it a must-have on your own Drupal site? Because it enables you to set a limit to the number of simultaneous sessions per user, per role.

This way, you trim down the chances of suspicious activity being carried out on your site and eventually leading to brute-force attacks.
 

Another module that's a must on your Drupal site:

It basically enables you, the site admin, to define a policy that would log out users after a specified time period of inactivity. 
 

LinkedIn, Google, Twitter, Instagram, Facebook are just some of the big names that have adopted this user authentication method for security reasons. So, why shouldn't you, too?

Especially when you have a dedicated module at hand, Two Factor Authentication, to:
 

  • provide you with various methods to select from: pre-generated codes, time-based one-time PINS or passwords, codes sent via SMS etc.
  • give you full freedom in defining that two-factor authentication strategy that suits your site best
     

The principle is as simple for the user, as it is effective for your website, from a security standpoint:

The user gets a security code that he/she'll then need to use for logging into your Drupal site.
 

A command-line tool, with IDE support, that gives your codebase a deep scan and detects any drift from the coding standards and best practices.

Why has it made it to this exclusive list of 15 best Drupal security modules? Cause vulnerabilities might be lurking right in your Drupal code, not necessarily in your users' weak passwords or unpatched core modules.

Having a tool at hand that would identify and notify you of all those weak links in your code, where the best practices aren't being followed, is just... convenience at its best.
 

Another key module to add to your Drupal security checklist. 

For you do agree that email addresses are some of hackers' easiest ways to infiltrate into your website, don't you? 

Now what this module here does is obfuscate email addresses so that spambots can't collect them.

Note: a key strength of SpamSpan is that it uses JavaScript for this process, which enhances accessibility.
 

12. ACL      

“A set of APIs” This is how we could define this module here, which doesn't come with its own UI.

Its key role? To enable other Drupal modules on your website to set up a list of users that would get selective access to specific nodes on your site.
 

Why is Paranoia one of the best Drupal security modules?

Because it will end your “paranoia” — as its name suggests — that an ill-intentioned user might evaluate arbitrary code on your site.

The module practically identifies all those vulnerable areas where a potential attacker could exploit your site's code and blocks them.
 

Limiting or blocking access to key content types on your site is no more than a common-sense security measure to take, don't you agree?

Therefore, this module here's designed to assist you throughout this process:
 

  • as you define detailed permissions on your site: to view/edit/ delete specific content types
  • … by user role and by author 
     

Word of caution: do keep in mind that, since Content Access uses Drupal's node API, you shouldn't enable other modules using the same endpoints on your website!
 

A module that ramps up not just your site's security, but also its accessibility.

Just think about it:

Nowadays anyone has at least one Google account. Therefore, “anyone” can easily log into your website using his/her own Google account credentials.

Once, of course, you will have installed and turned this Drupal module on.

END of list! These are the 15 best Drupal security modules worth installing on your site. 

Scan them through, weigh their key features, set them against your site's specific security needs and make your selection!

Pages

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