Jun 06 2019
Jun 06

“Can I use Drupal for project management?” Definitely. 

Given all its content-oriented baked-in capabilities — file management, version control, easy content creation, and editing — Drupal makes the perfect software for:
 

  • managing your projects the easy and the... smart way
  • streamlining communication among your team members and with your contractors
     

In this respect, Drupal provides its own feature-rich distributions to help you put together your robust setup in no time. “Distributions” that come already packed with a set of useful sub-modules and themes, that all support the core functionality: project management (and smooth collaboration).

And without further ado, here the 2 most popular Drupal distributions for project management and team collaboration for you to evaluate first: RedHen and Open Atrium.
 

Loaded with robust and modern features, this Drupal-native CRM is designed with flexibility in mind. Meaning that it integrates seamlessly with the enterprise solution that you're using (Blackboud, Salesforce) and it supports a wide range of use cases...

And speaking of its functionalities:
 

  • engagement tracking and monitoring
  • data mangement: information about your contacts, the relationships among them and with your own company (e.g. memberships)
  • event registration integration
  • one-page donation forms to custom-tune to your liking
     

As for those many use cases that this Drupal distribution's built to accommodate, let's pick just a few real-world examples:

  • It's the best choice if smoothly integrating your CRM with your other enterprise solutions is critical for you
     
  • It streamlines tracking interactions with your contacts and organizations. Furthermore, since you can easily integrate it with your website, you get to leverage the provided data in order to adjutst the user experience accordingly...
     
  • It allows you to customize it and thus to give it a Drupal-like look and feel: to integrate it with modules like Rules or Views, to go for the same field creation UI etc.
     
  • Is your contacts list a huge one? This CRM comes to your rescue with some powerful baked-in tools: an efficient find-and-dedupe interface, an automated filter built in the UI, that you can use to filter your contacts by specific fields etc.
     
  • It automatically syncronizes data in your Contacts list with any newly updated data on your Drupal Users list
     


In short: RedHen CRM makes one of the top choices when you consider using Drupal for project management purposes. It's a lightwright, self-contained framework, more of a “cluster” of multiple specialized modules:
 

  • Organization
  • Activity
  • Fields
  • Organization Group
  • Dedupe
  • Registration
  • and a few more...
     

Looking for a Drupal-native distribution built around the team collaboration functionality?

One that should be:
 

  • convenientyly extensible
  • “loaded” with robust collaboration and information sharing features?
     

Then Open Atrium fits the profile in the slightest detail.

Built on top of the Organic Groups and Panopoly modules, it's a framewrok flexible enough to support discussion configurations by key criteria like team, project, organization...

And here are some more powerful features worth considering when you're still thinking whether you should use Drupal for project management:
 

  • an access control system, that grants granular control to certain sections of your project
  • a drag and drop layout with plenty of widgets to select from for customizing your landing pages and dashboard
  • file storing and sharing features
  • built-in Events, Files, Discussions, Issue Tracking, Document Wiki
  • an easy to customise, responsive theme
     

The END!

These are but 2 viable answers to your “Can I use Drupal for project management and team collaboration?” type of question. 2 of the options available that best meet some of your main requirements when looking for a project management software:
 

  • to be easy to use
  • to ship with an entire collection of file management and communication features
  • to be flexible enough and allow quick customization and seamless integrations
     

Have you tried other Drupal modules/distributions built around this functionality so far? 

Image by jessica45 from Pixabay

May 29 2019
May 29

May has been most generous with us, no doubt about it: it has "spoiled" us with a heavy load of both useful and usable Drupal content. The community has been altruistic enough to share their “enlightening” experiences of working with Drupal, their discoveries and latest contributions. As for us, we "feasted" on their articles and tutorials, even managed to sync all our personal tops and to come up a unique "best Drupal blog posts” list for this month.
 

Ranging from valuable tutorials to overviews of the latest Drupal releases, to glimpses of these Drupal contributors' hard work, our selection is as varied as it is valuable.
 

Now, in the name of open source we're ready to share our selection with you, OPTASY team's 5 most appreciated Drupal blog posts in May:
 

Drupal 8.7 had just been "taken out of the oven", it was still steamy fresh when the Srijan team published their inventory on its new features and newsworthy updates.

From:
 

  • JSON:API now in Drupal 8 core
  • to the Media Libray module, that grew from experimental to stable 
  • to the "rockstar" Drupal 8 module, the Layout Builder, that turned stable
  • to the newly improved configuration management system
     

... and other upgrades, updates, and newly added features, they managed to include in their post all the "highlights" of this Drupal minor release.

And, most of all, to do it promptly enough to be among the first (if not the first) to share their overview on the release with the world/the Drupal community...
 

Another piece of content that made it to our “best Drupal blog posts” list this month has been Matt Oliveira's tutorial on how to use Laravel's Homestead for Drupal local development.

He first adds some sort of context to justify his choice (since he used to go with Vagrant for his Drupal projects), then he explains, step by step:
 

  • what software you need to install, first things first ( VMWare, a VM provider, Hyper-V, Vagrant, etc.)
  • how to install and setup Homestead using Composer, but only after you've first cloned your Composer Drupal project
  • the command to enter for... launching it, after you've run all the due configurations
     

And his clearly formulated and practical tutorial goes all the way to the cool features that Homestead will provide you with and some useful warnings to keep in mind.

Have you used Homestead for your local development when working on your Drupal projects before?
 

Did the “secure Drupal” frenzy get you, too, last year? Particularly after the Drupalgeddon attacks?

Then you must have rushed to:
 

  • implement all the security best practices out there
  • put up a thick security shield around your Drupal modules and your Drupal theme
     

But did you know how insecure Drupal code even looked like?

And it's precisely this rhetorical question that generated the ThinkShout team's blog post.

They point out that:
 

  • way too many Drupal developers risk to “host” insecure code under their websites' hoods without even knowing it
  • most of us genuinely assume that all Drupal APIs are safe
     

Next, once they point out the issue(s), they enlist several exploitable holes that you could identify in your code, grouped in 3 main categories:
 

  • XSS vulnerabilities when rendering HTML
  • SQL injection risks
  • PHP code issues
     

A priceless resource to keep at hand and to tap into whenever we run our own code review sessions here, at OPTASY. One that we're most grateful for. 
 

It's useful, it's enjoyable, it's packed with helpful tips on both:
 

  • what optimizing images for the web really means; take it as a helpful checklist
  • what Drupal tools to use to... automate the whole process
     

And I'm talking here about the “Configure image styles” feature that enables you to define some sort of “pattern” to apply on all the future images on your website. One already incorporating all the due properties, the right width and height.

About the “Image toolkit” feature, that enables you to easily improve your image's quality. And the list goes on (with the Responsive Images module and so on...)

A way too valuable piece of content not to include it in our “best Drupal blog posts” list.
 

The real challenge highlighted by the Duo team in their post? Drupal site search in case of large organizations.

And their real struggle to look for a solution that:
 

  • would allow users to query across an entire ecosystem of websites and platforms
  • wouldn't put too much pressure on Drupal
     

In this respect, they bring to our attention a solution architected and developed by the Palantir team: the federated search.

Next, they back up their choice with strong arguments:
 

  • it's a robust enough search solution to meet large organizations' needs
  • being a decoupled solution, it leverages Drupal's powerful back-end without putting a strain on its front-end, as well
     

In short: for us, the OPTASY team, this post opened a world of possibilities. What if search in Drupal could be way more flexible, yet powerful enough to meet enterprise-level requirements?

And I'm thinking here of all our clients “juggling” with multiples websites...

 
The END!

These are the best Drupal blog posts on our monthly list. And we have to admit: picking just 5 pieces of content on Drupal was one hell of a challenge.

Photo by Daniel McCullough on Unsplash

May 24 2019
May 24

What makes the Cache API in Drupal 8 any better than Drupal 7's cache system? What's so revolutionary about it? Which of the old limitations does it remove? What are those new concepts and terminology that you should learn about?

And, most of all: how complex is it to set up a cache in Drupal 8 for a specific use case?

You might have already bumped into terms like “max-age”, "context cache" or "cache tags".
 

But how precisely do these new concepts, part of Drupal 8's cache system, refine and streamline the way you cache data on your website?
 

Let's try to demystify the terminology of Drupal 8's Cache API and to translate its new “fancy” terminology into... crystal-clear benefits for you:
 

1. What Is Caching More Precisely? Why Do We Cache Data?

To your “What” question I'd answer:
 

Caching is a... strategy (or layer) for storing data from your website. Or: it's a software or hardware component where you store your data. 
 

Both definitions are equally accurate.

Why would you want to store your data?
 

Because this will streamline the way your website serves all future requests for that cached data.
 

And it goes without saying that reading data straight from the cache takes less time than... retrieving it from a slower data container or fully recreating the result.

In short: caching data translates into faster page load time.


2. Cache API in Drupal 8: The Automatic Cache System

A brief, yet accurate definition of cache in Drupal 8 would be:
 

Storing data that takes too long to load.
 

And if I am to detail it a bit I'd have to add that:
 

Caching can be either permanent or time-limited you'ree to cache any type of data on your website.
 

Now, talking about Drupal 8's cache API, what everyone points out is that: it is much improved. That it's so different from the cache systems of the previous Drupal versions that... you even risk turning your website uncachable if you're not familiar with its new concepts.

“But how different/sophisticated can it be?” you might ask yourself.

Before we delve deep into details let me add just one thing:
 

We're talking about an... automated cache system. Basically, your Drupal 8 website retrieves cache data for both anonymous and logged in users with no configuration whatsoever. All by default...
 

And now, let's shed some light on all these new fancy concepts that the Cache API in Drupal 8 is based on:
 

2.1.The Cache Tags

We all do agree that “invalidating cache” is one of the most challenging tasks of any cache system.

Luckily, not anymore. At least not in Drupal 8, where you now have the concept of “cache tags” that you can use for tagging:
 

  • specific pages
  • specific page elements
  • various types of content
     

… and thus invalidate them all. Improved efficiency and high accuracy through... basic tagging.

Basically, using these cache tags you can easily identify outdated data stored in multiple cache bins and... invalidate it.

This way, you no longer run the risk of invalidating “still green” cache items, in bulk, not knowing which data to invalidate.
 

2.2. The Context Cache

Here's an all too common scenario:
 

You're faced with multiple variants of the same data; only one of them should be cached, based on a specific criterion like language, user, country, content access permission...
 

Well, how do you automate targetting the right variant to be cached? And how do you automate caching the other left variants, as well, depending on the... context.

You use “cache contexts”, that's how...

They're one of those new remarkable features that the Cache API in Drupal 8 ships with, that allow you to specify the criteria to be used for the cached content on a page to vary. By user, by language, by country, by path...
 

2.3. The Max-Age (The Cache Duration)

Maybe you don't want certain data to be forever cached. Maybe you need it stored for a certain period of time only.

In this respect, the “max-age” property in Drupal 8's cache system allows you to define that time limit. To invalidate data that will have run... out of time.
 

2.4. The Bubbleable Cache Metadata

What does this even mean “cache metadata... bubbling”?

Let's take this example: 
 

You have a parent item with its own “family” of... children items. In this context, “bubbled tags” makes it possible for the parent item in this render array to receive cacheability metadata from its children.
 

Bubble cache metadata streamlines the whole process of invalidating... outdated cached data. As simple as that...
 

The END!

Is it any clearer for you now what makes the Cache API in Drupal 8 so... powerful? How its new features come to remove most of the limitations that you've already faced in Drupal 7?

And how you can use them to refine and automate caching on your own Drupal 8 website?

Image by Pexels from Pixabay  

Apr 26 2019
Apr 26

April's been unexpectedly generous with us. It has spoiled us with plenty of high-quality content on Drupal. From “enlightening” tutorials to articles raising awareness of certain limitations, to useful tips and actionable advice, to blog posts announcing life-saving module releases... reading our way through the pile of Drupal blog posts this month has been a true dare.

Then, trimming down our bulky list to just 5 posts has been an even bigger challenge...

Nevertheless, we did manage to make our selection. Here's what we kept:
 

The WishDesk team share their experience with leveraging the Drupal 8 Views contextul filters via a well-structured, easy to follow tutorial.

That we're highly grateful for...

Why has it drawn our attention? 
 

  • because we had already been excited about the unmatched flexbility that the contextual filters in Drupal 8 offer
  • it clearly outlines the main differences between regular and contextual filters
  • it presents a specific use of these filters: setting up a task tracker in Drupal 8 using Views 
     

With Views already providing us with an UI for putting together data collections based on certain criteria, now having contextual filters, as well, to fine-tune the results come as an... unexpected “present”.

Their key benefit and advantage over the “standard” filters? They accept dynamic values...

Another one of our top favorite Drupal blog posts this month has been this piece of content raising awareness of the Layout Builder's limitation:

The code generating the image element markup doesn't “store” information about the specific sizes of the column that the image will be placed in.

In other words: there's no way for Drupal site builders to enter an accurate value for the “sizes” attribute when using the Layout Builder...

And the author, Brian K Osborne, draws attention on this issue after first highligthing the main “dilemma” of using responsive image styles:

Providing just one high resolution, high-quality, oversized image vs providing a suitably sized image for efery screen resolution...
 

We couldn't leave out Dries' blog post on the due preparations for upgrading to Drupal 9.

The reassuring aspect that he reveals is that all these preparations revolve around one common best practice: detecting and removing deprecated code from our Drupal 8 websites.

He goes on giving straight answers to all those legitimate questions that we might ask ourselves in relation to these preparations for Drupal 9:
 

  • What is deprecated code?
  • How do we identify it on our websites?
  • How challenging and time-consuming is it to remove it/update it?
     

This has been, by far, one of the best rated Drupal blog posts in April here, at OPTASY.

We can no longer imagine our (work) lives without the Paragraphs module in our toolbox. So, upon hearing about the Paragraphs Editor Enhancements module we dropped evewrytging and looked for this blog post.

Which comes as an inventory of both:
 

  • users' (content editors) main improvement suggestions for the Paragraphs module
  • undpaul team's solutions to editors' complaints/suggestions, turned into enhancements for this module
     

From the:
 

  • well-known “dread” of having to drag the content elements to their right positions after you've added them
  • to the need to be enabled to add those content elements preferiantially (since most editors add pretty much the same elements, over and over again)
  • to the overwhelmingly high number of buttons and the overcrowded dialogs
     

 
… the Paragraphs Editor Enhancements ships with a solution to each one of these drawbacks.

We can't but predict that it will hugely influence the editorial experience in Drupal...

We could never thank enough the OSTraining team for their clear, concise and most useful tutorials. 

One of their April's Drupal blog posts has been this step-by-step guide on how to add webforms to content types. And the scenarios where you'd might find this kind of knowldge “life saving” vary from:
 

  • having to add a contact form to a “business” content type on your Drupal website
  • to having to add a contact form to your “Events” content type
     

Easy to follow, clearly explained, uncluttered, filled with relevant screenshots, their tutorial has been truly “enlightening” for us.

Especially since adding various types of forms is one of those recurring tasks in our Drupal projects...


The END! 

These have been our favorite Drupal blog posts this month. How does your own top 5 look like?

Photo by Bernard Hermant on Unsplash 

Apr 24 2019
Apr 24

Simple or custom-made? Is it a quick-to-assemble, rather “prototypical” form that you need for your website? Or a more complex, custom-made one? In a Drupal 8 Contact Forms vs Webform “debate”, which Drupal form builder best suits your data collection requirements?

On one hand, you have the convenience of creating your web forms in no time: simple, straightforward, “conventional” web forms. On the other hand, you get to scan through a never-ending list of advanced options and come up with a complex, fully custom-made web form.

That, of course, if you don't mind the time you need to invest in going through all those different form elements and available features and the risk of getting... overwhelmed by tons of field customization options.

Ease of use vs unlimited capabilities...

The convenience of getting your forms up and ready to collect user data in no time vs the chance to tailor some more advanced forms, ideally customized, carrying lots of different field values.

Decisions, decision...

Now, to help you decide here's a more detailed Drupal 8 Contact Forms vs Webform comparison. Weigh each one of the 2 form modules' benefits and drawbacks, set them against your own needs and... make the choice:


1. The Contact Forms Module 

Being part of Drupal core, there's no need to download and install the module.

Just go to Structure>Contact forms. Next, choose either to opt for the default form or to set up a new one: click the “Add contact form” button.

Drupal 8 Contact Forms vs Webform: Add Contact Form


Once in the form creation screen, enter your form's values in the predefined fields that you have there:
 

  • give the form a name in the “Label” field
  • enter the email address where all the form submission will be sent to (most probably your site admin address) in the “Recipients” field
  • enter your “Thank you” text in the “Message” field there; this will be the “thank you” text line your users will see once they hit the “submit/send” button 
  • in the “Redirect path”, enter the URL to the page that you want them to get forwarded to after they've submitted the forms (that if you don't want them to be redirected back to the homepage, by default)
  • click “Save” and there you have it: a simple form, with all the basic, must-have field values, built in no time
     

Of course, that doesn't mean that you can't further explore the given features and maybe add a few more fields and even styling options.

For instance, you could “Edit” your newly created form. Just select it in the “Contact Forms” screen and, scrolling down the options in the drop-down menu opening up, click the “Manage fields” option.

Click “Add field”, then “select a field type” – Text(plain), let's say – enter the “Label” and configure its settings.

Furthermore, if you want to style your form a bit, hit the “Manage form display” tab and... opt for a placeholder, for example. Next, explore the options available in the “Manage display” screen. For instance, you get to decide if you want your field label to be hidden, inline or visually hidden...

In short: in a Drupal 8 Contact Forms vs Webform comparison, the first form builder will always outshine the latter when it comes to ease of use.

It empowers you to set up a simple form quick and easy...
 

2. The Webform Module

Now, if Contact Forms is a rather minimalist form builder, the Webform module is a feature-rich, powerful one.

The customization features that it ships with go from email notifications to fine-grained access, from statistic collection of data to delivering results in a CSV format. From exporting data in various formats to... conditional sorting and filtering.

In other words, with Webform sky is the limit when it comes to the contact form that you can create.

It can go from a basic one to a highly complex, multi-page form. One made of lots of elements, advanced options for the user to select from, settings and features for you to leverage in the back-end...

