Structured content is central to the content strategy for our new Drupal-based Mass.gov. So is the idea of a platform-agnostic design that can be reused across our diverse ecosystem of web applications, to encourage a consistent look, feel, and user experience. We’re not the only ones with these priorities for our new digital platform. So we can’t be the only ones wrestling with the unsolved authoring experience implications either. This blog post is an attempt to articulate the basic problem and share our best, latest idea for one possible solution. As the saying goes, ‘If you want to go fast, go alone. If you want to go far, go together.’ We want to go far. If you like our idea, or if you have other possible solutions or insights, please share them with us in comments below, or by tweeting at us @massgov, or contact me at @bryanhirsch. Let’s go together.

Problems:

Drupal has made major strides toward improving the content authoring experience in recent years: Acquia’s Spark project in Drupal 7, Quick Edit in Drupal 8, and Edward Faulkner’s integrations with Ember. But (1) our vendors for Mass.gov have unanimously dissuaded us from leveraging these innovations in our new authoring experience because with complex data models it’s costly and highly customized to make in-place editing through the front end work. (2) This challenge is compounded by the desire to keep our design portable across diverse web properties, which means we want to keep Drupal’s Quick Edit markup out of our Pattern Lab-based component library. Additionally, (3) if we get structured content right, our Mass.gov content will be reused in applications we don’t control (like Google’s knowledge graph) and in an increasing number of government website via APIs. It’s both cost prohibitive and practically impossible to create frontend authoring UIs for each of these applications. That said, if we move authoring away from the front end in-place editing experience, (4) authors still need detailed context to visualize how different pieces of content will be used to write good content.

Here’s one possible solution we’re interested to explore that seems like it should address the four issues outlined above: Move high-fidelity live previews to the backend authoring experience, displayed alongside the content editing form as visualized in the designs below.

Visual design of possible UI for live preview of different components from the Pattern Lab-based Mayflower component library, incorporated into the backend Mass.gov authoring experience. View additional designs here.

By showing authors examples of how different pieces of content might be used and reused, we can give writers enough context to write meaningful structured content. But maybe we only need to give authors enough examples to have reasonable interactions with all the different content form fields. If this works, then we don’t have to try and keep up with an infinitely growing and changing landscape of possible new frontends. Pattern Kit (here) and Netlify CMS (here) both offer working, open-source, examples of how this authoring experience could work.

Mass.gov is not a “decoupled Drupal” ecosystem yet. Our API strategy is in its infancy. We know other people with much more experience are thinking about the same issues. Maybe some are even writing code and actively working to develop solutions. If this is you, we’d love to hear from you, to know how you’re approaching these problems, and to learn from anything you’ve tried here.

It was recently announced that 2020 will be the year Drupal 9 is officially released into the wild. The exact date hasn’t been set, but we can now look forward to the 9.0 release that year. The announcement also gave us an official End of Life date of November 2021 for Drupal 7 AND Drupal 8. So, what does this mean if you’re currently running or developing a site on one of those versions? In this post, I’ll explain.

What this means for Drupal 8?

Drupal 8 is built around a concept of continuous innovation. What this means is that new features and backwards-compatible changes are continuously added. When an old system or code is depreciated, instead of removing it, it stays in the codebase. This ensures that custom code and contributed modules will continue to work and have time to update. Eventually, there will be an excess amount of depreciated code and dependencies and there will be a need to remove it. That is one of the reasons for the release of Drupal 9. All that old stuff gets removed and we start fresh with the latest and greatest technology.

The great thing about Drupal 8 is that by the time Drupal 9 is released all of the modules and custom code in your site should be up-to-date. Therefor, updating from 8 to 9 is no different than from 8.5 to 8.6. Clean and painless!

And that’s the point. This method of building and releasing versions will continue for the foreseeable future which is why we like to say that a migration to the latest Drupal will be the last migration you ever need.

What this means for Drupal 7?

Unfortunately, Drupal 7 is a different story. When Drupal 7 reaches end of life in November of 2021, it will no longer be supported by the community at large. There are plans to release a Drupal 7 version that uses the latest version of PHP. There is also a paid support program planned (similar to Drupal 6 LTS) that will allow people and organizations unable or unwilling to migrate to continue to keep their sites secure. But really, your best course of action is to plan for a migration to Drupal 8 by 2020. This keeps your site current and guarantees it’s security moving forward.

The codebase between 7 and 8 is entirely different so a migration to Drupal 8 is a pretty big undertaking. You could call it replatforming. Drupal 8 does however include a built in data migration tool that will make the move easier. You might still need some help though depending on your site requirements and edge cases. Plus, data is one thing, but you would also need to move your theme, too. The silver lining is that migrating presents an opportunity to freshen up the look of your site and increase site speed with the latest software. For more information on what is involved in a migration, check out this post.

Like I mentioned earlier in this post, a migration to Drupal 8 may likely be the last migration you ever need since subsequent major version updates (i.e. from 8 to 9) should be very quick and easy. Once you’ve made that initial investment migrating to Drupal 8, you can rest assured that you won't have to go through that process again, possibly forever.

Migration experts

Acro Media is a Drupal agency specialized in eCommerce. We help build and maintain successful eCommerce websites as well as the underlying Drupal Commerce platform. We are also heavily involved in the development of Drupal’s migration tools. If you want to discuss what a migration might look like for your business, talk to us! We’re happy to help.

Although it can sometimes be easy to forget about that little URL bar at the top of your browser, what it contains for each page can be surprisingly important. Creating good paths (the part of the URL after the domain name) for your site content can have numerous benefits, especially for SEO, but doing so can be a bit frustrating. Usually, you end up needing to re-type most of the page title into Drupal's URL alias field, which isn't necessarily too bad on its own, but it's still an extra step whenever you create content. And what about when you update the page and change the title? This is where it gets very easy to forget to change the path, which can lead not only to worse SEO but also to your site's visitors not ending up on a page with the content they expected it to have.

Fortunately, the Pathauto module makes all such worries a thing of the past.

This module adds a whole host of new options to how you can configure Drupal's paths, perhaps the most important of which is path "patterns". Patterns allow you specify what you want your paths to look like for different pieces of content; for instance, if you have a site where each of its users can have a blog, you could set up a pattern for Blog nodes such as "/blog/[node:author]/[node:title]". Then, whenever a user creates a blog post, it will automatically be given an alias which includes their username and the title of the post, and it will even update the alias if the user edits the post to change its title.

If you already have a site which has inconsistent aliases, Pathauto can also be used to bulk generate new aliases for your content, which is also quite helpful if you ever decide you want to change the structure of your paths. The module also offers plenty of settings to configure exactly what the paths it generates look like, including the ability to use a wide range of tokens provided by the Tokens module.

Finally, Pathauto also integrates with the excellent Redirect module. If you have both modules installed, changing the title of your content won't just change the path, it will also create a redirect from the old path to the new one so that any links already out there to the old URL will continue to function as expected. This is a rather important bit of functionality, and thanks to Drupal's great selection of contrib modules, it's just a few clicks away from being set up and working on your site.

Recently, The Guardian Insurance Company made the strategic business decision to start marketing and selling their products directly to consumers. While Guardian has been around for nearly 160 years (WOW!) most consumer experiences with their products stem from employer insurance coverage offerings. As the industry landscape evolves and the US workforce moves slowly towards distributed and independent employment Guardian endeavored to differentiate their offerings not only from industry stalwarts but also from up-and-coming, startup-like products catering to the same demographics. Mediacurrent was proud to be chosen by Guardian Insurance Company as their Design and Strategy partner during product development of their new direct-to-consumer website.

Now that the site has launched, we’re happy to share some behind-the-scenes details of how this fresh, new experience came together. While our Case Study gives a broader overview of the project, this blog post will provide additional insight into our data driven design process.

Part 1 of this 2-part series covers the early planning parts of our process including Strategic Design Discovery, Style Tiles, and Wireframing. Part 2 will cover Mockups & Visual Design, Custom Illustration, and Custom Iconography. Let’s dive in!

Strategic Design Discovery

A Discovery phase begins many of our projects at Mediacurrent. This phase is led by a cross-functional group of our world-class team to help frame the challenges ahead. Throughout this phase, comprehensive knowledge of the Guardian brand, its customers, its competitors, and its business were gathered. These strategic design discovery insights allowed us to understand the types of consumers the new product is being geared towards (user personas), how success is being measured (Key Performance Indicators or KPIs), the ways in which a person becomes a customer (conversion paths) and a boatload of other data that served as our “guiding light” throughout the process.

Wireframes

Next, we moved on to really digging into the user personas and conversion paths generated in the Discovery phase by creating wireframes for the different sections of the site. One of the most exciting parts about this project was that we were not only designing the marketing section of the site but also the entire customer experience from the point where the visitor is attracted, becomes a lead, and eventually converts to a customer. This means that in addition to top-level marketing pages – like the home, about, and product pages – user journey designs were also needed for getting a quote and enrolling in one or multiple products.

Throughout the wireframing process, we broke down the different types of pages and sections of the site that users will encounter when visiting and organized the placement of content and calls-to-action (CTAs) by mapping the layout structure to the user journeys and KPIs identified in Discovery. Working from the Mobile First perspective, we made sure to consider this hierarchy not only on desktop machines but also tablets and mobile phones. In this case, we decided to take a medium fidelity approach – meaning that we avoided color or imagery in order to maintain focus on content organization and the user journey. We did include the typographic and iconography styles defined in our approved Style Tile, and we simulated actual copy since the process included quoting and checkout workflows which would not have made sense with greek copy.

In the end, these blueprints ensured that the user experience was providing the clearest path for a visitor to learn about the products, understand the cost and coverage offered, then ultimately enroll in a Guardian Insurance plan.

The goals mapped through the top-level marketing page wireframes were not only to educate the consumer about the company and the products offered but, more importantly, to serve as a hassle-free gateway to the actions the business measures – namely generating a quote and enrolling. On the homepage, Guardian wanted to make sure a newly developed brand message – Life is full of surprises. The cost of paying for them shouldn’t be. – was clearly communicated so we even started to play with some interaction suggestions.

Desktop, tablet, and mobile homepage wireframes.

The goals mapped through the quoting experience provided a simple way to understand the cost and coverage offered for a variety of different types of consumers – single person, couple, children, adult dependents, etc.

a) keep the experience as simple and logical as possible for all types of visitors; b) allow them to enroll in one or multiple products at the same time;c) gather all legally required information and consent – which varies between products.

Desktop-width wireframes of the Enrollment (or checkout) process.

Along with these broader page-level experiences, microinteractions – such as saving and retrieving quotes – were considered and wireframed to ensure that the experience was cohesive.

Style Tiles

With these insights in hand, we began creating Style Tiles that took the brand’s visual guidelines, placed them in an interactive digital context, and expanded on them where we saw the need and/or opportunity. This process created a high level view of the visual tone of the new website. Adding a bit of complexity, Guardian was deep in the midst of a larger corporate rebrand when our project began. In this case, we had to consider the existing brand guidelines, be flexible enough to incorporate new brand elements as they were provided, and ensure that the digital experience was coherent, unique, and accessible to all users – a critical concern identified during Discovery.

Three concepts were presented initially:

1. New Blue Suit

– This concept expresses subtle sophistication through the use of color, typography, and whitespace. It relies heavily on the brand’s primary blue hue as a color that reinforces trust, loyalty, and integrity. An overall contemporary, minimalist approach is suggested as a means of reducing cognitive load. The icon style followed these principles as well by choosing an outline style with subtle monotone accents. Typographically, we included the fonts defined in their brand guidelines in order to maintain consistency with existing materials.

2. Happy Place

This concept is lively and pleasant using bright colors to create a friendly experience. We expanded the brand color palette to add cheerful, accessible hues able to be used in a variety of UI elements. Typographically we pushed the existing brand guidelines by incorporating a new font – Open Sans – as its wider variety of weights allows it to be used more expressively than the currently defined Arial family. Our type treatments utilized a lighter weight body font to balance the heavy use of color and maintain valuable whitespace. The icon style suggested takes a more fully-realized illustrative approach making use of the expanded color palette and adding dimension through highlights and shadows.

3. Gilded Skies

This concept reduces the color palette and adds trendy accents. Broader than New Blue Suit, but more restrained than Happy Place, this example’s color palette features a rich gray, trusted blue, and adds shades of gold to suggest value, elegance, and quality. Here we’ve suggested a hand-drawn icon style that personalizes the experience with a more genuine feel. We also included photography style suggestions that feature color and light effects to extend the color palette and maintain a clean and crisp look.

Through this exercise, we were able to understand just how far Guardian was willing to push their existing brand and create a final document that was approved by all stakeholders as the visual voice we wanted to achieve with the final product. In the end, and with a few iterations in between, we landed on what was essentially a blend New Blue Suit and Gilded Skies as the path forward. This final Style Tile was chosen in order to maintain consistency with Guardian’s larger, existing brand guidelines while introducing elements that would help create a more casual tone appropriate for the demographic of their direct-to-consumer offerings.

