LATEST FROM OUR BLOG

Take your daily dose of (only) relevant news, useful tips and tricks and valuable how to's on using the latest web technologies shaping the digital landscape. We're here to do all the necessary information sifting for you, so you don't have to, to provide you with content that will help you anticipate the emerging trends about to influence the web.

3 Types of Content Management Systems to Consider in 2019: Traditional CMS vs Headless CMS vs Static Site Generators
Kind of stuck here? One 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 experienced 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 with the presentation layer. Speaking of which, let me give you the most common examples of external clients using APIs content:   static page application (SPA) client-side UI frameworks, like Vue.js or React a Drupal website, a native mobile app, an IoT device static site generators like Gatsby, Jekyll or Hugo   A traditional CMS vs headless CMS comparison in a few words would be: The first one's a “monolith” solution for both the front-end and the back-end, whereas the second one deals with content only. When opting for a headless CMS, one of the increasingly popular types of content management systems, you create/edit your website content and... that's it. It has no impact on the content presentation layer whatsoever. And this can only translate as “unmatched flexibility”: You can have your content displayed in as many ways and “consumed” by as many devices as possible.   Main benefits:   front-end developers will get to focus on the presentation layer only and worry less about how the content gets created/managed content's served, as APIs, to any device as a publisher, you get to focus on content only it's front-end agnostic: you're free to use the framework/tools of choice for displaying it/serving it to the end-user   Main drawbacks:   no content preview  you'd still need to develop your output: the CMS's “head”, the one “in charge” with displaying your content (whether it's a mobile app, a website, and so on) additional upfront overhead: you'd need to integrate the front-end “head” with your CMS   In short: the headless CMS fits any scenario where you'd need to publish content on multiple platforms, all at once.   3. Static Site Generators (Or Static Builders) Why are SSGs some of the future-proofed content management systems?  Because they're the ideal intermediary between:   a modular CMS solution a hand-coded HTML site   Now, if we are to briefly define it: A static site generator will enable you to decouple the build phase of your website from its hosting via an JAMstack architectural pattern. It takes in raw content and configures it (as JSON files, Markdown, YAML data structures), stores it in a “posts” or “content” folder and, templating an SSG engine (Hugo, Jekyll, Gatsby etc.), it generates a static HTML website with no need of a CMS. How? By transpiling content into JSON blobs for the front-end system to use. A front-end system that can be any modern front-end workflow. And that's the beauty and the main reason why static site generators 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 on a specific theme or database, so they can be easily adapted to a project's needs Jamstack sites generally rely on a content delivery network for managing requests, which removes all performance, scaling and security limitations  content and templates get version controlled with right out of the box (as opposed to the CMS-powered workflows) since it uses templates, an SSG-based website is a modular one   And, in addition to their current strengths, SSGs seem to be securing their position among the most popular types of content management systems of the future with their 2 emerging new features:   the improvement of their interface for non-developers (joining the “empower the non-technical user” movement that the headless CMS has embraced); a user-friendly GUI is sure to future-proof their popularity the integrated serverless functions; by connecting your JAMstack website with third-party services and APIs, you get to go beyond its static limitation and turbocharge it with dynamic functionality    To sum up: since they enable you to get your website up and running in no time and to easily integrate it with modern front-end frameworks like Vue and React, static site generators are those types of content management systems of the future. The END! What do you think now? Which one of these CMS solutions manages to check off most of the feature and functionality requirements on your wishlist? ... Read more
RADU SIMILEANU / Feb 26'2019
How to Send Richly Formatted HTML Emails in Drupal 8: Deliver the Experiences that Your Customers Expect in 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 ... Read more
Adriana Cacoveanu / Feb 06'2019
How to Decouple Drupal Commerce to Deliver Richer Shopping Cart Experiences: Useful Modules
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? ... Read more
RADU SIMILEANU / Feb 01'2019
The Drupal Quality Initiative: How Do You Know When Your Contributed Project Is Ready to Be Released? How Do You Assess Its Quality?
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? ... Read more
Adriana Cacoveanu / Jan 25'2019
Progressively Decoupled Drupal: Moving Towards a Standard Workflow
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? ... Read more
Silviu Serdaru / Jan 23'2019
How Do You Deal with Duplicate Content in Drupal? 4 Modules to Get this Issue Fixed
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? ... Read more
Adriana Cacoveanu / Jan 16'2019
How to Scale a Web Application in Drupal: Latest Techniques to Easily Scale Your Web App with Drupal 8
It's a fact: “the next generation” of web apps aren't just extremely fast, they're highly scalable, as well. Which brings us to the next question: “How do you scale a web application in Drupal?” What tools, best practices, and latest techniques do you use for leveraging Drupal 8's scalability capabilities? For ensuring that your custom web app will keep on scaling to:   handle sudden spikes in traffic avoid downtime  withstand “surprise” content overloads   Well, here they come:   1. But Is Drupal Scalable? How Scalable?  Let's just say that: Drupal's built with scalability in mind and that Drupal 8 is... extremely scalable. It's powering some of the world's most trafficked and content-rich websites (Weather, Grammy, Princess Cruises...). Therefore, it's designed to cope with heavy infrastructures of thousand content contributors, Drupal users and site/app visitors... And when gauging Drupal 8's scalability you need to go beyond Drupal's unmatched modularity: +30,000 free modules. Instead, just think of:   Drupal turned into a central API  all the improvements brought to Drupal 8's scalability till this day Drupal 8 enabling you, right out of the box, to integrate it with a wide range of third-party apps, software, and systems RESTful API now in core!!!   … and how all that empowers you, the Drupal web app developer, to easily serve JSON or HTML code. And Drupal 8's unparalleled scalability comes down to this: Empowering developers to create content and send it to any third-party app via JSON. Of course, its out-of-the-box scalability can get further optimized via:   an established set of best practices additional support from various tools and technologies   2. How to Scale a Web Application in Drupal: Server Scaling Techniques Let's say that... “it's time”: You've applied all the optimization techniques on your web application so that it should seamlessly “accommodate” the increasing influxes of traffic and content load. And still, its server hardware has started to show its limitations. So, it's time to scale your server hardware. And you have 2 options at hand:   2.1. You scale up your server vertically  This is the handiest method, so to say. That “emergency” technique to go for when:   you don't have time to install a caching module there's no one in your team with the needed expertise for adding more servers   So, what do you do? You increase your existing server size.  You boost its performance by adding more resources. This way, it could keep up with all those new traffic challenges calling for more memory, more CPU cores... Word of caution: there' no such thing as “sky is the limit” here; you'll still reach the limit of the hardware at some point when you scale up a web app in Drupal using this method.   2.2. You scale up your server horizontally The second best practice for scaling up your server is a bit more complex. And it involves 2 approaches, actually:   a. You separate your database from your Drupal web app.  Basically, your database will have its own server and thus you get to split the load in 2. Then, you can vertically scale each one of the 2 servers.   b. You add multiple servers and distribute the load between them. This is the most complex way to scale a web app in Drupal.  Just think about it: How will the servers included in this whole “ecosystem” “know” which users to take over? It goes without saying that you'll need a load balancer for properly “splitting up” the traffic load. And a database server, as well. See? It already gets more complex compared to the other 2 above-mentioned server scaling techniques. Nevertheless, this is the method which, when done properly, will reduce dramatically the load that each server must handle.   3. “Juggling with” Multiple App Servers for Drupal Let's say that you've opted for the last method of scaling up your server, so: Now you find yourself facing the challenge of handling multiple app servers. How will you deploy code to each of them simultaneously? That is the biggest question when you scale a web app in Drupal. The best practice is to keep all your servers on the same local network.  Having one single data center will speed up the data transfer compared to having it traveling through the internet.   The END! This how you can leverage Drupal 8's scalability capabilities and easily “adjust” your web app to withstand unexpected surges of traffic. Have you tried other techniques and best practices?  ... Read more
RADU SIMILEANU / Dec 10'2018
How to Create and Manage a Content Workflow in Drupal 8: Either a Standard or a Custom One
"A Drupal 8 initiative to improve Drupal's content workflow", this is how Dries Buytaert first defined the Workflow Initiative, back in 2016. Now, coming back to 2018, you must be asking yourself a legitimate question: “How do I set up a content workflow in Drupal 8?” “How do I manage, extend and customize an editorial workflow to fit my Drupal 8 website's publishing needs? One including multiple users, with different permissions, that manages the workflow status of... different content types.” Which are the (not so) new content management features and functionality implemented to Drupal core by now? Those aimed at improving the user experience (editors, content authors...)?   Let's get you some answers:   1. Introducing: The Content Moderation Drupal 8 Module Content Moderation has reached stable version in Drupal 8.5.  Why should you care? What makes this core module of critical importance for creating your content publication workflow?   because otherwise, you'd have only two built-in states to “juggle with”: published and unpublished because it enables you to build a simple workflow for drafts, too … to set up new custom editorial workflows, as well, in addition to the default one   In short, what this module does is that it enables you to create a flexible content workflow process where:   one of the editors in your team stags a “Draft” content and another user on your Drupal 8 website, with a different permission, reviews/updates it   It comes as a powerful tool for you to leverage when your workflow needs are more complex than “ON/OFF”.   2. How to Set Up a Simple Content Workflow in Drupal 8 You'll only need 2 modules for putting together the workflow for a basic content publishing scenario:   Workflows, that will provide just the framework needed for managing the states and transitions included in the process Content Moderation, which will add the “Draft” state, a “Draft to Published” content workflow, and an admin view for handling all the drafts   And here's setting up a basic content publishing workflow in 4 simple steps:   Enable the “Content Moderation” core module Go to “Configuration” and click the “Workflow” tab; it's the last one in the unfolding drop-down menu Open the “Workflows” page Tada! You've just turned on your default “Editorial workflow”   For now, you should be having 3 major states in your workflow:   draft published archived   Note: use permissions to grant content contributors the right to edit/create drafts, editors the “Transition drafts to published” permission, admins the right to “restore to draft transitions” and so on... And voila! Your default editorial workflow, with the Content Moderation module ON, should suit your basic state tracking needs. It should fit any standard use case. Now, if your workflow needs are a bit more complex and website-specific... keep on reading:   3. Content Revisions in Drupal 8 One of the most powerful features that Content Moderation will “turbocharge” your editorial workflow with is:  Saving each change as a content revision in the database.  It stores all revisions in the system. But let's take a common scenario, shall we? Let's say that a second editor decides to make an update to a piece of content (either a content type or a custom block type). He/she updates it, then saves it as a “Draft”. You'll then still have the published version of the content, that's live, on your Drupal website, as well as this Draft (or several of them), stored, as a revision, in your database. A crucial functionality for any complex content publishing workflow:   with content revisions, you get to keep track of who's updated what and when … to trigger log messages regarding those changes, informing other content authors that a given content has been edited and you can also revert to the oldest revisions if needed   4. How to Extend and Customize Your Content Publishing Workflow  Rest assured: there's no need for custom code writing, even if your content publishing needs are a bit more complex. Here's what it takes to extend and to custom-tune your default content workflow in Drupal 8:   While on your “Workflow” page, just click the “Add a new state” button and add more workflow states: “Needs Review” or “Second Review” etc. Next, make sure you adjust your transitions to support your newly added state(s). For instance, a “Second Review” state would require a “Move to Second Review” transition.  Then, apply your extended workflow to either a specific content type or to a custom block type You can also create new separate content publishing workflows to have a different one for your press releases, a separate publishing workflow, an editorial workflow for your blog posts, a warehouse workflow etc.   Defining multiple workflows in Drupal 8, each one with its specific “ecosystem” of states and transitions, is now possible. Notes: the transitions in your workflow will stand for the permissions that you'll assign to different Drupal roles in your team use clear, descriptive verbs to name them remember to grant editors the permission to undo transitions, as well (they might need to revert a piece of content to “Needs Work” once they've reviewed it, for instance) In short: By defining multiple states for your piece of content (Published, Pending Review, Ready for Review, Ready for Second Review, Unpublished, Draft etc.) and managing the permissions corresponding to the state transitions you can build a content workflow in Drupal 8 capable to support even the most complex publishing scenarios. Now, another common scenario where a custom content workflow in Drupal 8 is needed is when you have a website publishing content to multiple platforms.  You have a Drupal 8 website, a native application and an internal portal, let's say... Your publishing workflow would look something like this:   first, content gets moderated to be published on the front-facing Drupal website then, it gets put in the queue for review before it gets published (or declined) on each one of the other 2 platforms   Note: if you need to further extend your editorial workflow and to apply it to a custom entity, for example, you can always write a WorkflowType plugin that meets your specific needs. Then, you can apply your custom workflow to... steps in ordering in a resto app, steps in a manufacturing process and to pretty much any entity (think beyond content) that needs to change its workflow states...   5. How Do You Know If You Really Need an Editorial Workflow? Do you really need to use content moderation? To set up a whole workflow for your publishing scenario? You do, if and only if:   there are multiple content authors uploading content on your website, content that needs to be reviewed before it gets published you're managing a team of multiple admins, with different user roles each moderator knows his/her role in the publishing chain   But if the content authors in your team have the very same type of permission as the admins and they just push content through, a content moderation workflow is useless. It would only slow down the publishing process. So, just because you have the option to set up a content workflow in Drupal 8, doesn't mean that you should rush to implement it on your own website, too... Maybe you just don't need a workflow. The END!  What do you think about these content management capabilities in Drupal 8? Are they powerful and diverse enough to suit your workflow needs?  ... Read more
Adriana Cacoveanu / Nov 14'2018
The Drupal 8 Layout Builder Module: How It Revolutionizes Content Layout Creation in Drupal
What's your favorite tool for creating content layouts in Drupal? Paragraphs, Display Suite, Panelizer or maybe Panels? Or CKEditor styles & templates? How about the much talked about and yet still experimental Drupal 8 Layout Builder module? Have you "played” with it yet? As Drupal site builders, we all agree that a good page layout builder should be:   flexible; it should empower you to easily and fully customize every single node/content item on your website (not just blocks) intuitive, super easy to use (unlike "Paragraphs", for instance, where building a complex "layout", then attempting to move something within it, turns into a major challenge)   And it's precisely these 2 features that stand for the key goals of the Layout Initiative for Drupal:  To turn the resulting module into that user-friendly, powerful and empowering page builder that all Drupal site builders had been expecting. Now, let's see how the module manages to “check” these must-have strengths off the list. And why it revolutionizes the way we put together pages, how we create, customize and further edit layouts. How we build websites in Drupal...   1. The Context: A Good Page Builder Was (Desperately) Needed in Drupal It had been a shared opinion in the open source community: A good page builder was needed in Drupal. For, even if we had a toolbox full of content layout creation tools, none of them was “the One”. That flexible, easy to use, “all-features-in-one” website builder that would enable us to:   build complex pages, carrying a lot of mixed content, quick and easy (with no coding expertise) fully customize every little content item on our websites and not just entire blocks of content site-wide easily edit each content layout by dragging and dropping images, video content, multiple columns of text and so on, the way we want to   Therefore, the Drupal 8 Layout Builder module was launched! And it's been moved to core upon the release of Drupal 8.6. Although it still wears its “experimental, do no use on production sites!” type of “warning tag”, the module has already leveled up from an “alpha” to a more “beta” phase. With a more stable architecture now, in Drupal 8.6, significant improvements and a highly intuitive UI (combined with Drupal's well-known content management features) it stands all the chances to turn into a powerful website builder. That great page builder that the whole Drupal community had been “craving” for.   2. The Drupal 8 Layout Builder Module: Quick Overview First of all, we should get one thing straight: The Drupal 8.6. Layout Builder module is Panelizer in core! What does it do? It enables you, the Drupal site builder, to configure layouts on different sections on your website. From selecting a predefined layout to adding new blocks, managing the display, swapping the content elements and so on, creating content layouts in Drupal is as (fun and) intuitive as putting Lego pieces together. Also, the “content hierarchy” is more than logical:   you have multiple content sections you get to choose a predefined layout or a custom-design one for each section you can place your blocks of choice (field blocks, custom blocks) within that selected layout   Note: moving blocks from one section to another is unexpectedly easy when using Layout Builder!   3. Configuring the Layout of a Content Type on Your Website Now, let's imagine the Drupal 8 Layout Module “in action”. But first, I should point out that there are 2 ways that you could use it:   to create and edit a layout for every content type on your Drupal website to create and edit a layout for specific, individual nodes/ pieces of content   It's the first use case of the module that we'll focus on for the moment. So, first things first: in order to use it, there are some modules that you should enable — Layout Builder and Layout Discovery. Also, remember to install the Layout Library, as well! Next, let's delve into the steps required for configuring your content type's (“Article”, let's say) display:   go to Admin > Structure > Content types > Article > Manage Display hit the “Manage layout” button   … and you'll instantly access the layout page for the content type in question (in our case, “Article”). It's there that you can configure your content type's layout, which is made of:   sections of content (display in 1,2, 3... columns and other content elements) display blocks: tabs, page title... fields: tags, body, title   While you're on that screen... get as creative as you want:   choose a predefined layout for your section —  “Add section” —  from the Settings tab opening up on the right side of the screen add some blocks —  “Add block”; you'll then notice the “Configure” and “Remove” options “neighboring” each block drag and drop the layout elements, arranging them to your liking; then you can click on either “Save Layout” or “Cancel Layout” to save or cancel your layout configuration   And since we're highly visual creatures, here, you may want to have a look at this Drupal 8 Layout Builder tutorial made by Lee Rowlands, one of the core contributors. In short: this page builder tool enables you to customize the layout of your content to your liking. Put together multiple sections — each one with its own different layout —  and build website pages, carrying mixed content and multiple layouts, that fit your design requirements exactly.   4. Configuring and Fully Customizing the Layout of a Specific Node... This second use case of the Drupal 8 Layout Builder module makes it perfect for building landing pages. Now, here's how you use it for customizing a single content type:   go to Structure>Content types (choose a specific content type) click “Manage display” on the drop-down menu  then click the “Allow each content item to have its layout customized” checkbox and hit “Save”   Next, just:   click the “Content” tab in your admin panel choose that particular article that you'd like to customize click the “Layout” tab   … and you'll then access the very same layout builder UI. The only difference is that now you're about to customize the display of one particular article only. Note: basically, each piece of content has its own “Layout” tab that allows you to add sections, to choose layouts.  Each content item becomes fully customizable when using Drupal 8 Layout Builder.   5. The Drupal 8.6. Layout Builder vs Paragraphs “Why not do everything in Paragraphs?" has been the shared opinion in the Drupal community for a long time. And yet, since the Layout Builder tool was launched, the Paragraphs “supremacy” has started to lose ground. Here's why:   the Layout builder enables you to customize every fieldable entity's layout it makes combining multiple sections of content on a page and moving blocks around as easy as... moving around Lego pieces    By comparison, just try to move... anything within a complex layout using Paragraphs:   you'll either need to keep your fingers crossed so that everything lands in the right place once you've dragged and dropped your blocks or... rebuild the whole page layout from scratch   The END! What do you think:   Does Drupal 8 Layout Builder stand the chance to compete with WordPress' popular page builders? To “dethrone” Paragraphs and become THAT page layout builder that we've all been expected for? Or do you think there's still plenty of work ahead to turn it into that content layout builder we've all been looking forward to? ... Read more
RADU SIMILEANU / Nov 02'2018