But, let's keep in mind that it's contributed module so you'll first need to download it from Drupal.org.

Next, go to “Structure” and hit the “Webforms” tab. Then, click the “Add webform” button and, in the next screen popping up, give your new form a name (enter it in the “Title” field).

You'll be automatically forwarded to the “Build” tab, which is where all the “magic happens”. Once you click the “Add element” button, you'll get to “swim through” a sea of lots and lots... and lots of form elements (known as “fields” in Contact forms) to choose from. Ranging from basic to really advanced ones...

Webform: Select an Element Screen


Let's assume that you'll want to add a “Text field” element. Click the “Add Element” button corresponding it, then scan through all the new customization options listed up in the “Add Text field element” screen opening up next...

Feel free to add other elements to your webform: a “text area” maybe, an “email” element, as well... 

Note: do keep in mind that, once you've settled for the final fields/elements to be included in your web form, you can always change the order to get them displayed in. Just drag and drop them till they fit that predefined order in your mind...

Also, you can check/mark them as “Required” and turn them into “must fill in" fields, as opposed to optional form fields.

Note: feel free to edit that “Thank you” page that your webform will automatically forward users to. How? By clicking “Back to form”>"Settings”>"Confirmation” and selecting from the different options that you have there:
 

  • enter your own Confirmation title (e.g. “Thank you!”)
  • customize your Confirmation message
     

3. Drupal 8 Contact Forms vs Webform: Key Differences

Now that we've run our spotlight over each one of these 2 form building tools, let's make an inventory of the differences that we've identified:
 

  • first of all, it's obvious that the Webform module gives you more control over your web forms' design
     
  • also, unlike Contact Forms, it supports conditional emails; you get to send an email to a specific user in your list based on conditions associated with the value of certain elements in your form
     
  • Webform enables you to add basic logic to your web forms
     
  • … it comes packed with tons of advanced options, ranging from JS effects to conditional logic, to submission handling, etc.
     
  • Contact Forms, on the other hand, allows you to set up a simple contact form in the blink of an eye; you skip the tedious process of scanning through lots and lots of options, settings, and complex features
     
  • Webform allows you to create your forms either in a YAML file or in its the admin-friendly UI
     
  • also, Webform comes as a “cluster” of submodules – Webform REST, Honeypot, Webform Views, SMTP, Webform Encrypt, etc. – which are “responsible for” its multiple capabilities
     

4. In Conclusion...

The conclusion of this Drupal 8 Contact Forms vs Webform “debate” is quite simple: 

If you need a basic form on your website and you need it built fast, go with Contact Forms. Being included in Drupal 8 adds convenience...

But if you want to customize your form (and you have the time), to style it to your liking and “turbocharge” with advanced features and options, then go with Webform.
 

It's a much more powerful and feature-rich form builder, perfectly suited for your complex requirements...


Image by Tumisu from Pixabay

Apr 17 2019
Apr 17

What makes Drupal a great choice from a UX standpoint? What features are responsible for the enhanced end-user experience in Drupal 8? Those features that enable you to easily create an intuitive and enjoyable visitor experience on your own Drupal-based website/application.

And to constantly improve it...

Is it all those performance enhancements that it ships with? Or maybe its “responsive out-of-the-box” nature? Or rather its multilingual capabilities?
 

1. But First: 7 Evergreen Ways to Improve Your Website's UX

It goes without saying that, in order to create an enjoyable, rich user experience on your Drupal 8 website, you'll need to:
 

  • put together a solid UX strategy
  • run extensive user research and map the user's journey
  • come up with an effective, well-planned UX design, paying attention to all the latest design trends (and now decoupled Drupal empowers you to tap into a whole range of new possibilities...)
     

And while carrying out all these phases of the UX design process, make sure to apply the following evergreen techniques for enhancing the visitor's experience:
 

1.1. Optimize the page loading time

For speed will always be the factor with the biggest influence on the user's experience on your Drupal site.

In this respect, there are tons of performance enhancements that you can implement, ranging from aggregating your JS and CSS files to properly configuring your cache to opting for a CDN, to...
 

2.2. Use bullets to structure your text

Bulleted lists are the “holy grail” of neatly structured, easy to read content.

For, in vain you invest time and effort in providing content that delivers real value to your website's visitors if you display it as an... “impenetrable” block of text.

In this respect, bullets help you break down the information. The result: users will see the key product or service benefits/will go through all of the presented features a lot quicker.
 

2.3. Use white space strategically

Speaking of easy to read content: there's no better way to enhance readability and to draw attention to specific elements on a page than... by using the white space itself.

It will automatically direct their attention to the text/image emphasized by all the white space surrounding it.
 

2.4. UX design is consistent Design

From color palette to button styles, from the size of the headings in your text to the chosen font, from the used photos to various design elements... keep consistency across all the pages on your Drupal website.

Otherwise, you risk to confuse and eventually... tire its visitors.
 

2.5. Go for visible, attractive CTAs

Always use action words for your calls to action and make sure they're easily recognizable. CTAs play a crucial role in setting up an intuitive, efficient navigation structure on your website...
 

2.6. Use images wisely

As images are always well-deserved “breaks” for the eye, especially when it's a long text that it's challenged to go through.

And yet, if you fail in using the relevant images, those that perfectly team up with your text... the user experience that you'll deliver will be anything but compelling...
 

2.7. Make your headings a high priority 

Remember to write your headings around some of the main keywords.

Also, strategically design them so that they're highly visible and help users to quickly scan through the content.
 

2. 4 Features Responsible for the Superior End-User Experience in Drupal 8

Gluing together all the design best practices that make a great user experience does call for a flexible and dynamic web platform.

Drupal 8 is that platform. It comes packed with some powerful features that make it easy for you to create the best visitor experience on your website.

Here are the ones with a huge influence on your website's UX:
 

2.1. Drupal 8 is responsive right out-of-the-box

And responsiveness, along with top page loading speed, still is one of those factors with a great influence on visitors' experience with your Drupal website.

With:
 

  • all the available base themes now being responsive
  • the convenience of adapting your images to various screen sizes right from their display properties
     

… creating a compelling end-user experience in Drupal 8 is dead-simple.


2.2. Enhanced performance

From a performance standpoint, Dries Buytaert's post on Drupal 8's performance optimizations is still one of the most relevant sources.

If Drupal was already built to “inject” enterprise-level performance into static pages, Drupal 8, with all its caching enhancements, is designed to speed up dynamic web pages, as well...


2.3. Multilingual capabilities

Remember the user experience's main facets, ranging from useful to findable, to valuable, to credible to... accessible?

Well, Drupal 8 provides you with multilingual capabilities right out of the box. You get to translate your website's UI, content, configuration, etc.

Meaning that, with this multilingual system at hand, you can easily create an accessible user experience on your website.


2.4. Content personalization (by segment, login time, device, language...)

In this respect, the Aqua Lift Connector module is your most reliable tool.

What it does is bring together customer data and content, so that you can deliver targeted content experiences across multiple channels and devices.
 

The END!

And these are those robust features that stand behind the superior end-user experience in Drupal 8. The very reasons why this platform, and particularly this version of Drupal, makes your best ally in creating the most compelling UX on your website.

Photo by Lucian Novosel on Unsplash

Mar 16 2019
Mar 16

Planning to build a social network with Drupal? A business community maybe? A team or department collaborating on an intranet or portal? Or a network grouping multiple registered users that should be able to create and edit their own content and share their knowledge? What are those key Drupal 8 modules that would help you get started?

That would help you lay the groundwork...

And there are lots of social networking apps in Drupal core and powerful third-party modules that you could leverage, but first you need to set up your essential kit.

To give you a hand with that, we've selected:

5 modules in Drupal 8, plus a Drupal distribution, that you'll need to start a perfectly functional social networking website, with all the must-have content management features and knowledge sharing tools.
 

Before You Get Started: A Few Things to Take Care Of

First of all, let me guess the features on your must-have list:
 

  • articles
  • groups
  • photos
  • user profiles
  • groups
  • forums
     

It should feature pages with dynamic content leveraging a fine-grained access system and social media hubs, right?

Well, now that we've agreed on this, here are the preliminary steps to take before you get actually started, installing your key modules and so on:
 

  • configure your “Taxonomy” categories after you've installed the Forum module
  • set up a custom content type for Blog posts 
  • set up your thumbnail settings for the Article nodes
  • create your key user roles (admin, content author, paid subscriptions)
  • use the PathAuto module to define your URL path structure
  • define your Article nodes' thumbnail settings and remember to upload an anchor image, as well
     

Panels and Views make a “power team” to rely on for setting up pages with dynamic content for your social networking site.

What makes it a must-have module to add to your essential kit when you build a social network with Drupal? 

It enables you to create custom layouts for multiple uses.

You get to use it to set up your website's homepage, one featuring multiple Views blocks with dynamic content retrieved from forums, articles, blogs...

Feel free to add a top slideshow image, to go for multiple-tiled stacked layout, including views from forum, blog and article posts...

In short: the Panels module empowers you to get as creative as possible when setting up fine-tuned layouts for your landing pages displaying dynamic content.
 

Not only that it enables you to present content to your social network's registered users in pretty much any form you might think of — tables, lists, blocks, forum posts, galleries, reports, graphs — but it also:
 

  • enables you to display related content (e.g. display a list of the community members along with their pieces of content)
  • enables you to use contextual filters
     

It'll turn out to be one of the handiest Drupal 8 modules in your toolbox when you need to create and display dynamic content from:
 

  • forums
  • blocks
  • blogs
     

Yet, maybe one of the most common use cases for the Views module on a social networking website is that of:

Setting up a (Views) page listing all the article posts.
 

Another module you'll most certainly want to add to your social networking website as it:
 

  • enables both single and multi-user blogs
  • empowers authorized site members to maintain it
     

Speaking of which, blog entries can be either public or private for a specific user, depending on the role he/she's assigned with.

And it's precisely that system of user roles and corresponding permissions set up on your website that will determine whether a member can:
 

  • access the “Create Content” link or not
  • access a “My Blog” section or... not
     

You can further leverage this Blog module to add a “Recent blog posts” block to your webpages, in addition to the “Blogs” navigation link on your main navigation menu.
 

4. Profile, a Must-Have Module to Build a Social Network with Drupal

You just imagine that you could build a social network with Drupal without a module enabling you to create registration page fields, now can you?

Well, here it is: the Profile module.

And here are its “superpowers”:
 

  • it enables configurable user profiles
  • it enables expanded fields on the user registration page
  • it provides social network members with two different links, one for their account settings, one for their user profiles
  • it provides private profile fields (that only the admin and that specific user can access)
  • it enables you to set up different profile types for different user roles with... different permissions granted 
     

The sky is the limit in terms of what the Group module enables you to do when you build a social network with Drupal:
 

  • it powers pretty much any scenario you can think of, from subgroups to specific per-group behavior, to access permissions...
  • it enables you to put together content collections on your website and grant access to it based on your user roles and permissions policy
  • it enables you to easily add relevant metadata to define the group & content relationships on your site
  • it enables you to control all your settings via a user-friendly admin UI; no need to write custom code to determine what each group is allowed and not allowed to do on your social network
     

I just couldn't help it...

Even though this was supposed to be a roundup of those essential modules you'll need to build a social network with Drupal, I had to add this Drupal distribution, as well.

Open Social is that out-of-the-box solution that you can leverage to get your online user community up and running in no time.

An open source software with all the needed features and functionality already pre-built, so that you can enable members on your network to:
 

  • work together
  • share knowledge
  • organize events
     

Convenience at its best when you want to start a social networking website without worrying much about:
 

  • installing a whole collection of modules
  • doing custom work in the “backstage”. 
     

The END!

This is the minimal kit you'll need to build your online community website with Drupal.

Would you have added other essential modules to the list?

Mar 06 2019
Mar 06

“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 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 handle 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 particular technologies
     

… that will influence your final choice.

Photo by rawpixel on Unsplash

Feb 26 2019
Feb 26

Kind of stuck here? One one hand, you have all these 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 are and will be relevant many years to come and that cover all your feature requirements?

And your list of expectations for 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-CMSs “era”. Then, you would update your HTML pages manually, then 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 modules, content management systems scale 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 are still, 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?

Feb 14 2019
Feb 14

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:
 

  1. connection latency
  2. connection speed
  3. 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:
 

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

Feb 06 2019
Feb 06

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.
 

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?
 

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
Feb 01 2019
Feb 01

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?

Jan 16 2019
Jan 16

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:
 

  1. accessing the Redirect module's configuration page
  2. clicking on “URL redirects” 
     

How to Deal with Duplicate Content in Drupal: Global Redirect features
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?

Dec 10 2018
Dec 10

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:
 

  1. you don't have time to install a caching module
  2. 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? 

Aug 30 2018
Aug 30


We all love Drupal's granular permission and access control system! And yet: its life-saving hierarchy of user roles and permission levels is strictly for creating/editing content. Since Drupal wrongly assumes that all site visitors should be able to visualize all published content, right? But what if this default assumption doesn't suit your specific use case? What if you need to restrict access to content in Drupal 8?

… to limit users' access to certain content on your website? So that not all visitors should be able to see all published nodes.

In this case, Drupal's typical access control system for creating and editing content is not precisely the functionality that you need.

But there's hope!

And it comes in the form of 6 Drupal 8 access control modules that enable you to give content access of different levels, ranging from “average” to “more refined”.
 

But First: An Overview of Drupal's Typical Access Control System 

Now, we can't just jump straight to the “more sophisticated” content access solutions in Drupal 8, not until we've understood how its basic access control system works, right?

As you can see, in the screenshot here below, the logic behind it is pretty straightforward:

Restrict Access to Content in Drupal 8- Typical Access Control in Drupal

  • while in your admin panel, you need to access the People menu > Permissions
  • and there, you just assign different user types (authenticated, admin or anonymous) with specific sets of permissions (to administer blocks, to post/edit comments, to modify menus on your Drupal site etc.)

As you can see, Drupal's typical access control system is not configured so as to enable you to restrict visitors' access to specific content on your website.

Or to limit user access to a more granular level other than the standard “logged in/not logged in user”.
 

If you're not looking for anything “too fancy”, just a straightforward functionality for controlling access to view/edit/delete content entities, then this module's THE one.

And here are 2 of its most common use cases:
 

  • you define some access-restricted premium content areas on your Drupal site, for “privileged” user roles only
  • you grant publish/edit permissions to certain groups on your website, having specific predefined user roles
     

Definitely a go-to module when you need to restrict access to content — to specific content types — in Drupal 8.

It enables you to:
 

  • set up specific access control roles
  • define custom granular restrictions based on different user permissions (you could, for instance, limit access to certain content on your website for non-authenticated users only...)
  • set up content types with restricted access 
     

Note: do bear in mind that, once you've enabled Content Access, you'll need to rebuild your entire “collection” of access content permissions. The module is going to alter the way they work, that's why.

Restrict Access to Content in Drupal 8- Rebuild Permissions when Using Content Access module

Tip: if you need to control access to content nodes on your Drupal 8 site, this module's built to help you “refine” your restriction; for that you'll just need to define some more detailed permissions in People menu >  Permissions tab.
 

A lightweight solution to restrict access to content in Drupal 8. One that enables you to set up access-restricted content sections on your website.

Now, what makes it stand out from the other 5 modules in my list here is:

The refined, taxonomy term-based restrictions that it allows you to create for specific nodes on your Drupal site.

You can limit access to these nodes for:
 

  • specific user roles
  • certain individual user accounts
     

Restrict Access to Content in Drupal 8- Permission by Term module

How do you set everything up?
 

  1. first, you enable the module
  2. then, on the term edit page, you define a specific role access for each taxonomy term 


And there's more to look forward to! 

Unlike Organic Groups and Group, the Permissions by Term module comes with very little overhead, in the form of light contributed code.

In other words: for the taxonomy terms-based access control that it enables you to set up, it adds a new field to your current content types. That's all!
 

When it comes to Drupal role-based access control (to content types or nodes) this module's simple, straightforward approach is exactly what you need.

Not as “sophisticated” as Content Acess, yet conveniently easy to configure and to maintain.

And also, the perfect choice if it's just a basic kind of content type access restriction that you need to set up.

Summing up its functionality now, what you should know is that Node View Permissions enables you to define 2 types of... permissions:
 

  • “View any content”
  • “View own content”
     

… for every content type listed on your Drupal site's Permissions page. 
 

5. Group         

It enables you, as the site admin, to structure content into... groups.

Different group types, with their own hierarchies of group roles:
 

  • anonymous
  • member
  • outsider (a logged in user, but not a group member)
  • other group roles that, as an administrator, you'll need to create
     

Needless to add that with Group you'll restrict access to content in Drupal 8 based precisely on these group roles that you'll set up.

Furthermore, it allows you to define:
 

  • the most suitable permissions (view/edit/delete) for specific content types
  • the most appropriate group roles
     

… per group type. 

And the best is yet to come:

All group types, group roles, group/content relationships are set up as entities. Meaning that they're fully fieldable, exportable, extendable!
 

It's a restricted access to nodes, based on taxonomy terms, users and roles, that you get to define using this module:

A user role-based access control...

Note: mind you don't forget that, in order to restrict access to viewing/editing nodes on your Drupal website, you'll first need to reconfigure the existing user permissions.


The END! 

A bit curious now: which one of these solutions, ranging from straightforwardly simple to most refined, would you go for to restrict access to content in Drupal 8?

Aug 27 2018
Aug 27

You've put so much effort into crafting and polishing the content on your Drupal website and it just won't... rank? Why is it that search engines' web crawlers won't index its “juicy” content? Why they won't give your site a big push right to first-position rankings? As it clearly deserves... Could it be because you're making these 10 Drupal SEO mistakes? 

Knowingly or just recklessly...

And with the first 5 of them already exposed in the first part of this blog post, I'm keeping my promise and here I am now, with 5 more SEO mistakes that you don't want to make on your Drupal website, ranging from:
 

  • embarrassing gaffes
  • to faux pas
  • to catastrophes...
     

1. Underrating Meta Tags: One of (Too) Common, Yet Costly Drupal SEO Mistakes 