Stay Tuned!

Our process does not end here but part 1 of this post does, unfortunately. :( Keep an eye out for part 2 where we’ll dig into the visual design details of the site! We’ll look at different visual concepts that were created, how the design was finalized with custom illustrations and iconography, and the component-driven approach we follow. For now, just direct your feet to the sunny side of the street!

The Media module made its way into Drupal core for the Drupal 8.4 release a while back. It gives Drupal users a standardized way for managing local media resources, including image, audio, video, and document files. We wanted to add using this module into our Drupal Commerce demo site to give an example of how this module could potentially be used in a Commerce setting.

In this Tech Talk video, I’ll quickly show you how we updated our digital download Commerce product example to use the Media module, giving us the flexibility to add audio samples to the product page and access to the full download after purchase.

[embedded content]

Background

The product I wanted to update is the Epic Mix Tape by Urban Hipster digital download example product. This is a fake album featuring all of your favourites by artists you’ve never heard before. The idea is to showcase that you can add digital products to a Drupal Commerce based online store, not just physical products.

Originally we were using just a standard file field that, when checkout was completed, gave the customer access to download the file. This was done before the Media module made its way into core. Now that the Media module is in core, we figured it’s time to update it.

Setting up an Album media type

When the Media module is installed you get some new admin menu items. The first is a section called Media Types (under Structure) where you can configure your media entities like any other Drupal content entity. Here I created an ‘Album’ media type with two unlimited file fields, one for sample audio tracks and one for the full audio tracks. This is the basis for creating my downloadable albums.

The second admin menu is under Content. Here you get a new Media tab which is where you can add, edit and remove any media items. Since I already created the Album media type I can now add the Epic Mix Tape album files here. This completes the media side of the updated digital download product. All I need to do now is update the product configuration to use it.

Completing the digital download product configuration

Now that the media type has been added and I’ve uploaded an album, I need to set up a way to use it. It’s pretty easy to do. First, for the digital download Product Type, I add an entity reference field to give a way for selecting the album media entity to use for the product samples.

I then do the same thing for the Product Variation Type. This one, however, will be used to give access to the full files after purchase.

Finally, some template updates. The Drupal Commerce demo site has some pretty custom template files for the products. In the template, I access the media entity directly and loop through the items, printing each audio sample and track title onto the product page. I do the same thing for the checkout complete page but print out the full tracks instead.

Depending on your templates and display settings, you can get similar results without manually accessing the files in the template file, however I wanted to print out the file description with the audio player right on the page. Showing the description unfortunately is something you don’t have the option of doing using the standard audio display widget.

And that’s it! Check out the Urban Hipster Drupal Commerce demo site below to see it in action.

I was recently looking at all the default views that come with Drupal 8. For people who don’t know, the Views module is part of Drupal 8 core. In Drupal 7 and below it’s the most installed module so during Drupal 8’s development it was decided to move Views into core.

During my exploration into all of the default Views, I noticed that in the People (User) view there was a filter called “Combine fields filter”.

Now just a quick side note, if you’re new to Drupal and Views I’d highly recommend you spend time walking through all of the default views and see how they were configured. You can learn a lot just by seeing how things are set up.

The “Combine fields filter” does a pretty cool thing. It allows you to search across multiple fields or put another way, it allows you to combine fields and then filter by their combined value.

How to use “Combine Fields Filter”

Using this filter is relatively straightforward. Just click on Add in the Filter criteria field-set. Search for the filter by name or select Global from the Category drop-down.

When configuring the filter, you can select which fields you want to search from the “Choose fields to combine for filtering” drop-down.

If you want to see what the actual query looks like, turn on “Show the SQL query” from the Settings page (admin/structure/views/settings).

Then in the preview area, you should see the query that gets generated.

The above example is from the “People (User)” view.

Summary

If you want to add basic filtering across fields to your views, then this is the way to go. It’s useful for those custom admin pages which we create to help editors manage content. If you’re looking for something more advanced such as keyword searching, then look at using Search API.

About Ivan Zugec

Ivan is the founder of Web Wash and spends most of his time consulting and writing about Drupal. He's been working with Drupal for 10 years and has successfully completed several large Drupal projects in Australia.

Whilst at Drupal Europe last month, I was privileged to be invited by Drupal’s founder, Dries Buytaert, to a round table discussion, aimed at further marketing the Drupal project.

Bringing together a number of leaders from the Drupal community, we all shared the same desire to boost the marketable assets of the open source platform. One of the ways we hope to achieve this publicity is by creating a comprehensive, customer-facing "Pitch Deck".

The session began as a workshop, facilitated by Adam Goodman. We were guided to identify opportunities for delivering the benefits of Drupal to the uninitiated. The ultimate objective is to encourage the adoption of the Drupal platform. Consensus was reached that we focus upon three separate initiatives.

We're not competing with one another, yet we’re not helping each other either. Our role as leaders is to activate the assets that already exist in the community. Bert Boerland

One of these three initiatives is a plan to create a comprehensive, customer-facing marketing resource, or "Pitch Deck". The resource will present Drupal’s credentials in a persuasive manner, containing impressive exemplar case studies, to ease the process of convincing an organisation or client to choose Drupal.

The Team

I volunteered to take overall responsibility for the creation of the end result. Joining forces with Suzanne Dergachevaand Ricardo Amaro, who bring rich, varied perspectives and skill sets, I feel confident providing the basis for this universal toolkit. But we can only be truly successful if many others contribute to our initiative. We need sales people, marketers, copywriters to join our cause.

Providing a single and persuasive resource, available for all Drupal promoters, to sell the powerful advantages of Drupal will benefit all who use it. With strong consistent messaging, and bolstered by the many Drupal success stories, the deck will position all advocates better to expand the Drupal market share across many scenarios.

With a core team of fellow Drupal professionals, we plan to cover as many topics as we can identify, from security, accessibility and performance functionality through to specific industry verticals, like Higher Education or Media. The key intention is to show how Drupal can adapt to fit projects of all shapes and sizes, across all industries.

The Benefits

Many of Drupal’s competitors (think Wordpress, Squarespace etc.) are widely publicised and, consequently, innately popular. In many cases, Drupal may well be the ideal platform for a project, but it risks losing out to competing CMS providers as the success and potential of Drupal is not easily demonstrated.

Our intended users are sophisticated purchasers. As they ask more and more questions, our responsibility grows to equip agencies with comprehensive information. By using the collaborative resource, agencies will be able to accurately sell the Drupal platform, whilst spending more of their energy and resources focusing on the services they deliver. Freeing up time from writing and re-writing duplicated Drupal sales, organisations will be left to promote their unique strengths.

The Plan

We plan to kick off the project by identifying the high-level requirements and the mechanism to create the slide deck. From there, we hope to crowdsource for support, and seek volunteers from the wider business community. By recruiting sales people, marketers, copywriters and subject matter experts, we hope to create a well-rounded resource, targeted at the varied stakeholders of a new Drupal development project.

By working together, embracing open source ideals, we hope to rapidly achieve the first incarnation of the slide deck, ready for it to be built upon in the future. The sooner we create a draft, the sooner we can share the potential of Drupal with a wider audience. Projects like this prove that you needn’t be a web developer to be part of the welcoming Drupal community.

Get Involved!

If you’re interested in getting involved with this innovative project, please get in touch via our web form. Any contributions, big or small, will be gratefully received, as we strive to convert this idea into a reality.

Previously, we covered some simple tips that allow you to get more out of Drupal and I think we covered some basics. This time we are going to go a bit deeper to see what Drupal can really do. In the right hands, Drupal can be a very powerful tool for more than just content management. The following tips will take you through a few different topics to get more out of Drupal than ever before. Some of these tips are a bit more on the advanced side, but they are very useful.

Tip #1: Don't be afraid of caching

If you are at all familiar with website caching, then you know at least two things about it. It is useful for getting your pages to load faster, and it can be very complex. Caching is meant to speed up your site by putting your page together just one time and then simply redisplaying that rather than needing to build it anew every time. However, because of this, when something about how that content should display changes, that particular entry in the cache needs to be "invalidated" so that it doesn't continue to be used, which could result in it showing content that is no longer current.

Fortunately, Drupal 8 has a fantastic caching system, provided by two modules which are included in Core: Internal Page Cache and Internal Dynamic Page Cache. The former caches entire pages for users who aren't logged in, while the latter caches the individual components of pages (such as blocks and rendered nodes) for all users. On most Drupal sites, these should both be turned on. Drupal Core and most contributed modules are built with this caching already in mind, so it's easy enough to just turn on the modules and get a nice performance boost from doing so.

If you have lots of custom code which deals with how content renders, this may not be quite so simple, but it is still something worth looking into, especially if your site sometimes feels a bit slow.

Tip #2: Remove modules you don't need

Drupal, by default, usually comes with a whole suite of modules installed, some of which not every site needs. These include, for example, the Tour module (for creating tutorial-style interfaces which highlight certain parts of your site in) and the Search module (which provides Drupal's default searching mechanism and is useful only when your site doesn't warrant a different search solution). If you don't actually need a module, uninstall it, and if it is a contrib module rather than a core module, you can then remove it from your site's code entirely.

Every unnecessary module you have on your site can add clutter to the admin UI which makes it harder to find the things you actually want, and since each module can have its own potential security risks, uninstalling the ones you don't need can even help improve your site's security and stability.

Other core modules which are good candidates to consider removing are CKEditor (for sites which don't need WYSIWYG content), Color (for when you're using a custom theme and don't need to change its appearance through the UI), and Comment (if your site doesn't allow users to comment on content anyway). And that's just core modules in the C's!

Just be careful not to uninstall modules such as the Internal Page Cache module, which may not be specifically required to provide the site's intended functionality but which are important for keeping your site working smoothly. Consider each enabled module individually (and then, do the same with enabled themes!)

Tip #3: Use the latest version of PHP

Drupal is written in PHP and is designed to take advantage of the new features and performance improvements provided by its latest versions. Although Drupal 8 can run on PHP versions as old as 5.5, it is now optimized for and fully compatible with PHP 7.2, and so a simple PHP version update can be a great benefit for your site's speed and reliability. You can check which PHP version your site is on from Drupal's Status report, and your hosting provider should provide a way to upgrade PHP if necessary.

Important: Versions of Drupal prior to 8.5 are only compatible up to PHP 7.1. If you're on Drupal 8.4 or older, you should be sure to update Drupal (which is an important thing to do anyway to get all of its latest features, bug fixes, and security updates) prior to switching to the new version of PHP.

Tip #4: Manage config the Drupal way

We've spoken a bit before about configuration management in Drupal 8, but it's important enough it's worth mentioning again. Back in the Drupal 7 and earlier versions, deploying changes to a site typically involved recreating a whole bunch of "clicks" in the user interface, to arrange fields and blocks, API settings, user roles and permissions, and pretty much any other aspect of the site's configuration. Drupal 8 makes that a whole lot simpler with its configuration management system. Although managing config can get quite complex for some sites, for most it is simple. Once you've made a bunch of changes on your development site that you want to roll out to live, you can export those changes into a zipped collection of YAML files. You can then upload that zipped file directly to your live site to import the changes, or save the YAML files into your codebase and roll them out alongside your code changes. We prefer to use the latter method since it also has the benefit of keeping your config in your version control system, but either method works fine, and a direct upload of config can be a bit simpler to manage.

Tip #5: Join the community

Drupal is open source software and is built by a large community of developers and designers from across the world, and joining that community by signing up for an account at drupal.org can result in some tangible benefits for your site. One easy benefit of this is that if you come across a bug in Drupal or one of the contributed modules you are using, or even if you just find that some feature you'd like it to have is missing, you can post a message in the drupal.org issue queues to get a discussion started with the very people who can make the sort of improvements you want. Often, if you search the issue queues, you may even find that somebody else has thought of the same thing you have, and there might even be a patch already available to give you the functionality you want.

If you've had to create any custom modules or themes for your site, and they may be the sort of thing other people may find useful as well, it may be good to consider contributing them. If other people start looking at and using your custom modules, they may find ways to improve it and may even submit patches to fix bugs or add new features. Then it's easy to update your module with their recommendations, making it even more useful both for you and for the rest of the Drupal community.

There you have it. Five more tips to get the most out of Drupal. Some of these might seem obvious, but they are some big wins you can make for yourself and your website. We’ve been working with Drupal long enough that some of these seem like second nature and in time they may also be that way for you. Stay tuned for more Drupal tips in the future!

Such a feature would put an end to all those never-ending debates and ongoing discussions taking place in the Drupal community about the expectations and concerns with implementing such an auto-update system.

Moreover, it would be a much-awaited upgrade for all those users who've been looking for (not to say “longing for) ways to automate Drupal core and modules for... years now. Who've been legitimately asking themselves:

“Why doesn't Drupal offer an auto-update feature like WordPress?”

And how did we get this far? From idea to a steady-growing initiative?

first, it was the need to automate Drupal module and security updates

then, the issues queues filled with opinions grounded in skepticism, valid concerns and high hopes started to “pile up” on Drupal.org,

then, there was Dries' keynote presentation at Drupalcon Vienna in 2017, raising awareness around the need to re-structure Drupal core in order to support a secure auto-update system

Many concerns and issues have been pointed out. Many questions have been added to the long list.

Yet, one thing's for sure:

There still is a pressing, ever-growing need for an auto-update feature in Drupal...

So, let me try to answer my best to some of your questions regarding this much-awaited addition to Drupal core:

What's in it for you precisely? How will an auto-update pre-built feature benefit you?

Does the user persona profile suit you, too? Is it exclusively low-end websites that such a feature would benefit? Or are enterprise-level, company websites targeted, as well?

What are the main concerns about this implementation?

1. The Automatic Updates Initiative: Goal & Main Challenges

Let's shift focus instead and pass in review the inconveniences of manually installing updates in Drupal:

it's time-consuming

it's can get risky if you don't know what you're doing

it can be an intimidatingly complex process if you have no dedicated Drupal support & maintenance team to rely on

it can get quite expensive, especially for a small site or blog owner

See where I'm heading at?

This initiative's main objective is to spare Drupal users of all these... inconveniences when it comes to updating and maintaining their websites. Inconveniences that can easily grow into reasons why some might get too discouraged to adopt Drupal in the first place.

And now, let's dig up and expose the key challenges in meeting this goal:

enabling update automation in Drupal core demands a complete re-engineering of the codebase; it calls for a reconstructing of its architecture and code layout in order to support a perfectly secure auto-update system

such an implementation will have a major impact on the development cycle itself, causing unwanted disruption

such a built-in auto-update feature could get exploited for distributing and injecting malware into a whole mass of Drupal websites

2. Automatic Updates in Drupal: Basic Implementation Requirements

What would be the ideal context for implementing such a perfectly secure auto-update system?

Well, its implementation would call for:

multiple (up to date) environments

released updates to be detected automatically and instantly

an update pipeline for quality assurance

existing automate tests with full coverage

a development team to review any changes applied during the update process

3. How Would These Auto-Updates Benefit You, the Drupal User?

Well, let's see, maybe answering these key questions would help you identify the benefits that you'd reap (if any):

is your Drupal website currently maintained by a professional team?

has it been a... breeze for you so far to cope with Drupal 8's release cycle (one new patch each month and a new minor release every 6 months sure claim for a lot of your time)?

have you ever got tangled up in Composer's complexities and a whole load of third-party libraries when trying to update your Drupal 8 website?

did you run the Drupalgeddon update fast enough?

have you been secretly “fancying” about a functionality that would just update Drupal core and modules, by default, right on the live server?

To sum up: having automatic updates in Drupal core would keep your website secured and properly maintained without you having to invest time or money for this.

4. Drupal Updating Itself: Main Concerns

there is no control over the update process, no quality assurance pipeline; basically, there's no time schedule system enabling you to test any given update, in a development environment, before pushing it live

there's no clearly defined policy on what updates (security updates only, all updates, highly critical updates etc.) should be pushed

with Drupal updating itself, rolling back changes wouldn't be possible anymore (or discouragingly difficult) with no GIT for version control

again: automatic updates in Drupal could turn into a vulnerability for hackers to exploit for a mass malware attack

there's no clear policy regarding NodeJS, PHP and all the JS libraries in Drupal 8, all carrying their own vulnerabilities, too

it's too risky with all those core and module conflicts and bugs that could break through

such a feature should be disabled by default; thus, it would be every site owner's decision whether to turn it on or not

could this auto-update system cater to all the possible update workflows and specific behaviors out there? Could it meet all the different security requirements?

So, you get the point: no control over the update pipeline and no policy for handling updates are the aspects that concern developers the most.

6. Does It Cater for Both Small & Enterprise-Level Websites' Needs?

There is this shared consensus that implementing automatic updates in Drupal core would:

not meet large company websites' security requirements; that it would not fit their specific update workflows

Even the team behind the automatic updates initiative have prioritized low-end websites in their roadmap.

But, is that really the case?

Should this initiative target small websites, with simple needs and writable systems, that rarely update and to overlook enterprise-level websites by default?

Or should this much-wanted functionality be adjusted so that it meets the latter's needs, as well?

In this case, the first step would be building an update pipeline that would ensure quality.

What do you think?

7. How About Now?"What Are My Options for Automating Updates in Drupal?"

In other words: what are the currently available solutions if you want to automate the Drupal module and security updates?

7.1. You Can Use Custom Scripts to Automate Updates

… one that's executed by Jerkins or another CI platform.

Note: do bear in mind that properly maintaining a heavy load of scrips and keeping up with all the new libraries, tools, and DevOp changes won't be precisely a “child's play”. Also, with no workflow and no integrated tools, ensuring quality's going to be a challenge to consider.

7.2. You Can Opt for a Drupal Hosting Provider's Built-In Solution

“Teaming up” with a Drupal hosting provider that offers you automated updates services, too, is another option at hand.

In this respect, solutions for auto-updating, such as those provided by Pantheon or Acquia, could fit your specific requirements.

Note: again, you'll need to consider that these built-in solutions do not integrate with your specific DevOps workflows and tools.

And my monologue on automatic updates in Drupal ends here, but I do hope that it will grow into a discussion/debate in the comments here below:

Would you turn it on, if such a feature already existed in Drupal core?

The Drupal Unconference is coming up in November and we can’t wait! Following the huge success of last year's event, we are once again proud to be Silver Sponsors of this alternative annual conference.

As active members of the Drupal community, several of our team are already preparing lightning talks to pitch on the day. To secure attendance for the majority of our large Drupal team, we have just bought a batch of tickets. To avoid disappointment, we encourage you to do the same!

[embedded content]Co-organiser, Eli, on what to expect

This year’s Unconference will be held on 3rd November at The Federation, Manchester. The annual unconference breaks the mould, with an informal, accessible programme. All talks are planned on the day by the attendees rather than organisers. Representing open source ideals, Unconference recognises that the best ideas can come from anyone, no matter their experience. First-time speakers and long-term contributors have equal opportunity to share their insights into the Drupal Content Management System.

For the second year in a row, we are proudly sponsoring the event and attending en mass. Our developers are preparing talks on a wide range of topics: from front-end design using Pattern Lab, to a bold career change, swapping auto body repairs for Drupal development. The unplanned structure of the Unconference enables speeches that are reactive to recent topics and events. As such, we expect some competition for the most innovative talk this year!

Not sure what to talk about?

You can reach beyond Drupal core and open source code. Unconference presentations will address a wide range of digital topics. With talks and insights expected to cover UX, databases, frameworks, security and front-end design. Web developers, devops, project managers, designers and marketers can all expect relevant and actionable takeaways from the event. Website owners and end users, no matter their technical experience, are welcomed to the inclusive conversation.

Unlike Drupal sprints, which focus on delivering working software and contributed modules, the Unconference is designed to be a rich learning environment. Offering real-world case studies and ideas, NWDUG invite anyone to share their digital experiences.

Hosted at The Federation, the 2018 event will be bigger and better than ever. With more space comes more opportunities for different speakers and discussion groups.

[embedded content]Explore the Venue

Last year’s event was a huge success, so we are optimistic for Unconference 2018 to be the best yet. We are excited to see new faces and new innovations from the open source community.

Join the welcoming Drupal community this November 3rd for a day that celebrates inclusivity, accessibility and open source software.

The Urban Hipster Drupal Commerce demo site was built to showcase what Drupal 8 and Commerce related modules can do. While the main focus has been Commerce, recently I started enhancing the content side of the site, mainly the blog. After all, Drupal is a content publishing platform at its core, so why not show how content and commerce can work on the same platform together. In the ecommerce world, that’s actually a pretty big deal!

In thisTech Talkvideo, I’ll show you how the Drupal core Comments module is used for blog commenting and product reviews. I also go into detail on how you can configure a role based publishing workflow using core’s Workflows and Content Moderation modules.

[embedded content]

Comments and reviews

All of the blog posts and products on the demo site use the core Comments module for customer feedback. This allows any level of user (anonymous, authenticated, etc.) to add comments or reviews to these content items. The configuration and permissions for the Comments module controls whether or not the comments need to be approved by an administrator before they appear on the site. When logged in, an administrator who has permissions to manage the comments can use both the frontend interface as well as a backend interface for deleting, approving, editing and finally replying to the comments.

Like any content entity in Drupal, comments are fieldable. This means that you can configure fields to allow for additional functionality for your comments. It’s not covered in this video, but it’s worth mentioning that this is how I was able to get a 5 star review system easily integrated into the product comments.

Content moderation workflows

Drupal core also has a couple modules for letting you define a process for adding specific types of content to your site. The Urban Hipster blog is now setup to be an example for this.

The first aspect to configure is the workflow. Workflows is where you determine what content will make use of the workflow, the “states” that the content will transition through, and finally the transitions that can happen at any given state. These things all need to be configured first before moving on to permissions.

The second aspect is assigning role based permissions to use the workflow. Permissions for workflows are found in the usual permissions backend page where all other permissions are set. Each workflow transition has a permission attached to it and so you just simply check the role that can perform each transition. You can create new roles if you need to.

View the live example

As mentioned, the Urban Hipster Drupal Commerce is an example of what can be done. Try it out yourself and see what you think. Here are some username/password combinations that will let you check out the workflows in action. The site refreshes every night so you don’t need to worry about breaking anything.

Culture. It's the only truly sustainable competitive advantage for a Drupal business. But what does that look like in action? I've seen firsthand how that culture extends far beyond Mediacurrent's business and customer service approach, shaping the way we network.

We have all been to a party, lunch, or even coffee and cookies with a vendor trying to make a connection with you or your company. You can separate all of these into two basic categories: those that you walk into and have fun and those you walk into defensively because you know the goal is to pitch a sale to you.

Hosting a networking event can be a costly endeavor for your company and there is no guarantee that you will receive a high percentage of return on your investment. Between your time investment, activities, and potentially cost of a space, expenses can begin to pile up quickly.

Hitting that optimal zone where customers or potential clients will feel relaxed and are open to conversation is key to reaching your maximum potential for ROI for your event. There are several ways you can do this, but it all starts with one word.

Passion.

Passion for what you love is the difference between just hosting an event and connecting with the community in your field of business. The goal is to show your passion for what you do, and the community you are in -- in our case, the open source and Drupal communities.

Take the Dave and Paul approach for example. Over DrupalCon 2018, they threw an amazing after party hosted by Mediacurrent. Everything down to the invites was inclusive to all (not just those with purchasing power) with the message of “Hey, we are throwing a party, come to hang out! Hope to see you there.” Every single person was treated like a friend.

While at the party, the sales team focused on just interacting, listening to people’s experience and thanking the community for showing up. This approach made people feel so comfortable that if they had a sales question, they would just ask.

When a person feels welcomed, unpressured and a part of the group, then it's easy for them to make the leap from conference attendee to a potential client. Remember: you and everyone who attends your function is a part of the same community. If you view them as just potential sales, then this will be translated into your body language and verbiage.

In closing, being a part of the Mediacurrent team has reaffirmed for me the value of networking with authenticity. Hosting your event with the passion you have for the community you are a part of will shine through to everyone who attends and solidify you in their mind as the right partner for their project.

The media management experience had been one of the well-known sources of frustration for Drupal content editors for a long time. For, let's face it: Drupal's out-of-the-box media support was just... basic. But not anymore: there are new exciting features for media handling in Drupal 8.6.0 that will dramatically change the way you manage your media assets on your Drupal website!

As we enter the month of September and start planning for 2019, it’s a good time to take stock of where Drupal is as a project and see where it’s headed next year and beyond.

Dries Buytaert, founder of Drupal, recently wrote his thoughts around the timeline for Drupal 9 and “end of life” for Drupal 7 and 8. We will look at current Drupal 8 adoption and assess where we sit in 2019 as well.

An important part of this discussion that deserves attention is the rise of Javascript as a programming language, in particular, the rise of React.js. This technology has put CMSs like Drupal in an interesting position. We will look at how React/Javascript are evolving the web and assess what that means for the future of Drupal.

Finally, we will wrap up with thoughts on what these changes mean for both developers and organizations that use Drupal today or evaluating Drupal.

Drupal 8 Adoption

In early September Drupal 8 released version 8.6.0 which included major improvements to the layout system, new media features, and better migration support. This is in addition to many other improvements that have been released since Drupal 8.0 was first unveiled in late 2015.

As encouraging is that news is, it’s still should be noted that Drupal 7’s popularity still far exceeds Drupal 8 both in current usage (800k compared to 210k+ sites) and in terms of growth year over year.

Drupal’s weekly project usage from August, 2018

Drupal 7 will reach its end of life likely around November 2021 with paid support extending the lifetime with commercial support (as was the case with Drupal 6). Will Drupal 8 reach the level of usage and popularity D7 has? Perhaps not but that is largely due to focus on more robust, “enterprise” level features.

Drupal as a CMS sits largely in between Wordpress and enterprise proprietary CMSs like Adobe CMS and Sitecore in the marketplace. With the release of Drupal 8, the project moved more into the direction of enterprise features (which could explain some of the fall-off in adoption).

With the release of Drupal 8, Drupal’s target audience started consolidating more towards the enterprise user. In the future Drupal’s success as a project will be tied more closely to performance against platforms like Adobe CMS and Sitecore in the marketplace.

React (and Javascript) take over the world

The thing about Javascript is that it’s been around forever (in tech terms) but recently has taken off. I won’t detail all the reasons here. Seth Brown from Lullabot has one of the best write-ups I have seen from a Drupal community perspective. In short, the ability now to run Javascript both in the browser and on the server (Node.js) has led the surge in Javascript development. Github shows us that more projects are built with Javascript than any other technology and Stack Overflow’s survey tells us that Javascript is the current language of choice.

Stack Overflow 2018 survey results

Github projects 2018

Dries recognizes the importance of Javascript and has spoken about this recently at MIT. In a bit, we will look at some of Dries’ ideas for the future in relation to the Drupal project.

A few years ago we saw several Javascript frameworks pop up. These became very popular for single page applications (SPA) but also had broader appeal because they could make any website feel more interactive. React.js & Ember.js were both released in 2015 and Angular.js is older but has started getting more attention around the same time.

A big issue that needed to be solved with these frameworks was how to address SEO. Initially, these frameworks only rendered the page in the browser which meant site content was largely hidden from search engines. For SPA’s this was not necessarily a deal breaker but this limited the broader adoption of this technology.

Only fairly recently have we seen solutions that are able to use the same framework to serve pages both in the browser and on the server. Why do I bring this up? Because this has been one of the more difficult challenges and React.js addresses it better than any other framework. There are many reasons why React.js adoption is exploding but this is why I believe React is king.

John Hannah also has some great graphs on javascriptreport.com that demonstrate React’s dominance in this space (see below).

Npm downloads by technology (1 month)

Npm downloads by technology (1 year)

Finally it should be noted that Facebook’s technology, GraphQL paired with React.js is also on the rise and intertwined with the growth of this technology. GraphQL will come into play when we look at how CMSs are adapting to the surge in Javascript and Frontend frameworks.

React and the CMS

Is React compatible with CMSs of ‘ole (e.g. Wordpress, Drupal, etc.)? Well, yes and no. You can integrate React.js with a Drupal or Wordpress theme like you can many other technologies. In fact, it’s very likely that Drupal’s admin interface will run on React at some point in the future. There is already an effort underway by core maintainers to do so. Whether or not the admin will be fully decoupled is an open question.

Another example of React admin integration is none other than Wordpress’ implementation of React.js to create the much anticipated Gutenberg WYSIWYG editor.

Gutenberg editor

In terms of websites in the wild using React with Drupal, there have been solutions out there (TWC, NBA, and others) for many years that use Drupal in a “progressively decoupled” way. The “progressive” approach will still exist as an option in years to come. Dries wrote about this recently in his blog post entitled “How to decouple Drupal in 2018.”

The problem I have with this type of solution is that sometimes you get the best (and worst) of both worlds trying to bolt on a Javascript framework onto a classic templating system. The truth is that Drupal’s templating theme layer is going to have trouble adapting to the new world we now live in (addressed in detail at Drupalcon’s “Farewell to Twig”).

The real power of React is when you can combine it with GraphQL, React router and other pieces to create a highly performant, interactive experience that users will demand in years to come. To accomplish this type of app-like experience, developers are increasingly looking to API’s to address this dilemma, which we will examine next.

CMS as an API

The last couple of years there have been many Cloud CMS-as-an-API services pop up that have been generating some attention (Contentful might be the most popular). At this time it doesn’t appear that these API’s have disrupted market share for Wordpress & Drupal but they do signify a movement towards the idea of using a CMS as a content service.

The “Decoupled” movement in the Drupal community (previously known as “Headless”) has been a big topic of conversation for a couple of years now. Mediacurrent’s own Matt Davis has helped organize two “Decoupled Days” events to help the Drupal community consolidate ideas and approaches. Projects like Contenta CMS have helped advance solutions around a decoupled architecture. Dries has also addressed Drupal’s progress towards an “API-first” approach recently on his blog.

While cloud services like Contentful are intriguing there is still no better content modeling tool that Drupal. Additionally, Drupal 8 is already well underway to support JSON API and GraphQL, with the potential to move those modules into core in the near future.

As I look at the landscape of the modern technology stack, I believe Drupal will flourish in the enterprise space as a strong content API paired with the leading Javascript Frontend. React & GraphQL have emerged as the leading candidates to be that Frontend of record.

Next, we will look at a relatively new entrant to the family, JAM stacks, and see where they fit in with Drupal (if at all?) in the future.

JAMStacks - The Silver Bullet?

Netlify provides some great tooling for static hosted sites and even offers its own cloud CMS. Mediacurrent actually hosts our own website (Mediacurrent.com) on Netlify. Mediacurrent.com runs on Jekyll which integrates with a Drupal 8 backend so we are well aware of some of the benefits and drawbacks of running a static site.

Where Drupal fits into the JAM stack is as the ‘A’ (for API), with ‘J’ being the Javascript Frontend (i.e. React) and ‘M’ being the statically generated markup. Back in 2016 we liked this idea and settled on Jekyll as the tool of choice for our rebuild as it was the most popular and well supported project at the time.

Since then Gatsby.js has risen dramatically in popularity and has a robust source plugin system that enables it to be used as a Frontend for many platforms including Drupal and Wordpress.

The creator of Gatsby, former Drupal developer Kyle Matthews recently spoke on the subject at Decoupled Days 2018. While it’s hard to know if JAM stacks like Gatsby having staying power in the years ahead they do have a lot of appeal in that they simplify many of the decoupled “hard problems” developers commonly run into. The question of scalability is an important one yet to be answered completely but the upside is tremendous. In a nutshell, Gatsby provides an amazingly performant, React/GraphQL solution that can pull in content from practically any source (including Drupal).

Do JAM stacks like Gatsby have staying power? Will these close the complexity gap that blocks more sites (large or not) from decoupling? We will have to stay tuned but the possibilities are intriguing.

Looking Ahead

We have examined the state of Drupal as a project, future release plans and how it is adapting towards a future that is “API First” that also fits well with the React world in which we now live.

The main takeaway I would offer here is that Drupal, while still an amazing tool for managing content, is better suited as a technology paired with a leading Frontend like React. With the web evolving from monolithic systems to more of a services-type approach, it makes sense to use a best-in-class content modeling tool like Drupal with a best-in-class FE framework like React.js.

What does that mean for the average Drupal developer? My advice to Drupal developers is to “Learn Javascript, deeply.” There is no time like the present to get more familiar with the latest and greatest technology including GraphQL.

For organizations evaluating Drupal, I do think the “Decoupled” approach should be strongly considered when planning your next redesign or build. That being said, it’s important to have an understanding of how the pieces fit together as well as the challenges and risk to any approach. This article attempts to present a high-level overview of the technology landscape and where it’s headed but every organization’s needs are unique. At Mediacurrent we work with clients to educate them on the best solution for their organization.

Webform in Drupal 7 was always one of the top 10 must-haves on any Drupal site. Then Drupal 8 came along, and Webform wasn’t in the picture at first. Luckily, Drupal 8 came with the contact module in core that took care of most form needs, and we lived without the Webform module.

In the meantime, Drupal contributor Jacob Rockowitz had been working on the YAML Form module, which was a module used to define webforms in YAML files. At some point towards the end of 2017 YAML Form switched to the Webform namespace and Webform in D8 was born.

The Drupal 8 version of Webform will feel familiar to those with experience in the Drupal 7 version, but this is a completely new module and code base. It’s a really great tool for content creators to use, by giving them the ability to create complex forms without having to worry about code. However, as a developer, I found it tedious to create long forms through the Webform UI. Those days are in the past now, since Webform is a descendant of the YAML Form module, you still have the ability to define a form using YAML in the source tab of the build screen.

Direct editing in YAML really speeds things up for developers, and content creators can still use the UI to create and edit. It’s the best of both worlds.

The Webform module in Drupal 8 is such a powerful and fully featured form builder, that it could be reason enough alone for some site owners to switch to Drupal 8. If you run a site that is in need of new or dynamic forms on at least a monthly basis, then Drupal 8 + Webform would be a lifesaver and a budget saver. Personally, I find that Drupal 8 with Webform rivals any of the standalone form building tools available. There are dozens of features and settings that you get out of the box, and it’s easily extendible if you need to integrate with an outside service.

Like most things in Drupal 8, webforms created with Webform can be exported and synced as config. Webform also plays nice with Features if that’s your thing.

We still custom build many forms in Drupal 8 using the Form API, but Webform is a great tool to keep in mind when things need to be editable by administrators or when you just need a simple solution. It already deals with storage, email, and so many other things out of the box. If you have any webform needs, don’t hesitate giving Webform a shot.

This was the third rendition of this talk since 2015, and in this time our charity, our work, progress of our beneficiaries and our learnings from it have come a long way.

What started as a one way street for transfer of frameworks, tools and strategies from digital transformation to effect societal transformation has gone full circle over past couple of years. Eight years into the journey and am now cross-pollinating approaches and ideas from societal transformation back into my work as a digital transformation coach and consultant.

Suppose it was a matter of time when I started seeing patterns from marginalised individuals and communities back into the work place with disengaged teams and individuals! But that’s for another post!

As mentioned in my session there are two call to actions to further Peace Through Prosperity’s journey to continue and scale our work…

We are looking to partner with organisations on their Corporate Social Responsibility(CSR) programs – kindly reach out to your organisation’s CSR people and suggest sponsoring Peace Through Prosperity just as DropSolid currently do! We are looking to raise €30k with which we’d be able to engage with 800 micro-entrepreneurs in a 12 month period!

Steal our stuff – connect us with your friends, customers and acquaintances in the charity sector, we would like for them to steal our open source products and programs, incorporate them in their existing work and we will support them in the task! it’s free!

My session at Drupal Europe coincided with Peace Through Prosperity running a mini-MBA for our third all female cohort in Lyari, Karachi! here’s 35+ micro-entrepreneurs from a marginalised community in Karachi stepping out of their comfort zone and graduating from the program! Well done ladies!

Interested to learn more? would you like to get involved? Cool! get in touch, you know how to find me!

And lastly I’d like to add a special mention for Druid from Finland! these folks brought along SWAG for kids! their T-shirts are an absolute hit with mine! #Thankyou

Drupal has a bunch of great SEO tools. Here are several tips and suggested modules for fine tuning SEO within Drupal. Easy SEO wins can be achieved through configuring metatags and URLs. Don’t forget to setup an XML sitemap of your site and submit to major search engines. SEO isn’t a once and done effort, make sure to constantly research and update with search trends.

Yes, but is it good for SEO? This is a question we hear all the time when we mention all of the wonderful capabilities of a Drupal site. First off, let's dispel the myth that there is a CMS that automatically does magical SEO and makes all of your pages rank higher in search. If you want good SEO, the most important thing that you can do is write good and unique content that humans actually want to read. The CMS or web software has nothing to do with it. So let's assume that you already have great content and semantically perfect markup, there are tons of other little things that you can do to further boost your content in the eyes of search engines and Drupal is a great tool for implementing them.

To get the most out of Drupal SEO, you are going to want to download a couple of contributed modules from drupal.org.

The following is a list of our goto modules for SEO that I am going to talk about in this post:

Using Metatags to Help Search Engines

Metatags are important for search engines to index, categorize, and understand the content of your webpage. There are a lot of different metatags but a couple that really matter for SEO are the meta description and the title tags. Meta descriptions can be used as a summary in search engines, so it is important to write some compelling content here. It’s the first pitch to a potential site visitor so you may want to put a little thought into it. What if you have hundreds or thousands of pages on your site? The Drupal contributed Metatag module provides a way to dynamically set metatags based on content type, or on other content rules you may have. Working with the Token module you can have all of your metatags, including the description, generated based off of your content. For those pages that you are really trying to squeeze the SEO juice out of, Metatag allows you to override for when you need to fine tune things.

If you want to take things further with metadata, you can also install the Schema.org Metatag module which extends the base Metatag module. You can read more about the Schema.org project here. In a nutshell Schema.org is making a push for people to further define what kind of content they are writing by breaking things into categories of content that a search bot can read. The types of content that they have defined is very granular with deep sub categories. Check them all out here. Having Schema.org metadata, can give you a leg up on your competition as more devices and services start reading and prioritizing web sites based on this content categorization data.

URLs Should be Informative and Human Readable

Having URL paths that make sense can go a long way for SEO. Search engines are able to parse relevance from the words in a URL. For example a URL that is “example.com/node/34” gives no information as to what the topic of the page is. Alternatively, this URL “example.com/store/shirts/blue-shirt” can tell a lot more to a search bot. The Pathauto module enables you to make descriptive URLs. Similar to the Metatag module, you can use this with the Token module to automatically build new URLs based on the type of content you are creating. These are referred to as “patterns” in the Pathauto module. Paths generated by Pathauto can also be changed on a one by one basis, so you can overwrite the generated name in favor of a custom one.

Another useful module related to URLs is the Redirect module. The redirect module does a handful of useful things. Every time you go and change a URL, the redirect module will create a 301 redirect from the previous URL to the new URL. This is helpful when you are updating a page that may have been bookmarked or linked to elsewhere. 301 is the status code that a web server sends when a requested page has been moved and tells the browser to redirect to the new page. 301 redirects are essential to having good SEO, search bots give a poor evaluation to sites with a bunch URLs that go nowhere and humans don’t really like it either.

The Redirect module also comes with a really handy utility page called Fix 404 pages. 404 is the status code that a web server sends when a requested page doesn’t exist. We have all seen these annoying messages from time to time. Sometimes the page has been deleted and sometimes it has simply been renamed and moved, with a 404 message there is no way to know where the page you are looking for is and will leave you thinking that maybe you just visited the page in a dream. The Fix 404 pages utility gives you a report of all of the 404 URLs that your site is sending, it also tells you how many times a URL has been tried and the last time someone tried to go there. This report gives you the opportunity to add a redirect for those 404 URLs and send those users to a relevant page. This is a big boost for SEO because 301 > 404 in the eyes of a search bot.

Provide a Sitemap to Better Direct Search Bots

Search bots work hard, 24/7 365 days a year they are out there crawling the web to make your search experience better. So make it easy on them and provide a roadmap for traversing your site. This is done with an XML sitemap. An XML sitemap is simply an outline of your site’s pages with priority and update frequency all wrapped up in the XML format. We typically build a custom solution for generating an XML sitemap, but there is a Drupal contributed module out there to help you do it without needing to know how to write XML. The XML Sitemap module allows you to configure your sitemap based on things like content types or menu structure. Once you have a sitemap, go ahead and give those search bots a jump start and submit it to the search engines. Each search engine has a different process for doing this, so make sure you submit to more engines than just Google, the XML Sitemap module has a built in tool for submitting to search engines as well.

Research and testing

Lastly, let's talk about Google Analytics and so I don’t have to write that out a bunch of times i'm going to refer to Google Analytics as GA. GA won’t do anything to help your SEO, but it is a crucial tool for analyzing how effective your SEO work has been. The Drupal contributed Google Analytics module makes it easy to set up on your Drupal site. A good SEO strategy is all about testing and adjusting. Make some assumptions about what topics or keywords you think will drive traffic to your site but don’t stop there. Turn your assumptions into tested data with GA. Your website should be a testing ground for new search words, as you see traffic spike up around a search term adjust the rest of your content to cater to those search terms. GA is currently the best tool available for tracking visitors on your site. With testing and study eventually you will land on the right terms and words to use so that the right people find their way to your amazing content.

Yesterday at Drupal Europe, Drupal founder and lead developerDries Buytaert gave a keynotethat outlined the future for Drupal, specifically the release of Drupal 9, and how it impacts the lifespan of Drupal 7 and Drupal 8.

For the TL;DR crowd, the immediate future of Drupal is outlined in the snappy graphic above, and shared again below (thanks, Dries!).

The big takeaways are:

Drupal 9 will be released in 2020.

Drupal 7 end-of-life will be extended out to 2021, even though Drupal usually only supports one version back.

Drupal 7 and Drupal 8 will be end-of-life in 2021.

Wait… what?This proposed schedule breaks with tradition – Drupal has always supported one version back. And this schedule gives D8 users a single, short year to upgrade from Drupal 8 to Drupal 9.

So what now? Wait until 2021 to move your site off Drupal 7? Do two (possibly costly) upgrades in three years? Bail on Drupal entirely?

First and foremost, Don’t Panic.

Let’s explore each of the options in a little more detail to help inform your decision making process.

Upgrade from Drupal 7 to 9

When Drupal 8 became available, a lot of organizations using Drupal 6 opted to wait and bypass Drupal 7 entirely. The same is certainly an option for going from D7 to D9.

On the plus side, taking this route means that it’s business as usual until 2020, when you need to start planning your next steps in advance of 2021. Your contributed modules should still work and be actively maintained. Your custom code won’t have to be reworked to embrace Drupal 8 dependences like Symfony and the associated programming methodologies (yet).

Between now and then, you can still do a lot to make your site all it can be. We recommend taking a “Focused Fix” approach to your D7 work: rather than a wholesale rebuild, you can optimize your user experience where it has the most business impact. You can scrub your content, taking a hard look at what is relevant and what you no longer need. You can also add smaller, considered new features when and if it makes sense. And savvy developers can help you pick and choose contributed solutions that have a known upgrade path to Drupal 8 already.

But it isn’t all roses. Delaying potential problems in updating from 7 to 8 doesn’t make those problems go away. Drupal 9 will still require the same sort of rework and investment that Drupal 8 does. It is built on the same underlying frameworks as Drupal 8. And Drupal is still going to push out some updates to Drupal 7 up until its end-of-life, most notably requiring a more modern version of PHP. Changes like this will definitely affect both community-driven modules and any custom code you may have as well.

Upgrade from Drupal 7 to 8 to 9

“Ginger Rogers did everything [Fred Astaire] did, backwards and in high heels.”

— Bob Thaves

Colloquially, the most efficient way to get from Point A to Point B is a straight line. Major versions of a platform are effectively a line. In this case, you can think of that “straight line” as going from D7 to D8 to D9, instead of trying to go around D8 entirely.

It’s critically important to understand one unique feature of Drupal 9:It is designed from the ground up to be backwards compatible with Drupal 8.

Angie Byron, a.k.a. Webchick, gave an excellent talk about what this really means at BADCamp last year.

[embedded content]

Again for the TL;DRs — “backwards compatibility” means that code is deprecated and ultimately removed from a code base over time in a way that provides a lot of scaffolding and developer notice. This practice results in major version upgrades that require very little rework for the site to stay functional.

The backwards compatible philosophy means that the hard work you do upgrading to Drupal 8 now will still be relevant in Drupal 9. It won’t be two massive upgrades in three years. As long as your Drupal 8 site is up to date and working properly, D9 should not bring any ugly surprises.

Let’s talk community code

When Drupal 8 was released, one of the BIGGEST hurdles the community faced (and continues to face) was getting contributed modules working with the new version. It required ground-up rewrites of… well… pretty much everything. A lot of modules that people were using as “basics” in Drupal 7 were folded into Drupal 8 core. But a number were not, and people volunteering their time were understandably slow to bring their contributed code over to Drupal 8. As a result, many sites were hesitant or unable to upgrade, because so much work would have to be customized to get them to same place the were on Drupal 7.

So will it be the same story going from Drupal 8 to Drupal 9? Will we have to wait years, in some cases, for our business-critical tools to be updated?

According to Dries’ post, the answer is no. Drupal is extending the backwards-compatible philosophy to the contrib space as well.

… we will also make it possible for contributed modules to be compatible with Drupal 8 and Drupal 9 at the same time. As long as contributed modules do not use deprecated APIs, they should work with Drupal 9 while still being compatible with Drupal 8.— Dries Buytaert

Assuming this plays out as intended, we shouldn’t see the same dearth of contrib support that we did when Drupal 8 became a reality.

And yes. There are a lot of assumptions here. This is Drupal’s first pass at a backwards-compatible upgrade methodology. There is inherent risk that it won’t work flawlessly. All we can say for sure is that the community is very hard at work getting to a reliable release schedule. A thoughtful upgrade approach should make the “Drupal Burn” associated with major version upgrades a thing of the past.

If all of this feels overwhelming, contact us. Kanopi Studios is known for its great support (if you choose to stay on D7), as well as great design and build execution (if you choose to go to D8). Whichever way you choose, we’ve got you covered.

The marketing landscape is vastly different than it was when Drupal 7 was released in 2011. Since then, there has been a shift, placing the marketing team in the driver’s seat more often and almost always involved in the CMS decision. In this post, we’ll outline some of the ways you can up your SEO game with Drupal 8.

Traditional SEO is dead.

No longer will well-placed keywords alone get you to the top of the SERP ranks. Content is still King in the world of marketing and it’s what helps you improve your SEO.

Every algorithm change Google has made has one thing in common: it aims to provide the best content based on what it "thinks" the user is trying to find. In other words, - what is the users intent. If you want your rankings to stick past the next update, don't try to cheat the system. Attract your prospects with informative, entertaining pieces that they can use to take action. And avoid no value posts that are keyword stuffed with your industry and the word "best" 100 times. Google can see through it and so can all of your users.

That said, there are a few other factors that are critical to keeping your rankings high that can’t be ignored including quick load times and mobile-friendliness. Drupal 8 is built with several of these factors in mind to help us make needed improvements quickly and effectively.

Mobile First Mentality

Drupal 8 is created with responsive design capabilities built in, so you can begin to address any problems immediately. That’s not to say all of your responsive problems will be solved. Content editors will still need to think through their content and imagery, themers will still need to do configuration to establish things like breakpoints, etc. but Drupal 8 will set you on the right path, giving you and your team many of the tools you need.

You’ll also have the option to choose different images and content for desktop and mobile versions right from the WYSIWYG editor, making it easier to see the differences for every piece of content when you add it and before you publish. This means a solid visual of both versions in real-time for faster publishing and peace of mind knowing exactly what your users experience on any device.

The Need for Speed

Another big factor that could affect your rankings is speed on both desktop and mobile. Google places such high importance that they’ve given you a PageSpeed Insights test to show where and how your website is slowing visitors down. Drupal 8 is “smart” in that it caches all entities and doesn’t load JavaScript unless it has to. This means the same content won’t be reloaded over and over and instead can be loaded quickly from the cache.

Drupal 8 also uses industry-leading caching technology to allow updated content to be served fresh to a client, while preserving the cache on content that hasn’t changed. So, after your visitors come to your website once, they won’t have to wait for all content to load each time, making load times much faster.Another way Drupal 8 improves speed is through feature velocity. Because so much new functionality is built into Drupal 8 core, creating and publishing new dynamic content experiences is significantly faster than in Drupal 7. A blog post that features dynamically updated data, relevant to and powered by your content can be built in the UI in Drupal 8, something that in Drupal 7 would have taken custom development and several modules.

Responsive design is a must-have in today’s digital landscape and speeding up your website on both desktop and mobile is a surprisingly effective way to contribute to your SEO efforts. In short, if you’re marketing team is focused (as you should be) on top rankings, Drupal 8 provides many of the tools to make that happen.

Easy Breadcrumbs - uses the current URL (path alias) and the current page's title to automatically extract the breadcrumb's segments and its respective links.

SEO Checklist - uses best practices to check your website for proper search engine optimization. It eliminates guesswork by creating a functional to-do list of modules and tasks that remain.

Conclusion

Drupal’s content management system is perfectly structured for search optimization and its core features support many of the critical SEO elements. But, SEO is only part of the story. In the next post, we’ll explore some of the do’s and don’ts and things to keep in mind once you’re on Drupal 8.

Choosing a platform on which to build your website can be a daunting task. There is an ever-growing list of content management systems (CMS) from advanced platforms like Drupal and WordPress to all-inclusive DIY website builders like Wix and Squarespace. The right choice depends on factors such as desired functionality, flexibility, available budget, and your ability to manage the site after launch.

Where you fall on the spectrum between mom-and-pop shops and enterprise businesses will also heavily influence your decision.

Mom-and-Pop <—————————> Enterprise

Questions to consider before choosing your CMS

How often do you want to post or update content?

How many content editors will be adding to the site?

Do your editors need varying degrees of access and permissions?

Will your site have a heavy reliance on search, interactivity, or 3rd-party integrations?

Do you have specific design needs that require multiple custom layouts?

Scalability vs Simplicity

WordPress and Drupal have many things in common. Both are open source and freely available, are supported by their developer communities who contribute code to the projects including regular security updates, and offer extensive add-on functionality to the CMS core through plugins and modules.

Site builders or content managers who have used both systems often have a bias for WordPress over Drupal, considering WordPress the more user-friendly of the two. Before one can accurately make such an assessment, I believe the comparison must be apples to apples between comparably sized sites with similar functionality or complexity. If one compares how user-friendly WordPress is for creating and managing a personal blog or small business website that requires no customizations and has static content versus the complexities of using Drupal to build a site for the enterprise with dynamic relationships between various data points, that is not a reasonable comparison. It is true that Drupal has a higher learning curve than WordPress largely due to the amount of available customization that is built into its core. WordPress is simple to use, especially for blogs or small sites, but not necessarily scalable or suited for larger more complex sites. If pushed to the enterprise end of the spectrum above, would WordPress still maintain its user-friendliness and be able to scale? Conversely, Drupal is best suited for enterprise level sites with custom requirements and would add unnecessary development overhead if chosen for a small site or blog.

If WordPress and Drupal were Lego types...

I’ve often thought of Wordpress and Drupal in terms of Lego whereas:

Source: Lego.com

WordPress is like Lego Duplo where you can build things easily with preformed shapes as long as those preformed shapes match your specific needs. These preformed shapes equate to plugins to add functionality and pre-designed theme templates that determine the styles and layout of your site. Duplo blocks are appropriate for ages 1-5 or, in other words, personal projects or small to medium businesses with simpler requirements.

Source: Lego.com

Drupal is like Lego Technic where you can build whatever you can imagine with little to nothing preformed. Like Technic pieces, Drupal has highly configurable plugins that provide granular control over the functionality of your site and do not impose pre-selected designs to your theme. They are appropriate for ages 7-16 or, in other words, medium to large businesses or organizations with complex requirements.

With that analogy in mind, let's explore some of the advantages of each platform.

Advantages of WordPress

Confession: I love WordPress. It’s true! As a non-developer with several personal projects outside of work, whether it was for my consultant friend who needed a five-page site with a contact form, a guitarist wanting to promote his music, or managing several blogs, WordPress meets those needs perfectly. Below are the features that stand out in my experience from which people draw the conclusion that WordPress is so user-friendly.

Dashboard

Upon logging into WordPress you are presented a user-friendly and intuitive admin interface from which you can figure out almost instinctively how to manage your website. You can quickly navigate to various types of content or site functionality from the left rail admin toolbar. The admin toolbar has appropriately named menu items. Hovering over each one triggers a slide out sub navigation making it easy to find the action or setting for which you are looking.

Media Library

Adding images to your content or as a featured image above a post or page is quite simple. With a click of a button, you can add images, audio or video files, documents, and PDFs. Images are automatically given responsive image styles so that they adapt appropriately to the width of one’s browser window or mobile device.

Though not specifically part of the media library, inserting YouTube or Vimeo videos into a post is as simple as pasting the URL. WordPress will render the video as embedded on the page (also works with Twitter and Instagram posts).

Adding Content

As noted above, the Dashboard provides quick access in a few different ways to add new content. The Add New Post (or another type of content) edit page has a visual WYSIWYG editor for formatting your content with links to add media, categories, tags, and visibility of your new post. You can easily view revisions after content has been published and revised with functionality that is provided out of the box.

Plugins and Themes

I’m grouping these two together because here is where we begin to add to WordPress core and its out of the box functionality. I’ve used 3rd-party plugins to add custom forms, simple e-commerce capabilities, invoicing and client management features, automated backups, and SEO enhancements to WordPress sites. The WordPress Plugin Directory boasts 56,182 available plugins to add functionality that is not included or as customizable within WordPress core. Many plugins are completely free or offer freemium versions with more advanced premium features available for a one-time charge or subscription fee.

Likewise, the WordPress Theme Directory offers many free or commercial templates searchable by layout options, features, or subject (topic matter of your site). Themes typically have some customization built-in to control layout options, widgets, background images, and the like.

Updates

WordPress Core, installed plugins and themes can be updated with the click of a button through the Dashboard.

*Plugins are a double-edged sword in that they add flexibility from a non-developer standpoint while simultaneously introducing more risk from a security standpoint. The more 3rd-party plugins you use, the more dependence you will have on those 3rd-parties keeping their code secure by providing timely updates. Security issues with WordPress are introduced most often through vulnerabilities exploited in plugins.

Lower development costs

This isn’t a feature of WordPress, but it’s worth mentioning that if the “out of the box” solutions meet your needs and you are able to build a site without the assistance of a developer, it will cost you less. If you fall on the mom-and-pop end of the spectrum, have a lower development budget, and are not picky about every detail of design or functionality, WordPress is likely a great option for you.

Advantages of Drupal

Custom content types and views

Whereas WordPress comes with two content types (posts and pages), Drupal also comes with two content types out of the box (article and basic page). However, it not only allows you to edit the fields for those content types but also create new content types and views without custom code that meet your specific requirements. If your site needs a blog, you can create a content type for blog posts and a view that displays them the way you want. If you need a staff directory, you can create a content type for staff that has fields for name, title, profile picture, bio, etc., and then create a view to display the staff in a list, a grid, or to whatever your specs require.

This is one way in which Drupal and WordPress differ. Drupal is an application framework that allows you to build what you need the way you need it. WordPress core starts as a blog that makes you add to core in order to manipulate its built-in behavior. For example, in order to disable blogging in WordPress, you have to install a 3rd-party plugin such as Disable Blogging in WordPress.

If you compare WordPress core and Drupal core, Drupal is far more robust than WordPress.

Access control and user permissions

Out of the box Drupal core allows you to create and define your own user roles and associated permissions for each. If your site requirements call for multiple levels of user permissions with varying degrees of access, Drupal lets you create new roles and assign them with custom permissions. And, unlike WordPress, Drupal allows granting more than one role to your users. This gives you fine-grained control over what they are allowed to do. Building on the previous example of a staff directory, you could create a role for Staff and only give that role permissions to edit one’s bio page. All of these customizations for roles and permissions can be done in the admin without adding any custom code.

Taxonomy

Whereas the tagging system in WordPress is flat, in Drupal you can have multiple types of categorization and determine how much information you want to track on each one. Drupal allows you to create more complex and custom data relationships across various types of content.

Internationalization

Want the Drupal admin to display in the native language of your officemate overseas? No problem! Native language handling is now built into Drupal 8’s core APIs which improve the ease of globalization management. Building a multilingual site no longer requires installing multiple contributed modules.

Security

Drupal is known for having a volunteer security team and a standardized set of policies and procedures for dealing with security issues. Security advisories are routinely posted on https://www.drupal.org/security for Drupal core as well as contributed projects. For enterprise clients with specific security needs, the Drupal distribution Guardr is available with a combination of modules and settings to enhance the Drupal application’s security.

Customization

As a web application framework, Drupal can be adapted to meet very specific requirements. For example, the Drupal entity system allows tracking specific data points and values that are needed when building applications. At times, Content Types aren’t the best choice for these data elements, and more custom entities allow for improved performance and fit the requirements best.

If this has you scratching your head, you’re not the only one. I’m purposely skirting around the complexity of the section because it is beyond the scope of what I’m trying to speak to here. The important difference here is that Drupal allows tracking points of data without cluttering up the editorial experience. Sometimes the data needs to be seen but not heard. Drupal lets you do that. And site editors may never even realize it’s happening.

Conclusion

As a site builder who has built dozens of sites in HTML, Joomla, and WordPress and worked for five years as a project manager at Mediacurrent (almost exclusively with Drupal), I realize that the Lego analogy may be helpful but at the same time not completely accurate. After all, WordPress boasts such enterprise level sites such as Techcrunch, Sony Music, and Time, Inc. But my experience reinforces the perception that WordPress is amazing at simple sites or blogs while Drupal is the go-to for more complex sites.

I’ve found that clients will like a template design exactly the way it comes except for “insert numerous design changes” or the plugin functionality as-is “if you change this one behavior that isn’t built into the plugin.” And at that point, the gains of using out of the box functionality and design offered by WordPress (either via core WordPress or plugins and themes) are lost to customizations and a custom Drupal implementation is preferred. If you fall on the enterprise end of the spectrum and have deeply refined technical requirements, Drupal is likely a great option for you.

It comes down to the level of complexity for which you need to plan. If you are building a large site that is essentially brochureware (static pages), WordPress will work for you. If your site requirements call for a dynamic application with a heavy reliance on custom search results, interactivity, or 3rd-party integrations, or if you have specific design needs that require multiple custom layouts, your best bet is to use Drupal 8.

This week, thousands of members of the Drupal community have come together to share insights and to celebrate the power of open source. Embracing knowledge transfer, the Digital Transformation and Enterprise track stands out as accessible for developers, marketers and business owners alike.

From ambition, through innovation and implementation, the Digital Transformation track is not strictly technology-focused; rather it looks to the real-world impact of Drupal and how its adoption can transform the nature of a business.

These presentations are accessible for ‘Beginners’ yet affecting the top-level of international organisations from across industries; here's a detailed overview of our top talks:

Chatham House is a not-for-profit, non-governmental organisation with a mission to help governments and societies build a sustainably secure, prosperous and just world.

Founded in 1920, as a discussion group to prevent future wars, Chatham House has vastly transformed to its current world-leading position as a global independent policy institute. But its digital presence has struggled to evolve quite so prosperously...

Building Evidence for Change:

An audience survey in 2005 revealed that the Chatham House website was inaccessible and uninspiring. People were unable to access key reports and information in the “dull and academic” website.

Between 2004-2009, Josie Tree, Head of Digital Strategy and Development, built a case for the digital transformation at Chatham House. Providing evidence of success, building positive relationships and harnessing the power of healthy competition all proved vital. Working towards a clearer strategy, the plan was to ‘stop fire-fighting and refocus on priorities’.

Fear of change, cultural barriers and the ongoing battle for budget all hold back innovation; but Josie recognises that crisis can be an opportunity.

The Chatham House Website in 2004

Why Drupal?

The Chatham House website is content-heavy, with a set of complex requirements.

Drupal offers the editorial flexibility they need, along with an open source ethos that reflects the Chatham House commitment to knowledge transfer.

With a flexible platform and determined digital champions, the possibilities of Drupal are infinite.

-Paul Johnson, Drupal Director

What’s more, as the Drupal Europe conference demonstrates, Drupal is well-supported, widely used and comes from an inumerable choice of development partners.

Drupal acts as an ideal springboard for success, with endless possibilities.

Just the Beginning:

Moving to Drupal was just the beginning for the long-term digital transformation of Chatham House. The question remained:

How could digital better support the Chatham House mission?

A new strategy focused on improving the reputation of Chatham House, prioritising outputs, investing in marketing efforts and utilising insights from feedback. As with any strategy, this was all to be underpinned by measuring success KPIs and reporting.

The next steps for Chatham House involve a full website redevelopment project, with a user-centric design.

With plans to upgrade to Drupal 8 and implement a new CRM system, the digital transformation of Chatham House has been ongoing for many years and is still only just beginning…

Collaboration is Key:

The clear takeaway from Josie’s speech was the vital importance of working together. Combining strategic partnerships with strong internal relationships has seen positive results for Chatham House (with website growth climbing from 40k to 260k monthly visits).

Digital champions throughout the organisation are placed to provide training in necessary skills and to break down the barriers of communication.

Finding the right external support is important, but the core digital team remain at the heart of the project. This team has grown from just a single person to a group of 12 over the last seven years.

With growing collaboration between the research and digital outputs, Chatham House hope to enhance their international reach for a wider and more diverse range of audiences.

BASF are the world’s leading chemical company, combining economic success with social responsibility and environmental protection.

With over 115,000 employees and sales upwards of €64,000 million, BASF have always been sure to maintain their position at the cutting edge by carefully protecting their intellectual property.

The Translation Dilemma

As the global leader in their industry, it is vital that the entire BASF digital platform is accessible in over 50 local languages.

Unfortunately, to allow for this level of functionality, it became clear that each string of code needed to be crawled and translated individually.

Operating across multiple sites, in multiple languages, for multiple brands, the obstacle grew exponentially. With a collection of 146,880 strings, translation presented an unsustainable issue, in terms of time and budget.

The Solution:

As with most seemingly impossible scenarios, the solution is beautifully simple: BASF required a mechanism to flag and filter relevant strings. By focusing on those strings most urgently requiring translation, the overwhelming workload becomes manageable.

With the right connections we were led to the right solution, utilising the collective power of the Drupal community.

- Paul Johnson, Drupal Director

From there, untranslated strings can be arranged by order of the most viewed, to ensure a priority system for the inevitable translation of any multilingual site.

As any translations need to be maintained continually, this new interface streamlines the system for all future development.

Drupal 8 String Translation Solution

Lessons learnt:

Despite concerns during the project, Drupal 8 was presented as the right choice once again. The flexible extensibility of the platform has enabled BASF to maintain competitive advantage.

Most importantly, BASF learnt that open source is not about saving money. The principles of open source enabled the shared problem to result in a mutual solution. The contribution made as part of the BASF project has dramatically increased Drupal’s core capabilities, for all.

On Thursday morning, the Digital Transformation track will look to the future. The founder of Drupal, Dries Buytaert, alongside key players from Google, Mautic and the Drupal Association, will discuss life at the forefront of the digital industry.

This keynote session will address the opportunities, as well as the responsibility, that come with leading one of the largest open source communities in the world.

There is a lot of talk out there right now about “decoupled” or “headless” open source eCommerce platforms. I won’t get into why that is in this article, but I will show you how easy it is to enable a full REST API for your Drupal 8 and Drupal Commerce platform in JSON format. It’s literally the enabling of a module… that’s it! Let’s take a look.

In this Acro Media Tech Talk video, you’ll learn a little bit about the module used to expose the API, where to find documentation, and see an additional module that enhances the experience working with the API. Using our Drupal Commerce demo site as an example, you’ll see where you can view and modify the site resources as well as how to view the data for each resources in JSON format.

The data structure of Drupal is well suited to the JSON API which makes Drupal and excellent choice as a backend content-creation area for a decoupled application. This video will get you started, but what you ultimately do with that data is up to you!

Drupal has got new media management functionality in 8.6. In the above video, I’ll demonstrate what new media functionality we have in Drupal 8.6.

Thanks to the Media in Drupal 8 Initiative, media handling in Drupal has improved with every new release. In 8.4 we got the experimental core Media module. Then in 8.5, the module moved from experimental to stable and now it’s the recommended way for storing media assets. Now in Drupal 8.6 we get a few extra goodies such as oEmbed support, a Remote video media type and a media library.

oEmbed Support

Media Library

The new Media library module is by far the most exciting new functionality. You’ll need to install the experimental module called Media library. Don’t forget this is experimental for now; use at your own risk.

The first change you’ll notice is that the Media page looks different. You get to switch between a Grid and Table view.

The module also comes with a new widget for the Media field called “Media library”. This will allow you to browse media assets from the edit screen.

To use this widget make sure “Media library” is selected as the widget on the “Manage form display” page.

Here it is in action and watch how you can bulk upload images.

Can this module replace Entity browser? At this point I’d say no. Entity browser gives you more flexibility in how you build these types of browse pages. But I hope in the future Media library will be the standard way of creating these browse pages.

Summary

Slowly and steadily media handling in Drupal core is improving and becoming more powerful. It’s good to see this continued momentum. But if you need to create bespoke media functionality I still think the combination of Entity embed/Entity browser is the winner for now.

About Ivan Zugec

Ivan is the founder of Web Wash and spends most of his time consulting and writing about Drupal. He's been working with Drupal for 10 years and has successfully completed several large Drupal projects in Australia.

The making of Acro Media’s website content creation framework

It’s common place for brands to create guides so that there is a constant standard to follow when working with the brand’s identity. These are generally called Style Guides. We have one ourselves that we use when designing internal documents and printed layouts. This is great when it comes to branding, but how do you go about maintaining a level of consistency for something larger, such as a website? We recently underwent a fundamental shift in the way we create our website content, and with it, the Live Website Component Guide was born.

The Content Type Crux

For those familiar with Drupal, creating something called a Content Type is a common way to go about setting up a type of content - think your standard web page, blog post, frequently asked questions, rich media slider, etc. That content type can then be used to generate the pages of your website.

This works well enough if your site doesn’t need to change, but our marketing team is constantly looking to adapt to new trends, change content layouts, and A/B test. A website should ideally be dynamic and quick to change, however, changes ended up taking a lot of time because they need to first be designed and then built. The standard Drupal content type is rigid and the layout is fixed, so if you want to change the layout, the change is going to cascade to any page that uses that Content Type. Because of this, we often needed to create a whole new Content Type, template and styling. Something that should be quick ends up taking weeks because our process just wasn’t efficient. And furthermore, the more code we introduced, the more difficult the site was to maintain.

Eureka! Paragraphs

In February of 2017, we had a “eureka” moment while attending the Pacific Northwest Drupal Summit in Vancouver, BC, Canada. Here we learned about a new (to us) content creation module called Paragraphs. I know many people have been using this module for a while now, but it was new to us and we immediately saw the potential. As stated on the Paragraphs module’s Drupal.org project page:

“Paragraphs is the new way of content creation! It allows you — Site Builders — to make things cleaner so that you can give more editing power to your end-users.”

And it DOES do that! Instead of thinking in ‘pages’ we can now think in ‘components’. The graphic below illustrates this. On the left, a representation of a standard Drupal page layout using a Content Type. On the right, the same page broken out into individual Paragraphs components.

Content Type vs Paragraphs

What this module allowed us to do is to remove the rigid structure of the Content Type and instead build out a set of individual, standalone components that can then be inserted into a page wherever we want. If we want to add a new component to a page, we just select the component from a list and place it on the page. To remove one, we just click a remove button. To change the order, all we need to do is drag and drop the component where we want it. If there is a component that we need, but doesn’t yet exist, we can now create just that one component. It makes things fast!

The content creation aspect is incredible dynamic and easy to use. The best part of all is that once the components are built, the only need for a developer is to create new components later on. The actual content creation can easily be done by anyone with a very small bit of training.

From a design point of view, our designers can now piece a layout together knowing exactly what components are available to them. They know that if we’re missing a component, they can come up with something new and it’s not going to take weeks to implement. Plus, we already loosely follow the Atomic Design methodology by Brad Frost, so the whole concept was easy for them to grasp and got them excited. In fact, our Creative Director jumped on this concept and we now include a full set of content creation Paragraphs components in every new project that we build.

An example of how easily we can generate page layouts using component driven design.

Things get very easy from a code maintenance point of view too! We created each of our components to have a standalone template and styling. This means that things stay consistent throughout the site no matter how a page has been setup. If we need to make a visual change to a component, we make it once and the change cascades throughout the site. The code base is small and logical. Anyone new to the project can jump in and get up to speed quickly.

Our Live Website Component Guide

So, if you’ve read this far, I bet you want to see it in action? You’re in luck! I recorded a quick video that shows you how it works using our corporate website’s Live Website Component Guide. You can watch the video below or view the page in all its glory.

...And the story of how two unlikely organisations drove innovation in the Drupal Platform.

While delivering continual support for the Avanti Gas Drupal website, we wanted to implement a Postcode Lookup feature, with auto-complete functionality. Existing solutions were either too basic or needlessly expensive, but we couldn’t justify building a new solution from scratch. As luck would have, I discovered at our weekly Drupal 8 meeting that my colleagues working on The Wildlife Trusts’ sites required autocomplete capabilities for the address lookup on the trust’s donations page.

These two very different organisations, Avanti Gas and The Wildlife Trusts, shared a mutual requirement. Recognising the value of a Postcode Lookup across different sectors and services warranted the investment in developing and contributing the module to the open source community.

For The Wildlife Trusts, the team had used the PostCodeAnywhere PHP API (now Loqate) by writing their own JavaScript to complete the autocomplete functionality. But this was proving more and more time consuming; initially, it wasn’t even clear that the service offered a JavaScript widget.

The solution that the team built for The Wildlife Trusts was quite custom and specific, utilising the Address module’s more rigid form fields. So the end result wasn’t something we could quickly or easily contribute back to the community.

Clearly this was a feature that would benefit the Drupal experience if there was a permanent publicly available fix. When discussing how different organisations may use this feature, I came to the conclusion that it needed to be available as part of the widely adopted webform module that provided the popular drag-and-drop interface.

The Solution

The Postcode Lookup is fully responsive, has autocomplete capabilities, functions smoothly on an enterprise level, and has a comprehensive database to pull from for global addresses. All of this is available as a stand-alone widget, or as part of the existing webform module.

The Drupal 8 Loquate module in action

How it works

A user starts to type a postcode and the field will suggest addresses based on the text entered. Upon choosing an address from the drop-down list, a whole set of address fields are populated. This was achieved using Loqate’s (then PostCodeAnywhere) paid “Address Capture” JavaScript API, which was really quick and easy to implement.

To add Postcode Lookup to the Webform, we created the Loqate module. All you need is the Webform module and a Loqate API key and you’re up and running with a Postcode Lookup autocomplete field that you can put in any form on your site.

But that's not the end of it…

Going forward we are planning to add:

Integration with the Address module: This could have extensive use-cases, as this module is used heavily by the Commerce module and would make setting addresses for buying things significantly easier.

The ability to automatically change required fields based on a user's location, to improve international experience.

Toggles for manual entry vs postcode entry.

General code improvements, for better maintainability and more use-cases.

Over not more then 8 days it is finally there, Drupal Europe will be happening from 10 till 14 September in Darmstadt, Germany. We like to inform, you as active and committed Drupal professional with an update about the organization of this international event.

Last summer a lot of volunteers worked really hard to make the event happen. There was a search for sponsors, the session were reviewed, selected and all nicely planned in the big schedule.

The biggest draw of Drupal Europe is the inspiration and knowledge you can get in the 188 (!) sessions, keynotes and workshops. Drupal Europe is an unique possibility to meet your (international) colleagues again and talk about what drives, connect and challenges our community. There is only one open source community where “you come for the code and stay for the community” is so deeply rooted.

Besides the sessies and BOF’s we also plan our other traditional successful activities. On Wednesday evening we organise the exiting Trivia Night where you can win eternal fame with your team.

On Monday and Friday you can attend the mentored sprints and contribute with your knowledge and skills to the Drupal software.

New this year at Drupal Europe is the first international Splash Awards! All golden and silver winners from Europe will compete for the best European Drupal-website, so it is going to be exiting.

All together we think there are plenty of reasons why you should come to Darmstadt and participate at Drupal Europe.

Therefore we now offer you the last opportunity to buy your ticket during the Flash sale that will end on September 3rd. Use this voucher code while buying your ticket and you are guaranteed of the best price: FLS-LPNLGS5DS84E4

After September 3rd the price will go up.

So, get ready for Drupal Europe, book your overnights and have a safe trip getting there.

One of the best things about Drupal is its security. When tens of thousands of developers work collectively on an open source project, they find all the holes and gaps, and strive to fix them. When one is found, patches go out immediately to keep sites safe and secure. But a site is only secure if those patches are applied when they are released.

Pelo Fitness is a Marin County-based community dedicated to a culture of fitness. They offer cycling, strength, yoga & nutrition programs customized to an individual’s needs and fitness level. Whether someone is a competitive athlete, a busy executive or a soccer mom (or perhaps all three), their programs are designed to build strength and endurance, burn calories and boost energy.

Yet their site was weak since they hadn’t applied a few major Drupal security updates. There was a concern that the site could be hacked and jeopardize client information. Pelo Fitness customers use the site to purchase class credits and reserve bikes for upcoming classes, requiring users to log in and enter personal information.

The solution

Kanopi performed all the security updates to get the Pelo Fitness on the latest version of Drupal. All out of date modules were updated, and the site was scanned for suspicious folders and code; anything that looked suspect was fixed. Care was taken not to push code during high traffic times when reservations were being made, so code was pushed live during specific break times that would allow for the least disruption. Lastly the site was also moved over to Pantheon for managed hosting.

Due to the Drupal support provided by Kanopi, the Pelo Fitness website is now protected and secure. Inspired to make all their systems stronger, Pelo Fitness also switched to a different email system as well so all their tech solutions were more up to date.

How to keep your site secure

Websites are living organisms in their way, and need constant care and feeding. It’s imperative to always apply critical security patches when they come out so your users information (and your own) is kept secure at all times. There are a few simple things that you can do on your Drupal site to minimize your chances of being hacked.

Stay up to date! Just like Pelo Fitness, make sure you pay attention to security updates for both Drupal core and your contributed modules. Security releases always happen on Wednesdays so it’s easy to keep an eye out for them. To stay up to date, you cansubscribe via email or RSS on Drupal.orgor follow@drupalsecurityon Twitter.

Enable two-factor authentication on your site. It’s a few seconds of pain for an exponential increase in security. This is easily one of the best ways to increase the security of your site. And besides, it helps you makes sure you always know where your phone is. TheTFA moduleprovides a pluggable architecture for using the authentication platform of your choice, andGoogle Authenticator integrationis available already as part of their basic functionality.

Require strong passwords. Your site is only as secure as the people who log into it. If everyone uses their pet’s name as their password, you can be in trouble even if your code base is “bulletproof” (nothing ever is). ThePassword Policy modulesets the gold standard for traditional password strength requirements, or you can check out thePassword Strength moduleifXKCD-style entropyis more your thing.

Make sure you’re running over a secured connection. If you don’t already have an SSL (TLS, technically, but that’s another story) certificate on your website, now is the time! Not sure? If your site loads usinghttp://instead ofhttps://, then you don’t have one. An SSL certificate protects your users’ activities on the site (both site visitors and administrators) from being intercepted by potential hackers.

Encrypt sensitive information. If the unthinkable happens and someone gets hold of your data, encryption is the next line of defense. If you’re storing personally identifying information (PII) like email addresses, you can encrypt that data from the field level on up to the whole database. TheEncrypt moduleserves as the foundation for this functionality; check out the module page and you can build up from there.

Don’t let administrators use PHP in your content. Seriously. The PHP filter module can get the job done quickly, but it’s incredibly dangerous to the security of your site. Think seriously about including JavaScript this way, too. If your staff can do it, so can a hacker.

Think about your infrastructure. The more sites you run on a single server, the less secure it is. And if Drupal is up to date, but your server operating system and software isn’t, you still have problems. Use web application and IP firewalls to take your security even further.

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 creation/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:

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.)

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.

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 to:

specific user roles

certain individual user accounts

How do you set everything up?

first, you enable the module

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:

Congratulations! Your Boss just gave you approval to build the website you’ve been pitching to them for the past year. A budget has been approved, and you have an enthusiastic team eager to get started. Nothing can stop you… until you receive the deadline for when the website has to go live. It’smuchearlier than you planned and there just simply isn’t enough hours in the day, or resources available to make it happen. Whatever will you do?

Let me introduce you to the minimum lovable product, or MLP.

What is an MLP?

You may have heard of a minimum viable product (MVP). Where a minimum viable product is a bare-bones, meets your needs solution; the minimum loveable product can be described as the simplest solution that meets your needs and is a positive step toward achieving your goals. It’s easy to view every aspect, every deliverable, as being fundamental to a project’s success. But when you actually look at each nut and bolt with a more discerning eye, you begin to realize that each component is not fundamental to the overall product’s success.

So basically the MLP is the sufficient amount of features your site needs to be satisfactory to your business goals for launch.

It’s important to note that an MLP is not necessarily a reduction in scope. It’s more a prioritization in the order for which things are addressed. The project team can circle back on anything that wasn’t part of the MLP. The goal behind an MLP is to deliver a functional product that you’re excited about, within the confines of the project.

When should you consider an MLP?

