“Should I stay or should I go?” Should you stick to an all-too-familiar traditional CMS and “reap” the benefit of getting loads of much-needed functionality out-of-the-box? Or should you bid on flexibility, top speed, and versatility instead? In a headless CMS vs traditional CMS “debate”, which system best suits your specific needs?
Now, let me try and “guess” some of the CMS requirements on your wishlist:
to have all the needed functionality “under the same hood” (a predefined theme, robust database, a user-friendly admin dashboard...)
to be developer friendly
to integrate easily and seamlessly with any modern JS front-end of your choice
to “fuel” your website/app with high speed
Needless to add that:
You can't have them all in one CMS, either traditional or headless.
What you can actually do is:
set up a hierarchy with all your feature needs and requirements
set it against each of these two types of CMSs' advantages and limitations
Just see which one of them “checks off” the most requirements on your list.
Then, you'd have yourself a “winner”.
So, let's do precisely that:
A headless CMS vs traditional CMS comparison to help you determine which one's... a better fit for you.
1. Traditional CMS: Benefits and Challenges
Everything in one place...
That would be a concise, yet fully comprehensive definition for the traditional CMS.
Just imagine a content management system that provides you with all the critical features and functionality, all the needed elements straight from the box:
a generic theme
a dashboard for easily managing your own content
a predefined database
PHP code for retrieving the requested content from your database and serving it to the theme layout
The back-end and front-end, meaning the code, database, and the layout/design, are “under the same hood”, strongly coupled.
It's all there, pre-built, at hand... “Convenience” must be another word for “traditional CMS”.
Security & Performance: A Few Challenges to Consider
Getting all that critical functionality out-of-the-box does translate into... code. Lots and lots of code, lots and lots of files.
Which also means lots and lots of potential vulnerabilities to be exploited.
There could be an error in any of the files in that heavy load of files that you get. Or a query string parameter that could be turned into “free access” into your database...
Therefore, the convenience of built-in functionality does come with its own security risks.
Also, whenever you make a “headless CMS vs traditional CMS” comparison, always be mindful of the maintenance aspect:
Of the upgrading that you'll need to perform with every new security patch that gets released.
Now, as regards the performance “pumped” into your traditional CMS-based website/application, just think: compiling files.
That's right! Consider all those custom files, in addition to the pre-defined ones that you'll be provided with, that you'll pile up for... customizing your website.
All these files, all the new libraries that you'll want to integrate, will need to get compiled. Which can only mean:
more stress put on your server memory
copying code of functionalities that you might not even use
a poor page loading time, with an impact on the user experience provided on your website
2. A Traditional CMS Is the Best Choice for You If...
Now, you must be asking yourself: “How do I know if a traditional CMS is the best fit for my own use case?”
My answer is:
You go through the here listed “scenarios” and see if any of them matches your own.
you already have a team of PHP experts with hands-on experience working with a particular CMS (Drupal, WordPress...)
it's a stand-alone website that you need; no other applications and tech stack that might depend on a CMS's provided functionality
you're not opinionated on the technology that your website will get built on
3. Headless CMS: What Is an API-Based Website, More Precisely?
“It's a CMS that gives you the flexibility and freedom to build your own front-end — Angular, Rails, Node.js-based, you name it — and integrate it with content management tools via an API."
In short: your headless CMS can then serve raw content — images, text values — via an API, to a whole “ecosystem” of internet-connected devices: wearables, websites, mobile apps.
And it'll be those content-consuming devices' responsibility to provide the layout and design of the content delivered to the end-users.
What's in it for you?
it dramatically streamlines the development cycle of your API-based website; you can get a new project up and running in no time
there's no need to pile up lots and lots of files and the code of out-of-the-box functionalities that you might not even need
if there's a particular service that you need — store form submissions or a weather forecast — there's always a specific service with an API that you could integrate to have that particular content served on your website
A headless approach gives you the freedom to integrate exclusively the functionalities that you need into your website.
Moreover, you still get a dashboard for easily managing your content. Your headless CMS will have got you covered on this.
With no code being “forced” into your website/mobile app or need to perform a performance “routine” for this. You get it by default.
Security and Performance: Main Considerations
In terms of security, a short sentence could sum all the advantages that you can “reap” from having an API-based website:
There's no database...
Therefore, there are no database vulnerabilities, no unknown gateway that a hacker could exploit.
Furthermore, in a “headless CMS vs traditional CMS” debate, it's important to outline that the first one doesn't call for an administration service.
Meaning that you get to configure all those components delivering content to your website as you're building it. Except for that, the rest of the dynamic content gets safely stored and managed in your headless CMS.
“But can't anyone just query the service endpoints delivering content on my API-based website?”
True. And yet, there are ways that you can secure those channels:
use double-authentication for sensitive content
be extra cautious when handling sensitive data; be mindful of the fact that anyone can query the JS implementation
Now, when it comes to performance, keep in mind that:
It's just assets that your web server will provide. As for the content coming from all those third-party services that your headless CMS is connected with, it will get delivered... asynchronously.
Now, considering that:
most of those endpoints are hosted in the cloud and highly flexible
the first response — the first static HTML file that gets served — is instant
you could go with a headless CMS that leverages a CDN for delivery
in a traditional CMS scenario the website visitor has to wait until the server has finished ALL the transactions (so, there is a bit of waiting involved in there)
… you can't but conclude that in a “headless CMS vs traditional CMS” debate, the first one's way faster.
4. Use a Headless Approach If...
you already have your existing website built on a specific modern tech stack (Django, React, Node.js, Ruby on Rails) and you need to integrate it with a content management system, quick and easy
you don't want your team to spend too much time “force-fitting” your existing tech stack into the traditional CMS's technology (React with... WordPress, for instance)
you need your content to load quickly, but you don't want a heavy codebase, specific to traditional CMSs, as well
you want full control over where and how your content gets displayed across the whole ecosystem of devices (tablets, phones, any device connected to the IoT...)
you don't want to deal with all the hassle that traditional CMS-based websites involve: scaling, hosting, continuous maintenance
5. Headless CMS vs Traditional CMS: Final Countdown
Now, if we are to sum it up, the two types of CMSs' pros and cons, here's what we'd get:
Traditional CMS
It comes with a repository for your content, as well as a UI for editing it and a theme/app for displaying it to your website visitors.
While being more resource-demanding than a headless CMS, it provides you with more built-in functionality.
Headless CMS
It, too, provides you with a way to store content and an admin dashboard for managing it, but no front-end. No presentation layer for displaying it to the end user.
Its main “luring” points?
it's faster
it's more secure
more cost-effective (no hosting costs)
it helps you deliver a better user experience (you get to choose whatever modern JS framework you want for your website's/app's “storefront”)
It's true, though, that you don't get all that functionality, right out-of-the-box, as you do when you opt for a traditional CMS and that you still need to invest in building your front-end.
In the end, in a “headless CMS vs traditional CMS” debate, it's:
your own functionality/feature needs
your versatility requirements
the level of control that you wish to have over your CMS
your development's team familiarity with a particular technology
… that will influence your final choice.
Photo from Unsplash
Silviu Serdaru / Mar 06'2019
Which of those Drupal modules that are crucial for almost any project make you want to just... pull your hair out?
For, let's face it, with all the “improving the developer experience” initiatives in Drupal 8:
BigPipe enabled by default
the Layout Builder
Public Media API
and so on
… there still are modules of the “can't-live-without-type” that are well-known among Drupal 8 developers for the headaches that they cause.
And their drawbacks, with a negative impact on the developer experience, go from:
lack of/poor interface
to a bad UI for configuration
to hard-to-read-code
too much boilerplate code, verbosity
to a discouragingly high learning curve for just some one-time operations
Now, we've conducted our research and come up with 4 of the commonly used Drupal modules that developers have a... love/hate relationship with:
1. Paragraphs, One of the Heavily Used Drupal Modules
It's one of the “rock star” modules in Drupal 8, a dream come true for content editors, yet, there are 2 issues that affect the developer experience:
the “different paragraphs for different translations” issue
the deleted (or “orphaned”) paragraphs that seem to “never” leave the database for good
Developers are dreaming of a... better translation support for the Paragraphs module. And of that day when the deleted pieces of content with paragraphs data don't remain visible in their databases.
2. Views
Here's another module with its own star on Drupal modules' “hall of fame” that... well... is still causing developers a bit of frustration:
You might want to write a query yourself, to provide a custom report. In short, to go beyond the simple Views lists or joins. It's then that the module starts to show its limitations.
And things to get a bit more challenging than expected.
It all depends on how “sophisticated” your solution for setting up/modifying your custom query is and on the very structure of the Drupal data.
Luckily, there's hope.
One of the scheduled sessions for the DrupalCon Seattle 2019 promises to tackle precisely this issue: how to create big, custom reports in Drupal without getting your MySQL to... freeze.
3. Migrate
There are plenty of Drupal developers who find this module perfectly fit for small, simple website migration projects. And yet, they would also tell you that it's not so developer friendly when it comes to migrating heavier, more complex websites.
Would you agree on this or not quite?
4. Rules
Another popular Drupal module, highly appreciated for its flexibility and robustness, yet some developers still have a thing or two against it:
It doesn't enable them to add their own documentation: comments, naming etc.
And the list could go on since there are plenty of developers frustrated with the core or with the Commerce Drupal module...
The END!
What do you think of this list of Drupal modules that give developers the most headaches? Would you have added other ones, as well?
What modules do you find critical for your projects, yet... far from perfect to work with?
Adriana Cacoveanu / Mar 01'2019
Kind of stuck here? On one hand, you have all those software development technologies that are gaining momentum these days — API, serverless computing, microservices — while on the other hand, you have a bulky "wishlist" of functionalities and expectations from your future CMS. So, what are those types of content management systems that will be relevant many years to come and that cover all your feature requirements?
And your list of expectations from this "ideal" enterprise-ready content infrastructure sure isn't a short one:
to enable you to build content-centric apps quick and easy
multi-languages support
user role management
a whole ecosystem of plugins
inline content editing
to be both user and developer-friendly
personalization based on visitors' search history
to support business agility
search functions in site
... and so on.
Now, we've done our research.
We've weighed their pros and cons, their loads of pre-built features and plugins ecosystems, we've set them against their “rivaling” technologies and selected the 3 content management systems worth your attention in 2019:
But What Is a Content Management System (CMS)? A Brief Overview
To put it simply:
Everything that goes into your website's content — from text to graphics — gets stored in a single system. This way, you get to manage your content — both written and graphical — from a single source.
With no need for you to write code or to create new pages. Convenience at its best.
1. Traditional CMS, One of the Popular Types of Content Management Systems
Take it as a... monolith. One containing and connecting the front-end and back-end of your website: both the database needed for your content and your website's presentation layer.
Now, just turn back the hands of time and try to remember the before-the-CMS “era”. Then, you would update your HTML pages manually, upload them on the website via FTP, and so on...
Those were the “dark ages” of web development for any developer...
By comparison, the very reason why content management systems — like Drupal, WordPress, Joomla — have grown so popular so quickly is precisely this empowerment that they've “tempted” us with:
To have both the CMS and the website's design in one place; easy to manage, quick to update.
Main benefits:
your whole website database and front-end is served from a single storage system
they provide you with whole collections of themes and templates to craft your own presentation layer
quick and easy to manage all your content
there are large, active communities backing you up
Main drawbacks:
they do call for developers with hands-on experience working with that a specific CMS
except for Drupal, with its heavy ecosystem of modules, content management systems generally don't scale well
they require more resources — both time and budget — for further maintenance and enhancement
A traditional CMS solution would fit:
a small business' website
a website that you build... for yourself
an enterprise-level website
… if and only if you do not need it to share content with other digital devices and platforms.
You get to set up your website and have it running in no time, then manage every aspect of it from a single storage system.
Note: although more often than not a traditional CMS is used to power a single website, many of these content infrastructures come with their own plugins that fit into multi-site scenarios or API access for sharing content with external apps.
2. Headless CMS (or API-First Pattern)
The headless CMS “movement” has empowered non-developers to create and edit content without having to get tangled up in the build's complexities, as well. Or worrying about the content presentation layer: how it's going to get displayed and what external system will be “consuming” it.
A brief definition would be:
A headless CMS has no presentation layer. It deals exclusively with the content, that it serves, as APIs, to external clients.
And it's those clients that will be fully responsible for the presentation layer.
Speaking of which, let me give you the most common examples of external clients using APIs content:
static page application (SPA)
client-side UI frameworks, like Vue.js or React
a Drupal website, a native mobile app, an IoT device
static site generators like Gatsby, Jekyll, or Hugo
A traditional CMS vs headless CMS comparison in a few words would be:
The first one's a “monolith” solution for both the front-end and the back-end, whereas the second one deals with content only.
When opting for a headless CMS, one of the increasingly popular types of content management systems, you create/edit your website content, and... that's it. It has no impact on the content presentation layer whatsoever.
And this can only translate as “unmatched flexibility”:
You can have your content displayed in as many ways and “consumed” by as many devices as possible.
Main benefits:
front-end developers will get to focus on the presentation layer only and worry less about how the content gets created/managed
content's served, as APIs, to any device
as a publisher, you get to focus on content only
it's front-end agnostic: you're free to use the framework/tools of choice for displaying it/serving it to the end-user
Main drawbacks:
no content preview
you'd still need to develop your output: the CMS's “head”, the one “in charge” with displaying your content (whether it's a mobile app, a website, and so on)
additional upfront overhead: you'd need to integrate the front-end “head” with your CMS
In short: the headless CMS fits any scenario where you'd need to publish content on multiple platforms, all at once.
3. Static Site Generators (Or Static Builders)
Why are SSGs some of the future-proofed content management systems?
Because they're the ideal intermediary between:
a modular CMS solution
a hand-coded HTML site
Now, if we are to briefly define it:
A static site generator will enable you to decouple the build phase of your website from its hosting via an JAMstack architectural pattern.
It takes in raw content and configures it (as JSON files, Markdown, YAML data structures), stores it in a “posts” or “content” folder and, templating an SSG engine (Hugo, Jekyll, Gatsby etc.), it generates a static HTML website with no need of a CMS.
How? By transpiring content into JSON blobs for the front-end system to use. A front-end system that can be any modern front-end workflow.
And that's the beauty and the main reason why static site generators still are, even after all these years, one of the most commonly used types of content management systems:
They easily integrate with React, for instance, and enable you to work with modern front-end development paradigms such as componentization and code splitting.
They might be called “static”, yet since they're designed to integrate seamlessly with various front-end systems, they turn out to be surprisingly flexible and customizable.
Main benefits:
they're not specialized in a specific theme or database, so they can be easily adapted to a project's needs
Jamstack sites generally rely on a content delivery network for managing requests, which removes all performance, scaling, and security limitations
content and templates get version-controlled right out of the box (as opposed to the CMS-powered workflows)
since it uses templates, an SSG-based website is a modular one
And, in addition to their current strengths, SSGs seem to be securing their position among the most popular types of content management systems of the future with their 2 emerging new features:
the improvement of their interface for non-developers (joining the “empower the non-technical user” movement that the headless CMS has embraced); a user-friendly GUI is sure to future-proof their popularity
the integrated serverless functions; by connecting your JAMstack website with third-party services and APIs, you get to go beyond its static limitation and turbocharge it with dynamic functionality
To sum up: since they enable you to get your website up and running in no time and to easily integrate it with modern front-end frameworks like Vue and React, static site generators are those types of content management systems of the future.
The END!
What do you think now? Which one of these CMS solutions manages to check off most of the feature and functionality requirements on your wishlist?
RADU SIMILEANU / Feb 26'2019
How do you run a page speed audit from a user experience standpoint? For, let's face it: website performance is user experience!
What are the easiest and most effective ways to measure your Drupal website's performance? What auditing tools should you be using? How do you identify the critical metrics to focus your audit on?
And, once identified, how do you turn the collected data into speed optimization decisions? Into targeted performance improvement solutions...
Also, how fast is “ideally fast”, in the context of your competition's highest scores and of your users' expectations?
Here are the easiest steps of an effective page performance audit, with a focus on the prompt actions you could take for improving it.
1. Front-End vs Back-End Performance
They both have their share of impact on the overall user experience:
Long response times will discourage, frustrate and eventually get your website visitors to switch over to your competition.
Front-End Performance
It's made of all those elements included in the page loading process, as being executed by the browser: images, HTML, CSS and JavaScript files, third-party scrips...
The whole process boils down to:
Downloading all these elements and putting them together to render the web page that the user will interact with.
Back-End Performance
It covers all those operations performed by your server to build page content.
And here, the key metrics to measure is TTFB (Time To First Byte).
It's made of 3 main elements:
connection latency
connection speed
the time needed for the server to render and serve the content
2. What Should You Measure More Precisely? 5 Most Important Metrics
What metrics should you focus your page speed audit on? Here's a list of the 5 most relevant ones:
a. Speed index
The essential indicator that will help you determine the perceived performance on your Drupal website:
How long does it take for the content within the viewport to become fully visible?
When it comes to optimization techniques targeting the speed index, “battle-tested” techniques, like lazyloading and Critical CSS, are still the most effective ones.
b. Time to first byte
As previously mentioned, the back-end performance:
Measures the time passed from the user's HTTP request to the first byte of the page being received by the browser.
c. Start render
The time requested for rendering the first non-white content on the client's browser.
Note: the subsequent requests are “the usual suspects” here, so you'd better ask yourself how you can reduce, defer or relocate them. Maybe you'd consider a service worker?
d. Load time
How long does it take for the browser to trigger the window load event? For the content on the requested page to get loaded?
Note: consider enabling HTTP/2, with a dramatic impact on individual page requests.
e. Fully loaded
It measures the time of... zero network activity. When even the JavaScript files have all been already fired.
Note: make sure your third-party scripts are “tamed” enough. They're the main “responsible” factors for high fully loaded times.
3. How to Perform a Page Speed Audit: 5 Useful Tools
Now that you know what precisely to analyze and evaluate, the next question is:
“How do I measure these key metrics?”
And here are some of the easiest to use and most effective tools to rely on when running your page performance audit:
WebPageTest
PageSpeed Insights
Lighthouse
SpeedCurve
Chrome DevTools
Use them to:
collect your valuable data on all the above-mentioned metrics
get an insight into the page rendering process performed by the browser
identify the “sore spots” to work on
automate repeated page speed tests
keep monitoring your website (SpeedCurve) across multiple devices and in relation to your competition's performance
get a peek into your web page's structure and into the process of downloading resources over the network (Chrome DevTools)
4. 3 Key Benchmarks to Evaluate Your Website's Performance
So, now that you've got your “target metrics” and your toolbox ready, you wonder:
“What should I measure those metrics against?”
And here, there are 3 major benchmark-setting processes to include in your page speed audit:
determine your competition: your current production site before its rebuild, your direct and indirect “rivaling” websites
determine the key pages on your Drupal website: homepage, product listing page, product detail page etc.
measure your competition's web page performance
5. Most Common Performance Bottlenecks & Handiest Solutions
Here are the most “predictable” culprits that you'll identify during your page speed audit, along with the targeted performance-boosting measures to take:
Factors Impacting the Front-End Performance & Solutions
a. Too many embedded resources
Too many embedded stylesheets, JavaScript and images are an extra challenge for your page loading time. They'll just block the rendering of the page.
Each connection setup, DNS lookup and queuing translates into... overhead, with an impact on your site's perceived performance.
The solution: consider caching, minification, aggregation, compression...
b. Oversized files
And images (stylesheets and JavaScript) sure are the main “culprits” for long response times on any Drupal website.
The solution: consider aggregating/compressing them, turning on caching, lazyloading, resizing etc.
c. Wrongly configured cache
Is your website properly cached? Have you optimized your cache settings? Or is it possible that your Drupal cache could be broken?
If so, then it will have no power to reduce latency, to eliminate unnecessary rendering.
The solution: look into your response headers, URL/pattern configuration, expiration and fix the problem cache settings.
d. Non-optimized fonts
Your heavy fonts, too, might play their part in dragging down your website.
The solution: consider caching, delivery, compression, and character sets.
In conclusion: do re-evaluate all your modal windows, third-party scripts and image carousels. Is their positive impact on the user experience worth the price you pay: a negative impact on your page loading time?
Word of caution on caching:
Mind you don't overuse caching as a performance boosting technique. If there are serious back-end performance issues on your website, address them; using caching as the solution to mask them is not the answer. It works as a performance improvement technique on already working systems only.
Factors Impacting the Back-End Performance & Solutions
And there are some handy, straightforward measures that you could take for addressing back-end performance issues, as well:
Consider optimizing the page rendering process directly in the CMS.
Upgrade your server's hardware infrastructure (e.g. load balancing, RAM, disk space, MySQL tuning, moving to PHP7).
Keep the number of redirects to a minimum (since each one of them would only add another round trip, which bubbles up to the TTFB).
Reconfigure those software components that are lower in the server stack (caching back-end, application container).
Consider using a CDN; it won't serve everything, plus it will lower the distance of a round trip.
Consider using Redis, Varnish.
6. Final Word(s) of Advice
Here are some... extra tips, if you wish, to perform a page speed audit easily and effectively:
remember to run your audit both before and after you will have applied your targeted performance improving techniques
grow a habit of tracking weekly results
define the goal of your Drupal website performance test: what precisely should it test and measure and under which circumstances?
… for instance, you could be analyzing your site's back-end performance only: the time requested for generating the most popular web pages, under a load of 700 concurrent visitors, let's say (so, you won't be testing connection speed or the browser rendering process)
pay great attention to the way you configure your page speed audit system if you aim for accurate and representative results
The END!
This is the easy, yet effective way of performing a website speed and optimization audit. What other tools and techniques have you been using so far?
Photo by Veri Ivanova on Unsplash.
RADU SIMILEANU / Feb 14'2019
API first, responsive Bartik, headless and decoupled Drupal, Layout Builder, React admin UI... Drupal's evolved tremendously over these 18 years! Yet: the emails that we send out via its otherwise robust email sending system aren't different from those we used to send a... decade ago. And customers expect rich experiences outside your Drupal website or app. While website administrators expect to be enabled to easily manage, via the admin UI, their email content templates. So: how do you send HTML emails in Drupal 8?
Without relying on external services, of course...
And who could blame customers for expecting 2019-specific user experiences? Experiences that HTML-enabled emails deliver through their great features.
Features that support Drupal editors' marketing efforts, as well:
traffic-driving hyperlinks; you get to link to your landing page right from the email
visually attractive custom design; emails that look just like some... microsites
all sorts of design details that reinforce your brand: buttons over cryptic links, responsive design, templated footers and headers
web fonts
QR codes
hierarchical display of content, that enhances readability and draws attention to key pieces of content and links in your email
images and attachments
tracking for monitoring opens
And speaking of admin and/or editors, the questions they ask themselves are:
“How can I easily theme the emails to be sent out?”
“How can I change their content templates right from the admin UI?”
And these are the questions that I'll be answering to in this post.
Here are your current options at hand — 3 useful Drupal 8 modules — for easily crafting and sending out HTML emails that appeal and engage.
1. The HTML Mail Module
It does exactly what you'd expect:
It enables you to configure HTML emails from Drupal 8.
It's the Drupal 7 go-to option whenever you want to go from plain text emails to HTML-formatted ones. A module available for Drupal 8 in alpha version.
Furthermore, it integrates superbly with the Echo and the Mail MIME modules.
2. The Swift Mailer Module, The Best Way to Send HTML Emails in Drupal 8
Swift Mailer is the highly recommended method for configuring Drupal 8 to send out visually-arresting, HTML emails.
Since you can't (yet) send them right out of the box with Drupal...
The module stands out as the best option at hand with some heavy-weighing features:
it supports file attachments
it supports inline images, as well
it enables admins to send HTML (MIME) emails
… to send them out via an SMTP server, the PHP-provided mail sending functionality or via a locally installed MTA agent
Note: you even get to use this module in tandem with Commerce to send out your HTML-enabled emails. There's even an initiative underway for replacing Drupal's deprecated core mail system with the Swift Mailer library.
And now, here are the major configuration steps to take to... unleash and explore this module's capabilities:
first, set up the Swift Mailer message (/admin/config/swiftmailer/messages) settings to use HTML
next, configure the Swift Mailer transport settings (/admin/config/swiftmailer/transport) to your transport method of choice
and finally, configure the core mail system settings to use this module for the formatter and the sender plugins
And if you're not yet 100% convinced that the Swift Mailer module is significantly superior to Drupal's default mail system, here are some more arguments:
it enables you to send... mixed emails: both plain text and HTML-enabled
it provides HTML content types
it supports various transport methods: Sendmail, PHP, SMTP (the current mail system supports but one method)
it enables you to integrate key services with Drupal — like Mandrill, SendGrid — right out of the box
it incorporates a pluggable system, allowing you to further extend its functionality
How about now? Are these strong enough arguments that Swit Mailer's the way to send HTML emails in Drupal 8?
3. The PHPMailer Module
Another option for configuring Drupal 8 to send out HTML emails is the PHPMailer module.
How does it perform compared to Swift Mailer?
It's not pluggable
it's not as easily customizable as Swift Mailer
it's already embedded in the SMTP module (in fact, in Drupal 8 the default mail interface class is named “PHPMail” instead of DefaultMailSystem)
What features does it share with Swift Mailer?
it enables you to send out HTML-enabled emails with Drupal
it enables you to add attachments to your emails
it, too, enables you to send out mixed emails
it, too, supports external SMTP servers
Moreover, you can extend its core functionality by integrating it with the Mime Mail component module (currently in alpha 2 version for Drupal 8).
4. The Mime Mail Component Module
Briefly, just a few words about Mime Mail:
as already mentioned, it's a “component module”, that can be used for boosting other modules' functionality
it enables you to send out HTML emails with Drupal: your mail would then incorporate a mime-encoded HTML message body
it enables you to set up custom email templates: just go to your mimemail/theme directory, copy the mimemail-message.tpl.php file and paste it into your default theme's folder; this way, your email will take over your website's design style
any embedded graphics gets Mime-encoded, as well, and added as an attachment to your HTML email
do some of your recipients prefer plain text over richly formatted HTML emails? Mime Mail enables you to switch your email content over to plain text to meet their specific preferences
The END!
Now that you know your options, it's time to step out from the (too) long era of rudimentary, plain emails sent out with Drupal.
... and into the era of richly formatted HTML emails, that will:
enrich your customers' experiences
enhance Drupal 8 site admins' experience
Adriana Cacoveanu / Feb 06'2019
Just imagine it: Drupal 8's robust features as a CMS, the flexible e-commerce functionality of the Drupal Commerce ecosystem and a JavaScript framework for the front-end! All in the same native mobile app! You can easily achieve this “combo” — a reliable content repository & a JS-based front-end providing a fantastic shopping cart experience — if you just... decouple Drupal Commerce.
For why should you trade Drupal's battle-tested content authoring and administration tools for a more interactive user experience?
And why should you give up on your goal to deliver richer cart experiences just because Drupal 8 can't rival the JavaScript in terms of advanced native mobile app functionality?
push notifications
complex shopping options
enabling users to manage their own delivery times and places
... to configure various aspects of their orders and so on
Just leverage a decoupled Drupal Commerce strategy in your shopping app project and you can have both:
Drupal as your secure content service
the front-end framework of your choice “in charge” with the user experience
In this respect, these are the most useful Drupal tools at hand for implementing an API-based headless architecture:
1. Headless Commerce Comes Down to...
… separating your commerce stack (back-end content handling area, data store etc.) from the user interface.
Or the “head”, if you wish.
The presentation layer would “retrieve” content from the back-end content storage area and is the one fully “responsible” with delivering fantastic user experience.
This way, you're free to choose your own front-end tools.
Now, why would you consider choosing a decoupled architecture for your e-commerce solution? The benefits are quite obvious and not at all negligible:
higher flexibility and scalability (that JS frameworks are “famous” for)
freedom to customize your app to your liking (for every platform or/and device)
richer, more interactive shopping experiences
2. Decoupled Drupal Commerce... Out of the Box? The Commerce Demo
Narrowing our focus down to... Drupal, to Drupal Commerce, more specifically, the question's still there:
“How do I decouple Drupal Commerce?”
Considering that:
there are specific challenges that such a decoupled front-end architecture poses
Drupal solutions like Forms API and Views won't fit your specific (probably quite complex) design implementation requirements
Luckily, the Commerce Guys team has already faced and solved these challenges.
First of all, they've put together the Commerce Demo project, a store providing default content to be “injected” into Drupal.
Secondly, their attempt at integrating a design meant to support advanced functionality, for richer shopping cart experiences, resulted in 2 new modules:
Commerce Cart API
Commerce Cart Flyout
More about them, here below...
3. Useful Modules to Decouple Drupal Commerce
Here's a collection of the most... relevant modules that you could use in your headless Drupal Commerce project:
3.1. The Commerce Cart API Module
It's no less than a handy Drupal tool that enables you to custom build your shopping cart widget.
3.2. The Cart Flayout Module
The go-to module when you need to ajaxify the “Add to cart” form in your shopping app.
Basically, what it does is:
Provide a sidebar that “flies out” once the user clicks the “Add to cart” button or the cart block.
If I were to dive into details a bit, I'd add that the flyout enables users to:
view the products in their shopping carts
remove all the items there
update the quantity of a specific item
Should I add also that Cart Layout comes with no less than 9 different Twig templates, for various parts of the module? By leveraging Drupal's library management feature you can easily override these JS segments of the module.
And not only that you get to customize it to suit your needs entirely, but:
it comes with a well structured JS logic
it's built on top of Backbone
… which translates into an efficient models-views separation.
3.3. Commerce 2
Use Drupal Commerce 2 as the core structure of your e-commerce project.
Being an ecosystem of Drupal 8 modules and “spoiling” you with unmatched extensibility via its APIs, Drupal Commerce empowers you to implement all kinds of headless commerce scenarios.
It enables you to use Drupal as your content/data (user and order-related info) repository and to easily serve this content to your mobile app. To your end-users.
3.4. The Commerce Recurring Framework Module
Some of its handy charging & billing features include:
configurable billing cycles
configurable retries in case of payment declines
both prepaid and postpaid billing systems
3.5 The JSON API & JSON API Extras Modules
Need to decouple Drupal Commerce, to enable a full REST API in JSON format?
It's as easy as... enabling a module (or 2 at most): the JSON API module.
What it does is:
Expose the API so you can vizualize the data in JSON format.
And Drupal's built and perfectly adapted to support JSON API, which turns it into the go-to option when you need a back-end content repository for your headless shopping app.
In addition to this module, feel free to enable JSON API Extras, as well. It comes particularly handy if you need to customize the generated API.
It allows you to:
override the name of your resources
change their path...
You'll then have a specific place in your app's user interface where you can visualize your content paths.
Once you have your data in JSON format, safely stored in your back-end content creation & moderation Drupal area, you're free to... serve it to your mobile shopping app!
The END!
And these are some of the already tested tools and techniques to decouple Drupal Commerce so that you can deliver richer, more interactive cart experiences.
Have you tried other modules/methods? Writing custom JavaScript code... maybe?
RADU SIMILEANU / Feb 01'2019
Let's say you've been working on this contributed project for a few months now. It has gone from Beta 1 to Beta 2 to Beta... Now, how long till its final release? How do you know when it's ready for the Drupal community to see and use? And this is precisely why the Drupal quality initiative was launched in the first place.
So that can we finally have some sort of a checklist at hand to use whenever we need to assess our code's level of quality:
the standards that we should evaluate our contributed projects by
the specific elements that go into the quality of our projects, such as contributed Drupal modules
a certain hierarchy of quality that we could rate our own projects by
And so on...
For, let's admit it now:
Except for our own personal methodologies for self-assessment, there's no standardized benchmark that could help us evaluate our contributed Drupal projects. There's no way of knowing for sure when our projects are 100% ready to go from beta to... full release.
Now, here are the legitimate questions that this initiative brings forward, along with some of the suggested paths to take:
1. What Drupal-Specific Quality Metrics Should We Use to Evaluate Our Code?
How do you know when your contributed project is efficient enough to... be used by other members of the Drupal community?
You need some sort of criteria for measuring its level of quality, right?
2. The Drupal Quality Initiative: A Checklist for Project Quality Assessment
And this is how the “Big Checklist” for Drupal modules has been put together. One outlining all those areas of a contributed Drupal project that you should carefully evaluate when assessing its quality.
Areas such as:
team management
documentation
testing
code
design
requirements
DevOps
All those factors and Drupal-specific elements that go into the quality of a contributed project.
3. Introducing the Idea of a Multi-Leveled Quality Hierarchy
What if we had multiple levels of quality to rate our Drupal projects?
Imagine some sort of hierarchy of quality that would challenge us to keep improving the way we write code for Drupal. To keep growing as teams working with Drupal.
Your project might be rated “level 1”, from a quality standpoint, on its first release. But it would still stand stand the chance to get a higher score for if you strove to meet all the other criteria on the checklist.
4. You'll Be Particularly Interested in The Drupal Quality Initiative If You're A...
Site builder, scanning through the pile of contributed Drupal modules in search of the ones that perfectly suit your project's specific needs
Drupal contributor in need of some sort of checklist that would include all those standards of quality and best practices to help you assess your own code's value
5. What About Non-Drupal Software Projects? How Is Their Quality Assessed?
In other words: how do other communities assess their projects' levels of quality?
What metrics do they use?
And here, the Drupal quality initiative's... initiator gives the “The Capability Maturity Level”, set up by the Software Engineering Institute, as an example.
The process model highlights 5 levels of “maturity” that a project can reach throughout its different development phases.They range from:
the“initial chaos”
to planning and collecting project requirements
… all the way to continuous process improvement
Now, just imagine a similar multi-level evolutionary benchmark that we could use to assess our own Drupal projects' levels of... maturity.
6. A Few Quality Indicators and Suggested Tools
And the whole Drupal Quality Initiative comes down to identifying the key endpoints for assessing a project's quality, right?
Here are just some of the suggested questions to use during this evaluation process:
Is it easy to use?
Does it perform the intended functions?
Is it efficient enough?
How many detected bugs are there per 1000 lines of code
How secure is it?
Now, for giving the most accurate answers to these quality assessing questions, you'll need the right toolbox, right?
All those powerful tools to help you:
check whether your code is spell checked
monitor the status of specific operations
check whether all strings use translation
see whether your code has been properly formatted
The END! And this is just a brief overview of the Drupal Quality Initiative.
What do you think now, does the suggested checklist stand the chance to turn into a standardized Drupal benchmark for assessing quality?
How do you currently determine your contributed projects' value?
Adriana Cacoveanu / Jan 25'2019
Progressively decoupled Drupal has gone from concept to buzzword. Until recently, when we've started to witness sustained efforts being made to set up a standard workflow for implementing this architecture.
New dedicated modules have been developed to fit those use cases where just a few particular blocks, affecting the website's overall performance, need to be decoupled. All while preserving Drupal's standard robust features.
Features too famous among content editors and site builders to be sacrificed in the name of high speed and rich UX.
We've gradually shifted focus from “Why would I choose progressive decoupling over a headless CMS?” to:
“How precisely do I implement the progressive approach into my own decoupled Drupal project? Is there a standardized process, based on a set of dedicated modules, that I can leverage?”
And this is what I'll be focusing on in this post here.
More precisely, on the efforts for standardizing the whole workflow: see Decoupled Blocks and the SPALP module!
1. Progressively Decoupled Drupal: Compromise or Viable Alternative to an All-In Transition?
Is this approach nothing but a compromise between:
content editors — and all Drupal users working in the site assembly — who depend on key features like content workflow, layout management, site preview, seamless administrative experience
and front-end developers, who're “dying” to “inject” application-like interactivity and high-speed front-end technologies into certain portions of the Drupal web pages?
Progressively decoupling blocks in Drupal is, indeed, the best compromise you could get between:
your editorial team's “fear” of losing familiar Drupal features critical for their workflow
front-end developers willing to experiment with new technologies promising top speed and richer user experiences
Developers get to leverage the JavaScript framework of their choice without interfering with the site assemblers' workflow. Flexibility at its best!
But does being a viable compromise makes it also a worthy alternative to the fully decoupling option?
It does.
Specifically because:
it caters to all those who haven't been won over by the “headless CM movement”
it removes the risk of trading vital Drupal functionality for the benefits of a powerful front-end framework
In other words:
For all those Drupal projects requiring that only certain components should be decoupled, an all-in transition would be simply... redundant and unnecessarily risky.
For all those projects there's the progressively decoupled Drupal alternative.
2. Why Has this Approach to Decoupling Drupal Been So Unpopular?
How come the progressively decoupled Drupal strategy gained so little traction?
It seems that despite its drawbacks — the need to reinvent some of the lost “Drupal wheels” and its higher costs — the fully decoupled approach has been more popular.
And there are 3 main causes for this, that Dries Buytaert identified and exposed in his blog post on “How to Decouple Drupal in 2018”:
progressive decoupling doesn't leverage server-side rendering via Node.js
modern JavaScript cohabits with old-school PHP
JavaScript's ascension is not going to stop any time soon; therefore, the risk of sacrificing some of Drupal's popular capabilities might still seem insignificant compared to the JS advantages at a front-end level
3. The SPALP Module: Towards a Standard Workflow for Implementing Progressive Decoupling
Now, back to this blog post's main topic:
Clear pieces of evidence that we're finally heading towards a standardized process for implementing this type of decoupled system.
And one such evidence is the SPALP module: Single Page Application Landing Page.
Here's a specific use case, so you can get an idea of its role in the entire workflow of a progressively decoupled Drupal project:
Let's say that you need to integrate a couple of JavaScript-based one-page apps into your Drupal website. The CMS will continue to be “in charge” of the page rendering, access control routing and navigation, while the JS apps would be developed independently, outside of Drupal. How would you configure these JS apps as Drupal web pages?
You'd use the SPALP module to configure each one of them so that:
you stay consistent and “joggle with” the same configuration every time you need to add a new app to your Drupal website
you make its easy for your content team to manage this entire ecosystem of single-page JavaScript apps
“And how does this module work?”
Here's the whole “back-stage” mechanism:
the SPALP module helps you to set up a new “app landing page" content type, the one providing the URL for the app about to be integrated
each one of these applications must have its own module that would declare a dependency on SPALP, include its JSON configuration and define its library
once a module meeting all these requirements is enabled, SPALP will create a landing page node for it, which will store the initial configuration
the SPALP module will add the pre-defined library and a link to an endpoint serving JSON each time that node is viewed
Note: speaking of the efforts made to create a “Drupal way” of implementing this decoupled architecture, you might want to check out Decoupled Blocks, as well. It's designed to empower front-end developers to use the JS framework of their choice to develop individual custom blocks that would be later on integrated into Drupal. No Drupal API knowledge required!
The END!
What do you think: will the community continue their efforts to build a standard workflow for the progressively decoupled Drupal approach? Or will it remain a conceptual alternative to headless Drupal?
Silviu Serdaru / Jan 23'2019
Accidentally creating duplicate content in Drupal is like... a cold:
Catching it is as easy as falling off a log.
All it takes is to:
further submit your valuable content on other websites, as well, and thus challenging Google with 2 or more identical pieces of content
move your website from HTTP to HTTPs, but skip some key steps in the process, so that the HTTP version of your Drupal is still there, “lurking in the dark”
have printer-friendly versions of your Drupal site and thus dare Google to face another duplicate content “dilemma”
So, what are the “lifebelts” or prevention tools that Drupal “arms” you with for handling this thorny issue?
Here are the 4 modules to use for boosting your site's immunity system against duplicate content.
And for getting it fixed, once the harm has already been made:
1. But How Does It Crawl into Your Website? Main Sources of Duplicate Content
Let's get down to the nitty-gritty of how Drupal 8 duplicate content “infiltrates” into your website.
But first, here are the 2 major categories that these sources fall into:
malicious
non-malicious
The first ones include all those scenarios where spammers post content from your website without your consent.
The non-malicious duplicate content can come from:
discussion forums that create both standard and stripped-down pages (for mobile devices)
printer-only web page versions, as already mentioned
items displayed on multiple pages of the same e-commerce site
Also, duplicate content in Drupal can be either:
identical
or similar
And since it comes in “many stripes and colors”, here are the 7 most common types of duplicate content:
1.1. Scraped Content
Has someone copied content from your website and further published it? Do not expect Google to distinguish the copy from its source.
That said, it's your job and yours only to stay diligent and protect the content on your Drupal site from scrapers.
1.2. WWW and non-WWW Versions of Your Website
Are there 2 identical version of your Drupal website available? A www and a non-www one?
Now, that's enough to ring Google's “duplicate content in Drupal” alarm.
1.3. Widely Syndicated Content
So, you've painstakingly put together a list of article submission sites to give your valuable content (blog post, video, article etc.) more exposure.
And now what? Should you just cancel promoting it?
Not at all! Widely syndicated content risks to get on Google's “Drupal 8 duplicate content” radar only if you set no guidelines for those third-party websites.
That is when these publishers don't place any canonical tags in your submitted content pointing out to its original source.
What happens when you overlook such a content syndication agreement? You leave it entirely to Google to track down the source. To scan through all those websites and blogs that your piece of content gets republished on.
And often times it fails to tell the original from its copy.
1.4. Printed-Friendly Versions
This is probably one of the sources of duplicate content in Drupal that seems most... harmless to you, right?
And yet, for search engines multiple printer-friendly versions of the same content translates as: duplicate pages.
1.5. HTTP and HTTPs Pages
Have you made the switch from HTTP to HTTPs?
Entirely?
Or are there:
backlinks from other websites still leading to the HTTP version of your website?
internal links on your current HTTPs website still carrying the old protocol?
Make sure you detect all these less obvious sources of identical URLs on your Drupal website.
1.6. Appreciably Similar Content
Your site's vulnerable to this type of duplicate content “threat” particularly if it's an e-commerce one.
Just think of all those too common scenarios where you display highly similar product descriptions on several different pages on your eStore.
1.7. User Session IDs
Users themselves can non-deliberately generate duplicate content on your Drupal site.
How? They might have different session IDs that generate new and new URLs.
2. 4 Modules at Hand to Identify and Fix Duplicate Content in Drupal
What are the tools that Drupal puts at your disposal to detect and eliminate all duplicate content?
2.1. Redirect Module
Imagine all the functionality of the former Global Redirect module (Drupal 7) “injected” into this Drupal 8 module!
In fact, you can still define your Global Redirect features by just:
accessing the Redirect module's configuration page
clicking on “URL redirects”
Image Source: WEBWASH.net
What this SEO-friendly module does is provide you with a user-friendly interface for managing your URL path redirects:
create new redirects
identify broken URL paths (you'll need to enable the “Redirect 4040” sub-module for that)
set up domain level redirects (use the “Redirect Domain” sub-module)
import redirects
Summing up: when it comes to handling duplicate content in Drupal, this module helps you redirect all your URLs to the new paths that you will have set up.
This way, you avoid the risk of having the very same content displayed on multiple URL paths.
2.2. Taxonomy Unique Module
How about “fighting” duplicate content on your website at a vocabulary level?
In this respect, this Drupal 8 module:
prevents you from saving a taxonomy term that already exists in that vocabulary
is configurable for every vocabulary on your Drupal site
allows you to set custom error messages that would pop up whenever a duplicate taxonomy term is detected in the same vocabulary
2.3. PathAuto Module
Just admit it now:
How much do you hate the /node125 type of URL path aliases?
They're anything but user-friendly.
And this is precisely the role that Pathauto's been invested with:
To automatically generate content friendly path aliases (e.g. /blog/my-node-title) for a whole variety of content.
Let's say that you want to modify the current “path scheme” on your website with no impact on the URLs (you don't want the change to affect user's bookmarks or to “intrigue” the search engines).
The Pathauto module will automatically redirect those URLs to the new paths using any HTTP redirect status.
2.4. Intelligent Content Tools
Personalization is key when you strive to prevent duplicate content in Drupal, right?
And this is precisely what this module here does: it helps you personalize content on your website.
How? Through its 3 main functionalities delivered to you as sub-modules:
auto tagging
text summarizing
detecting plagiarized content
Leveraging Natural Language Processing, this last sub-module scans content on your website and alerts you of any signs of duplicity detected.
Word of caution: keep in mind that the module is not yet covered by Drupal's security advisory policy!
3. To Sum Up
Setting a goal to ensure 100% unique content on your website is as realistic as... learning a new language in a week.
Instead, you should consider setting up a solid strategy ”fueled” by (at least) these 4 modules “exposed” here. One that would help you avoid specific scenarios where entire pages or clusters of pages get duplicated.
Now, that's a far less utopian goal to set, don't you think?
Adriana Cacoveanu / Jan 16'2019