And let me just say it: forgetting (or choosing not to) to check those 3 on-page ranking factors:
 

  1. description
  2. page title
  3. tags
     

... is one rookie SEO mistake. 

And one costly neglect, too...

Why? Because by simply checking your meta tags, making sure that the content entered there:
 

  • contains all the relevant keywords
  • is user-friendly and engaging
     

you hit 2 birds with just one stone:
 

  1. search engines' crawlers will just know whether specific web pages on your site are relevant for specific search queries or not; whether the keywords that you will have added to your meta elements are precisely those that online visitors use
  2. users will get a “teaser” of what the page is about, helping them decide whether it matches their searches and expectations or not
     

Note: Drupal's got your back with a dedicated Metatag module that you should install even before you “release your website out into the wild".
 

2. Ignoring the Slow Page Loading Speed 

If it takes more than 2 seconds to load... then you'll lose them. Visitors on your Drupal site will lose all interest in accessing that given page.

And could you blame them? 

Instead, you'd better:
 

  • blame yourself for accepting this status quo and refusing (or just postponing or not putting enough effort into it) to optimize your site for high speed
  • rush to address this major UX issue risking to grow into a critical SEO issue
     

How? By:
 

  • compressing all JS and CSS files using a dedicated tool of your choice (and thank God there are plenty of those to choose from!)
  • compressing all overly large pages
  • reducing images, graphics, and videos to reasonable sizes
  • disabling all those Drupal modules that you haven't used in ages (or maybe never...)
  • enabling caching (and luckily there are Drupal cache modules — like Memcache, for instance — that can help you with that)
  • upgrading your server or even moving to a new hosting company
  • optimizing your site's current theme

See? Improving your Drupal site's load time is no rocket science and it doesn't require overly complex measures, either. They're no more than... “common sense” techniques.

Assess the resources that implementing them would require and... just do it:
 

  • the user experience on your Drupal website will improve significantly
  • search engines will “detect” this increase in user satisfaction
  • … which will translate into a higher ranking 
     

3. Overlooking to Redirect From Its HTTP to Its Secure HTTPs Version

Migrating your Drupal site to HTTPS is a must these days. Just face it and deal with it or... be ready to face the consequences!

Yet, if you overlook to redirect your site to its new HTTPS version, thus sending its visitors out to... nowhere — to error pages — then... it's all but wasted effort and resources.

One of those SEO Drupal mistakes with long-term consequences on your website's ranking.
 

4. Broken Internal Images

Leaving broken internal images and missing ALT attributes behind is a clear sign of SEO sloppiness...

And now, here's what we would call a “broken image”:
 

  • an image that has an invalid file path
  • an image with a misspelled URL
     

The result(s)?
 

  1. first, a broken image has an impact on the overall user experience; your site visitor gets discouraged and quits the page in question
  2. next, search engines rate your site's content as “of poor quality”
  3. and finally, all these lead to an inevitable drop in Google search rankings
     

5. Underestimating (or Just Ignoring) the Importance of an XML Sitemap for SEO

Not generating an XML sitemap of your Drupal site is more than just one of those Drupal SEO mistakes that you should avoid: it's a missed opportunity! A huge one!

Here's why:
 

  • an XML sitemap would include all the URLs on your website
  • … as well as information (via heading tags) about your site's infrastructure of web pages, for search engine crawlers to use
  • … “alerts” about which pages they should be indexing first
  • an XML sitemap provides an early index of your website
  • all the pages on your website get submitted to the search engine database even before they get indexed in their own database
     

Note: the sitemap.xml file not only that communicates with and informs search engines about the current content ecosystem on your Drupal site, but will “keep them posted” on any updates of your site's content, as well.

So, what an XML sitemap provides is a prioritized, conveniently detailed and easily crawlable map of your Drupal website meant to ease web crawlers' indexing job.

And the easier it gets for them to crawl through your site's content, the faster your site's indexing process will be.

In short: if the robots.txt file alerts search engines about those pages that they shouldn't crawl into, the sitemap.xml file lets them know what pages they should index first!

Tip: discouraged by the thought of manually building your site's sitemap? Well, why should you, when there are Drupal modules built especially for this?
 

From taxonomy terms, menu links, nodes, useful entities, to custom links, these modules will automatically generate all the entities that you'd need to include in a detailed sitemap of your Drupal site.

The END! 

Just face it now: you'll inevitably continue to make gaffes influencing your site's SEO, no matter how many precautions you might take...

Yet, these10 Drupal SEO mistakes here, ranked from least to most damaging, are the ones that you should strive to avoid at all costs...

Aug 24 2018
Aug 24

You have made, are currently making and will continue to make various Drupal SEO mistakes. From those easy to overlook gaffes to (truly) dumb neglects, to critical mistakes severely impacting your site's ranking... 

Just face it and... fix it! 

And what better way of becoming aware of their impact on your site than by... getting them exposed, right? By bringing them into the spotlight...

Therefore, here are the 10 SEO mistakes you really don't want to make on your website: the “culprits” for your site's poor ranking.

Take note of them, assess their occurrence/risks for your Drupal site's SEO and strive to avoid them:
 

1. Overlooking or Misusing Header Tags

Do it for the crawlers or do it for your site visitors.

For whichever reason you decide to structure the content on your web pages using H1, H2, H3 tags, Google will take note of your efforts...

And it all comes down to setting up an SEO-valuable hierarchy on each page on your Drupal site. One that:
 

  • crawlers will painlessly scan through, which translates your website getting indexed more quickly
  • users will find conveniently “readable”, which bubbles up to the overall user experience
     

Note: one of the worst SEO gaffes that you could make —  one that would confuse the crawlers and intrigue the site users — would be to use multiple H1 tags on the very same page. 

It's one of those silly, yet harmful rookie Drupal SEO mistakes that you don't want to make!
 

2. Duplicate Content: It's Literally Killing Your SEO

Now, speaking of running the risk to confuse the crawlers in your Drupal site, duplicate content makes the "ultimate source of confusion” for search engines.

And how does this show on your site's SEO? 

Basically, since the crawler can't identify the right page to show for a specific query, it either:
 

  1. "refuses" to rank any of them
  2. or applies specific algorithms to recognize the "suitable" page for that search query
     

Needless to add that the second decision is discouragingly time-consuming, while the first is simply... disastrous for your site's ranking.

"But how did I end up with duplicate content on my website in the first place?" you might ask yourself.

Here are 3 of the most common causes:
 

  • HTTP vs HTTPS 
  • URL variants
  • WWW and non-www pages
     

Now, since an identified and acknowledged mistake is already a half-solved one, here's how you can get it fixed:
 

  • just set up a 301 redirect from that web page's primary URL to the new one
  • set up a rel=canonical attribute on the old URL, one that would let search engines know that they should handle the new URL as a duplicate of the original one
     

Note: It goes without saying that all metric records and all the links that search engines will have monitored on these two duplicate pages will then be automatically attributed to the original URL.
 

3. Optimizing for the Wrong Keywords

And this sure is one of the most frequent Drupal SEO mistakes, that goes back to:

Not investing enough resources (of time mostly) in a proper keyword research strategy.

And no, trying to rank for the prime keywords isn't a foolproof action plan!

The result(s)?
 

  • you end up targeting all the wrong keywords
  • you optimize your site's content for all the wrong terms, that your target audience isn't actually searching for
     

Wasted efforts for putting together non-targeted (or not properly targeted) content...

Instead, invest time in identifying and then ranking for the right search terms.

For yes, it will take longer to carry out a proper keyword process and for your site to start ranking for those keywords. But it won't be wasted time...
 

4. Having Pages with Duplicate Title Tags on Your Drupal Site

Here's another way of confusing crawlers even more:

Faced with two separate web pages having the same <title> tags, search engines won't know which one of them stands for a specific search query.

And their confusion only risks to lead to your Drupal site's getting banned...

Moreover, it's not just search engines that will get discouraged by the duplicate titles, but site visitors, too. They won't know which is the “right” page to access.

“OK, but how can I get it fixed?”
 

  • you install and turn the Metatag module on
  • you craft and give each page on your Drupal site a unique title 
     

5. Ignoring Robots.txt: One of the Common Drupal SEO Mistakes

Now, before answering your otherwise valid question:

“Why do I even need Robots.txt file on my Drupal website?”

… we'd better see what this protocol brings, right?

Take it as a standard that websites use to communicate with crawlers and web robots “in charge” with indexing their content. It's this file that points out what web pages should be crawled and indexed and which ones should be skipped.

Now, if it's a blog that you own, ignoring this protocol isn't one of the biggest Drupal SEO mistakes that you could do. But if it's a larger Drupal site, with a heavy infrastructure of web pages, that you're trying to optimize, then having Robots.txt file makes all the difference...

Tip: do consider installing the Robots.txt module for streamlining the efforts of making your site “crawling-friendly”.

END of Part 1! Stay tuned for I'll be back with 5 more Drupal SEO mistakes — ranking from seemingly harmless to critical — that you definitely don't want to make on your website.

Aug 24 2018
Aug 24

With the Drupalgeddon2 "trauma" still “haunting” us all — both Drupal developers and Drupal end-users — we've convinced ourselves that prevention is, indeed, (way) better than recovery. And, after we've put together, here on this blog, a basic security checklist for Drupal websites and revealed to you the 10 post-hack “emergency” steps to take, we've decided to dig a bit deeper. To answer a legitimate question: “What are some good ways to write secure Drupal code?”

For, in vain you:
 

  • build a “shield” of the best Drupal security modules and plugins around your website
  • enforce a rigid workplace security policy 
     

… if you leave its code vulnerable to various types of cyber attacks, right?

  • But how do I know how unsecured code looks like, to begin with?
  • What are the site configuration gotchas that I should pay attention to?
  • What are the most common vulnerabilities that I risk exposing my Drupal site to?
  • And how can I test it for security issues that might be lurking in its code?

But most of all: What top secure coding practices should I and my Drupal development team follow?

Now, let's get you some answers:
 

1. SQL Injection Vulnerabilities: How You Can Fix & Prevent Them 

SQL injections sure make one of the most “banal”, nonetheless dreadful types of attacks. Once such vulnerabilities are exploited, the attacker gets access to sensitive data on your Drupal site.
 

1.1. Prevent SQL Injection Attacks Using The Database Abstraction Layer

In other words: the proper use of a database layer makes the best shield against any SQL injection exploit attempts.

Now, let's talk... code.

For instance, linking together data right into the SQL queries does not stand for a secure coding practice:

db_query('SELECT foo FROM {table} t WHERE t.name = '. $_GET['user']);

In this case here, this is how you write secure Drupal code:

db_query("SELECT foo FROM {table} t WHERE t.name = :name", [':name' => $_GET['user']]);

Notice the usage of the proper argument substitution with db_query. The database abstraction layer uses a whole range of named placeholders and works on top of the PHP PDO.

Now, as for a scenario requesting a variable number of arguments, you can use either db_select() or an array of arguments:

$users = ['joe', 'poe', $_GET['user']];
db_query("SELECT t.s FROM {table} t WHERE t.field IN (:users)",  [':users' => $users]);
$users = ['joe', 'poe', $_GET['user']];
$result = db_select('table', 't')
  ->fields('t', ['s'])
  ->condition('t.field', $users, 'IN')
  ->execute();

1.2. Have You Detected an SQL Injection Vulnerability? Here's How You Can Fix It

There are some key Drupal security best practices to follow for addressing SQL injection issues:
 

  • always stick to the well-known Drupal database API
  • always filter the parameters that you get (be twice as vigilant and cautious about those who can type anything on your Drupal site)
  • always use placeholders: db_query with :placeholder
  • always check the queries in the code: db_like()
     

Tip: remember to follow these coding practices for addressing and preventing SQL injections on your contrib modules, as well.
 

2. How to Protect Your Drupal Site Against Cross-Site Scripting (XSS) Attacks

We could easily say that XSS attacks “rival” SQL injection attacks in “popularity”:

Drupal's highly vulnerable to cross-site scripting.

All it takes is some wrong settings — input, comment, full HTML — as you configure your website, to make it vulnerable to this type of attacks:

They make a convenient gateway into your website for remote attackers to use to inject HTML or arbitrary web.
 

2.1. Check Functions to Rely on for Sanitizing the User Input (in Drupal 7)

Securing your Drupal 7 site against cross-site scripting attacks always starts with:

Identifying the very “source” of that submitted data/text.