An MLP isn’t for every project, but is usually best leveraged when there is a restraint of some sort. I used timeline as an example in my opening, but as you know restraints can take many forms:

Timeline: Maybe the deadline you need to hit, simply won’t provide enough time to complete all the work you have queued.

How do you create an MLP

When you’re able to parse the individual elements that are crucial to your website’s success into user stories and features, you’ll have effectively identified your project. But how do you actually go about separating the core building blocks that will comprise your MLP from the bells and whistles? It all starts with goals.

Goals

Chances are that you already have a set of goals describing what you’re hoping to achieve with the project. These ideally should be as specific as possible (ie. increase traffic) and ideally measurable (analytics). Without realistic, concrete goals you set the project up for failure. For example if your goal is to make people happy; chances are you’re going to have a hard time measuring whether you were successful. Establishing measurable goals will set the project up for success.

It’s not enough to know your goals, you have to be able to prioritize them. It’s simply not realistic that every goal be top priority. Try to narrow your priorities down to no more than three goals. Goals in hand where do we go from here in our quest to define an MLP?

Definition

Begin by thinking of all the factors that are needed for a User to accomplish a given goal. These could include anything from Layouts, to Features, to Content. Start a list of these factors:

What are the things a User sees?

What copy does a User read?

What actions is a User taking while they navigate through the site?

