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.
Adriana Cacoveanu / Aug 21'2018
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 that 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:
using this search box you can track down precisely those content blocks that you need to add to your page
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:
the URL defining the editor routes (edit page route, new page route, preview page route)
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 stylings 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:
the Drupal Gutenberg module is downloadable, yet still experimental (for developer use only)
the team's still working on the project, implementing new features and functionalities aimed at making it feel more... Drupal native
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:
Are you looking forward to using it, hoping that this editor would make up for the inconvenience of working with Drupal's current admin UI?
Are you skeptical about the perspective of being tied up to a WordPress page builder?
Adriana Cacoveanu / Aug 17'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
Thinking to convert your website to a progressive web app? And why shouldn't you?
Since the benefits are obvious:
you “end up” with a website behaving like a native web app
… one that works offline (and “offline” is the new black these days, right?), having its own home-screen icon
improved user experience: not only that your site goes mobile, but users don't even need to get your site-turned-into-an-app downloaded from an app store and then installed on their devices
Furthermore:
Putting together a PWA out of a regular website (or blog) is unexpectedly easy! Basically, any site/blog can be turned into a progressive web app...
No need to let yourself discouraged by terms such as:
service workers
web app manifest (or “manifest.json)
… for the whole process is actually far less complex than it sounds.
Here, see for yourself: go through the 3 essential steps it takes to convert your website to a progressive web app:
But First: All You Need to Know About PWAS— Benefits & Common Misconceptions
A succinct and clear enough definition of progressive web apps would be:
A PWA is a website that behaves like a native mobile app once visited on a mobile device.
Whereas a more detailed and comprehensive one would go something like this:
A PWA is a sum of modern web capabilities (and basic mobile capabilities) that enable users to save it on their own mobile devices (thus enjoying a native app-like experience) and access it offline, too.
And now, without getting into the old “native mobile app vs PWAs” debate, let me point out to you some of progressive web apps' most “luring” benefits:
as compared to native apps, the setup process, on users' end, is significantly simplified: PWAs get instantly installed on their home screens, with no need to visit an app store for that
they can get accessed offline, as well, via the home screen icon (a huge step forward from responsive web design)
installation is conveniently lightweight: a few hundred KB
essential files get cached locally (needless to say that this makes them faster than the standard web apps)
they feature modern web capabilities: push notifications, cameras, GPS
updates are run automatically, with no user interaction
not only that they work offline, too, but once the network connection is restored, they synchronize the data
And now, before we virtually convert your website to a progressive web app, let's go, briefly, through some of the most common misconceptions about PWAs:
a. A progressive web app is literally an... “application”.
Not necessarily:
A progressive web app can be a blog, an online shop, a collection of... dog memes, you name it.
Do not take the term “application” too literally when referring to PWAs. It's more of a concept, a code optimization technique which, once leveraged, "turbocharges” your app-like website or blog to deliver content faster.
b. Progressive Web Apps Are Developed Specifically for iOS or Android.
On the contrary! Probably one of PWAs' “hardest to resist to” advantage is that:
They're platform-independent.
So, you don't need to:
develop separate codebases
comply with platform-specific submission guidelines
c. Your Site Has to Be a JS-Based Single Page One So You Can Turn it Into a PWA.
Nothing of that sort!
If you're currently running... something on the web (be it a set of static HTML files), then you can easily make a PWA out of it!
And now, let's go straight to the 3-step set up process of a PWA out of your regular website:
Step 1: Go HTTPS to Convert Your Website to a Progressive Web App
There's no way around it: the HTTPs protocol is the ONLY way to go when it comes to progressive web apps!
All data exchanges need to be served on a secure domain: over an HTTPs connection!
And how do you switch from HTTP to HTTPs? You get yourself an SSL certificate from a trusted authority.
Now, there are 2 ways to get hold of it:
if your site runs on your own server (or at least you have root access to your server), consider setting up the LetsEncrypt certificate.
if your website runs on a shared hosting, then both the process and the cost of your SSL certificate (for yes, there will be a monthly or an annual fee) depends greatly on your provider.
Step 2: Create a Web App Manifest
“But what is a web app manifest?”, you might ask yourself.
A JSON text file that contains all the meta data of your PWA: description, scope, start_url, name, images, display, short_name...
It's this information that will let browsers know how precisely they should display your app once saved as a home-screen icon.
Now, before I go ahead and share a working example with you — one including the must-have entries of any web app manifest — I should also highlight that:
A link to this JSON text file should be placed in the <head> of all your PWA's pages:
<link rel="manifest" href="/manifest.json">
That, of course, after you've:
entered all the information about your PWA
copied the manifest.json
created a new “manifest.json” file in the root directory of your site
and pasted it there
It should be served with:
Content-Type: application/json HTTP header or
a Content-Type: application/manifest+json
And here's a “sample” piece of code:
{
"name": "My PWA Sample App",
"short_name" : "PWA",
"start_url": "index.html?utm_source=homescreen",
"scope" : "./",
"icons": [
{
"src": "./android-chrome-192x192.png",
"sizes": "192x192",
"type": "image/png"
},
{
"src": "./android-chrome-512x512.png",
"sizes": "512x512",
"type": "image/png"
}
],
"theme_color": "#ffee00",
"background_color": "#ffee00",
"display": "standalone"
}
Once the “Manifest” section of the Chrome's Development Tools Application tab has validated your JSON file, it will generate an “Add to home screen” link to be accessed on all desktop devices.
Tip: as you convert your website to a progressive web app you don't necessarily need to configure the manifest.json file yourself — with all its different images sizes, meta tags etc. Instead, if you want to make it quick, you can just make a 500x500 sized image of your PWA and then rely on Real Favicon Generator to create all the needed icon sizes and a manifest file for you!
And this is just one of the generators you could use!
Step 3: Set Up Your Service Worker
This is where the “true power” of your PWA lies:
A service worker is a JavaScript file, placed in your app's root, that plays the role of a “middleman” between the browser and the host. The one which, once installed in the supported browsers, intercepts and responds to the network request in different ways.
Note: in most cases, it's for caching all the static files, so that our PWAs can function offline, too, that we use service workers.
Now that we've seen what a service worker is, here's how you create one as you convert your website to a progressive web app:
a. You get it registered first things first.
For this, just run this code in the JS file on your site:
if ('serviceWorker' in navigator) { // register service worker navigator.serviceWorker.register('/service-worker.js'); }
Practically, it will check whether the browser does support Service Workers and, if it does, it registers your Service Worker file.
Note: NEVER call this file, inside your website, like this:
<script src="./service-worker.js"></script>
b. If you do not need your PWA to work offline, too, just set up an empty /service-worker.js file.
Users will just be notified to install it on their devices!
c. Once you've registered your Service Worker, generate your Service Worker file, too.
For this, just run this command in your terminal:
$ npm install --global sw-precache
Next, go ahead and run it on your website directory:
$ sw-precache
Et voila! You will have generated a service-worker.js including the service worker contents.
Test It Out!
At this stage of the "convert your website to a progressive web app" process, you should:
check whether your service worker got properly registered and installed on Chrome
run a performance audit on your PWA, using Chrome's Lighthouse Extension
For the first operation, go through these 3 basic steps here:
press F12 to open your Chrome Dev Tools
click on the “Application” tab
next, on the sidebar, select “Service Workers”
Then, check whether your service worker has been properly activated and is running normally:
Just tick the “Offline” checkbox and try reloading. Does your PWA-site still display its content, even when there's no internet connection?
Now let's run an audit using Chrome's dedicated testing tool, Lighthouse:
press F12 again to visualize the Chrome Dev Tools
select the “Audits” tab
then select “Perform an audit”
check all the suggested checkboxes
and finally, run the audit
And here's how the generated report would look like:
The END! This is how you convert your website to a progressive web app in 3 steps:
enabling HTTPS
configuring your web app manifest
creating your service worker
See? Any website can be turned into a PWA and you don't need to be a senior developer to do it.
Check out our development services for Magento websites in Vancouver.
Silviu Serdaru / Jul 24'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
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:
improve the user experience
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:
navigate to “Form” (you'll find it under “Entity”)
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:
define “#autocomplete_route_name”, so that the autocomplete JavaScript library uses the route name of callback URL
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?
RADU SIMILEANU / Jul 18'2018
All sorts of highly likely confusions, data taken out of its context, “obsessing over” numbers, approaching analytics with no clear goals in mind, metrics subjected to your own biases... We're all prone to making mistakes when analyzing data. Still, as a UX team striving to pull off an accurate picture of the user behavior, you need to take note of the most common mistakes in interpreting analytics data (UX analytics).
… of the biggest "gaffes" in reading data.
Those responsible for all the wrong assumptions about your users that you'll end up making:
that low numbers are always a bad sign
that if results show a correlation, there is definitely a causal relationship, as well
... and so on.
Now, allow me to “expose” to you the 7 most common mistakes that one can make when interpreting statistics:
1. Visits and Views: Confusing Them and Obsessing Over Them
Using these two notions interchangeably is a pitfall that not only rookie data analysts fall into:
With different UX analytics tools using different terminology for the very same concept and (even) confusing terminology used within the same tool, no wonder that you end up taking views for visits and vice versa.
And still: make sure you fully understand the terminology, otherwise you risk to:
report on the wrong data
put together some dangerously inaccurate reports
This is, no wonder, one of the most common data interpretation errors.
Now, let's define views and visits and present them as two different concepts once and for all:
a view (or “pageview”) refers to a view of a page on your website tracked by the analytics tracking code
a visit (or “session”) refers to a user's whole of interactions taken on your site, within a specific time frame
And now, speaking of views and visits, another one of the too common mistakes in interpreting analytics data is:
Obsessing over views and visits!
As a UX designer though, you may want to leave the challenge of increasing visits and page views to the marketing people in your team to handle. And, instead, to focus your efforts on that data that 's relevant to the user experience.
2. Settling for a Birdseye View Instead of Digging Deeper into Data
Scratching the surface of the available data:
a quick assessment of the data at hand
rapidly going over the “headline” figures
… will only tell you something about your website's current performance in terms of traffic, but won't give you any clue on how to improve UX. How to increase the conversion rate.
In other words: visits are no more than metrics signaling you how many visitors landed on your site during a given period of time, but this metrics won't reveal anything about how they actually engaged with those visited pages.
See? Analyzing data as broadly as considering sessions to be the key indicator of performance and UX is another one of those common pitfalls in interpreting statistics:
By far the best method of reading analytics data, as a UX-er, is to approach it with some well-defined goals in mind. This way, you'd focus your efforts on specific metrics, relevant for understanding user behavior, instead of getting yourself “drown” in a sea of data.
3. Common Mistakes in Interpreting Analytics Data: Not Looking Beyond Numbers
… and not putting them in their contexts.
For that's the proper way to interpret them. Otherwise, you're just... analyzing quantitative data stating the obvious:
The “what” and not the “why”.
This is undoubtedly one of the most common mistakes in interpreting analytics data: falling under the “spell” of numbers!
Instead, you'll need to keep in mind that:
it's real users that those collected numbers represent
once taken out of their contexts, numbers lack their true value
they become truly valuable only when interpreted in connection with the user experience:
What do they tell you about the overall user experience on your website?
This is why you should always apply qualitative methods when analyzing quantitative data. User research methods that enable you to go from “what has happened” to:
“Why is it that visitors behaved that way on my website?”
4. Always Taking Low Numbers for a Bad Sign
Another one of those more than common mistakes in data analysis is:
Always thinking that low or a drop in numbers is a bad thing.
Context is everything here!
Just think of reading data analytics as a three-phase process:
what you want to see in those numbers
what the available data seems like
what it really means
Let me give you one good example:
Less time spent on a web page could be good or bad. If we're talking about your redesigned homepage, it could very well mean that users do find its new design more intuitively efficient. That they can get to the pages on your site that they're interested in far more easily.
In other words: do put those drops in numbers against their contexts before you alert everyone in your team that the site's going down the hill!
5. Overlooking to Segment Users
For you surely agree that every given visitor uses your website differently:
on desktop
on mobile
at different times of the day
And that multiple users interact differently with your site.
Need I say more?
Don't overlook these valuable considerations on your users' behavior when interpreting your quantitative data.
Before you rush to make all the wrong assumptions reading your analytics data, make sure you break those figures down into multiple relevant segments:
mobile users
desktop users
users from different countries
users falling into different age groups and so on
It's user base segmentation that turn quantitative data into... relevant data. And which, most importantly:
Provide you with priceless clues regarding the areas on your site that you should be focusing your UX efforts on.
Let's just say that your site has a conversion rate of 7%. Before you get overexcited about it, make sure you break that figure down. You might just discover that 9% comes from your desktop users and only 1% from your mobile users.
And there you have it, there's your clue! Now you know just where to focus your UX efforts.
6. Not Setting Clear Goals Before Approaching Your Analytics
And, as already stated, this could get you “tangled up” in a huge amount of data.
But, if you take some time to define your goals first things first, you'll know just what you'll want to achieve from your data analysis session.
And to:
direct your UX efforts towards those specific objectives
focus exclusively on those metrics relevant for interpreting user behavior
If you don't know where you're heading, how can you know just how to get there; how to improve UX on your website?
7. Settling for a One-Size-Fits-All Reporting Setup
Another one of those common mistakes in interpreting analytics data is sticking to a standard reporting setup.
That instead of trying to custom-tune it so that it should deliver you precisely the data you need. The one relevant for your own website.
Since each site works differently, you can't expect a one-size-fits-all approach to data analytics to perfectly suit them all, in the slightest details, now can you?
So, You've Analyzed Your Data: Now What?
For reading your analytics data is just the first step. Now it's time you:
get some actionable takeaways from your analyzed data
get to action
Are there usability tests that you need to run to figure out why the conversion rate is higher on your desktop site than on its mobile version?
Or maybe you need to implement some user research methods to identify those contexts where users visit your site from their mobile devices?
Time to put together your “data-fueled battle plan”!
Adriana Cacoveanu / Jul 12'2018
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:
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"
or use Composer to create your new Drupal project: composer create-project drupal-composer/drupal-project:8.x-dev my_drupal_project --stability dev --no-interaction
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:
open up your terminal window
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:
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"
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)
Once you reach the step where you need to configure your database, enter these options here:
Database host: database
Database name, username, password: drupal8
Next, unfold the "Advanced Options" drop-down menu and:
replace "localhost", currently showing up in the "Host" field, with "database"
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.
The END! And this is how you do it... Told you it was just a matter of a few easy steps!
RADU SIMILEANU / Jul 10'2018
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?
1. Login Security
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.
2. Drupal Core Update Module
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?
3. Captcha
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.
4. Password Policy
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.
6. Security Kit
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.
7. Session Limit
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.
8. Automated Logout
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.
9. Two Factor Authentication
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.
10. Coder
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.
11. SpamSpan
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.
13. Paranoia
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.
14. Content Access
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!
15. Google Apps Authentication
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 the 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!
If you want to access expert Drupal support for your development projects, contact Optasy.
Adriana Cacoveanu / Jul 04'2018