Now, if the “culprit” is a user-submitted piece of content, depending on its type you have several check functions at hand to use for sanitizing it:
 

  • check_url
  • check_plain (for plain text)
  • filter_xss (when dealing with pure HTML)
  • filter_xss_admin (if it's an admin user that entered the “trouble-making” text)
  • check_markup
     

Note: always remember never to enter the user input as-is into HTML!

Tip: a good way to write secure Drupal code is to use t() with % or @ placeholders for putting together translatable, safe strings.
 

2.3. Cross-Site Scripting In Drupal 8: Twig & 3 Useful Sanitization Methods

In Drupal 8, handling cross-site scripting attacks gets significantly easier.

Here's why:
 

  • you have TWIG, with its autoescaping and “sanitize all” HTML mechanism!!!
  • no SQL queries
  • no access to Drupal APIs
     

Now, besides Twig, you have 3 more sanitizing methods at hand for fixing cross-site scripting issues in Drupal 8:
 

  1. HTML: :escape(), for plain text
  2. Xss: :filterAdmin(), for admin-submitted content
  3. Xss: :filter(), where HTML can be used
     

2.4. Testing Your Code Against XSS

In order to check whether certain user inputs are vulnerable, all you need to do is:
 

  • take the “suspicious” user input as a field, as an input HTML
  • enter them both (or just one of them) in your test
     

Note: feel free to user Behat or another framework of choice to automate the whole process.

2 clear signs that you've detected an XSS vulnerability are:
 

  1. you get this pop up alert: <script>altert ('xss') </script>
  2. or this error message close to the IMG tag: img src="https://www.optasy.com/blog/what-are-some-good-ways-write-secure-drupal-..." onerror="alert ('title')"
     

3. Use Twig Templates: They Sanitize All Output...  Automatically 

Did you know that a lot of the Drupal security issues on your website occur precisely because you've skipped sanitizing the user-submitted content before displaying it?

And someone's neglect quickly turns into another one's opportunity...

By skipping to clean up that text beforehand, you lend the attacker a “helping hand” with exploiting your own Drupal site.

Now, getting back to why using Twig templates is one of the best ways to write secure Drupal code:
 

  • they sanitize the user input and output (all HTML, basically) by default; you can write your custom code without worrying about it risking to break up your website
  • you won't run the risk of having safe markup escaped


In short: securing your Drupal 8 website is also about having all HTML outputted from Twig templates.
 

4. How to Write Secure Drupal Code for Finding & Fixing Access Bypass Issues

One of Drupal's strongest “selling points” is precisely its granular permission system. Its whole infrastructure of user roles with different levels of permissions assigned to them.

Furthermore, there are all kinds of access controls that you can “juggle with”:
 

  • Node access system
  • field access
  • Views access control
  • Entity access
     

In short: you're free to empower users to access different sections/carry out different operations on your Drupal site.
 

4.1. How You Can Check for Access Bypass Issues

How do you know whether there are access bypass flaws on your website, that could be easily exploited?

It's easy:
 

  • you simply visit some nid/node and other URL on your site 
  • and just run your Behat automated tests
     

4.2. And How You Can Fix the Identified Access Bypass Issues

Do keep in mind that there are quite a few access callbacks to consider:
 

  • entity_access
  • user_access for  permissions
  • Squery – addTag ('node_access')
  • Menu definitions (make sure you set those correctly)
  • node_access

All you need to do is write automated tests to address any detected problems related to access bypass.
 

5. 3 Ways Deal With Cross-Site Request Forgery (CSRF) in Drupal 

What does it take to write secure Drupal code? 

Writing it... strategically, so that it should prevent any possible cross-site request forgery attack...

Now, here are 3 ways to safeguard it from such exploits:
 

  1. sending and properly validating the token
  2. using Form API
  3. using the built-in csrf_token in Drupal 8
     

In conclusion: a trio of good practices keeps the CSRF attacks away...
 

6. 7 Best Contrib Security Modules to Back Up Your Coding With

Now, after we've gone through some of the best ways to write secure Drupal code, let's see which are the most reliable contrib security modules to strengthen your site's shield with:

  1. Hacked!      
  2. Permission report  
  3. Encrypt      
  4. Composer Security Checker        
  5. Security Review          
  6. Paranoia      
  7. Text Formats Report
     

The END! This is how your solid Drupal security “battle plan” could look like. It includes:
 

  • some of the most frequent types of attacks and security issues to pay attention to
  • most effective preventive measures
  • vulnerability detecting methods
  • post-attack emergency actions and sanitization mechanisms
     

What ways to write secure Drupal code would you have added or removed from this list?

Aug 21 2018
Aug 21

Let me guess: you're a Drupal developer (temporarily) turned into a... Drupal project manager! Or maybe a PM new to Drupal, facing the challenge of your first Drupal project management assignment?

Have I guessed it?

Now the questions roaming in your head right now must be:
 

  • What Drupal project-specific challenges should I expect?
  • How should I address them?
  • How should I approach the Drupal developers, site builders and themers involved?
  • What questions should I ask them at each phase of the project?
  • And which are the stages of a Drupal project management process more precisely?
  • How do I collect accurate and explicit requirements for my Drupal project?
     

“Spoiler alert”: managing a Drupal project the right way isn't so much about using the right project management modules and “heavy-lifting” tools. It's about:
 

  • understanding the specific challenges that Drupal projects pose
  • understanding the specific phases of the process
  • empowering the people in your team to capitalize on their Drupal expertise within the given time frames and according to your client's objectives
     

Now, here's an insight into the process of managing a Drupal project. One shaped as a list of predictable challenges and their most suitable solutions:
 

1. Proper Planning: Get The Whole Team Involved

In other words: defining objectives and setting up a final time frame with the client without getting your team, too, involved in the process is like:

Throwing spaghetti at a wall and hoping that it would just... stick somehow.

They're the Drupal experts, you know...

Therefore, getting the Drupal developers, themers and site builders engaged at this stage of the project is no more than... common sense.

They're the (only) ones able to:
 

  • give you an accurate time estimate for developing and implementing each functionality/feature
  • tell if certain of the requested features can't be delivered
  • identify interdependencies and conditions
  • provide you vital information about the Drupal-specific architecture and the project-specific development process
  • … information on what components to take, whether new contrib modules need to be developed to support certain functionalities etc.
     

Get your Drupal team involved in the planning and preparation process and strike a balance between their valuable input, the client's objectives, and time frames.
 

2. Tempted to... Micromanage? Empower Your Team Instead

Yet, resisting temptation won't be easy. Especially if you're a former Drupal developer now turned into a Drupal project manager.

You'd just die to get your hands dirty with code, wouldn't you? To supervise, closely, how every single line of code is being written.

Refrain yourself from that...

Instead, do keep your focus on the bigger picture! And, moreover, empower each member of your team to... shine. To excel at what he/she's doing. 

That instead of obsessing over details, getting everyone on their nerves and making them doubt their own skills:

By focusing on each one of the small steering wheels, you'd just lose sight of the larger mechanism that's a Drupal project.
 

3. To Tell or Not to Tell: Do Encourage Your Team Members to... Tell

Hiding the dirt under the carpet, from the stakeholders' eyes/ears and having members of your team remain silent over certain bottlenecks in the project will only act as 2 “Trojan horses”.

They'll lead your Drupal project to... failure.

Instead:
 

  • dare be honest with the client and inform him/her if you run the risk of a delay 
  • encourage your team to be open with you and with their teammates when they hit sudden challenges, unexpected issues
     

By:
 

  • hiding
  • ignoring
  • “genuinely” underrating
     

... issues detected in the development process — instead of getting them “exposed” and dealt with —  you're only sabotaging the Drupal project.

And now speaking of encouraging good communication within your team, how about creating a dedicated open forum for them to use? This could be the “place” where they'd share any issues that they will have detected in the project.

Or challenges that they face and can't address by themselves.
 

4. Juggling with Resources, Timeline, and Unforeseen Events

I'm not going to lie to you about this one: keeping the balance between staying flexible and being capable to assess risks is not going to be easy...

Unplanned issues will strike, new requirements will come to “jeopardize” this balance, unexpected changes will need to be accommodated under the same time frame...

Should you keep yourself rigid and inflexible to all changes, sticking to the initial plan?

Or should you “assimilate” all the incoming requirements and additions to scope with the risk of a project delay?

And that of overburdening your team with unscheduled tasks...

Can't help you with a universal answer here, one that would apply to all Drupal project management scenarios. It's you, together with your Drupal team, who should be able to estimate:
 

  • the changes' level of complexity
  • the project delay (if it's the case)
  • the chances for these additional tweaks to turn into contractual changes
     

5. Drupal Project Management Is 90% Good Time Management

And it all comes down to:

Breaking your Drupal project down into small, manageable tasks. 

Tasks that can be easily turned into goals and objectives:
 

  • daily objectives
  • weekly objectives
  • and so on...
     

Efficient Drupal project management, even if we're talking about truly complex ones, is all about making it... manageable.

About ensuring that the lists of tasks are logically structured and (most of all) time framed!

Needless to add that this strategy acts as a motivation-booster for your team: 

Just think about it: with every ticked off task, each team member can visualize the project's progress in... real-time. A progress that he/she, too, will have contributed to.

The END! These are the Drupal project-specific challenges that any project manager dealing with this CMS faces, accompanied by their life (reputation)-saving solutions.
 

Jul 20 2018
Jul 20

So, you've installed your version of Drupal and you're now ready to actually start building your website. What essential tools should you keep close at hand, as a site builder? Which are those both flexible and powerful must-have modules to start building your Drupal site from scratch?

The ones guaranteeing you a website that:
 

  1. integrates easily with all the most popular third-party services and apps
  2. is interactive and visually-appealing, irrespective of the user's device
  3. is a safe place for users to hang on, interact with, shop on, network on...
  4. is conveniently easy for content managers and admins to handle
     

Luckily, there are plenty of modules, themes and plugins to overload your toolbox with:

Long gone are the code-centric webmaster's “glory days”! Nowadays, as a Drupal site builder, you have a whole array of tools at your disposal to just start building and getting a Drupal site up and running in no time.

Sometimes without the need to write a single line of code!

But, let's not beat around the bush any longer and have a close look at these 10 essential modules that you'll need for your “Drupal 8 site building” project:
 

Definitely a must-have module:

Just consider that Drupal accepts ANY user password, be it a... one-letter password!

So, in order to set up your own stricter and safer password policy, you need to install this module here.

Then, you can easily define:
 

  • the minimal (and maximal) no. of characters that any user password on your Drupal site should include
  • the no. of special characters that it has to include
  • specific restrictions Like: "one can't use his/her email address as his/her password"
     

Why should this module, too, be in your essential toolkit of modules to start building your Drupal site with?

Because it implements the functionality to get notified — you, the admin or content manager —  as soon as a user posts a comment on the website.

Note: you can get “alerts” about both the logged in and the anonymous visitors' comments.
 

3. Breakpoints, One of the Must-Have Modules to Start Building Your Drupal Site 

It goes without saying that one of the Drupal site building best practices is providing it with a responsive web design.

And this is precisely what this module here facilitates:

Setting the proper media queries, once you've defined your own breakpoints.
 

A module whose functionality bubbles up to the content manager's experience.

Whenever he/she will have to make a selection involving both categories and subcategories, this hierarchical type of selection will prove to be more than useful:

Practically, once you/they select the “main” option, a new drop-down menu/widget including the subcategories to select from, pops up, as well. Like in the image here below:

Essential Modules to Start Building Your Drupal Site With: Simple Hierarchical Select

And complying with this EU notification is mandatory. 

So, this is why EU Cookie Compliance is another one of the essential modules to start building your Drupal site with:

It displays the given notification — providing visitors with the option to agree or/and to read more information about your cookie policy —  in the footer of your website.
 

6. Shield              

Any Drupal site building guide would advise you to install a module that shields your website from anonymous users and search engines when running your test environments.

And this is what Shield is built for:

To screen your site from the rest of the world —  except for you and the logged in users — when you deploy it in a test environment.

A more than convenient method, as compared to manually setting up a .htpasswd and then integrating it with .htaccess.
 

If you're not just another Drupal site builder, but a user experience-centric one, you must consider also those modules to build your Drupal site with that boost the level of user interactivity.

Like Beauty Tips here.

It displays balloon-help style tooltips whenever a user hovers over a certain text or page element on your website.

Pretty much like Bootstrap tooltip does.
 

Another one of the Drupal site building best practices is to turn it into a safe place for your users to be. 

In short: to protect their privacy.

And if you're building a website that's available on both HTTP and HTTPS, the Secure Login module comes in handy as it makes sure that:
 

  1. the user login form
  2. all the other fill-in forms that you'll configure for extra security
     

… get submitted via HTTPS.

It locks them down, enforcing secure authenticated session cookies, so that user passwords and other critical user data don't get exposed all over the internet.
 

It's another one of those essential modules to start building your Drupal site with if you're determined to provide the best user experience there.

What does it do?

It enables particular visitors on your site — those granted permission to edit and to add new menu items — to choose whether they open menu items in new windows or in the current ones.
 

A module that makes up for the “Remember me” feature that's missing from the user login screen in Drupal:

It comes to implement this missing option, one independent from the PHP session settings.

So, we're not talking about the conventional, too long “PHP session time” here, but about a more secure and user-friendly “Remember me” feature added to the login form.

Furthermore, the module enables you to define some extra security policies, too:
 

  • the no. of persistent sessions that a Drupal user can enjoy at the same time
  • specific pages where users still have to log in again
  • after how long the logged-in users will need to re-enter their credentials once again
     

And 2 “Extra” Modules to Consider When Building Your Drupal Site

By “extra” I mean that they're not really essential modules to start building your Drupal site with. Yet, they're the first 2 ones to consider right after you've put together your “survival” toolkit as a site builder:
 

1. Site Settings & Labels    

Take this common scenario:

You need to display a social network URL on multiples pages on your Drupal site. 

What do you do?
 

  1. you hard coding this single setting in the source
  2. you start building a custom Drupal module for handling this variable
  3. you install the Site Settings & Labels module and thus display a checkbox to render page elements through a template conditional
     

The “c” variant's undoubtedly the winner here. 

A win-win for you, in fact:
 

  1. you save the time you'd otherwise have spent coding
  2. you improve the user experience on your Drupal site
     

2. Slick/Slick Views/Slick Media          

It's actually a suite of modules to start building your Drupal site with. One “injecting” the needed functionality so that you can easily set up:
 

  • carousels
  • slideshows
     

… on your freshly built website.

Note!

I won't lie to you: setting up the library dependencies is not exactly a child's play. Yet, once you've succeeded it, configuring the modules in this suite, right in your Drupal admin, is piece of cake.

The END! These are the 10 must-have modules to start building your Drupal site from scratch with. Would you have added some more? 

Or maybe you wouldn't have included some of the modules listed here, as you don't consider them “essential”?

A penny for your thoughts!

Jul 18 2018
Jul 18

Let's say that it's a WhatsApp-like, a decoupled, Drupal 8-backed, real-time chat platform that you're building. One using Node.js. In this case, implementing field autocomplete functionality becomes a must, doesn't it? But how do you add autocomplete to text fields in Drupal 8?

Needless to add that such otherwise "basic" functionality — implemented on fields like node reference and user/tags — would instantly:
 

  1. improve the user experience 
  2. increase the level of user interactivity and engagement
     

Users would group around different "channels" and be able to easily add new members. The auto-complete text fields will make the whole “new member coopting” process conveniently easy:

Users would only need to start typing and an array of name suggestions (of the already existing team members) would spring up.

But let's see, specifically, what are the steps to take to implement autocomplete functionality in Drupal 8:
 

1. The Drupal Autocomplete Form Element: Adding Properties to the Text Field

The first basic step to take is to define your form element. The one that will enable your app's users, on the front-end, to select from the suggested team members' names. For this:
 

  1. navigate to “Form” (you'll find it under “Entity”)
  2. scroll the menu down to ”NewChannelForm.php”
     

Note: using “#autocomplete_route_name element”, when defining your form element, will let Drupal know that it should ignore it on the front-end.

And now, let's go ahead and assign specific properties to your form's text field! For this:
 

  1. define “#autocomplete_route_name”, so that the autocomplete JavaScript library uses the route name of callback URL
  2. define “#autocomplete_route_parameters”, so that an array of arguments gets passed to autocomplete handler
     
$form['name'] = array(
    '#type' => 'textfield',
    '#autocomplete_route_name' => 'my_module.autocomplete',
    '#autocomplete_route_parameters' => array('field_name' => 'name', 'count' => 5),
);


And this is how you add #autocomplete callback to your fill-in form's text field in Drupal 8!

Note: in certain cases — where you have additional data or different response in JSON —  the core-provided routes might just not be enough. Then, you'll need to write an autocomplete callback using the “my_module. autocomplete“ route and the proper arguments (“name” for the field name and “5” as count, let's say).

And here's specifically how you write a custom route:
 

2. Add Autocomplete to Text Fields in Drupal 8: Define a Custom Route

How? By simply adding the reference to the route — where data will get retrieved from — to your “my_module.routing.yml file”:
 

my_module.autocomplete: path: '/my-module-autocomplete/{field_name}/{count}' defaults: _controller: '\Drupal\my_module\Controller\AutocompleteController::handleAutocomplete' _format: json requirements: _access: 'TRUE' 


Note: remember to use the same names in the curly braces (those that you inserted when you defined your “autocomplete_route_parameters”) when you pass parameters to the controller!
 

3. Add Controller with Custom Query Parameters

In the custom route that you will have defined, you'll have a custom controller AutocompleteController, with the handleAutocomplete method.

Well, it's precisely this method that makes sure that the proper data gets collected and properly formatted once served.

But let's delve deeper into details and see how precisely we can generate the specific JSON response for our text field element.

For this, we'll need to:
 

  • set up a AutoCompleteController class file under “my_module>src>Controller > AutocompleteController.php"
     
  • then, extend the ControllerBase class and set up our handle method (the one “responsible” for displaying the proper results)
     
  • it's the Request object and those arguments already defined in your routing.yml.file (“name” for the field name and “5” for the count, remember?) that will pass for your handler's parameters
     
  • the Request object will be the one returning the typed string from URL, whereas the “field_name” and the “count” route parameters will be the ones providing the results array.
     

Note: once you get to this step here, as you add autocomplete to text fields in Drupal 8, remember that you should be having data in “value” and “label” key-value, as well:

Next, you'll set up a new JsonResponse object and pass $results, thus generating a return JsonResponse.
 

Summing Up

That's pretty much all the “hocus pocus” that you need to do to add autocomplete to text fields in Drupal 8. Now the proper data results should be generated.

Just reload your app's form page and run a quick test:

Try to create a brand new channel in your app and to add some of the already existing team members.

Does the text field have autocomplete functionality added to?

Jul 04 2018
Jul 04

I'm a woman of my word, as you can see: here I am now, as promised in my previous post on the most effective ways to secure a Drupal website, ready to run a “magnifying glass” over the best Drupal security modules. To pinpoint their main characteristics and most powerful features and thus to reveal why they've made it to this list.

And why you should put them at the top of your own Drupal security checklist.

So, shall we dig in?
 

It's only but predictable that since the login page/form is the entry to your Drupal site, it is also the most vulnerable page there, as well.

Therefore, secure it!

In this respect, what this module enables site admins to do is :

  • define a certain number of login attempts; too many invalid authentication attempts will automatically block that account
  • block/limit access for specific IPs
     

Moreover, you get notified by email or via Nagios notifications when someone is just username/password guessing or using other kinds of brute force techniques to log into your Drupal site.

In short: the Login Security module, through its variety of options that it “spoils” you with, empowers you to set up a custom login policy on your site. To define your own restrictions and exceptions.

As already mentioned here, on this blog, when we've tackled the topic of Drupal security:

Keeping your Drupal core updated is that easily underrated, yet most powerful security measure that you could implement!

Now what this module here does is assisting you in keeping your Drupal codebase up to date: safely patched and having all the crucial upgrades.

And I don't need to remind you the security risk(s) that all those site owners ignoring the latest patches to Drupal core expose their websites to, right? 
 

Captcha is one of the best Drupal security modules since it's one of the most used ones.

And no wonder: could you imagine submission forms on your website with no Captcha? The age-old system is one of the handiest ways to keep spammers and spambots away.

So, having this module “plugged in”, providing you with the needed captcha support, becomes wisely convenient.
 

The module enables you, as your Drupal site's admin, to define specific rules for “wannabe users” to follow when they set up their account passwords.

From constraints related to:
 

  • special symbols that those passwords should include, to ramp up both the given account's and your own site's security
  • to uppercase letters
  • to numbers...
     

… once you plug in this Drupal security module in, it's you who gets to set up the policy for creating account passwords.
 

5. Security Review, One of the Best Drupal Security Modules

The Security Review module is that “Swiss knife” that you need for hardening your site's shield.

Meaning that it's an all-in-one tool. One that comes with its own Drupal security checklist that it regularly goes through and sets against your website, detecting any missing or improperly implemented security measures.

Moreover, it automates a whole series of tests for tracking down any signs of exploits and brute-force attacks:
 

  • arbitrary PHP execution
  • XSS exploits
  • SQL injection
  • suspicious PHP or JavaScript activity in content nodes
     

Once it identifies the vulnerabilities, it “alerts” you and gives you the best recommendations for mitigating those security risks. All you need to do is follow the suggestions.
 

Another module that “empowers” you to take full control over the security strategy on your Drupal site. To set up specific options for minimizing the chances of exploitable “cracks” showing up in its security shield:

For instance, it could recommend you to set up HTTP headers on your Drupal site.
 

Here's another one of those best Drupal security modules that's also one of the widely used ones.

Why is it a must-have on your own Drupal site? Because it enables you to set a limit to the number of simultaneous sessions per user, per role.

This way, you trim down the chances of suspicious activity being carried out on your site and eventually leading to brute-force attacks.
 

Another module that's a must on your Drupal site:

It basically enables you, the site admin, to define a policy that would log out users after a specified time period of inactivity. 
 

LinkedIn, Google, Twitter, Instagram, Facebook are just some of the big names that have adopted this user authentication method for security reasons. So, why shouldn't you, too?

Especially when you have a dedicated module at hand, Two Factor Authentication, to:
 

  • provide you with various methods to select from: pre-generated codes, time-based one-time PINS or passwords, codes sent via SMS etc.
  • give you full freedom in defining that two-factor authentication strategy that suits your site best
     

The principle is as simple for the user, as it is effective for your website, from a security standpoint:

The user gets a security code that he/she'll then need to use for logging into your Drupal site.
 

A command-line tool, with IDE support, that gives your codebase a deep scan and detects any drift from the coding standards and best practices.

Why has it made it to this exclusive list of 15 best Drupal security modules? Cause vulnerabilities might be lurking right in your Drupal code, not necessarily in your users' weak passwords or unpatched core modules.

Having a tool at hand that would identify and notify you of all those weak links in your code, where the best practices aren't being followed, is just... convenience at its best.
 

Another key module to add to your Drupal security checklist. 

For you do agree that email addresses are some of hackers' easiest ways to infiltrate into your website, don't you? 

Now what this module here does is obfuscate email addresses so that spambots can't collect them.

Note: a key strength of SpamSpan is that it uses JavaScript for this process, which enhances accessibility.
 

12. ACL      

“A set of APIs” This is how we could define this module here, which doesn't come with its own UI.

Its key role? To enable other Drupal modules on your website to set up a list of users that would get selective access to specific nodes on your site.
 

Why is Paranoia one of the best Drupal security modules?

Because it will end your “paranoia” — as its name suggests — that an ill-intentioned user might evaluate arbitrary code on your site.

The module practically identifies all those vulnerable areas where a potential attacker could exploit your site's code and blocks them.
 

Limiting or blocking access to key content types on your site is no more than a common-sense security measure to take, don't you agree?

Therefore, this module here's designed to assist you throughout this process:
 

  • as you define detailed permissions on your site: to view/edit/ delete specific content types
  • … by user role and by author 
     

Word of caution: do keep in mind that, since Content Access uses Drupal's node API, you shouldn't enable other modules using the same endpoints on your website!
 

A module that ramps up not just your site's security, but also its accessibility.

Just think about it:

Nowadays anyone has at least one Google account. Therefore, “anyone” can easily log into your website using his/her own Google account credentials.

Once, of course, you will have installed and turned this Drupal module on.

END of list! These are the 15 best Drupal security modules worth installing on your site. 

Scan them through, weigh their key features, set them against your site's specific security needs and make your selection!

Jun 28 2018
Jun 28

You have patched your Drupal website, haven't you? If so, then that critical 3-month-old security flaw, Drupalgeddon2, can't get exploited on your site. Even so, with the menace of a cryptocurrency mining attack still lurking around the unpatched websites, you legitimately ask yourself: what are some quick and easy ways to secure Drupal?

“Which are the most basic steps to take and the simplest best practices to adopt to harden my Drupal site's security myself?”

Now, using keywords such as “security measures”, “quick”, “easy” and “handy”, I've come up with a list of 7 basic steps that any Drupal site owner can (and should) take for locking down his/her website.

Here they are, in no particular order:
 

1. Keep Your Drupal Core and Modules Updated 

Not only is this one of the simplest ways to secure Drupal, but one of the most effective ones, as well.

Even so more now, with the Drupalgeddon2 Drupal security threat still fresh in our memory, ignoring the regularly released security updates for both Drupal core and its modules is just plain recklessness or... self-sabotage.

Keep your Drupal version updated: apply security patches as soon as they get released, avoiding to leave your site exposed and exploitable. As simple as that!

And where do you add that this is one of those Drupal security best practices that's the easiest to integrate into your routine. Since to run the latest updates you only need to:
 

  • sign in to your Admin panel
  • go to “Manage” 
  • scroll down to “Reports” → “Available Reports”
  • click on “Check manually”
  • if there are any critical security updates that you're advised to run, just click “Update”
     

This is all it takes for you to:

  1. seal any security loopholes in your Drupal core
  2. prevent any identified vulnerability from growing into a conveniently easy to access backdoor for hackers to get in
     

2. Install Drupal Security Modules 

Strengthening the shield around your Drupal site with some powerful Drupal security modules is another both handy and effective measure that you, yourself, can easily implement.

Luckily, you're definitely not out of options when it comes to good security modules in Drupal.

And I'm only going to run a short module inventory here, since I'm already preparing a blog post focused precisely on this topic. Therefore, I promise to delve deep into details about each one of the here-listed modules in my next post:
 

Downloading, installing security modules on your Drupal site is both:
 

  • quick and simple to do
  • highly effective 
     

And they serve a wide range of purposes, from:
 

  • enforcing strong password policies
  • to monitoring DNS changes
  • to locking down your site from security threats
  • to blocking malicious networks
  • to turning on a firewall on your site
     

As for their selection, it depends greatly on your list of priorities when it comes to improving your site's security. Take some time to weigh and to compare their features.
 

3. Remove Unused Modules: One of the Easiest Ways to Secure Drupal 

Being the “easiest” security measure to implement doesn't make it also “the most popular” among Drupal site owners.

Owners who more often than not:
 

  • underrate the importance of running a regular module usage audit on their sites
  • ignore the Drupal security threat that an outdated piece of code (or an unused module) could turn itself into, once exploited by an attacker
     

So, don't be one of those site owners! Are there modules on your site that you no longer use? 

That have grown outdated and that are just... lingering there, using your site's resources and risking to grow into an exploitable backdoor for hackers?

Identify them and remove them! It won't take more than just a few priceless minutes of your time.
 

4. Enforce a Strong Password Policy

Since it's not just the admin (you do have a smart username and password for logging into your admin dashboard, don't you?) that will log into your Drupal site, but users, too, implementing some strong user-side security measures is a must.

In this respect, creating a strong password policy — one that would enforce the creation of complex, “hard-nut-to-crack” type of login credentials — is one the best and the easiest ways to secure Drupal on the user's side.

Come up with a policy that defines specific requirements for setting up passwords of high enough entropy (letters, uppercase/lowercase, symbols, different characters combos).

And don't hesitate to rely on dedicated Drupal modules for enforcing those requirements defined in your policy:
 

5. Block Access to All Your Sensitive Files

I bet you don't want important folders, core files — upgrade.php., install.php, authorize.php, cron.php —  to be easily accessible to just... anyone, right?

So, how about limiting or blocking access to them?

And you can easily do that by configuring your .htaccess file —  it's the one containing details of crucial importance regarding your website access and credentials to specific parts and core files on your site:

Just specify the IP addresses allowed to access those core folders, files and subdomains.

Here's one “enlightening” example:

<FilesMatch "(authorize|cron|install|upgrade)\.php">
Order deny, allow
deny from all
Allow from 127.0.0.1
</FilesMatch>


Note!

Now speaking of limiting access, don't limit your restrictions to your core folders and files. Remember to restrict/block access to your web server, to your server login details, as well.

How? By adding a basic layer of authentication limiting server access and file access usage.

Also, do remember to cautiously manage access to certain port numbers that your site/app might be using.
 

6. Back Up, Back Up, then... Back Up Some More 

You can't anticipate brute-force attacks, but you sure can “land back on your feet” if the worst scenario ever happens.

And you can only do that if you have a clean and recent backup at hand to just rollback and restore your website.

In other words: back up regularly! 

And remember to always back up your files and MySQL database before any update that you run on your Drupal code and modules. It is one of those common sense Drupal security best practices that should be included in any basic security checklist!

Where do you add that you even have a dedicated Drupal module —  Backup and Migrate — to assist you with this process.

Some of the back up “burdens” that this module will take off your shoulders are:
 

  • backing up/restoring code and multiple MySQL databases
  • integrating Drush 
  • backing up files directory
  • setting up several backup schedules
  • AES encryption for backups


7. Review All User Roles and Grant the Minimum Permissions Necessary

How many user roles are there assigned on your Drupal site?

If you don't quite know the answer, then it's obvious:

You must give your entire user role system an audit!

And to stick to this habit, one of the simplest ways to secure Drupal, after all.

Review all the user roles and, most of all, review each one's set of permissions and make sure you trim them down to the minimum necessary for each role. 

This way, you'll also limit access to critical files for those users that shouldn't have the permission to download or visualize them.

And speaking of permission, do keep in mind to review all your file permissions, as well!

See which user roles are granted permission to access key directories or to read, write or modify certain files on your website and block/restrict access where necessary.

The END! Of course, this isn't even close to a complete list of ways to secure Drupal. If it had been an exhaustive one, it would have continued with more Drupal security best practices, such as:
 

  • getting the SSL Certificate
  • securing HTTP headers
  • using secure connections only
     

Etc. etc. I've only focused on some of the easiest and quickest measures that anyone, with little, close to no technical know-how at all, can implement. And I feel like stressing out the term “practice” here:

Securing your Drupal site is a constant process; a series of persistent efforts and not a one time thing. Remain vigillant and cautious and don't rely on just a one-time, multifaceted security hardening “marathon”.
 

Jun 25 2018
Jun 25

Oops! The worst has happened: your Drupal site has been hacked! Maybe it was precisely one of those critical vulnerabilities, that the Drupal security team has been drawing attention to these last months, that the attacker(s) exploited? 

Now what? What to do?

Should you be:
 

  1. rushing to restore your website to a healthy, good-working state (that, of course, if you do have a clean and recent backup available)?
  2. starting to rebuild it?
  3. investigating how your Drupal site got contaminated in the first place: where's the “open door” that the attackers used to get in?
  4. focusing on closing any backdoors that could make new attacks possible?
     

Now “tormenting” yourself with too many questions simultaneously will only distract you from what should be your main objective: cleaning up your website (and preventing further hacks I should add).

So, let's go about it methodically, step by step:
 

Step 1: Write Down Issues, Steps to Take, Preventive Measures to Apply

Keep your cool and go for a methodical approach to crisis management:

Just open up a document and start... documenting:
 

  • the issues and any suspicious activity that you identify on your site
  • all the steps that your strategy for removing malware and restoring your site should include
  • the preventive security measures you commit to taking for preventing such a scenario from happening again the future
     

Step 2: Make a Forensic Copy of Your Drupal Site 

Before you start running your “investigations” on the attack, on how your Drupal site has been hacked, and way before you get to rebuild anything:

Make a forensic copy of all your files, you database and your operating system environment!

Note: go with an external storage medium for these copies and store them offsite.

As you're scanning through your files, detecting viruses and malware and having them cleaned up, feel free to make new and new “working backups”. And to store them in a different directory (from your regular backup files, I mean).

“But why bother? When will these backups turn out particularly useful?”
 

  1. when you call out to a third party to assist you with the troubleshooting process; these “working” backups will then provide a clear picture of the site before you started “malware detecting” on your own
  2. when you try to fix the issues you detect, but instead you make them worse; then, you can easily roll back those changes 
     

Step 3: Scan Your Servers and PC for Malware, Malicious Code Injections, Viruses

Before you rush to change all the passwords on your site, pause for a moment to think through your next “move”:

What if the attack has been “programmed” so that the attacker should get notified once you change your password(s)? And what if it's precisely your PC or one of your servers that's got infected? Then storing a clean backup of your site precisely there would only make it even more vulnerable.

So, how do you prevent that? You give both your PC and your servers a deep scan before making any change.

And, thank God, you sure aren't nickel and dimed in anti-malware tools and anti-virus software: AVG, BitDefender, Malwarebytes, ESET, AV-Comparatives etc.
 

Step 4: Detect & Remove the Backdoors

One of the crucial steps to take, once you realize that your Drupal site has been hacked, is to “close” all the backdoors.

These could easily turn into hackers' access ticket into your site even after you've removed malware and restored it to its healthy state. But, for closing them you first need to... find them right?

So, where to look?

Here are a few key places on your site that you should focus your “searches” on:
 

  • access logs: while scanning them, be vigilant and look for PHP scrips and POST requests added to directories that have writable access
     
  • eCommerce set up: check all the payment methods, shipping addresses, credit card addresses, linked accounts, looking for any suspicious, newly added data
     
  • passwords: FTP passwords, admin passwords, control panel passwords
     
  • email rules and filters: check that the answers to the security questions are “legitimate”, that messages are being forwarded to correct email addresses etc.
     

Step 5: Consider Taking Your Site Offline

And your decision depends greatly on the nature of your site:

If it's a hacked eCommerce Drupal site that we're talking about here, then don't wait even one more minute: take your site down (along with the internal network and servers) and install a placeholder!

This way, you'll prevent:
 

  • malware from being further distributed
  • spam from being sent to your online store's customers
     

Note: do keep in mind that taking your site offline will instantly let the attackers know that you've detected the malware that they've “infiltrated” and that you are about to “take action”.

If you decide not to take your Drupal site offline at the web server level, ensure that you've got your clean forensic copy at hand before deleting all the sessions.

Note: have you detected suspicious changes of the passwords? If so, use this query here for updating them (Drupal 7):
 

update users set pass = concat('ZZZ', sha(concat(pass, md5(rand()))))

As for the users, they can easily use the reset password tool for updating their passwords.

Word of caution: mind you don't take "Drupal on maintenance mode” for “offline Drupal". They're 2 completely different things! Once your Drupal site has been hacked, the malware could be of such nature that it allows the attacker to infiltrate as long as the site's online.
 

Step 6: Notify Your Hosting Provider That Your Drupal Site Has Been Hacked 

They should be informed about the breach and about your site being taken offline (if it's the case) immediately.

The sooner the better, this way they can:
 

  • start scanning their own systems for incursions
  • get ready to assist you with your site recovery and securing process
     

Step 7: Handle Client Data with Extra Precaution 

And these are the specific scenarios where you'll need to take extra precautions when handling client information:
 

  1. your Drupal site stores client information on the web host
  2. … it leverages the data POST method for sending form data via e-mail
  3. … it doesn't integrate with a 3rd party payment gateway, but manages the payment processes itself
     

If one of these 3 scenarios suits your case, then here are some of these extra precautions that you need to make to ensure the private user data doesn't get exposed:
 

  • update your SSL certificate
  • re-check all logfiles (have any of the hosted client information been copied, updated or downloaded?)
  • implement AVS (address verification system) 
  • add CVV (card verification value)
  • encrypt connections to back-end services used for sending confidential user data 
     

Step 8: Investigate the Attack: Identify the Source(s) of Infection

No matter how much pressure you might find yourself under to get your site back online ASAP, don't let take control over your site's restoring process!

Not until you've detected the main source of contamination on your site. The key vulnerability that attackers exploited, the key reason why your Drupal site has been hacked in the first place.

That being said, make sure that:
 

  1. you first audit, on a staging server, that “clean” backup of your site that you're planning to get online; this way, you track down and remove infected files, unauthorized settings, malicious code 
  2. you compare pre- and post-hack files, looking for any suspicious changes
     

Now if you have a clean (and recent) backup at hand for running this comparison, the problem's almost solved. Just use the right tools to compare your files and track down discrepancies.

But if you don't have a backup at hand, then there's no other way but to:

Manually inspect your files and databases to identify any suspicious changes that have been made.

  • look for any suspicious iframe or JavaScript at the end of the files (if detected, save the code in an external file)
  • look for any sources of “Drupal site hacked redirect”; for links to external URLs
     

Now, as for the places that you should be running your investigations on, let me give you just a few clues:
 

  • .php files, .html files 
  • sessions table 
  • newly modified/created files
  • new/updated user accounts 
  • in writable directories and database 
     

Step 9: Do a Full Restore of Your Site 

So, you've noticed that your Drupal site has been hacked, you've assessed all the damage caused, removed malware and even detected the vulnerability that hackers exploited to get in, not it's only but logical to:

Try to repair your website, right?

Word of caution: never ever run your changes on your production site; instead, fix all detected issues on a staging site. Also, once you've cleaned it all up, remember to run the latest Drupal security updates, as well!

Now, getting back to repairing your site, you have 2 options at hand:
 

  1. you either restore a clean backup, if you know the date and time that your Drupal site has been hacked and you're also 100% sure that none of the system components, other than Drupal, got contaminated
  2. or you rebuild your Drupal site 
     

The latter method is, undoubtedly more cumbersome, yet a lot more cautious. Go for it if:
 

  • you do not know the precise date and time when your site's got contaminated
  • you do not have a clean (and recent) backup available to restore
  • you've evaluated the damages as being already too widespread  
     

Step 10: Give Your Restored Site a Full Check Before Going Live 

Do remember to give your newly recovered site a final audit before getting it back up:
 

  • remove all malicious code detected
  • suspicious files
  • unauthorized settings
     

And, most of all:

Close all the backdoors!
 

Final Word 

A pretty long, complex and discouragingly tedious recovery process, don't you think? 

So, why wouldn't you avoid all these steps that you need to go through once your Drupal site has been hacked?

Why not avoid the risk of finding yourself forced to take your website offsite for... God knows how long, risking to impact your site's reputation and to drive away users/online customers?

Don't you find it wiser to:
 

  • be prepared instead?
  • opt for ongoing Drupal maintenance and support services?
  • make a habit of regularly backing up your website?
  • keep your system and software up to date (and to install all the recommended patches)?
  • stop underrating the security advisories that the Drupal team makes?
     
Jun 11 2018
Jun 11

There's no way around it, not anymore: with Google's index now mobile-first, adopting a mobile-first approach when building a new Drupal site (or redesigning a legacy one) is… a must! It no longer depends on a specific project's needs or on the used technology. The need to develop a mobile-first content strategy has gone from particular to universal.

And facing the challenge of:
 

  1. (re)creating
  2. optimizing
  3. structuring
     

… content on your Drupal website means conforming to those specific patterns that mobile users have developed for reading content on their smartphones.

In short: developing a fully responsive Drupal site comes down to centering your mobile content strategy around the idea that:

It's for the smallest screen sizes that you should plan your content for, first things first … then scale it up from there.

Now, let's see precisely what it takes to develop a mobile-first content strategy. What focus points and must-have components to include:
 

1. Take the Smallest Screen Size as the Starting Point

In other words: think mobile-first!

And by “mobile” I do mean “smartphones” — the smaller the screen size, the better. 

This way, you'll be adjusting your content so that it makes the most of the smallest interface. Starting “small” is the best way to stick to the “keep it simple” approach:

Thinking through every content-related decision in the light of the viewport size challenge will constrain you to keep the truly essential content elements only.

Hence, this “spartan” way of eliminating the unnecessary will reflect on your site's desktop design, as well: 

It will turn out cleaner and lighter.
 

2. Use Visual Content Wisely: Weigh Your Choices of Images 

The golden rule when it comes to the imagery that you'll use on your responsive website is:

If an image doesn't enhance and complement your content, then you're better off without it!

And I know what you must be thinking:

“But people remember what they see far more easily than what they read.”

True, you need to keep in mind that visuals do come at a cost, though:

Those stunning, visually-arresting images on your website risk to divert your users' attention from the message itself.

And still, probably the most heavy-weighing reason why you should use images wisely when you develop a mobile-first content strategy is: weigh.

Visuals risk to take up valuable screen space and thus:
 

  • outshine your calls to action themselves
  • impact your site's overall performance (leading to frustration)
     

Now that doesn't mean that you should strip your content off ALL the visuals! Absolutely not!

Just to be cautious and weigh your every choice, think through your every decision involving the usage of an image. 

Once you've selected the truly essential ones, keep in mind:
 

  1. not to no resize them (or optimize them in any other way) before uploading them to your CMS: let Drupal do the heavy-lifting here 
  2. to leverage the Responsive Image module's (Drupal 8) capabilities for resizing them to fit the given screen sizes
     

3. Content Before Design

This is the right sequence to follow when you're designing (or re-designing) your Drupal site with mobile users in mind:

First, you create and strategically organize your content and upload it to your Drupal 8 CMS. It's only then that you focus on styling and developing a responsive and visually-striking web design.

If it's legacy content that you're dealing with, trying to convert it to mobile, the very first step to take when you develop a mobile-first content strategy is:

Removing all the design elements from your written content.
 

4. Create a Hierarchy of Your Calls to Action

Making the most of a small interface means also setting your priorities in terms of calls to action:

Pair each one with a corresponding objective, evaluate them all wisely, then select THE call to action that's most critical for you and place it — and it alone — above the fold.
 

5. Organize and Optimize Your Content for Mobile Devices

I'll briefly list all the key requirements that mobile-friendly content should meet — aspects to pay attention to when writing content for mobile devices — for I'm sure they're nothing new to you:

  • the phrases should be kept short and concise, thus eliminating the burden of “never-ending-scrolling”
  • the content should be sharp, targeted and skimmable, so users can easily “digest” it and modular, so that users can swiftly browse through it
  • “modular” meaning made either of multiple clear paragraphs — each one standing for one thought — or chunks of 3 paragraphs at most 
     

6. Optimize Media, too, When You Develop a Mobile-First Content Strategy

And there are a couple of essential steps that you mustn't overlook when it comes to mobile-optimizing your media:
 

  • always go for thumbnails instead of video players that your users would have to load and thus strain on your site's valuable resources
  • don't ever use autoplay on your audio and video content 
  • optimize your sound, image and video files both for large and small devices
     

7. Trim Down Your Navigation Menu

In other words: when you develop a mobile-first content strategy, consider simplifying your navigation to its truly essential links.

No user would gladly scan through a “beefy” navigation menu taking his device's entire screen:
 

  • flatten your navigation: stay away from the technique of piling up submenus, layers and navigation points
  • feel free to place the links that you'll remove on other places on your website (or even to turn them into calls to action)
     

8. Convert Your Legacy Content to Mobile-Friendly Content 

If it's a legacy Drupal website that you need to restructure and to adapt to your mobile users' specific patterns for browsing through and consuming content on their smartphones, then it's time you:
 

  • dug into your static HTML
  • … and cleaned it up
     

And by “cleaning it up” I do mean:
 

  • removing inline media
  • removing the fixed-width tables
  • eliminating floats with content 
  • breaking it down into skimmable chunks of content
     

… that can be easily structured into content fields.

The END! These are the 8 main aspects to focus on when you develop a mobile-first content strategy. 

Now time to test the “saying” that:

“Creativity strives under constraints.”

… and to make the most of those small interfaces.

May 29 2018
May 29


Content is a way too valuable asset not to handle it with utmost care — from its creation to its revision, all the way to its... distribution. And with utmost efficiency, as well! But how do you choose the business software to “orchestrate” your entire content workflow? Since, on one hand, you have the top enterprise content management systems in 2018 and, on the other hand, you have... Drupal?

And the dilemma that you're facing right now could be summed up like this:

Choosing between a complex ECM system with a load of powerful tools that comes at a cost and a feature-rich one — already famed for its robustness and customization options — with no price tag on...

Now to ease your decision-making process, let's compare these enterprise information management solutions, the top rated ones, to Drupal, by weighing their feature loads and costs.
 

1. But What Is an Enterprise Content Management System More Precisely?

First, let's try to define what we mean by “content” in relation to a content management software:

Content is all the written pieces of information entering and “moving about” your organization. It comes in the form of:

  • internal process documents
  • content for your company website (or blog)
  • sales-focused content
  • targeted, custom content available to paying cutomers only
  • ... and the list goes on.

As you can see, I've intentionally left out graphical and audio-visual content. And this because it's only text-based digital content that a CMS would handle.

Now, coming back to our initial question:

An enterprise content management system is a software geared at managing all the processes in your content's lyfecycle: creation, revision, publication, distribution to multiple channels, promotion etc.

Packed with different sets of tools designed to automate all your content-based processes, an ECM system is a... “Swiss knife” type of business software.

The one you'd use to streamline your content workflow(s).
 

2. M-Files, One of the Top Enterprise Content Management Systems in 2018

Introducing the enterprise-leveled information management solution of the year: M-files!

The promise that it makes? 

To break the “siloed information” pattern and enable users to access specific content from any buiness system, any device.

… to easily access it, but also to organize it, to manage it, to identify particular information/documents, to set up custom workflows and even to manage document reviews. 
 

Top features
 

  • version control 
  • automated workflows
  • pre-built search engine: you get to track documents by type, name, keywords; it provides within-text search features as well 
  • notifications: users get alerted whenever they'll need to review or approve changes made to documents
  • approval processing 
  • permission management and offline access 
  • integration capabilities: it easily integrates with Microsoft Dynamics, NetSuite, SAP, Salesforce 
  • document collaboration tools: co-authoring features and check-in/check-out tools 
     

Price


Mi-files is one of those enterprise content management vendors that leverage the quote-based method for pricing their services.

Basically, there are no standard prices, as there are no standard packages that they offer, only tailored content management solutions.
 

Cons

The great majority of negative user feedbacks revolve around the M-Files mobile app's limited functionality.
 

Another one of the top enterprise content management systems in 2018 is OnBase:

An all-in-one software coming “equipped” with:

  • business process management tools
  • integrated document management tools
  • records management tools

And before I “expose” to you its most heavy-weighing features, I feel that I should put the spotlight on its versatility feature first:

You get to easily configure your OnBase ECM system to fit any environment of choice.
 

Top Features 
 

  • approval process control
  • indexing
  • version control
  • built-in search engine
  • document management
     

Cons

Do expect a steep learning curve! So, be prepared to invest a significant amount of time in growing comfortable with using it.

In learning to “juggle” with all its apps and functionalities.
 

Price

You'll need to contact the OnBase team for a custom pricing plan.
 

Box is a cloud content management platform built to assist you with:
 

  • online sharing your files
  • storing your files
  • integrating content across your entire “infrastructure” of digital tools via open APIs
  • collaborating within your team
     

Top Features 
 

  • granular access permission
  • easy integration with other platforms 
  • advanced security capabilities: device trust, watermarking, data governance
  • easy integration with other platforms
  • collaboration tools: a document management system that enhances collaboration among end-users on various file types and devices; tools which also enable them to choose the right storage place, to set up metadata-driven content workflows etc.
     

Cons

Even top enterprise content management systems manage to collect their own “pile” of “bad reviews”. What users reproach OnBase here, for instance, is its user-based pricing model. 

In other words, if you have +100 people in your company, expect to get charged separately for each email domain... and thus to overstretch your budget over time.
 

Price

Box pricing plans start from €4.50 per user/month (we're talking about a starter business plan here) and can go up to $500 per month or more if it's a “build with BOX platform” plan that you'll select.
 

And now that we've put the top-rated ECM systems in 2018 into the spotlight, let's see what Drupal here has to offer. How it can counterbalance all these heavy loads of tools, features, and functionalities.
 

Drupal's Key Features 
 

  • advanced integration capabilities: Drupal “spoils” its end-users with conveniently accessible API, backed by a rich collection of modules built precisely for 3rd party integrations
  • no maintenance effort required: since it runs in Acquia Enterprise cloud, Drupal gets automatically updated; maintenance is already included in the Enterprise support costs plan
  • feature richness: and we're talking here about features, plug-ins (thousands of them) and content management tools that you get right out of the box
  • modular architecture: which goes hand in hand with the unlimited freedom of customization that you'll get to leverage
  • high performance: Drupal's already famed for its robustness and capabilities to withstand high influxes of traffic
  • unmatched scalability
  • a full toolbox (contributed modules here included) put at editors' disposal: Drupal's also won its reputation as a CMS that's been constantly improved to enrich the experience; all the in-built content-handling tools speak best of its “empower the content creator/end-user” philosophy
     

Price
 

  • license costs: unlike the top enterprise content management systems previously outlined, Drupal's open source; there are no license costs, only support costs associated with the Acquia Enterprise Platform 
  • vendor lock-in: all modules and plug-ins that you might select and mix and match to custom-tune your CMS are free
  • development costs: Drupal resources are available to anyone who wants to build and then to custom tune and scale up its CMS
     

In conclusion...

… Drupal comes feature-packed and, moreover, it “spoils” you with unlimited freedom of customization. And all this without putting a price tag on.

On the other hand, some of the top enterprise content management systems do tempt you with their feature richness, but at a cost. One that can go up precisely if you feel like customizing your ECM solution or scaling it up sometime in the future. 

In short: you do get your share of customization freedom... but not for free.

So, it's not really an “apples vs oranges” type of dilemma that you're facing, but rather an:

Apples vs Apples with a price tag on

Apr 24 2018
Apr 24

Whether you're "constrained" to migrate content to Drupal 8 or you're just eager to jump on the Drupal 8 bandwagon and harness its much-talked-about advanced features, the most important “warning/advice” to keep in mind is:

Don't migrate mindlessly!

Meaning that before you even get to the point of:
 

  • triggering the Migrate module's capabilities and adjusting them to your migration project's needs and requirements
  • selecting and combining all the needed contrib modules
  • writing down your YAML files for carrying out your content migration process
     

You'll need to think through every little aspect involved in/impacted by this process:
 

  • your goals
  • your growth plan
  • your current site visitors' complaints and suggestions
     

That being said, here's more of a “backbone” or summary of the migration workflow, one that highlights the:
 

  1. main phases to go through
  2. the right approach to the whole process
  3. Drupal-specific concepts and tools to use
     

Do NOT expect a very detailed, highly technical tutorial, though!

As for the Drupal concepts that you'll need to be already (more than) familiarized with once you launch your migration process, maybe you want to have a look at this guide here, on Understanding Drupal

And now, let's delve in:
 

1. The Migration Workflow: 4 Key Phases to Consider 

Here's the entire process in 4 steps (so you know what to expect):
 

  1. first, you'll need to migrate your data into the destination nodes, files and paragraphs on the newly built Drupal 8 site
  2. then you'll migrate data into date, image, taxonomy, address fields and file
  3. next, you'll move your precious data from JSON and CVS files
  4. and finally, you'll complete your migrations from the UI and the terminal
     

2. Are You Upgrading from Drupal 6 or 7 or Migrating From a Different System?

And here's what to expect depending on your answer to the above question:
 

  1. if you migrate content to Drupal 8 from an older version of Drupal (6 or 7), then you're quite “spoiled”: a lot of hard work has been done, by the Drupal community, for turning this migration process into the official path to Drupal 8; you could say that the solid framework has already been set up, so all there's left for you to do is to... take advantage of it!
  2. if it's from a whole different system that you're migrating your site (let's say WordPress or maybe Joomla), then... expect it to be a bit more challenging. Not impossible, yet more complex
     

3. Plan Everything in Detail: Think Everything Through!

Now with the risk of sounding awfully annoying and repetitive, I feel like stressing this out:

Don't migrate... mindlessly!

Plan everything in the smallest detail. Re-evaluate the content on your current site and its “load” of features. 

Take the time to define your clear goals and to put together your growth plan (if there's any).

Then, do lend ear to what your current site visitors have to say, filter through all their complaints and suggestions and tailor your final decisions accordingly.

It's only then that you can go ahead and set up your content architecture.
 

4. Start With the Structure: Build Your Drupal 8 Site First

“But I haven't picked a theme yet!” you might be thinking.

No need to! Not at this stage of the migration process.

You can still build your Drupal 8, from the ground up, even without a theme ready to be used. You can add it later on, once you have the final version of your content!

But the site itself, its solid structure, this is a “must do”. It's the very foundation of all your next operations included in your migration workflow!
 

5. Deep Clean & Declutter! Take Time to Audit Your Content

Don't underrate this very step! For moving over all that clutter, that heavy load of unused, outdated features and all those chaotic, crummy pages will only impact your Drupal 8 site's performance from the start.

So, now it's the right time to do some... deep cleaning!

Audit your content, your features, plugins and other functionalities included in your site's infrastructure and... trim it down by:
 

  1. relevance (are you using it?)
  2. quality: keyword-stuffed, unstructured pages (a heavy pile of them) will surely not give your new Drupal 8 site any significant jumpstart in rankings!
     

6. About the Migration Module Included in Drupal 8 Core

Using this dedicated module in Drupal core to migrate content to Drupal 8 comes down to implementing the:

Extract- Transform-Load process

Or simply: ETL.

In Drupal — as related to the Drupal migrate module — these 3 operations come under different names:
 

  • the source plugin stands for “extract”
  • the process plugin stands for “transform”
  • the destination plugin stands for “load”
     

7. Time to... Migrate Content to Drupal 8 Now!

Now it's time to put some order into that “pile” of content of yours! To neatly structure Google Sheets, XML files, CVS files etc.

And here's the whole “structuring process” summed up to the 3 above-mentioned plugins: source, process and destination.
 

Source: 

  • XML file
  • SQL database
  • Google Sheet
  • CVS file
  • JSON file
     

Process:

  • iterator
  • default_value
  • migration_lookup
  • concat
  • get 


Destination:

  • images
  • users
  • paragraphs
  • nodes
  • files

And here's a specific example of how to “glue” data for a neater and ideally structured content architecture:
 

Before the migration:

  • A: First Name- Kevin
  • B: Last Name: Thomson
  • C: Department- Commerce
     

After Migration: 

  • A: Name- Kevin Thomson
  • B: Department- Commerce
     

8. 4 Contrib Modules to Incorporate Into Your Migration Workflow

As already mentioned, the migrate content to Drupal 8 process also involves using a combination of contrib modules. 

Speaking of which, allow me to get them listed here:
 

  1. Migrate Tools          
  2. Migrate Source CVS    
  3. Migrate Spreadsheet 
  4. Migrate Plus 
                 

The END! This is the tutorial on how to migrate content to Drupal 8 trimmed down to its bare essentials.

To its core phases, key steps to take, main Drupal concepts to “joggle with”, right approach/mindset to adopt and best tools/modules to leverage for a smooth process!

Any questions?

Apr 06 2018
Apr 06

With popularity comes trouble... In this case here meaning: security vulnerabilities and risky over-exposure to cyber threats. And this can only mean that securing your website, that's running on the currently third most popular CMS in the world, calls for a set of Drupal security best practices for you to adopt.

And to stick to!

There's no other way around it: a set of strategically chosen security measures, backed by a prevention-focused mindset, pave the shortest path to top security.   

Stay assured: I've selected not just THE most effective best practices for you to consider adopting, but the easiest to implement ones, as well.

Quick note: before I go on and knee deep into this Drupal security checklist, I feel like highlighting that:
 

  • Drupal still has a low vulnerability percentage rate compared to its market share
  • the majority of Drupal's vulnerabilities (46%) are generated by cross-site scripting (XSS)
     

And now, here are the tips, techniques and resources for you to tap into and harden your Drupal site's security shield with.
 

1. The Proper Configuration Is Required to Secure Your Drupal Database 

Consider enforcing some security measures at your Drupal database level, as well.

It won't take you more than a few minutes and the security dangers that you'll be safeguarding it from are massive.

Here are some basic, yet effective measures you could implement:
 

  • go for a different table prefix; this will only make it trickier for an intruder to track it down, thus preventing possible SQL injection attacks
  • change its name to a less obvious, harder to guess one
     

Note: for changing your table prefix you can either navigate to phpMyAdmin, if you already have your Drupal site installed, or do it right on the setup screen (if it's just now that you're installing your website).
 

2. Always Run The Latest Version of Drupal on Your Website

And this is the least you could do, with a significant negative impact on your Drupal site if you undermine its importance. If you neglect your updating routine.

Do keep in mind that:
 

  1. it's older versions of Drupal that hackers usually target (since they're more vulnerable)
  2. the regularly released updates are precisely those bug fixes and new security hardening features that are crucial for patching your site's vulnerabilities.
     

Why should you leave it recklessly exposed? Running on an outdated Drupal version, packed with untrusted Drupal modules and themes?

Especially since keeping it up to date means nothing more than integrating 2 basic Drupal security best practices into your site securing “routine”:
 

  1. always download your themes and modules from the Drupal repository (or well-known companies)
  2. regularly check if there are any new updates for you to install: “Reports” → “Available Updates”→“Check manually” 
     

Drupal Security Best Practices: run the latest version of Drupal
 

3. Make a Habit of Backing Up Your Website

And here's another one of those underrated and too often neglected Drupal security best practices!

Why should you wait for a ransomware attack and realize its true importance... “the hard way”?

Instead, make a habit of regularly backing up your website since, as already mentioned:

There's no such thing as perfection when it comes to securing a Drupal site, there's only a hierarchy of different “security levels” that you can activate on your site

And backing up your site, constantly, sure stands for one of the most effective measures you could apply for hardening your Drupal website.

Now, here's how you do it:
 

  1. make use of Pantheon's “one-click backup” functionality
  2. test your updates locally using MAMP or XAMPP or another “kindred” software
  3. harness the Backup and Migrate module's power, currently available only for Drupal 7
  4. export your MySQL database and back up your files “the old way”... manually
     

There, now you can stay assured that, if/when trouble strikes, you always have your backup(s) to retrieve your data from and get back “on your feet” in no time!
 

4. Block Those Bots That You're Unwillingly Sharing Your Bandwidth With

No need to get all “altruist” when it comes to your bandwidth!

And to share it with all kinds of scrappers, bad bots, crawlers.

Instead, consider blocking their access to your bandwidth right from your server.

Here's how:

Add the following code to your .htacces file and block multiple user-agent files at once:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^.*(agent1|Wget|Catall Spider).*$ [NC]
RewriteRule .* - [F,L]

Or use the BrowserMatchNoCase directive as follows:

BrowserMatchNoCase “agent1” bots
BrowserMatchNoCase "Wget" bots
BrowserMatchNoCase "Catall Spider" bots

Order Allow,Deny
Allow from ALL
Deny from env=bots

Use the KeyCDN feature for preventing those malicious bots from stealing your bandwidth!



5. Use Strong Passwords Only: One of the Easiest to Implement Drupal Security Best Practices

More often than not “easy” doesn't mean “less efficient”. 

And in this particular case here, simply opting for a strong username (smarter than the standard “admin”) and password can make the difference between a vulnerable and a hard-to-hack Drupal site.

For this, just:

Manually change your credentials right from your admin dashboard:  “People” → “Edit”→ “Username” while relying on a strong password-generating program ( KeePassX or KeePass) 
 

6. Use an SSL Certificate: Secure All Sensitive Data and Login Credentials

Would you knowingly risk your users' sensitive data? Their card information let's say, if it's an e-commerce Drupal site that you own?

And how about your login credentials?

For this is what you'd be doing if — though you do recognize the importance of using an SSL certificate —  you'd still put this measure at the back of your list of Drupal security best practices.

In other words, running your site on HTTPs (preferably on HTTP/2, considering all the performance benefits that it comes packaged with) you'll be:
 

  • encrypting all sensitive data that's being passed on, back and forth, between the server and the client
  • encrypting login credentials, instead of just letting them get sent, in crystal-clear text, over the internet.
     

7. Use Drupal Security Modules to Harden Your Site's Shield

For they sure make your most reliable allies when it comes to tracking down loopholes in your site's code or preventing brutal cyber attacks.

From:
 

  • scanning vulnerabilities
  • to monitoring DNS changes
  • blocking malicious networks
  • identifying the files where changes have been applied
     

… and so on, these Drupal modules will be “in charge” of every single aspect of your site's security strategy.

And supercharging your site with some of the most powerful Drupal security modules is, again, the easiest, yet most effective measure you could possibly enforce.

Now speaking of these powerful modules, here's a short selection of the “must-have” ones:
 

  • Password Policy: enables you to enforce certain rules when it comes to setting up new passwords (you even get to define the frequency of password changes)
  • Coder : runs in-depth checks, setting your code against Drupal's best practices and coding standards
  • Automated Logout: as an admin, you get to define the time limit for a user's session; he/she will get automatically logged out when time expires
  • SpamSpan Filter: enables you to obfuscate email addresses, thus preventing spambots from “stealing” them
  • Login Security: deny access by ID address and limit the number of login attempts
  • Content Access: grant permission to certain content types by user roles and authors
  • Hacked!: provides an easy way for you to check whether any new changes have been applied to Drupal core/themes
  • Security Review Module: it will check your website for those easy-to-make mistakes that could easily turn into security vulnerabilities; here's a preview of this module “at work”
     

Drupal Security Best Practices: the Drupal Security Review Module
 

8. Implement HTTP Security Headers

Another one of those too-easy-to-implement, yet highly effective Drupal security best practices to add to your Drupal security checklist:

Implementing (and updating) HTTP security headers

“Why bother?”

Cause:
 

  1. first of all, their implementation requires nothing more than a configuration change at the web server level
  2. their key role is letting the browsers know just how to handle your site's content
  3. … thus reducing the risk of security vulnerabilities and brute force attacks
     

9. Properly Secure File Permissions

Ensure that your file permissions for:
 

  • opening
  • reading
  • modifying them
     

… aren't too dangerously loose.

Since such negligence could easily turn into an invitation for “evil-minded” intruders! 

And it's on Drupal.org's dedicated page that you can find more valuable info on this apparently insignificant, yet extremely effective security measure 
 

10. Restrict Access To Critical Files 

Told you this was going to be a list of exclusively easy-to-implement Drupal security best practices.

Blocking access to sensitive files on your website (the upgrade.php file, the install.php file, the authorize.php file etc.) won't take you more than a few minutes.

But the danger you'd avoid — having a malicious intruder risking to access core files on your Drupal site — is way too significant to overlook.
 

END of list! These are probably the easiest steps to take for securing your Drupal site.

How does your own list of Drupal security tips, techniques and resources to tap into look like?

Apr 05 2018
Apr 05

Who are your visitors? Where do they come from? And what do they do precisely during their visits on your Drupal site? How long are their visits? What content on your site do they linger on and what content do they “stubbornly” ignore? Needless to say that for getting your answers to all these questions you need to set up Google Analytics on your website.

Since:

“This data--aka analytics--is the lifeblood of the digital marketer.” (Jeffrey Mcguire, Acquia, Inc. Evangelist)

The good news is that integrating it is nothing but a quick and simple 3-step process. And the great news is that:

Drupal's got you covered with its dedicated Google Analytics module, geared at simplifying the otherwise tedious and time-consuming process.

So, shall we dive into the installation guide?
 

1. But First: Why Web Analytics? And Why Precisely Google Analytics?

In an UX-dominated digital reality, that takes personalization to a whole new level, user behavior data turns into... superpower.

And by “user behavior data”, I do mean web analytics.

Therefore, injecting a web analytics service into your Drupal site is like... injecting true power into its “veins”.

But why precisely Google Analytics?

Why set up Google Analytics on your Drupal site instead of another web analytics tracking tool? Is its popularity a strong enough reason for you to jump on the trend?

To answer your question, I do think that its own key features make the best answers:
 

  • audience demographic reporting: discover where your site visitors come from, their native languages, the devices and operating systems they use for accessing your website...
  • goal tracking: monitor conversion rates, downloads, sales and pretty much all stats showing how close (or far) you are to reaching the goals that you've set for your website
  • acquisition reporting: identify your site's traffic sources; where do your visitors come from exactly?
  • on-site reporting: gain a deep insight into the way visitors engage with specific pieces of content on your website, so you know how to adjust the experience your deliver them on your site/app to their specific needs 
  • event-tracking: tap into this feature for measuring all activities carried out on your Drupal site
     

And the list of features could go on and on. Providing you with a high-level dashboard and enabling you to go as deep as you need to with your “data digging”.

For Google Analytics is only as powerful as you “allow” it to be. It empowers you to dig up both surface and “in-depth data”.

Moreover (or better said: “thanks to...”), being such a feature-rich tracking tool, Google Analytics's highly versatile, too. From email marketing to social media marketing, to any type of marketing campaign that you plan to launch, it's built to fit in just perfectly.

To power all forms of marketing strategies.

And where do you add that it's been a while now since we've been having Google Analytics for mobile apps and the Google Analytics 360 suite, too! 2 more powerful GA tools to add to your web analytics “tracking arsenal”.
 

2. The Drupal Google Analytics Module and How It Will Make Your Life (So Much) Easier

Let me try a lucky guess: 

Your Drupal site has... X pages (have I guessed it?)

The “standard” way to add Google Analytics to your Drupal site would involve:

Copying the tracking ID that Google Analytics provides you with and pasting it on each and every page on your website.

A hair-pulling monotonous and time-consuming process, don't you think?

And it starts to look even more cumbersome if you think that you have the alternative to set up Google Analytics on your Drupal site using the dedicated module.

But how does it streamline... everything more exactly? 

You'll just need to paste that Google Analytics javascript snippet for tracking data right to this module's Configuration page and... that's it!

The module will take it from there! It will distribute it itself to all the pages on your website.

Less effort, less time wasted for carrying out in a tedious and repetitive activity. And more time left for customizing all those statistics features to perfectly suit your goals and your site's needs.

How to Set Up Google Analytics on Your Drupal Site: The Google Analytics Drupal Module

Luckily enough, the Drupal Google Analytics module puts an admin-friendly UI at your disposal precisely for that:
 

  • use it to track down key data 
  • use it for tailoring your web analytics-tracking activity to your needs: by user role, by pages etc.
     

3. Set Up Google Analytics on Your Drupal Site In Just 3 Simple Steps 

As promised, here's a “dead-simple 3-step guide on how to add Google Analytics to your Drupal site (“leveraging the power of the dedicated Drupal module here included”)
 

Step 1

The very first thing you'll need to do is sign up for a Google Analytics account if you don't have one already. And then to add your Drupal site (obviously!).

And here are the quick steps to take:
 

  1. go to www.google.com/analytics
  2. hit “sign in” (you'll find it in the top right corner) and select “Google Analytics” from the unfolding drop-down menu
  3. click “Sign Up” and just follow the given steps for setting up your new account
  4. next, follow the instructions for setting up web tracking
     

Now you should be able to see your Drupal site displayed under your account, on your admin page in Google Analytics.

And it's now that you should be able to retrieve your site's “Tracking ID”, as well. You'll find it in the “Property Setting” section.
 

Step 2

The next major step to take as you set up Google Analytics on your Drupal site is to actually go back to your site and... install THE module itself.

Since I've already praised its “superpowers” and how they “conspire” to make your life easier, I'm not going to point them out once again.

Instead, I'll go straight to the steps to take once you've enabled the module on your website:
 

  1. access its configuration page (you'll find the “Configuration” tab on top of the page, “flanked by” the “Modules” and the “Reports” tabs)
  2. there, right under the “General Setting” section, just enter your “Web Property ID”
  3. … which is precisely the Google Analytics tracking code that you've just retrieved at Step 1
     

And this is precisely the “magic trick” that's going to add the Google Analytics tracking system site-wide. A monotonous, multiple-step process turned into a one-step operation.

This thanks to the Drupal Google Analytics module!
 

Step 3

Here you are now, ready to save your settings and to officially harness the power of Google Analytics on your website!

Normally you should be just fine with the default settings that the service provides you with, right out-of-the-box.

Yet, if you need to “refine” your searches, your entire tracking activity, feel free to do that. To explore all the options stored in the “Tracking Scope” tabs for you.

Speaking of which, let me give you just a few examples of how deep you could narrow down your “investigations” and customize the modules:
 

  • roles: a setting which lets you define which user roles to track (and which roles the system should ignore)
  • domains: indicate whether it's a single or multiple domains that you need monitoring
  • privacy: it enables you to make visitors' IP addresses anonymous
  • pages: indicate precisely which pages on your website you need to track
  • messages: track and monitor the messages displayed to your site visitors
  • search and advertising: keep track of your internal site searches and AdSense advertisements; do keep in mind, though, that some additional settings might be needed!

And... more! You actually get even more power for configuring your JavaScript setting and adding custom variables.

The END! This is how you set up Google Analytics on your Drupal site in 3 dead-simple steps, a streamlined process powered by the dedicated Drupal module.

Mar 02 2017
Mar 02

When you’re making a decision about which Toronto web design agency to hire, you’re making a decision about the future of your business.

A well designed, quickly loading, good looking website will bring you clients, increase sales and lead to success. A bad website… well, let’s just say it will cost you more.

If you’re a small business, looking for an affordable web design Toronto studio is understandable. It’s perfectly achievable too. There are good web design agencies in any price range. There are bad ones in all price ranges as well.

So how do you make sure to hire the Toronto web design agency that’s right for you?

Here are a few considerations that can help you make the right decision.

  1. Look for relevant experience. Markets and industries are different. If an agency worked with fashion shop websites in Europe, it doesn’t mean they will know how to build a website for a Toronto hi tech company or a local car repair shop. They may, or they may not. Picking a company that worked with clients in your industry locally is the safer choice.

  2. Affordable is not the same as cheap. Remember there’s the trio of things: Fast, Cheap, Good. You can only ever choose two of them. Choose fast and good, and it won’t be cheap. Choose cheap and fast, and you won’t get quality results. But it can be affordable. As we just said above, there are good companies in all price ranges. Just don’t make it your top priority.

  3. See how communication works. Are emails answered quickly? Do they provide detailed answers? The company you’re hiring should sound interested and reliable. They should be able and happy to explain what exactly you’re getting for your money. Make sure you’re also available, to establish good communication and trust, of course.

  4. Portfolios are important, but checking them won’t hurt. Unfortunately, it’s not impossible for a businesses - in any field, for that matter - to exhibit projects that are not their own. Luckily, it’s easy to check. All you need to do is contact their client and ask how the service was. This way you gain a confirmation that the portfolio project is real, and also find out about how good it was working with the firm. An honest Toronto web design agency will only encourage that.

We hope this helps. Good luck in your search and subsequent new project!

Jan 31 2016
Jan 31

Here is a complete guide to get your drush working OS X El Capitan.

1) Download latest stable release using the code below or browse to github.com/drush-ops/drush/releases.

wget http://files.drush.org/drush.phar

(Or use our upcoming release: wget http://files.drush.org/drush-unstable.phar)

2) Test your install.

php drush.phar core-status

3) Rename to `drush` instead of `php drush.phar`. Destination can be anywhere on $PATH.

chmod +x drush.phar
sudo mv drush.phar /usr/local/bin/drush

4) Enrich the bash startup file with completion and aliases.

drush init

5) Add the following lines to .bashrc. (Check which PHP version you are using!)

export MAMP_PHP=/Applications/MAMP/bin/php/php5.6.10/bin
export PATH="$MAMP_PHP:$PATH"
export PATH=$PATH:/Applications/MAMP/Library/bin
export PHP_OPTIONS='-d memory_limit="512M"'

6) Add the following line to .bash_profie

if [ -f ~/.bashrc ]; then . ~/.bashrc; fi

That’s it, you will have a fully functional drush on your Macintosh.

Oct 09 2014
Oct 09

Field collections is a nice contributed module that extends the default Drupal entity functionality by creating a new entity field that can be composed by other fields. With this module we solve problems like creating complex entities where we want to store multiple different values into one single field. This works because Drupal lets us assign unlimited values for a field, which links to the field collection entity where we have multiple fields, thats how we "grouped" multiple fields into one field.

At a basic usage, field collections is not difficult to add to our entity, but when we want to do some advanced stuff, this module can be very complex. Here I will show how to do some magic with it, programatically.

Obtain the values of the child fields

How to access the field collection values of an entity? Field collections store field collection items, which are the values of this kind of field. The field collection items use an ID, and with this ID we can find other fields. It also defines a new entity type called “field_collection_item”.

  1. Access to all values of a field collection on an existing entity, using Field API // Get the items of a field collection, from a node
    $field_node_example_values = field_get_items('node', $node, 'field_node_example');

    // Use a field collection helper function to get all the field collection item ids
    $field_node_example_ids = field_collection_field_item_to_ids($field_node_example_values);
    // By default, Drupal don't load the field collection items
    $field_node_example_fc_items = field_collection_item_load_multiple($field_node_example_ids);

    // Loop over every field collection item and get the values for each field
    foreach ( field_node_example_fc_items as $item) {
        $fc_field_values = field_get_items('field_collection_item', $item, 'field_inside_fc');
    }

  2. Access to all values of a field collection on an existing entity, using an entity wrapper

    $node_wrapper = entity_metadata_wrapper('node', $nid);
    // Loop over the collections until we find which we have to modify
    foreach ($node_wrapper->field_example->value() as $field_example_value) {
       // Wrap it with Entity API
       $fc_wrapper = entity_metadata_wrapper('field_collection_item', $field_example_value);
       $fc_field_value = $fc_wrapper->field_example_child->value();
    }

Alter the child fields

Now let's see how we can modify or remove items from an existing field collection of an entity. To do things easily, I prefer to use here an entity wrapper.

  1. Alter the value of one of the fields of a concrete field collection item $fc_item = field_collection_item_load($item_id);

    // Check there's no problem with the item
    if (!$fc_item) {
      return;
    }

    // Wrap it before modifying
    $fc_item_wrapper = entity_metadata_wrapper('field_collection_item', $fc_item);
    $field_value = $fc_item_wrapper->field_example->value();
       ... change $field_value ...
    $fc_item_wrapper->field_example->set($field_value);
    $fc_item_wrapper->save();

  2. Delete a field collection item

    $fc_item_wrapper = entity_metadata_wrapper('field_collection_item', $item_id);
    $fc_item_wrapper->delete();

Create a field_collection_item

Field collection items use a “entity host”, which is the entity to whom the field collection is attached. To add a new field collection item to an existing field collection field, we have to create it and set its entity host, then we can assing values to every single field of the field collection item and save it.

// Create a field_collection_item entity
$fc_item = entity_create('field_collection_item', array('field_name' => 'field_example_is_a_field_collection'));

// Attach it to the node
$fc_item->setHostEntity('node', $node);

// Check there's no problem with the item
if (!$fc_item) {
  return;
}

// Wrap it with Entity API
$fc_item_wrapper = entity_metadata_wrapper('field_collection_item', $fc_item);

// Assign values to its fields
foreach($fc_item_values as $field_name => $field_value){
  $fc_item_wrapper->$field_name->set($field_value);
}

$fc_item_wrapper->save();


Alter a field_collection field into a form

When we are creating or editing a node (or any other entity) we use a form, and to modify it usually the hook_form_alter is used. Here are some interesting examples of how to alter the field collection widget.

  1. Change the options for a select box on all the field collection items and don't display the remove button for the first item. $field_name = 'field_collection_example';
    $fp_langcode = $form[$field_name]['#language'];
    $options = array( … );
    foreach (element_children($form[$field_name][$fp_langcode]) as $child) {
      // All the unlimited values fields have the “Add more” button as a child, but it's not a field collection item
      if (is_numeric($child)) {
        $form[$field_name][$fp_langcode][$child]['field_selectable'][$fp_langcode]['#options'] = $options;

        // Don't display the remove button for the first field collection item
        if ($child == 0) {
          unset($form[$field_name][$fp_langcode][$child]['remove_button']);
        }
      }
    }

  2. The field collection field stores some state information about it on $form_state. With this information we can know, realtime, how many items we have on the form and take decisions about it. For example, we have an unlimited values field collection field, but we want to limit the number of items depending on some certain circunstances. With this example, we can control a field to not display more than 3 field collection items on the form. $field_name = 'field_collection_example';
    $fp_langcode = $form[$field_name]['#language'];

    // Get state information about this field
    $fp_parents = $form[$field_name][$fp_langcode]['#field_parents'];
    $field_state = field_form_get_state($fp_parents, $field_name, $fp_langcode, $form_state);

    // The field state will change everytime we click on “Add more”, after the ajax call is triggered and the form is re-rendered to display the changes.

    // The user can see a maximum of 3 field collection items
    $items_limit = 3;
    if ($field_state['items_count'] < $items_limit) {
      // I want to change the “Add more” button title
      $form[$field_name][$fp_langcode]['add_more']['#value'] = t('Add another');
    }
    else {
      unset($form[$field_name][$fp_langcode]['add_more']);
    }

Clone field_collections from an existing node to a new node

Finally, here is an example of how to assign some default values to a field collection on a node creation form. As you can suspect, this is tricky if the value to clone is only one field collection item, but if we want to clone more than one, it's a problem because Drupal by default will only provide the form widget to enter the first item values (and wait for you to click on “Add more”).

The technique is to reproduce what Drupal does when the Field API attaches the fields to the node form. Using this way, Drupal will provide all the form structure we need to see all the values that come from the node we want to use as origin, but this has a problem and is that doing it this way we are assigning the same field collection items to two different nodes and if one of the nodes changes the values of one of the items, this will be reflected on the other node. The solution is to reset the item_id and revision_id values for the items on the new node, so we get the default values we want and they will be stored as new field collection items attached to the new node.

    $original_node = node_load(123);
    $node_type = 'my_custom_type';
   
    // Get the fields defined for this node type;
    $node_fields =  field_info_instances('node', $node_type);

    // Re-create the fields for the original node, like when editing it
    $tmpform = array();
    $tmpform['#node'] = $original_node;
    $tmpform['type']['#value'] = $node_type;
    $tmpform_state = array( 'build_info' => array('form_id' => $form['#form_id']) );
    field_attach_form('node', $original_node, $tmpform, $tmpform_state, entity_language('node', $original_node));

    // Here we have on $tmpform the form structure we need and with the default values.
    // We can choose what fields to clone, but in this example we will loop over all the node fields and clone all of them
    foreach($node_fields as $field_name => $field_settings) {
      // Copy the form structure
      $form[$field_name] = $tmpform[$field_name];
      // Copy state information about this field
      $form_state['field'][$field_name] = $tmpform_state['field'][$field_name];

      // When copying the field_collection structure, reset the id of the entities and
      // they will be created again with a new id.
      $langcode = field_language('node', $original_node, $field_name);
      if ($form_state['field'][$field_name][$langcode]['field']['type'] == 'field_collection') {
        $field_childs = &$form_state['field'][$field_name][$langcode]['entity'];
        foreach(element_children($field_childs) as $idx => $fc_entity) {
          $field_childs[$idx]->item_id = NULL;
          $field_childs[$idx]->revision_id = NULL;
        }
      }
   }

Mar 31 2014
Mar 31

I'm working on a Drupal application that stores data in separate mysql databases, and syncs some of the data to CouchDB with node.js scripts.

The extra mysql dbs are 16+ GB and it's not practical nor necessary to keep them locally since I only want to read the latest data in local development.

Wouldn't it be cool if my local development Drupal sites can read from the remote database servers?

In some cases you can just use the connection you find in the remote site's settings.php:

'otherdb' => 'mysqli://username:[email protected]/dbname'

(note: it's a Drupal 6 site so that's why you don't see an array - I will give a Drupal 7 example below)

However, there's often a twist: I must create a SSH tunnel to connect to this particular db server.

First, you need to have configured and installed SSH keys on your local and remote machines.

Then fire up your terminal and create the SSH tunnel to forward the remote mysql port to a local port. This technique is based on information clearly presented by RevSys (quick example) and noah.org (more details).

ssh -L [local port]:[db host]:[remote port] [ssh-username]@[remote host] -N

NOTES:

  1. -N tells ssh that you don't want to run a remote command; you only want to forward ports.
  2. use a different port for your tunnel [local port] than the one you normally use for mysql; for example, if you connect to mysql locally on the default port 3306, use 3307 (or any other unused port) for your tunnel. You should use the correct [remote port] which is typically 3306, and you can see if it is different by looking at settings.php in the remote site.
  3. Keep this connection alive as long as you need to connect to the remote database.

ssh -L 3307:[db host]:3306 [ssh-username]@[remote host] -N

Then you can test your connection (in a different terminal instance):

mysql -u[dbuser] -p -P 3307 -h 127.0.0.1

Here is the connection in settings.php for Drupal 6:

What's cool is that you can mix local and remote databases. For example, I want to use a local copy of the Drupal database, which is smaller and easier to sync, and read the data from the second (and third, in my case) remote dbs.

$db_url = array(

);

You can also connect Drupal to the default remote database, but it makes sense to use a local instance for development.

And in Drupal 7:

$databases['default']['default'] = array(

  'driver' => 'mysql',

  'database' => 'local-dbname',

  'username' => 'local-dbuser',

  'password' => 'password',

  'host' => 'localhost',

  'prefix' => '',

);

$databases['otherdb']['default'] = array(

  'driver' => 'mysql',

  'database' => 'dbname',

  'username' => 'username',

  'password' => 'password',

  'host' => '127.0.0.1',

  'port' => '3307',

  'prefix' => '',

);

WARNING: 

If the db user for the remote db has all privileges, your application may alter the remote database.

Therefore, you should create a "read-only" user for the remote database which will prevent you from altering it.

THINK

Jan 31 2012
Jan 31

“Why is your window transparent?” a coworker asked me when she noticed my screen. I told her about how I do my CSS theming, and she pulled another coworker over and made me repeat the explanation. Since that seems like something other people might find handy, here it is.

Sass: Syntactically Awesome Sytlesheets

I rarely do CSS/front-end theming work, but when I do, I try to make it as fun and easy as back-end development. I use Sass (Syntactically Awesome Stylesheets) so that I can use nested selectors, variables, and mixins. This makes my code cleaner and easier to write. You’ll need Ruby in order to install Sass, but the tool will give you CSS that you can use on any web platform.

Browser-based tools

I prefer doing the initial tweaking in Google Chrome, because I like the way that the developer tools make it easy to modify the stylesheet. The Chrome CSS Reloader extension is handy, too. Most of the time, I make my CSS changes in the text editor, then use the CSS Reloader to reload the stylesheet without refreshing the page. This makes it easy to manually toggle the display of some elements while allowing me to refresh style rules. If I want to figure out the values for a few simple changes, I’ll sometimes make the changes directly in Chrome (you can use arrow keys to adjust values), then copy the values to my Sass source file.

Colors, sizes, and spaces

A second monitor is totally awesome and well worth it.

Designs rarely specify all the colours, sizes, and spacing needed. To quickly get the color of a pixel, I use WhatColor. This shows the hex code for colors, and allows me to quickly copy the code with the F12 shortcut key. If you want to change the shortcut key, the source is available as an AutoHotkey script.

To make it easier to match sizes and spaces, I use WinWarden to make my browser window 20% translucent. Then I carefully position it over my design reference until the important features match. Magnifixer makes it easier to line things up because it can magnify a fixed portion of the screen. By focusing Magnifixer on the part I’m working on, I can tweak CSS without straining my eyes.

When I know I’m going to be making a lot of changes, I use AutoHotkey to map a shortcut so that I can refresh the CSS with one keystroke instead of several. When I happen to have my USB foot pedal handy, I rig it up to refresh my stylesheet.

Regression testing

Sometimes my CSS changes modify other rules. Instead of laboriously checking each page after changes, I’ve figured out how to use Selenium WebDriver to write a Java program that loads the pages in Mozilla Firefox and Internet Explorer, capturing screenshots and numbering them according to the pages in my design reference. This means that I can run the program in the background or start it before taking a break, and then flip through all the screenshots when I get back.

Cross-browser testing

What’s CSS theming without the requirement of browser compatibility? Someday, when I need to deal with more browsers, I might look into Selenium RC. In the meantime, I develop in Chrome, my Selenium-based program makes it easier to test in Firefox and IE, and it’s easy enough to try the URLs in Safari as well. Virtual machines handle the rest of the requirements. 

So that’s how I’ve been doing CSS theming on this project. What are your favourite tips?

Jan 04 2011
Jan 04

When doing development work, from time to time it is handy to be able to look up documentation. Bookmarking manuals is handy, but often you still need to search for the function you're after. Firefox, and possibly other browsers (not Chrome or Chromium), allows you to setup a keyword bookmark linked to a search.

I've setup a few search bookmarks for development resources. This is how I've done it:

  1. Select Bookmarks > Organise Bookmarks... from the menu.
  2. Right click on the bookmarks menu (or any folder) on the left pane
  3. Select New Bookmark... from the context menu
  4. Drupal bookmark example
    Fill in the information for the bookmark, the import piece is the keyword, that will allow us to search.
  5. Click save and return to the browser

Now when we want to search the Drupal 7 API, we can just type "dapi ",>

Example Drupal API search in location bar

Now we should see the appropriate page from the Drupal API documentation.

Example Drupal API page

The same method can be used for other PHP web app developer resources, here are some which I'm using.

  • I've found Google to be the best resource for getting help with javascript

I could have implemented this using OpenSearch plugins, but that requires changing the search provider everytime I want to look for something. By using keyword bookmarks I just type the keyword and the search term into the location bar.

Feel free to share your keyword bookmarks in the comments.

Nov 11 2010
Nov 11

Setting up Simpletest and Drush on Drupal 6.x:

  1. Download and enable Simpletest with drush dl simpletest; drush en -y simpletest
  2. Download simpletest.drush.inc to your ~/.drush/drush_extras directory. This version allows you to run a single test from the command-line.
  3. Create a custom module with a tests/ subdirectory, and write your tests in it. (See this Lullabot Simpletest tutorial.)

We’re starting another Drupal project. While the IT architect is working on clarifying the requirements, I volunteered to implement the risky parts so that we could get a better sense of what we needed to do.

The first major chunk of risk was fine-grained access control. Some users needed to be able to edit the nodes associated with other users, and some users needed to have partial access to nodes depending on how they were referenced by the node. Because there were many cases, I decided to start by writing unit tests.

SimpleTest was not as straightforward in Drupal 6.x as it was in Drupal 5.x. There were a few things that confused me before I figured things out.

I wondered why my queries were running off different table prefixes. I didn’t have some of the data I expected to have. It turns out that Simpletest now works on a separate Drupal instance by default, using a unique table prefix so that it doesn’t mess around with your regular database. I’m doing this on a test server and I want to be able to easily look up details using SQL, so I needed to add this to my test case:

class ExampleTestCase extends DrupalWebTestCase {
  function setUp() {
    global $base_url;
    $this->originalPrefix = $GLOBALS['db_prefix'];
  }
  function tearDown() { }
}

I also didn’t like how the built-in $this->drupalCreateUser took permissions instead of roles, and how it created custom roles each time. I created a function that looked up the role IDs using the {role} table, then added the role IDs and roles to the $edit['roles'] array before creating the user.

Lastly, I needed to add the Content Profile operations to my custom user creation function. I based this code on content_profile.test.

$this->drupalLogin($account);
// create a content_profile node
$edit = array(
  'title' => $account->name,
  'body'  => $this->randomName(),
);
$this->drupalGet('node/add');
$this->drupalPost('node/add/' . str_replace(' ', '-', $role), $edit, t('Save'));

It would’ve been even better to do this without going through the web interface, but it was fine for a quick hack.

I had the setup I wanted for writing test cases that checked user permissions. I wrote functions for checking if the user could accept an invitation (must be invited, must not already have accepted, and must be able to fit). SimpleTest made it easy to test each of the functions, allowing me to build and test blocks that I could then put together.

The code in content_permission.module turned out to be a good starting point for my field-level permissions, while the Drupal node access API made it easy to handle the user-association-related permissions even though I used node references instead of user references.

It was a good day of hacking. I wrote tests, then I wrote code, then I argued with the computer until my tests passed. ;) It was fun seeing my progress and knowing I wasn’t screwing up things I’d already solved.

If you’re writing Drupal code, I strongly recommend giving SimpleTest a try. Implementing hook_node_access_records and hook_node_grants is much easier when you can write a test to make sure the right records are showing up. (With the occasional use of node_access_acquire_grants to recalculate…) Otherwise-invisible Drupal code becomes easy to verify. The time you invest into writing tests will pay off throughout the project, and during future work as well. Have fun!

Nov 09 2010
Nov 09

One of the best things about building websites with Drupal is that there are thousands of modules that help you quickly create functionality.

To set things up, you need to download Drush and add it to your path. For example, you might unpack it into /opt/drush and then add the following line to your ~/.bashrc:

PATH=/opt/drush:$PATH
export PATH

Reload your ~/.bashrc with source ~/.bashrc, and the drush command should become available. If you’re on Microsoft Windows, it might need some more finagling. (Or you can just give up and use a virtual image of Linux to develop your Drupal websites. You’ll probably end up much happier. ;) )