Everything you write down while asking these questions should be in the interest of one of your priority goals. If an item isn’t directly contributing to accomplishing the goal, then it should not be on the list. If you’re not a subject matter expert that will be directly contributing to the work, you should connect with your team to determine the specific work that needs to be carried out for each of the items you’ve identified. Additional refinement, and further simplification may be needed to compensate for the restraint you’re up against.

By this point, you’ve probably realized that defining the MLP is a difficult task. The choices will be tough, and ultimately everyone is not going to get their way. What’s important is that the work you do strives to meet the goals you’ve set. This sometimes means detaching personal wants from the needs of the company. If you can tie the work back to this core philosophy, you’ll always have a strong direction for your product.

Time to get to work!

All done? Congratulations! You’ve now defined your MLP. Now you’re off to the races. Best of luck on the journey of building out your minimum loveable product.

Drupal, especially once you consider the many contributed modules available for it, is a vast system of open source software, and as with most such software, there are a lot of little things you can do to make sure you get the most out of what it has to offer. In this post, I'm going to go over a few such things and touch on how to make Drupal's admin interface more useful while also finding ways to improve site performance and stability.

Tip #1: Clean up your content forms with Field Group

It can be pretty easy to end up with a content type (or another type of entity) that has a whole lot of settings on it, and even if you organize the fields into a logical order, it can make the content forms a bit difficult to navigate. On most any somewhat content-heavy site, Field Group is one of the first modules we install. It allows you to group fields together in various ways, such as with a tabbed interface or collapsible fieldsets, and with it, you can have your forms better organized in no time. Your content editors will thank you.

