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
Save the date(s): 10-12 August! And join us for a 3-day conference on building with Drupal, driving this open-source technology forward and strengthening & growing the community behind it: Drupal North Regional Summit 2018.
You'll find us in our booth at the Toronto Reference Library's exhibit hall, to be more specific, since this year OPTASY's a proud gold sponsor of the fourth edition of this event:
The biggest annual summit in Canada focused on promoting Drupal.
Why Would You Attend Drupal North Regional Summit 2018?
That's right: why would you pack your bags and get en route for Toronto's Reference Library when summer is at its peak and everyone's looking for a place in the sun?
For a bunch of strong reasons, actually:
first of all, if you're already living in Canada, why would you want to miss the biggest annual event in North America promoting Drupal?
no less than 300+ individuals and organizations will be attending it
if you're a Drupal developer, this is a once-in-a-year opportunity to grow and to... outgrow yourself; the event's schedule is “overcrowded” with sessions covering a variety of Drupal-related topics, with “can't miss” keynote sessions and networking opportunities
… grow your profile by sharing your knowledge and expertise all while enriching it as you learn from other Drupalists attending the event
as a Drupal-powered organization, Drupal North Regional Summit 2018 is a great chance to recruit new talent (and this is the event's key “mandate”: to showcase Canadian Drupal talent), to make connections with other Drupal-fueled businesses...
Whether you're:
in the government, nonprofit, education, business field
a freelancing Drupal enthusiast looking to keep his/her knowledge up to date
… don't miss the largest summit in Canada promoting Drupal!
It'll be a win-win-win type of situation:
you (the Drupal developer) get to keep your knowledge up to date
you (the organization) get to dig through a pool of Drupal talent and also to network with other key decision-makers from some of the most notorious companies in Canada running their businesses on Drupal
and it's a winning situation for Drupal itself: all the individuals and companies attending the summit will help to extend its reach to more people and more businesses
OPTASY Proudly Supports Drupal and the Drupal North Regional Summit 2018
Why? What's in it for us? Why are we so proud to be one of the gold sponsors of this Drupal summit in Canada?
Because we like to practice what we preach:
To give back to the (Drupal) community, what the community gave to us for free. And along these +15 years years since we've been developing in Drupal there's been plenty of work done by all those developers contributing to Drupal and moving this open-source technology forward that we leveraged in our own projects. It's only but common sense to give something back now and to contribute ourselves, too.
And sponsoring Drupal events is one way that we can do that.
But there are other reasons, too, why we decided to support the Drupal North Regional Summit 2018 as a gold sponsor. All of them deriving from the above-presented reasoning:
the 3-day conference makes the perfect “lab” where brilliant solutions to well-known issues in Drupal get identified and shared with the community, new Drupal modules get put into the spotlight, new ways of innovating this technology get presented
in other words: investing in this Drupal summit we invest in us, as a team and as a company, and implicitly in our own clients, as well
... all the knowledge and “steamy-fresh information” that we get from this conference will then be put to use when working on our clients' future projects
it's also a great place to network with existing and potentially new Drupal-using companies
and an opportunity for us to “expose” the key advantages that set OPTASY apart as a Drupal agency: +15 years hands-on experience, proven Drupal expertise, pure passion for what we do, a strong work ethic and stellar communication skills confirmed by our clients
So, are you curious about Drupal's main strengths as a technology of the future? Interested to discover what precisely helps it stand out?
Are you looking for a Drupal partner with both the proven experience and the proper “weakness” for innovation to turn your ideas into digital reality? Stop by our booth then, in August, and let's talk Drupal, growth opportunities and everything in between!
Adriana Cacoveanu / Jul 02'2018
You have patched your Drupal website, haven't you? If so, then that critical 3-month-old security flaw, Drupalgeddon2, can't get exploited on your site. Even so, with the menace of a cryptocurrency mining attack still lurking around the unpatched websites, you legitimately ask yourself: what are some quick and easy ways to secure Drupal?
“Which are the most basic steps to take and the simplest best practices to adopt to harden my Drupal site's security myself?”
Now, using keywords such as “security measures”, “quick”, “easy” and “handy”, I've come up with a list of 7 basic steps that any Drupal site owner can (and should) take for locking down his/her website.
Here they are, in no particular order:
1. Keep Your Drupal Core and Modules Updated
Not only is this one of the simplest ways to secure Drupal, but one of the most effective ones, as well.
Even so more now, with the Drupalgeddon2 Drupal security threat still fresh in our memory, ignoring the regularly released security updates for both Drupal core and its modules is just plain recklessness or... self-sabotage.
Keep your Drupal version updated: apply security patches as soon as they get released, avoiding to leave your site exposed and exploitable. As simple as that!
And where do you add that this is one of those Drupal security best practices that's the easiest to integrate into your routine. Since to run the latest updates you only need to:
sign in to your Admin panel
go to “Manage”
scroll down to “Reports” → “Available Reports”
click on “Check manually”
if there are any critical security updates that you're advised to run, just click “Update”
This is all it takes for you to:
seal any security loopholes in your Drupal core
prevent any identified vulnerability from growing into a conveniently easy to access backdoor for hackers to get in
2. Install Drupal Security Modules
Strengthening the shield around your Drupal site with some powerful Drupal security modules is another both handy and effective measure that you, yourself, can easily implement.
Luckily, you're definitely not out of options when it comes to good security modules in Drupal.
And I'm only going to run a short module inventory here, since I'm already preparing a blog post focused precisely on this topic. Therefore, I promise to delve deep into details about each one of the here-listed modules in my next post:
Secure Login
The Security Review (Drupal 7 only)
Paranoia
Captcha
Two-factor Authentication
Content Access
Security Kit
Password Policy
Automated Logout
Password Strength
Downloading, installing security modules on your Drupal site is both:
quick and simple to do
highly effective
And they serve a wide range of purposes, from:
enforcing strong password policies
to monitoring DNS changes
to locking down your site from security threats
to blocking malicious networks
to turning on a firewall on your site
As for their selection, it depends greatly on your list of priorities when it comes to improving your site's security. Take some time to weigh and to compare their features.
3. Remove Unused Modules: One of the Easiest Ways to Secure Drupal
Being the “easiest” security measure to implement doesn't make it also “the most popular” among Drupal site owners.
Owners who more often than not:
underrate the importance of running a regular module usage audit on their sites
ignore the Drupal security threat that an outdated piece of code (or an unused module) could turn itself into, once exploited by an attacker
So, don't be one of those site owners! Are there modules on your site that you no longer use?
That have grown outdated and that are just... lingering there, using your site's resources and risking to grow into an exploitable backdoor for hackers?
Identify them and remove them! It won't take more than just a few priceless minutes of your time.
4. Enforce a Strong Password Policy
Since it's not just the admin (you do have a smart username and password for logging into your admin dashboard, don't you?) that will log into your Drupal site, but users, too, implementing some strong user-side security measures is a must.
In this respect, creating a strong password policy — one that would enforce the creation of complex, “hard-nut-to-crack” type of login credentials — is one the best and the easiest ways to secure Drupal on the user's side.
Come up with a policy that defines specific requirements for setting up passwords of high enough entropy (letters, uppercase/lowercase, symbols, different characters combos).
And don't hesitate to rely on dedicated Drupal modules for enforcing those requirements defined in your policy:
Password Strength
Secure Login
5. Block Access to All Your Sensitive Files
I bet you don't want important folders, core files — upgrade.php., install.php, authorize.php, cron.php — to be easily accessible to just... anyone, right?
So, how about limiting or blocking access to them?
And you can easily do that by configuring your .htaccess file — it's the one containing details of crucial importance regarding your website access and credentials to specific parts and core files on your site:
Just specify the IP addresses allowed to access those core folders, files and subdomains.
Here's one “enlightening” example:
<FilesMatch "(authorize|cron|install|upgrade)\.php">
Order deny, allow
deny from all
Allow from 127.0.0.1
</FilesMatch>
Note!
Now speaking of limiting access, don't limit your restrictions to your core folders and files. Remember to restrict/block access to your web server, to your server login details, as well.
How? By adding a basic layer of authentication limiting server access and file access usage.
Also, do remember to cautiously manage access to certain port numbers that your site/app might be using.
6. Back Up, Back Up, then... Back Up Some More
You can't anticipate brute-force attacks, but you sure can “land back on your feet” if the worst scenario ever happens.
And you can only do that if you have a clean and recent backup at hand to just rollback and restore your website.
In other words: back up regularly!
And remember to always back up your files and MySQL database before any update that you run on your Drupal code and modules. It is one of those common sense Drupal security best practices that should be included in any basic security checklist!
Where do you add that you even have a dedicated Drupal module — Backup and Migrate — to assist you with this process.
Some of the back up “burdens” that this module will take off your shoulders are:
backing up/restoring code and multiple MySQL databases
integrating Drush
backing up files directory
setting up several backup schedules
AES encryption for backups
7. Review All User Roles and Grant the Minimum Permissions Necessary
How many user roles are there assigned on your Drupal site?
If you don't quite know the answer, then it's obvious:
You must give your entire user role system an audit!
And to stick to this habit, one of the simplest ways to secure Drupal, after all.
Review all the user roles and, most of all, review each one's set of permissions and make sure you trim them down to the minimum necessary for each role.
This way, you'll also limit access to critical files for those users that shouldn't have the permission to download or visualize them.
And speaking of permission, do keep in mind to review all your file permissions, as well!
See which user roles are granted permission to access key directories or to read, write or modify certain files on your website and block/restrict access where necessary.
The END! Of course, this isn't even close to a complete list of ways to secure Drupal. If it had been an exhaustive one, it would have continued with more Drupal security best practices, such as:
getting the SSL Certificate
securing HTTP headers
using secure connections only
Etc. etc. I've only focused on some of the easiest and quickest measures that anyone, with little, close to no technical know-how at all, can implement. And I feel like stressing out the term “practice” here:
Securing your Drupal site is a constant process; a series of persistent efforts and not a one time thing. Remain vigillant and cautious and don't rely on just a one-time, multifaceted security hardening “marathon”.
Adriana Cacoveanu / Jun 28'2018
Oops! The worst has happened: your Drupal site has been hacked! Maybe it was precisely one of those critical vulnerabilities, that the Drupal security team has been drawing attention to these last months, that the attacker(s) exploited?
Now what? What to do?
Should you be:
rushing to restore your website to a healthy, good-working state (that, of course, if you do have a clean and recent backup available)?
starting to rebuild it?
investigating how your Drupal site got contaminated in the first place: where's the “open door” that the attackers used to get in?
focusing on closing any backdoors that could make new attacks possible?
Now “tormenting” yourself with too many questions simultaneously will only distract you from what should be your main objective: cleaning up your website (and preventing further hacks I should add).
So, let's go about it methodically, step by step:
Step 1: Write Down Issues, Steps to Take, Preventive Measures to Apply
Keep your cool and go for a methodical approach to crisis management:
Just open up a document and start... documenting:
the issues and any suspicious activity that you identify on your site
all the steps that your strategy for removing malware and restoring your site should include
the preventive security measures you commit to taking for preventing such a scenario from happening again the future
Step 2: Make a Forensic Copy of Your Drupal Site
Before you start running your “investigations” on the attack, on how your Drupal site has been hacked, and way before you get to rebuild anything:
Make a forensic copy of all your files, you database and your operating system environment!
Note: go with an external storage medium for these copies and store them offsite.
As you're scanning through your files, detecting viruses and malware and having them cleaned up, feel free to make new and new “working backups”. And to store them in a different directory (from your regular backup files, I mean).
“But why bother? When will these backups turn out particularly useful?”
when you call out to a third party to assist you with the troubleshooting process; these “working” backups will then provide a clear picture of the site before you started “malware detecting” on your own
when you try to fix the issues you detect, but instead you make them worse; then, you can easily roll back those changes
Step 3: Scan Your Servers and PC for Malware, Malicious Code Injections, Viruses
Before you rush to change all the passwords on your site, pause for a moment to think through your next “move”:
What if the attack has been “programmed” so that the attacker should get notified once you change your password(s)? And what if it's precisely your PC or one of your servers that's got infected? Then storing a clean backup of your site precisely there would only make it even more vulnerable.
So, how do you prevent that? You give both your PC and your servers a deep scan before making any change.
And, thank God, you sure aren't nickel and dimed in anti-malware tools and anti-virus software: AVG, BitDefender, Malwarebytes, ESET, AV-Comparatives etc.
Step 4: Detect & Remove the Backdoors
One of the crucial steps to take, once you realize that your Drupal site has been hacked, is to “close” all the backdoors.
These could easily turn into hackers' access ticket into your site even after you've removed malware and restored it to its healthy state. But, for closing them you first need to... find them right?
So, where to look?
Here are a few key places on your site that you should focus your “searches” on:
access logs: while scanning them, be vigilant and look for PHP scrips and POST requests added to directories that have writable access
eCommerce set up: check all the payment methods, shipping addresses, credit card addresses, linked accounts, looking for any suspicious, newly added data
passwords: FTP passwords, admin passwords, control panel passwords
email rules and filters: check that the answers to the security questions are “legitimate”, that messages are being forwarded to correct email addresses etc.
Step 5: Consider Taking Your Site Offline
And your decision depends greatly on the nature of your site:
If it's a hacked eCommerce Drupal site that we're talking about here, then don't wait even one more minute: take your site down (along with the internal network and servers) and install a placeholder!
This way, you'll prevent:
malware from being further distributed
spam from being sent to your online store's customers
Note: do keep in mind that taking your site offline will instantly let the attackers know that you've detected the malware that they've “infiltrated” and that you are about to “take action”.
If you decide not to take your Drupal site offline at the web server level, ensure that you've got your clean forensic copy at hand before deleting all the sessions.
Note: have you detected suspicious changes of the passwords? If so, use this query here for updating them (Drupal 7):
update users set pass = concat('ZZZ', sha(concat(pass, md5(rand()))))
As for the users, they can easily use the reset password tool for updating their passwords.
Word of caution: mind you don't take "Drupal on maintenance mode” for “offline Drupal". They're 2 completely different things! Once your Drupal site has been hacked, the malware could be of such nature that it allows the attacker to infiltrate as long as the site's online.
Step 6: Notify Your Hosting Provider That Your Drupal Site Has Been Hacked
They should be informed about the breach and about your site being taken offline (if it's the case) immediately.
The sooner the better, this way they can:
start scanning their own systems for incursions
get ready to assist you with your site recovery and securing process
Step 7: Handle Client Data with Extra Precaution
And these are the specific scenarios where you'll need to take extra precautions when handling client information:
your Drupal site stores client information on the web host
… it leverages the data POST method for sending form data via e-mail
… it doesn't integrate with a 3rd party payment gateway, but manages the payment processes itself
If one of these 3 scenarios suits your case, then here are some of these extra precautions that you need to make to ensure the private user data doesn't get exposed:
update your SSL certificate
re-check all logfiles (have any of the hosted client information been copied, updated or downloaded?)
implement AVS (address verification system)
add CVV (card verification value)
encrypt connections to back-end services used for sending confidential user data
Step 8: Investigate the Attack: Identify the Source(s) of Infection
No matter how much pressure you might find yourself under to get your site back online ASAP, don't let take control over your site's restoring process!
Not until you've detected the main source of contamination on your site. The key vulnerability that attackers exploited, the key reason why your Drupal site has been hacked in the first place.
That being said, make sure that:
you first audit, on a staging server, that “clean” backup of your site that you're planning to get online; this way, you track down and remove infected files, unauthorized settings, malicious code
you compare pre- and post-hack files, looking for any suspicious changes
Now if you have a clean (and recent) backup at hand for running this comparison, the problem's almost solved. Just use the right tools to compare your files and track down discrepancies.
But if you don't have a backup at hand, then there's no other way but to:
Manually inspect your files and databases to identify any suspicious changes that have been made.
look for any suspicious iframe or JavaScript at the end of the files (if detected, save the code in an external file)
look for any sources of “Drupal site hacked redirect”; for links to external URLs
Now, as for the places that you should be running your investigations on, let me give you just a few clues:
.php files, .html files
sessions table
newly modified/created files
new/updated user accounts
in writable directories and database
Step 9: Do a Full Restore of Your Site
So, you've noticed that your Drupal site has been hacked, you've assessed all the damage caused, removed malware and even detected the vulnerability that hackers exploited to get in, not it's only but logical to:
Try to repair your website, right?
Word of caution: never ever run your changes on your production site; instead, fix all detected issues on a staging site. Also, once you've cleaned it all up, remember to run the latest Drupal security updates, as well!
Now, getting back to repairing your site, you have 2 options at hand:
you either restore a clean backup, if you know the date and time that your Drupal site has been hacked and you're also 100% sure that none of the system components, other than Drupal, got contaminated
or you rebuild your Drupal site
The latter method is, undoubtedly more cumbersome, yet a lot more cautious. Go for it if:
you do not know the precise date and time when your site's got contaminated
you do not have a clean (and recent) backup available to restore
you've evaluated the damages as being already too widespread
Step 10: Give Your Restored Site a Full Check Before Going Live
Do remember to give your newly recovered site a final audit before getting it back up:
remove all malicious code detected
suspicious files
unauthorized settings
And, most of all:
Close all the backdoors!
Final Word
A pretty long, complex and discouragingly tedious recovery process, don't you think?
So, why wouldn't you avoid all these steps that you need to go through once your Drupal site has been hacked?
Why not avoid the risk of finding yourself forced to take your website offsite for... God knows how long, risking to impact your site's reputation and to drive away users/online customers?
Don't you find it wiser to:
be prepared instead?
opt for ongoing Drupal maintenance and support services?
make a habit of regularly backing up your website?
keep your system and software up to date (and to install all the recommended patches)?
stop underrating the security advisories that the Drupal team makes?
RADU SIMILEANU / Jun 25'2018
There's no way around it, not anymore: with Google's index now mobile-first, adopting a mobile-first approach when building a new Drupal site (or redesigning a legacy one) is… a must! It no longer depends on a specific project's needs or on the used technology. The need to develop a mobile-first content strategy has gone from particular to universal.
And facing the challenge of:
(re)creating
optimizing
structuring
… content on your Drupal website means conforming to those specific patterns that mobile users have developed for reading content on their smartphones.
In short: developing a fully responsive Drupal site comes down to centering your mobile content strategy around the idea that:
It's for the smallest screen sizes that you should plan your content for, first things first … then scale it up from there.
Now, let's see precisely what it takes to develop a mobile-first content strategy. What focus points and must-have components to include:
1. Take the Smallest Screen Size as the Starting Point
In other words: think mobile-first!
And by “mobile” I do mean “smartphones” — the smaller the screen size, the better.
This way, you'll be adjusting your content so that it makes the most of the smallest interface. Starting “small” is the best way to stick to the “keep it simple” approach:
Thinking through every content-related decision in the light of the viewport size challenge will constrain you to keep the truly essential content elements only.
Hence, this “spartan” way of eliminating the unnecessary will reflect on your site's desktop design, as well:
It will turn out cleaner and lighter.
2. Use Visual Content Wisely: Weigh Your Choices of Images
The golden rule when it comes to the imagery that you'll use on your responsive website is:
If an image doesn't enhance and complement your content, then you're better off without it!
And I know what you must be thinking:
“But people remember what they see far more easily than what they read.”
True, you need to keep in mind that visuals do come at a cost, though:
Those stunning, visually-arresting images on your website risk to divert your users' attention from the message itself.
And still, probably the most heavy-weighing reason why you should use images wisely when you develop a mobile-first content strategy is: weigh.
Visuals risk to take up valuable screen space and thus:
outshine your calls to action themselves
impact your site's overall performance (leading to frustration)
Now that doesn't mean that you should strip your content off ALL the visuals! Absolutely not!
Just to be cautious and weigh your every choice, think through your every decision involving the usage of an image.
Once you've selected the truly essential ones, keep in mind:
not to no resize them (or optimize them in any other way) before uploading them to your CMS: let Drupal do the heavy-lifting here
to leverage the Responsive Image module's (Drupal 8) capabilities for resizing them to fit the given screen sizes
3. Content Before Design
This is the right sequence to follow when you're designing (or re-designing) your Drupal site with mobile users in mind:
First, you create and strategically organize your content and upload it to your Drupal 8 CMS. It's only then that you focus on styling and developing a responsive and visually-striking web design.
If it's legacy content that you're dealing with, trying to convert it to mobile, the very first step to take when you develop a mobile-first content strategy is:
Removing all the design elements from your written content.
4. Create a Hierarchy of Your Calls to Action
Making the most of a small interface means also setting your priorities in terms of calls to action:
Pair each one with a corresponding objective, evaluate them all wisely, then select THE call to action that's most critical for you and place it — and it alone — above the fold.
5. Organize and Optimize Your Content for Mobile Devices
I'll briefly list all the key requirements that mobile-friendly content should meet — aspects to pay attention to when writing content for mobile devices — for I'm sure they're nothing new to you:
the phrases should be kept short and concise, thus eliminating the burden of “never-ending-scrolling”
the content should be sharp, targeted and skimmable, so users can easily “digest” it and modular, so that users can swiftly browse through it
“modular” meaning made either of multiple clear paragraphs — each one standing for one thought — or chunks of 3 paragraphs at most
6. Optimize Media, too, When You Develop a Mobile-First Content Strategy
And there are a couple of essential steps that you mustn't overlook when it comes to mobile-optimizing your media:
always go for thumbnails instead of video players that your users would have to load and thus strain on your site's valuable resources
don't ever use autoplay on your audio and video content
optimize your sound, image and video files both for large and small devices
7. Trim Down Your Navigation Menu
In other words: when you develop a mobile-first content strategy, consider simplifying your navigation to its truly essential links.
No user would gladly scan through a “beefy” navigation menu taking his device's entire screen:
flatten your navigation: stay away from the technique of piling up submenus, layers and navigation points
feel free to place the links that you'll remove on other places on your website (or even to turn them into calls to action)
8. Convert Your Legacy Content to Mobile-Friendly Content
If it's a legacy Drupal website that you need to restructure and to adapt to your mobile users' specific patterns for browsing through and consuming content on their smartphones, then it's time you:
dug into your static HTML
… and cleaned it up
And by “cleaning it up” I do mean:
removing inline media
removing the fixed-width tables
eliminating floats with content
breaking it down into skimmable chunks of content
… that can be easily structured into content fields.
The END! These are the 8 main aspects to focus on when you develop a mobile-first content strategy.
Now time to test the “saying” that:
“Creativity strives under constraints.”
… and to make the most of those small interfaces.
Adriana Cacoveanu / Jun 11'2018
Content is a way too valuable asset not to handle it with utmost care — from its creation to its revision, all the way to its... distribution. And with utmost efficiency, as well! But how do you choose the business software to “orchestrate” your entire content workflow? Since, on one hand, you have the top enterprise content management systems in 2018 and, on the other hand, you have... Drupal?
And the dilemma that you're facing right now could be summed up like this:
Choosing between a complex ECM system with a load of powerful tools that comes at a cost and a feature-rich one — already famed for its robustness and customization options — with no price tag on...
Now to ease your decision-making process, let's compare these enterprise information management solutions, the top rated ones, to Drupal, by weighing their feature loads and costs.
1. But What Is an Enterprise Content Management System More Precisely?
First, let's try to define what we mean by “content” in relation to a content management software:
Content is all the written pieces of information entering and “moving about” your organization. It comes in the form of:
internal process documents
content for your company website (or blog)
sales-focused content
targeted, custom content available to paying cutomers only
... and the list goes on.
As you can see, I've intentionally left out graphical and audio-visual content. And this because it's only text-based digital content that a CMS would handle.
Now, coming back to our initial question:
An enterprise content management system is a software geared at managing all the processes in your content's lyfecycle: creation, revision, publication, distribution to multiple channels, promotion etc.
Packed with different sets of tools designed to automate all your content-based processes, an ECM system is a... “Swiss knife” type of business software.
The one you'd use to streamline your content workflow(s).
2. M-Files, One of the Top Enterprise Content Management Systems in 2018
Introducing the enterprise-leveled information management solution of the year: M-files!
The promise that it makes?
To break the “siloed information” pattern and enable users to access specific content from any buiness system, any device.
… to easily access it, but also to organize it, to manage it, to identify particular information/documents, to set up custom workflows and even to manage document reviews.
Top features
version control
automated workflows
pre-built search engine: you get to track documents by type, name, keywords; it provides within-text search features as well
notifications: users get alerted whenever they'll need to review or approve changes made to documents
approval processing
permission management and offline access
integration capabilities: it easily integrates with Microsoft Dynamics, NetSuite, SAP, Salesforce
document collaboration tools: co-authoring features and check-in/check-out tools
Price
Mi-files is one of those enterprise content management vendors that leverage the quote-based method for pricing their services.
Basically, there are no standard prices, as there are no standard packages that they offer, only tailored content management solutions.
Cons
The great majority of negative user feedbacks revolve around the M-Files mobile app's limited functionality.
2. OnBase
Another one of the top enterprise content management systems in 2018 is OnBase:
An all-in-one software coming “equipped” with:
business process management tools
integrated document management tools
records management tools
And before I “expose” to you its most heavy-weighing features, I feel that I should put the spotlight on its versatility feature first:
You get to easily configure your OnBase ECM system to fit any environment of choice.
Top Features
approval process control
indexing
version control
built-in search engine
document management
Cons
Do expect a steep learning curve! So, be prepared to invest a significant amount of time in growing comfortable with using it.
In learning to “juggle” with all its apps and functionalities.
Price
You'll need to contact the OnBase team for a custom pricing plan.
3. Box
Box is a cloud content management platform built to assist you with:
online sharing your files
storing your files
integrating content across your entire “infrastructure” of digital tools via open APIs
collaborating within your team
Top Features
granular access permission
easy integration with other platforms
advanced security capabilities: device trust, watermarking, data governance
easy integration with other platforms
collaboration tools: a document management system that enhances collaboration among end-users on various file types and devices; tools which also enable them to choose the right storage place, to set up metadata-driven content workflows etc.
Cons
Even top enterprise content management systems manage to collect their own “pile” of “bad reviews”. What users reproach OnBase here, for instance, is its user-based pricing model.
In other words, if you have +100 people in your company, expect to get charged separately for each email domain... and thus to overstretch your budget over time.
Price
Box pricing plans start from €4.50 per user/month (we're talking about a starter business plan here) and can go up to $500 per month or more if it's a “build with BOX platform” plan that you'll select.
4. Drupal
And now that we've put the top-rated ECM systems in 2018 into the spotlight, let's see what Drupal here has to offer. How it can counterbalance all these heavy loads of tools, features, and functionalities.
Drupal's Key Features
advanced integration capabilities: Drupal “spoils” its end-users with conveniently accessible API, backed by a rich collection of modules built precisely for 3rd party integrations
no maintenance effort required: since it runs in Acquia Enterprise cloud, Drupal gets automatically updated; maintenance is already included in the Enterprise support costs plan
feature richness: and we're talking here about features, plug-ins (thousands of them) and content management tools that you get right out of the box
modular architecture: which goes hand in hand with the unlimited freedom of customization that you'll get to leverage
high performance: Drupal's already famed for its robustness and capabilities to withstand high influxes of traffic
unmatched scalability
a full toolbox (contributed modules here included) put at editors' disposal: Drupal's also won its reputation as a CMS that's been constantly improved to enrich the experience; all the in-built content-handling tools speak best of its “empower the content creator/end-user” philosophy
Price
license costs: unlike the top enterprise content management systems previously outlined, Drupal's open source; there are no license costs, only support costs associated with the Acquia Enterprise Platform
vendor lock-in: all modules and plug-ins that you might select and mix and match to custom-tune your CMS are free
development costs: Drupal resources are available to anyone who wants to build and then to custom tune and scale up its CMS
In conclusion...
… Drupal comes feature-packed and, moreover, it “spoils” you with unlimited freedom of customization. And all this without putting a price tag on.
On the other hand, some of the top enterprise content management systems do tempt you with their feature richness, but at a cost. One that can go up precisely if you feel like customizing your ECM solution or scaling it up sometime in the future.
In short: you do get your share of customization freedom... but not for free.
So, it's not really an “apples vs oranges” type of dilemma that you're facing, but rather an:
Apples vs Apples with a price tag on
Adriana Cacoveanu / May 29'2018
Just imagine: a user asks Amazon Alexa to read out loud to him/her the headline of your latest blog post! Or maybe to look for a specific section on your Drupal site! Or, even better: quit imagining this and start implementing it instead! Right on your website. And here's how you integrate Alexa with your Drupal 8 website via the Alexa integration APIs.
A 7-step tutorial:
on how to get Alexa to “talk to” your site users/online customers
on turning your site's content into the needed “raw material” for setting up your custom Alexa skills
on how you can leverage Drupal 8's outstanding third-party integration capabilities to “fuel” your implementation plan with
So, here's how it's done:
But Why Precisely Amazon Alexa over Other Voice Assistants?
Because Amazon Alexa stands out with its top notch integration capabilities.
Its integration APIs make it possible for this particular voice service to be “plugged into” various devices and web services.
As simple as that! Alexa's more than just a voice assistant making voice (obviously!) interaction possible:
It's a voice service that empowers you to integrate it even with your Drupal 8 website quickly and smoothly, via its own built-in APIs!
Introducing Alexa: The Drupal Module for Amazon Alexa Integration
With Alexa “doing its own part” and the voice service bringing its Alexa integration APIs into the equation, it was only fair that the Drupal community should play their own part, as well.
The result of their sustained efforts? The Alexa Drupal module:
which provides an endpoint for your Drupal 8 website, where it would receive the vocal user requests “stored” in the Alexa Skills
"user requests” which get converted into text strings before getting sent over to the Alexa module on your Drupal site
Note: do keep in mind that the Alexa module is still under development, but with a more than promising, long-term future ahead of it.
For now, it offers basic integration with Amazon's Alexa. And this is precisely why you'll need to build a custom module, as well, to integrate Alexa with your Drupal 8 website.
But more details on this, in the tutorial here below:
Integrate Alexa With Your Drupal 8 Website: A 7-Step Guide
Step 1: Make Sure Your Site Uses HTTPs
In other words: make sure your Drupal 8 website's “easily detectable” by Amazon's servers!
The very first step to take will be to switch your site over to an HTTPs domain (a step you can skip if your site's already on HTTPs)
Step 2: Install the Alexa Module
Go “grab” the Alexa Drupal module and get it installed and enabled on your website.
Step 3: Set Up Your Alexa Skill
With your dedicated Drupal module ON, it's time to focus on all the needed setting up to be done on the Amazon Developer site. And the very first step to take is to create your own new Alexa Skill in the Skills Kit there.
Step 4: Copy & Paste Your Application ID
And this is no more than a quick 2-step process:
first, you copy the Application ID provided in your “Skill information” section, on the Amazon developer site
then you submit it to your website's configuration at /admin/config/services/alexa
Step 5: Configure Your New Alexa Skill
A key 3-part step to take when you integrate Alexa with your Drupal 8 website, where you:
give a name to the Alexa skill (in the Alexa app) to be triggered
set up an Invocation Name for your users to utter for “activating” your newly created Alexa skill
set up the custom vocal commands or “intents” that Alexa will need to respond to
For this, you'll need to go to the Amazon Development website again and access the “Skill Information” section.
Note: maximize the odds that it's precisely those intents that your users will utter by adding more phrasings of the very same question/vocal command.
Another note: this flexibility proves that you get to harness the power of... variables when setting up your custom intents. “Variables” that you'll use with the custom module that you're going to build at the following step of the process:
Step 6: Create a Custom Module for Triggering The Right Responses to Your Intents
What should happen when your custom intents get invoked and sent through to your Drupal 8 website?
You'll need to create a custom Drupal 8 module that would handle responses.
For this, insert the following info in the demo_alexa.info.yml file:
name: Alexa Latest Articles Demo
type: module
description: Demonstrates an integration to Amazon Echo.
core: 8.x
package: Alexa
dependencies:
- alexa
Note: Do keep in mind to add the Alexa Drupal module as a dependency!
Now, time to build the custom module itself:
create a file at src/EventSubscriber/
name it RequestSubscriber.php
As for the code that will “populate” your module, first of all it's the namespace and use statements that you'll need to create:
namespace Drupal\demo_alexa\EventSubscriber;
use Drupal\alexa\AlexaEvent;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Drupal\paragraphs\Entity\Paragraph;
Then, you'll need to set up your main class, as well as a function to trigger the event:
/**
* An event subscriber for Alexa request events.
*/
class RequestSubscriber implements EventSubscriberInterface {
/**
* Gets the event.
*/
public static function getSubscribedEvents() {
$events['alexaevent.request'][] = ['onRequest', 0];
return $events;
}
Next, set up the function “responsible” for giving responses to each one of your custom intents.
With the code for your responses at hand, the very last file that you'll need to focus on is the demo_alexa.services.yml:
services:
alexa_demo.request_subscriber:
class: Drupal\demo_alexa\EventSubscriber\RequestSubscriber
tags:
- { name: event_subscriber }
Note: Remember to enable your demo Alexa module, then to navigate to the Amazon Developer site once again!
Step 7: Test Out Your New Alexa Skill
Another essential step to take when you integrate Alexa with your Drupal 8 website is testing your newly created Alexa skill.
And there's even a Test tab on https://developer.amazon.com for that!
Click on this specific tab, ensure that your new Alexa skill is enabled and thus ready to be tested and... see whether you'll get the right responses!
The END! This is the “how it's made” for getting Amazon Alexa to “talk to” your Drupal 8 website via:
the Alexa integration APIS
the Alexa module
a custom-built Drupal 8 module
RADU SIMILEANU / May 18'2018
Here's how the ideal decoupling Drupal scenario looks like:
Stripping Drupal to its essential role, that of a robust and flexible content repository, no Drupal expertise needed. Then using it to back your front-end with; one that you'd be free to build by leveraging any modern (JavaScript) technology of your choice.
… a Drupal back-end content store that would still preserve all its content editing and managing functionalities, needless to add.
Luckily, this is no longer “daydreaming”. Not since Reservoir, the headless Drupal distribution, has been available.
Here are some of its “promises” or well-known challenges, if you prefer, that this distribution's geared at solving:
to make Drupal far more accessible (cutting the intimidating Drupal setting up and configuration out of the equation) to developers of all stripes
to empower developers with all the best practices for building their Drupal-backed front-ends quick and easy
to provide an opinionated starting point enabling any developer to build a Drupal content repository backing his non-Drupal application with... no Drupal knowledge needed, actually
Your Current Situation: Why Would You (Even) Consider “Headless” Drupal?
Here you are now, dealing with the pressure of:
having to deliver content agnostically across any given channel and device: single-page JS apps, mobile apps, digital signage, AR and VR-driven content, IoT apps etc...
… all while storing it (content) in one single place
providing your editorial team with a... way to edit, manage and overall administrate content conveniently easy, via an editor-friendly UI
… independently of the development team, of course
finding a way to enable your developers to easily send content across this entire “ecosystem” of channels, devices and platforms
In other words: you're grappling with the challenge of making Drupal ideally accessible to your (non-Drupal) developers; so they can easily build their Drupal-based content store enabling them to deliver content to any given device.
… to serve it to any given app/site.
And this definitely calls for a decoupling Drupal approach.
Decoupling Drupal: The Most Discouraging Challenges You Must Be Facing
Let's assume that you're already considering headless Drupal as a solution for your current challenge, that of delivering content to multiple channels, devices, platforms.
Whether you're planning to decouple Drupal for:
building a Drupal-backed front-end, leveraging one of your modern JavaScript frameworks of choice
or using it as a content store for your non-Drupal app
Then, it's these specific challenges that you must be facing right now:
your non-Drupal developers are having trouble maneuvering Drupal content; they're not familiar with all the dials and knobs needed for making the most of Drupal's REST API
Drupal's serialization format is... alien to them
there's no starting point or well-defined best practices for non-Drupalists, that would ease their way to turning Drupal into a content repository
… one that they could back their front-ends with
True story!
And still, there is hope...
5 Reasons For Being “Skeptical” About Distributions
You must be legitimately cautious right now when it comes to using an API-first distribution for Drupal. And that's due to some bad experiences with... distributions.
Now let me try and guess some of your “fears” regarding Reservoir:
that it might turn out to be overly complex
that you risk getting “stuck with” architectural debt
that its maintainers might someday lose interest in it
that it's built primarily for other use cases, for scenarios different from your own decoupled Drupal implementation project
that you risk “inheriting” bugs in features that you haven't even used
And the list of reasons why you're not yet jumping on this decoupling Drupal trend could go on...
Introducing Reservoir: The Headless Drupal 8 Distribution! How Is It Different?
Before putting it into the spotlight and giving it a “full scan”, let me try to read your mind and identify the questions that you must be asking yourself right now:
“How precisely do I use Reservoir as a content store backing my front-end website or app?”
“Which are the bare essential Drupal modules and core functionality that this distribution comes packed with?”
“How can I leverage these ready-to-use components for decoupling Drupal?”
And now that we've put your valid queries into words, let me try and define Reservoir for you:
1st definition: a distribution for decoupling Drupal
2nd definition: an ideally flexible and minimalist tool empowering developers of all backgrounds to build content repositories for their apps to “consume”
3rd definition: the headless Drupal 8 distribution “specialized” in manipulating content and interacting with it via HTTP APIs
4th definition: a Drupal-based content store with all the web service APIs backed into, so that any developer can jump straight to building his front-end app
5th definition: simply a... content repository; one that just happens to be Drupal-based, as the Reservoir project's maintainers admitted.
Now the 4 key goals behind this distribution for decoupling Drupal — besides that of providing a simple way of building a content repository enabling you to use any technology for your front-end — are:
on-boarding developers or all stripes, making Drupal ideally accessible to... anyone
providing a much-needed opinionated starting point for any type of decoupled Drupal implementation; no Drupal knowledge required
keeping itself away from the scope creep that end-user facing products risk falling into
serving a specific decoupled use case
Decoupling Drupal Made Easy & Accessible: Key Reservoir Features
“But how does Reservoir make building Drupal-based content repositories so much easier than other... distributions?”
“How precisely does it make Drupal accessible to non-Drupal developers, as well?”
You're more than entitled to ask yourself that...
Therefore, let me outline here the out-of-the-box Reservoir features geared at speeding up any decoupled Drupal implementation. Regardless of the developer's background:
an opinionated selection of API-first/ web services modules — Reservoir offers each developer a much-needed starting point/”push” so that he can ramp up and have his content stores built in no time: Simple OAuth modules here included
quick and easy access to the content back-end via JSON API
auto-generated documentation (API documentation), that gets automatically updated, as well, as you're browsing it, as your content model changes
OpenAPI format export, that supports hundreds of tools integrating with the OpenAPI specification
easy-boarding/tailored UI — expect a “welcoming tour” once you've installed Reservoir, one focused on getting you familiar with modeling and managing content, web service APIs, mapping out new content models etc.
a permission system and content editing UI empowering your editorial team to easily manage content
SDKs, libraries and references — included in the Waterwheel ecosystem — so that your development team can skip the time-consuming API learning phase and jump straight to “attaching” Drupal back-end content to their front-end apps
Note: Reservoir, the distribution for decoupling Drupal, deliberately shakes off some of Drupal's functionality that's irrelevant for content repositories (modules such as Breakpoint, Views, Content, the user-facing front-end etc.)
For we couldn't even talk about speeding up your decoupled Drupal project when there's an unnecessarily heavy weight of Drupal modules and features “dragging down” the whole implementation process, right?
Wrapping Up: What Reservoir Aims At Is...
... enabling your developers to jumpstart building self-hosted content repositories capable to serve any given front-ends.
Front-ends that they get to build independently, tapping into the technologies they prefer, on a project-by-project basis.
Pretty convenient, don't you agree?
Adrian Ababei / May 09'2018
Whether you're "constrained" to migrate content to Drupal 8 or you're just eager to jump on the Drupal 8 bandwagon and harness its much-talked-about advanced features, the most important “warning/advice” to keep in mind is:
Don't migrate mindlessly!
Meaning that before you even get to the point of:
triggering the Migrate module's capabilities and adjusting them to your migration project's needs and requirements
selecting and combining all the needed contrib modules
writing down your YAML files for carrying out your content migration process
You'll need to think through every little aspect involved in/impacted by this process:
your goals
your growth plan
your current site visitors' complaints and suggestions
That being said, here's more of a “backbone” or summary of the migration workflow, one that highlights the:
main phases to go through
the right approach to the whole process
Drupal-specific concepts and tools to use
Do NOT expect a very detailed, highly technical tutorial, though!
As for the Drupal concepts that you'll need to be already (more than) familiarized with once you launch your migration process, maybe you want to have a look at this guide here, on Understanding Drupal
And now, let's delve in:
1. The Migration Workflow: 4 Key Phases to Consider
Here's the entire process in 4 steps (so you know what to expect):
first, you'll need to migrate your data into the destination nodes, files and paragraphs on the newly built Drupal 8 site
then you'll migrate data into date, image, taxonomy, address fields and file
next, you'll move your precious data from JSON and CVS files
and finally, you'll complete your migrations from the UI and the terminal
2. Are You Upgrading from Drupal 6 or 7 or Migrating From a Different System?
And here's what to expect depending on your answer to the above question:
if you migrate content to Drupal 8 from an older version of Drupal (6 or 7), then you're quite “spoiled”: a lot of hard work has been done, by the Drupal community, for turning this migration process into the official path to Drupal 8; you could say that the solid framework has already been set up, so all there's left for you to do is to... take advantage of it!
if it's from a whole different system that you're migrating your site (let's say WordPress or maybe Joomla), then... expect it to be a bit more challenging. Not impossible, yet more complex
3. Plan Everything in Detail: Think Everything Through!
Now with the risk of sounding awfully annoying and repetitive, I feel like stressing this out:
Don't migrate... mindlessly!
Plan everything in the smallest detail. Re-evaluate the content on your current site and its “load” of features.
Take the time to define your clear goals and to put together your growth plan (if there's any).
Then, do lend ear to what your current site visitors have to say, filter through all their complaints and suggestions and tailor your final decisions accordingly.
It's only then that you can go ahead and set up your content architecture.
4. Start With the Structure: Build Your Drupal 8 Site First
“But I haven't picked a theme yet!” you might be thinking.
No need to! Not at this stage of the migration process.
You can still build your Drupal 8, from the ground up, even without a theme ready to be used. You can add it later on, once you have the final version of your content!
But the site itself, its solid structure, this is a “must do”. It's the very foundation of all your next operations included in your migration workflow!
5. Deep Clean & Declutter! Take Time to Audit Your Content
Don't underrate this very step! For moving over all that clutter, that heavy load of unused, outdated features and all those chaotic, crummy pages will only impact your Drupal 8 site's performance from the start.
So, now it's the right time to do some... deep cleaning!
Audit your content, your features, plugins and other functionalities included in your site's infrastructure and... trim it down by:
relevance (are you using it?)
quality: keyword-stuffed, unstructured pages (a heavy pile of them) will surely not give your new Drupal 8 site any significant jumpstart in rankings!
6. About the Migration Module Included in Drupal 8 Core
Using this dedicated module in Drupal core to migrate content to Drupal 8 comes down to implementing the:
Extract- Transform-Load process
Or simply: ETL.
In Drupal — as related to the Drupal migrate module — these 3 operations come under different names:
the source plugin stands for “extract”
the process plugin stands for “transform”
the destination plugin stands for “load”
7. Time to... Migrate Content to Drupal 8 Now!
Now it's time to put some order into that “pile” of content of yours! To neatly structure Google Sheets, XML files, CVS files etc.
And here's the whole “structuring process” summed up to the 3 above-mentioned plugins: source, process and destination.
Source:
XML file
SQL database
Google Sheet
CVS file
JSON file
Process:
iterator
default_value
migration_lookup
concat
get
Destination:
images
users
paragraphs
nodes
files
And here's a specific example of how to “glue” data for a neater and ideally structured content architecture:
Before the migration:
A: First Name- Kevin
B: Last Name: Thomson
C: Department- Commerce
After Migration:
A: Name- Kevin Thomson
B: Department- Commerce
8. 4 Contrib Modules to Incorporate Into Your Migration Workflow
As already mentioned, the migrate content to Drupal 8 process also involves using a combination of contrib modules.
Speaking of which, allow me to get them listed here:
Migrate Tools
Migrate Source CVS
Migrate Spreadsheet
Migrate Plus
The END! This is the tutorial on how to migrate content to Drupal 8 trimmed down to its bare essentials.
To its core phases, key steps to take, main Drupal concepts to “joggle with”, right approach/mindset to adopt and best tools/modules to leverage for a smooth process!
Any questions?
RADU SIMILEANU / Apr 24'2018