Once you’ve installed Drush, what can you do with it?

Drush is a huge time-saver. For example, I install dozens of modules in the course of building a Drupal website. Instead of copying the download link, changing to my sites/all/modules directory, pasting the download URL into my terminal window after wget, unpacking the file, deleting the archive, and then clicking through the various module enablement screens, I can just issue the following commands to download and enable the module.

drush dl modulename
drush en -y modulename

(The -y option means say yes to all the prompts.)

So much faster and easier. You can use these commands with several modules (module1 module2 module3), and you can use drush cli to start a shell that’s optimized for Drush.

Drush is also useful if you’ve screwed up your Drupal installation and you need to disable themes or modules before things can work again. In the past, I’d go into the {system} table and carefully set the status of the offending row to 0. Now, that’s just a drush dis modulename.

Drush has a bucketload of other useful commands, and drush help is well worth browsing. Give it a try!

Read the original or check out the comments on: How to use Drush to download and install Drupal modules (Sacha Chua's blog)

Feb 24 2009
Feb 24

I know it seems like a far distance away and as much as you'd like to ignore it, Drupal 7 is coming and it will be awesome. Some ambitious developers have actually started with Drupal 7 version of their modules, but what if you just want to get a little head start? I'll show you a few ways that you can help prepare your Drupal 6 modules now to help make life easier when you full port to Drupal 7 later on. To see a list of all the current 6.x to 7.x module changes, view http://drupal.org/node/224333.

  1. Split your hook_nodeapi($op, ...), hook_user($op, ...), and hook_block($op, ...) functions into hook_nodeapi_op(...), hook_user_op(...), and hook_block_op(...). See http://drupal.org/node/224333#remove_op. Here is an example of how you could prepare/split your module's hook_user($op):
    <?php
    /**
    * Implementation of hook_user().
    * @todo Remove in Drupal 7.
    */
    function mymodule_user($op, &$edit, &$account, $category = NULL) {
      switch (
    $op) {
        case
    'form':
        case
    'validate':
         
    $func = 'mymodule_user_'. $op;
          return
    $func($edit, $account, $category);
      }
    }
    /**
    * Implementation of hook_user_form().
    */
    function mymodule_user_form(&$edit, &$account, $category = NULL) {
      if (
    $category == 'account') {
       
    $form['mymodule_setting'] = array(
         
    '#type' => 'textfield',
         
    '#title' => t('MyModule setting'),
         
    '#default_value' => isset($edit['mymodule_setting']) ? $edit['mymodule_setting'] : '',
        );
        return
    $form;
      }
    }
    /**
    * Implementation of hook_user_validate().
    */
    function mymodule_user_validate(&$edit, &$account, $category = NULL) {
      if (isset(
    $edit['mymodule_setting']) && $edit['mymodule_setting'] != 'foobar') {
       
    form_set_error('mymodule_setting', t('MyModule settings is not foobar.'));
      }
    }
    ?>
  2. Change your db_query() parameters to an array of parameters keyed by named placeholders. Drupal 7 has a great new Database API (DBTNG) that uses arrays of placeholders. You can safely convert your D6 db_query parameters to arrays now; then when you actually port your module to Drupal 7, you only need to change your %d, %s, etc to the same named placeholders as your parameter array's keys. See http://drupal.org/node/224333#dbtng.

    <?php
    D6 BEFORE
    : $query = db_query("SELECT nid FROM {node} WHERE nid > %d AND title = '%s'", 20, 'foobar');
    D6 AFTER: $query = db_query("SELECT nid FROM {node} WHERE nid > %d AND title = '%s'", array(':nid' => 20, ':title' => 'foobar'));
    D7: $query = db_query("SELECT nid FROM {node} WHERE nid > :nid AND title = :title", array(':nid' => 20, ':title' => 'foobar'));
    ?>

  3. Drupal 7 supports a dynamic-loading code registry and all modules must now declare their code files in their .info file. You can add these lines to your module's .info files now! See http://drupal.org/node/224333#registry.

    name = MyModule
    description = This is really your module, not my module.
    ...
    files[] = mymodule.module
    files[] = mymodule.admin.inc
    files[] = mymodule.pages.inc
    files[] = mymodule.install

  4. Make sure all your module's update functions have a small, one-line Doxygen function comment block. This documentation will actually be displayed in Drupal 7's update.php. Instead of update numbers, we get to see what the updates are actually doing! See http://drupal.org/node/224333#update_php. While you're there, double check that all your update functions return some kind of array. Not returning an array causes errors.

    <?php
    /**
    * Adds a new mycolumn column to the mymodule table.
    */
    function mymodule_update_6020() {
     
    $ret = array();
     
    db_add_field($ret, 'mymodule', 'mycolumn', array('type' => 'int', 'default' => 0));
      return
    $ret;
    }
    ?>

  5. Write test suites for your modules! Drupal 7 includes the SimpleTest module in core, but you can get nearly the same exact module in Drupal 6 with SimpleTest 2.x. Writing tests for your modules is a great way to make sure that everything still works properly when you make any kind of changes, big or small. Be sure to check out the testing documentation and standards!
  6. If your module creates any hooks or has an associated API, add examples of these hooks in mymodule.api.php in the module's directory. This not only helps other developers understand the provided API a little easier, but also gives IDEs the hook information. This will also bring us a step closer to being able to have a searchable contrib API like api.drupal.org. See core's system.api.php for an example of this and also see http://drupal.org/node/224333#api_php.
  7. Be sure to mark specific Drupal 7 todo's with Doxygen todo comments (//@todo This is something to do!) so you can easily find them later on. Little thing to look out for are functions that you needed to backport for PHP4 (Drupal 7 requires PHP 5.2), referer_uri(), time(), drupal_clone(), etc.

Be sure to mark anything you've identified

If you have found any other ways to help being porting your Drupal 6 module, please add a comment and I'll add it to the list!

Feb 24 2009
Feb 24

OpenDNS logoFor a while I had been using the OpenSearch browser plugins to help me search Drupal.org, and different versions of the Drupal APIs. But now I have found an even better method using OpenDNS. If you are not using the OpenDNS service already, I highly suggest you do! Not only does it provide fast and reliable DNS lookups, typo correction, and anti-phishing protection, but also a handy little feature called shortcuts, which lets you map a short term to a long URL via the address bar. This feature is pretty identical to FireFox's Smart Keywords, but they will work on any computer and any browser! As a Drupal developer, I have found the following shortcuts very useful to quickly get to certain areas on drupal.org:

So if I type "dpi path_redirect" in my browser's address bar, I will automatically be directed to http://drupal.org/project/issues/path_redirect. Do you have any handy shortcuts that you use? Please comment and share them!

Pages

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web