Tip #2: Have a cup of Coffee (and Admin Toolbar)

When it comes to making it easy to find what you're looking for in Drupal's admin UI, few modules compare to Coffee and Admin Toolbar (including its Extra Tools submodule).

Coffee adds a "Go to" button to the admin bar which, when clicked, opens up a search bar similar to the Spotlight Search on a Mac. Then you can just start typing to find whatever admin page you might be looking for. For those of you who prefer using the keyboard over the mouse, there's also a keyboard shortcut to open the search.

The Admin Toolbar module modifies Drupal's existing toolbar to use a series of dropdown menus, making it easy to find the right page without needing go click through a bunch of screens to get to it, and it also adds some quick links to do common development tasks such as flushing caches and running cron.

Since Coffee and Admin Toolbar both are designed to make it easier to get where you want to go in Drupal, you may only need one of them, but it's worth giving both a try to see what makes your workflow fastest.

Tip #3: Send emails your users can trust

Many sites have to send out emails of some sort – whether it's just for simple password resets or a more critical part of a site's functionality. Drupal can send emails on its own easily enough, but unfortunately, (especially if your site is on a shared hosting environment), there's a decent chance that the email may be automatically get marked as spam. There's an easy fix for this: First, you set up an account with an email delivery service such as Sendgrid or MailGun, then you add the SMTP Authentication Support module to your Drupal and configure it with the credentials provided by that mail service. And ta-da – now your site's emails are all delivered by a trusted service. No more ending up in the spam folder!

