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:
you don't have time to install a caching module
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?
RADU SIMILEANU / Dec 10'2018
You're ready to turn your idea of a machine learning app using image recognition into “the next best thing”! It's going to revolutionize mobile advertising, the education sector, the automobile industry, the world of finance... you name it.
But then, reality strikes you:
"How do I implement image recognition functionality into my application the... easy way?"
And the “easy-to-use” factor becomes particularly important if you have no machine learning background.
How do you incorporate such a service/API into your app? An app that should analyze, organize, alter different images?
Now, here's what you need to keep in mind when you build a machine learning-powered app, plus a selection of the best image recognition APIs.
So you can compare and experiment with in order to select the one that perfectly suits your goals and your machine learning background...
1. 4 Things to Keep in Mind When Building a Machine Learning App
Before you jump into enabling machine learning capabilities into your web or mobile app, make sure:
that you've gained in-depth knowledge of that specific market that you're targeting
that you've properly prepared your data: make sure you've selected the best data sources and data collecting techniques
you've chosen the best algorithm for your app (run it, tune it, test it)
you're using the right method: for on-device machine learning you'll need to pay attention to your model's size (make sure it's not oversized; otherwise, you'll need to rely on cloud services for machine learning)
Note: organize your dataset ensuring that your images are of different lengths, that they feature plenty of particularities, thus helping your custom model to identify the target objects/emotions/scenes more accurately.
2. Implement Image Recognition to Your App: Choosing the Best API
“What are the best image recognition APIs in the market?” you must be asking yourself right now.
“What's the best solution for me to incorporate image recognition into my machine learning app if:
I have little to no machine learning background
I'm looking for an image analysis software that's straightforward to implement, easy to use, yet powerful
… one that should enable me to quickly train a custom model"
2.1. Mobile Vision API
A Google-powered framework equipped with the capability to detect objects in images and videos.
For this, it uses 3 types of detectors:
a face detector
a text detector
a barcode detector
Image source: Google Developers.
The “face detector” is “loaded” with some great features such as:
providing information about the state of the human faces in the analyzed images/videos: eyes open/closed, smiling, crying etc.
identifying parts of a face: mouth, nose, eyes
analyzing multiple faces on a single image
identifying human faces on recorded videos, on mobile camera and still images
Note: do keep in mind that this API does not provide face recognition capabilities; it cannot tell whether 2 images, presenting human faces, are identical or not.
2.2. Google Vision API
Looking for something a bit more complex, more... refined that an "object detection” service?
For an image recognition software that does more than just:
provide similar images
“detect” faces and visual objects
… and detects “details” about the uploaded images instead? One that identifies whether:
the being in the picture is a human or a dog
the characters are sad or happy (sentiment analysis)
they're racy or engaged activities marked as “not OK” in the Google Safe Search
… and labels the given images (“weather”, “autumn”, “dog walking”, “male”)?
Then, the Google Vision API (or “Cloud Vision API”) is what you're looking for.
Unlike other leading image recognition solutions available, it “spoils” you with:
a simple REST API
landmark detection functionality
How does it do it? The API connects the code of your machine learning app to Google's image recognition capabilities.
Now, here's how you set it up:
Sign Up for a Google Compute Engine Account
Select a Project (if you're a newly registered user, then the “My First Project” is selected by default)
“Grab” an API key from the menu on the left side of the screen (save it to a text file) and run it in your project (just enable the API at this URL)
Select your app project
You're now ready to roll with your new image recognition API integrated to your app project; just save the text in a google_vision.json file:
It's this JSON request that will point out to Google Vision API the specific image to parse and the detection capabilities to trigger.
Note: remember that you should use this API in personal applications only!
2.3. Clarifai
Here's a custom image recognition software in our list to start experimenting with if:
you're looking for a visual search tool with a video-analysis functionality added to, as well
you need an easy to implement and to use API for tagging images; for recognizing and understanding the content features in your images/videos
you're looking for an API with a strong concept modeling
you're planning to incorporate an image recognition functionality that enables you to create and to train your own custom models to test against
“But how do I use Clarifai's Custom Training API to set up my own model?”
It's pretty straightforward:
for declaring a positive you use: clarifai.positive('https://goo.gl/1Q8W8S 'dog', callback);
for predicting an image you use: clarifai.predict('https://goo.gl/xNNRJg 'dog', callback);
for declaring a negative you use: clarifai.predict('https://goo.gl/xNNRJg 'lion', callback);
2.4. Einstein Vision
Looking to get in on a little AI action?
To build an image recognition app leveraging AI and deep learning models trained to recognize images at scale?
Consider Einstein Vision then! Integrate it into your machine learning app and start to explore its two APIs:
Einstein Object Detection: empowers you to train models that should recognize several distinct objects in an image (providing information such as the location and the size of each item)
Einstein Image Classification: enables you to create and to train models to detect and classify images at scale
“Where would I use such an AI-enabled app?”
Here's one of its most common image-recognition use cases:
You can use all those contextual clues stored in your images (your customers' preferences, your products/services' level of quality, your inventory levels etc.) to empower your marketing, sales and/or service teams. This way, they'll gain more accurate insights about your customers.
2.5. Amazon Rekognition
What if you're not looking for the best tool for sentiment analysis, object and scene detection, but for one that rocks at facial recognition instead?
Then you go with Amazon Rekognition.
It's designed to:
provide detailed information (e.g. beard recognition)
run facial comparisons and assess the likelihood that 2 faces are of the very same person
2.6. Google Tensorflow Object Detection API
A non-complicated way to integrate image recognition functionality into your machine learning app.
Tensorflow Object Detection API is an open source framework designed around the idea that:
Building, training and deploying of object detection models should be quick and easy.
In this respect, the available guide supports the whole idea.
Image source: Github
Here's how to use the API:
Download the frozen model (.pb — protobuf) and run it into memory
Load categories, labels, visualization tools and so on using the built-in helper code
Launch a new session and run the resulting model on one of your images
2 tips for incorporating and using this API in your machine learning app:
figure out how you can speed up the API so you can use it for real-time object detection on mobile devices
experiment with the more accurate models to see the difference
The END!
Have I managed to (at least partially) answer your questions:
“What do I need to know for building a machine learning app?”
“How do I build custom image recognition functionality into my web/mobile app?”
“What are the best image recognition APIs in the market right now?”
Photo by Antoine Beauvillain on Unsplash.
RADU SIMILEANU / Nov 16'2018
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:
flexible; it should empower you to easily and fully customize every single node/content item on your website (not just blocks)
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:
to create and edit a layout for every content type on your Drupal website
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?
RADU SIMILEANU / Nov 02'2018
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?
first, it was the need to automate Drupal module and security updates
then, the issues queues filled with opinions grounded in skepticism, valid concerns, and high hopes started to “pile up” on Drupal.org,
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
… which grew into the current Auto Update Initiative
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):
do you outsource your Drupal Maintenance tasks to 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:
not meet large company websites' security requirements; that it would not fit their specific update workflows
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?
Definitely yes
No way
It depends on whether...
RADU SIMILEANU / Sep 28'2018
“Should I use Docker in production?”
Are you "torn” between:
Docker's superpower as a container platform and all the security concerns related to the Docker model?
“Seduced” by the names of all those giant companies — Twitter, Google, Amazon, eBay, Netflix — who're already using Docker containers in production? Yet, still skeptical and hesitant to run them in production environment considering all the signaled data management issues?
Now, instead of letting this question turn into a “haunting” dilemma, you'd better dug for some answers. Find out:
whether Docker is right for your own unique project, as well
how a container infrastructure works (compared to a traditional environment)
what it takes to use Docker in production
which are the common misconceptions and issues with Docker in production
And, most of all: based on your own use case, should you be running Docker in production environment or not?
1. The One Question to Ask Yourself: “What Will I Do with Docker in Production?”
Before asking yourself:
“Should I be using Docker in production? How safe is it?”
… you'd better answer one critical question:
“What will I do with Docker in production?”
And toying with the thought of using Docker containers does require a reevaluation of your system's whole infrastructure. From the ground up:
How will you monitor Docker containers in production?
How will things be deployed?
How will backups be performed?
What about updates? How will they be handled?
Also, while giving yourself some realistic and straightforward answers to all these questions, try to consider different attack vectors, as well:
What services will your Docker containers get access to?
Are you able to restrict their access to the host system?
And what kind of “privileges” will they get?
So many things to clarify before you can ask yourself:
“Should I use Docker in production?”
2. Container Infrastructure vs Traditional Environments
How does a Docker container infrastructure work?
It's critical that you fully understand what sets it apart from a traditional environment before you can assess whether it's safe for production usage in your project or not.
Unlike traditional environments, where a sysadmin would normally run upgrades and restart services, in container infrastructures, containers are read-only, immutable... elements.
In other words: security upgrades won't happen inside your Docker containers; for these upgrades to run, you'll need to redeploy newly upgraded versions of your containers.
Note: since developers can push containers to your platform, you should define and enforce custom policies to limit the no. of privileges assigned to each one of the containers in your infrastructure.
3. 2 Most Common Misconceptions about Using Docker in Production
Since it hit the systems scene (2002) and quickly “stole the show”, Docker's generated a lot of misconceptions. And probably the most common one (that all the other ones stem from) is that:
"Docker's ridiculously easy to use; it's a “one size fits all projects/use cases/infrastructures...” type of technology."
Well, not quite...
Now, let's “bust some Docker-related myths” once and for all:
3.1. Running Docker in Multi-Host Production Environments Is (So) Simple
It's almost grown into a universal truth that:
Using Docker even in a multi-host production environment is... nothing but a child's play.
It is technically possible, indeed, yet, it's far from simple!
Before running Docker in a multi-host network — in a robust and safe way, I mean — you need to consider and to put in place the proper management of a whole lot of variables:
orchestrating container deploys with no downtime at all
managing container logs
ensuring that the private image repository's 100% secure
managing container logs
properly handling all container deploy roll-backs
And the list is almost a never-ending one...
See? Sure, big companies manage to use Docker in multi-host production environments and to successfully handle all the above variables, yet the process's anything but trivial.
3.2. It's OK to Blindly Jump into Docker, No Matter The Infrastructure
Tempted to go from “Should I use Docker in production?” to “I should/can definitely use it straight away!”?
And this is yet another misconception that has grown out of the general idea that using Docker requires zero preparations; zero planning and evaluation of your current infrastructure.
That it's conveniently easy to use and it fits all use cases.
Wrong!
You need to take a whole lot of aspects into account before using Docker in production:
It requires a robust, stable foundation/infrastructure!
In other words, if your current system does not have:
an automated system setup
a fully secured least-privilege type of access
automated deploys
easy-to-be-restored and 100% secure database backups
and more
... you should reconsider using Docker in production ASAP. Or at least postpone your plan till you've filled in all those cracks in your systems' infrastructure...
4. Choosing the Right Path From Test Environment to Production Environment
The very first step to take for “leveling up” from running Docker in your test environment to using it in production is: choosing the right path.
This can be either:
predetermined by your own project's particularities (project-specific constraints such as a specific cloud service or datacenter)
DIY
a rented cloud service
a pre-made platform
Choose your path wisely!
5. 3 Key Aspects to Take into Account For a Smooth Production Usage of Docker
5.1. The Docker Engine: Tweaking Its Default Settings Is a Must
As I've been trying to stress out here:
Running Docker in production does require certain preparations and considerations.
For instance, once you install the Docker engine to your distribution of choice (Ubuntu or Red Hat or... another one), you shouldn't stick to its default settings.
They're not suitable for production usage!
Therefore, it will require some tweaking so that your Docker engine can handle the load once in production environment.
Moreover, your engine will be in charge of running the containers and nothing more. When it comes to:
cleaning up containers
… volumes
… logs
… these are all your configuration's responsibility.
And 2 more words of caution/pieces of advice:
keep in mind to check the graph driver (go for Overlay2 if it's the latest version of kernel that you're using)
keep both your Docker engine and the kernel safely up-to-date
5.2. A Well-Built CI/CD Pipeline Can Save Your Life
And it's just partly an exaggeration...
For once you run your Docker containers in production and you need to handle a complex infrastructure of services, having a reliable pipeline in place can do wonders.
In short: if you don't automate the process of moving your containers across all the 3 stages of production — build phase, test phase, deployment phase — you'll go nuts...
Tip: remember to script everything; also, to version control each and every script and configuration.
5.3. Security: Handle It Properly, Right from the Testing Environment
In other words: no matter how tempted you might be to overlook this aspect once you finally have Docker running properly in production, don't underrate the security issue.
Moreover, you should give it due consideration right from the testing environment...
Once you deploy your Docker containers in production environment, be 101% cautious and vigilant to detect any network vulnerabilities threatening your data.
6. “Should I Use Docker in Production?” Is It Safe? Is It Efficient?
Back to our initial question:
“Is it safe to run Docker in production environment?”
My answer to you is:
It is, as long as you take into account all the above-mentioned technical aspects and variables and as long as you adopt the best practices for using Docker in production.
Meaning:
applying updates
running your CI tests
automating... everything
closely monitoring your Docker containers once in production
using the available tools
running only current versions
running only one process per container
“supercharging” your orchestration tool with all the appropriate security measures (Kubernetes, Swarm, Titus, DCOS etc.)
etc.
In short: Docker is only as safe as its users' implemented safety measures.
Technically, it can be used in production.
When it comes to safety, Docker's come a (really) long way since its early days.
With:
a whole set of best practices in place
appropriate powerful tools to use for securing it
... Docker's once glaring security flaws (e.g. less isolation of containers as compared to virtual machines) now seem like a bad memory from its old “experimenty” stage.
Yet, to your “Should I use Docker in production?” type of question I can only answer:
“You should, if you don't do it blindly and you commit yourself to following the best practices”
7. In Conclusion...
If I was to sum up, into a “shortlist of commandments”, all the recommendations, words of caution, clarifications, and explanations here-above, it would go something like this:
don't jump blindly into Docker; take your time to think through all the involved aspects
keep in mind that it's far more unlikely for an attacker to exploit an insecure Docker container in your system than to... tap into social engineering for getting his hands on the password
Docker's an extremely powerful tool, so running it on top of an unstable infrastructure is pretty much like driving a sports car on a pothole-riddled road
RADU SIMILEANU / Aug 31'2018
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:
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”.
1. Access by Entity
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
2. Content Access
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.
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.
3. Permissions by Term
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
How do you set everything up?
first, you enable the module
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!
4. Node View Permissions
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!
6. Taxonomy Access Control Lite
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?
RADU SIMILEANU / Aug 30'2018
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:
HTML: :escape(), for plain text
Xss: :filterAdmin(), for admin-submitted content
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:
you get this pop up alert: <script>altert ('xss') </script>
or this error message close to the IMG tag: img src="a" 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:
sending and properly validating the token
using Form API
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:
Hacked!
Permission report
Encrypt
Composer Security Checker
Security Review
Paranoia
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?
RADU SIMILEANU / Aug 24'2018
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:
turn it into a directory with a single HTML file
… 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:
Gatsby'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 advantages:
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:
jsonapi_extras: for gaining more control over the API (to disable resources, to change the default endpoint, to enhance field output etc.)
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.
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:
create the blog.js in /src/pages
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.4. 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:
a modern static site generator's robustness and high performance, built with developer experience in mind
a powerful CMS's content managing capabilities, built with the editorial experience in mind
RADU SIMILEANU / Aug 13'2018
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:
integrates easily with all the most popular third-party services and apps
is interactive and visually-appealing, irrespective of the user's device
is a safe place for users to hang on, interact with, shop on, network on...
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:
1. Password Policy
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"
2. Comment Notify
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.
4. Simple Hierarchical Select
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:
5. EU Cookie Compliance
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.
7. Beauty Tips
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.
8. Secure Login
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:
the user login form
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.
9. Menu Target
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.
10. Persistent Login
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?
you hard coding this single setting in the source
you start building a custom Drupal module for handling this variable
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:
you save the time you'd otherwise have spent coding
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!
RADU SIMILEANU / Jul 20'2018