Tip #4: Limit the size of your images

Large images can take a long time for your site's visitors to load, especially if they're on a slower network. If they're too large, this can result in your visitors seeing blank space while the image is still downloading. To avoid this, ideally, images should be exactly as large as they need to be, and no larger. There are several great ways to accomplish this without needing to load up Photoshop for every image.

First, before even uploading your image to Drupal, use a tool such as Compressor.io to compress your image. This step is especially important for most JPEG images and photographs.

Within Drupal itself, there are a couple of possibilities available to you. If you are uploading your images to the image field of nodes, you can set restrictions on the field itself, such as maximum dimensions for the uploaded file (and Drupal can even resize the image to fit if you upload one that is too large). You should also set an appropriate image style for the image wherever you use it, which can include things like automatic cropping and centering.

Tip #5: Update often

New versions of Drupal and its many contributed modules are being released all the time, often bringing with them stability improvements as well as brand-new features. For Drupal Core and most contrib modules, each individual update is easy to apply (especially if you use Composer), but the further out of date your site is the trickier updating it can be, so keeping on top of updates means that updating stays simple.

One other critical reason to keep up to date is that once in a while there are security updates necessary for Drupal, and if you're already on the latest version applying the security update is a fast and painless process. You don't want to end up delaying security fixes to the site because of difficulties in upgrading several versions at once. If you have a drupal.org account, it's worthwhile to go to your user account page and subscribe to their security notifications email newsletter so that you get alerted as soon as these important updates are released.

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:

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:

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

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.

first, a broken image has an impact on the overall user experience; your site visitor gets discouraged and quite the page in question

next, search engines rate your site's content as “of poor quality”

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 about your site's infrastructure of web pages (via heading tags), 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.

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...

“Excuse me, Mr./Mrs. Client, I’m so sorry but I accidentally just sent your 3000 users a fake purchase email receipt when I was testing.”

Ugh.

Big complex systems are a lot to keep track of, especially when it comes to email. There are emails for resetting passwords, emails for new users, email receipts, email notifications for workflows, etc, and it’s frankly a little terrifying to rely on yourself to remember all the implications of what’s going on when working on local environments, or test servers or anywhere but production. All you have to do to experience this pain is trigger an accidental FAKE email send to REAL people.

That’s where modules like today’s spotlight comes in.

We’re talking about the Reroute Email module, a simple plugin that allows you to override all outbound email sending and send them to a configured address, allowing you to both test that email content is working but not have to apologize to all of your users.

Installation is simply turning the module on and then going to the configuration page at /admin/config/development/reroute_email. From there, you can set the rerouting email addresses and even set whitelisting emails that are permitted to pass through the reroute.

This is helpful for situations where you want to use test emails for specific purposes and you want the emails to go out as they will in production without having all email functionality enabled on your site. Pretty great. Lastly, you can even enter module key patterns so that emails coming from particular modules are the only ones being rerouted. Very flexible.

And a special note: On many of our sites, we set the config for the module in the local settings files for each environment so we can ensure, for example, that local or test environments never send real emails even if we pull code or refresh the database from production. It’s as simple as the following lines of code:

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:

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.

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 10post-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?

Background

For our two main websites (QSR & FNF), we send out a monthly e-letter to about 20k+ each and we have it setup such that it goes through Amazon SES and all email notifications (deliveries, bounces, unsubs, complaints, etc.) get posted back to the site. Our custom Drupal module receives each notification and updates several places so that we can track bounce rates, delivery rates, and opt out people who complain or unsubscribe. So our site bogs down (at least for authenticated traffic) when we send the 40k e-letters because these notifications bypass all of the layers of caching in order to make those database updates.

Inspiration

Decoupled Drupal is a major mind-shift for me. QSR was our first Drupal (6) site back in 2010 and over the last 8 years, we have written over 40 custom modules to do things big (lead generation, circulation, etc.) and small (user surveys, etc.).

The advantage is that it's one place for your users to go for all the tools they need. The disadvantage, though, is that your server resources are shared and is probably taking away from the higher priority of serving your users.

There's also something to be said about splitting a feature off into an environment where you're free to choose the best tech for the job, which might not necessarily be Drupal.

Setup

First, this article was a big help in getting things setup. I ended up using a different table schema, just having 4 fields, event_id (the SNS event messageid, which is also my primary key), the source (so I can gather items based on the site), a processed boolean flag, and the message itself, stringified JSON.

One thing to keep in mind is that SNS posts its event differently to HTTP(S) than it does for Lambda, so you cannot rely on your HTTP(S) examples as test cases. I have a (sanitized) captured example here.

Finally, the easy/cool bit is changing the SNS subscription from your HTTP(S) endpoint to your Lambda function. You don't even have to program a subscription confirmation for that - it just works.

Next Steps

So I went live with this without testing an actual load scenario. Big mistake! Once the SNS messages came flying in, Lambda reported a ton of errors and DynamoDB's default write capacity caused a lot of throttling. So while Lambda can scale from input dynamically, what it does with the output can wreak havoc. I would highly recommend you do some load testing based on your situation. You can set up a test run to send 40k emails to a random assortment of AWS SES' test addresses. I ended up having to scramble my Lambda and DynamoDB configurations to bump up the timeout max and enable auto-scaling for writes. I ended up losing a lot of tracking data because my Lambda function didn't fail properly and SNS thought everything was OK and didn't try again. :(

After I get that fixed and more bulletproof, my next step is to write a cron job to gather any unprocessed messages that belong to the site and process them. I'll write a follow-up post when I'm done with that.

Drupal Console and Drush are two command line (CLI) tools built for Drupal. For a long time Drush was the only CLI tool and it was very useful for managing Drupal sites. Common tasks you’d do with Drush are rebuild caching, installing sites, import/export configuration and so much more.

Then Drupal Console came onto the scene and offered other goodies such as the ability to generate boilerplate code, which Drush 9 can now do as well. People often ask “Can you run Drush and Drupal Console together” and the answer is yes, I personally use both. If you install Drupal using drupal-composer/drupal-project then you get both Drush and Drupal

In the video above, you’ll learn how to use Drush and Drupal Console.

Drupal Console

Drupal Console is a CLI tool for Drupal built using the Symfony Console library. One of its many strengths is the ability to generate boilerplate code. With a few simple commands you can create a module or a custom entity type.

About Ivan Zugec

Ivan is the founder of Web Wash and spends most of his time consulting and writing about Drupal. He's been working with Drupal for 10 years and has successfully completed several large Drupal projects in Australia.