Oct 09 2018
Oct 09

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.

Oct 09 2018
Oct 09

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.

Contact us to discuss your migration!

Oct 03 2018
Jay
Oct 03

drupal 8 logo in spotlights

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.

New Call-to-action

Oct 03 2018
Oct 03

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. 

medium fidelity wireframe focuses on content organization and the user journeyDesktop, 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.

wireframe shows progression toward getting a quote

Tablet-width wireframes of the Find a Dental Plan (or quoting) process.

The goals mapped through the enrollment/checkout process were to 

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.

wireframes show user journey to find a price quote

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.

style tile includes blue and gray color palette and brandon grotesque typography

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.

style tile with primary color palette

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.

style tile features photography examples and a gray, blue, and gold palette

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. 

final style tile includes blue, grey, gold and red tones, typography, buttons, and icons

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!

Oct 02 2018
Oct 02

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.

Demo Drupal Commerce today! View our demo site.

Oct 02 2018
Oct 02

[embedded content]

Watch other videos on our YouTube channel. Click here to subscribe.

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

Want to learn about Views? Read Build a Blog in Drupal 8: Using Views or watch it as part of our FREE Drupal 8 Site Building course.

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.

Ivan Zugec

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.

Oct 02 2018
Oct 02

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 Dergacheva and Ricardo Amarowho 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.

Get Involved Today

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.

Brainstorm Notes from Drupal Europe RoundtableBrainstorm Notes from Drupal Europe Roundtable - Photo by Meike Jung

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.

Join the cause, let’s make Drupal better together!

Get Involved Today

Drupal.org Issue: Drupal "Pitch Deck" for Presenting to (Potential) Customers 

Sep 28 2018
Jay
Sep 28

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.

Ready to get the most out of Drupal?  Schedule a free consultation with an Ashday Drupal Expert. 

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!

Offer for a free one-hour consultation, make you next project a success

Sep 28 2018
Sep 28

Just imagine... automatic updates in Drupal core.

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?
 

  1. first, it was the need to automate Drupal module and security updates
  2. then, the issues queues filled with opinions grounded in skepticism, valid concerns and high hopes started to “pile up” on Drupal.org,
  3. 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
  4. … which grew into the current Auto Update Initiative
  5. that echoed, recently, at Drupal Europa 2018, during the “Hackers Automate but the Drupal Community still Downloads Modules from Drupal.org” session
     

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.

The goal is to develop an auto-update mechanism for Drupal core conceptually similar to those already implemented on other platforms (e.g.WordPress).

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

And concerns increase exponentially as the need for an update automation in Drupal rises (along with the expectations).

Now, let's outline some of the most frequently expressed ones:
 

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

  1. not meet large company websites' security requirements; that it would not fit their specific update workflows
  2. benefit exclusively small, low-end websites that don't benefit from professional maintenance services
     

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?

  1. Definitely yes
  2. No way
  3. It depends on whether...
Sep 26 2018
Sep 26

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! 

Unconference Tickets

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

 

Find out more and order your tickets of the Unconference website. We'll see you there!

Unconference Tickets

Sep 25 2018
Sep 25

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 this Tech Talk video, 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.

Role based workflow logins:

  • Blog author: blogauthor/blogauthor
  • Blog reviewer: blogreviewer/blogreviewer
  • Blog publisher: blogpublisher/blogpublisher

Administrator login (for viewing the configuration):

  • Administrator: demoadmin/demoadmin
Demo Drupal Commerce today! View our demo site.
Sep 24 2018
Sep 24

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.  

DrupalCon 2018 conference aerial group shot

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.

karaoke at Mediacurrent's DrupalCon Nashville after party

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.

Sep 21 2018
Sep 21

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!

Now, let's take a sneak peek at these most-anticipated media handling features that Drupal 8.6.0 comes equipped with:
 

  • adding media from a remote source
  • adding various types of media
  • embedding Youtube and Vimeo videos in the content (via URL)
  • easily accessing and reusing the existing media
  • uploading new media types right out of the box
     

And this is almost... overwhelming:

From almost no built-in media support in Drupal, for so many years, to a whole set of modern, powerful media management options now in Drupal 8.6.0.

But let's not ramble about this topic anymore and dive right in! Into the pile of new features meant to enhance the whole media management experience in Drupal:
 

But First: An Update on The Progress of the Media in Drupal 8 Initiative

The main goal of this media initiative was to:

Add a rich media support to Drupal 8.

One that would empower the content editors to easily reuse existing media assets, add new media entities and to overall gain more control (and meta information) over their media.

And there are 3 core milestones that we can trace while tracking the progress of this initiative for Drupal 8:
 

  1. adding the experimental Media module to Drupal 8.4 in late 2017
  2. leveling up this module from experimental to stable phase in Drupal 8.5.0
  3. turning it into the standard way of storing media in Drupal 
     

Moreover, starting with Drupal 8.6.0 a new key module for handling media has been added to core — Media Library — along with a few more exciting options:
 

  • quick access to the existing media assets
  • oEmbed support
  • a new media type: remote video content
     

Quite a “leap” forward, to a great media management experience in Drupal, I would say...
 

2. Welcome a New Media Type in Drupal 8: Remote Video

Let us list the 4 media types that you could add to your site's content up to Drupal 8.6.0's release:
 

  1. file
  2. image
  3. video
  4. audio
     

OK, now it's time you welcomed a new media type to the group: remote video!

Basically, as a content editor you're now able to add videos from remote sources, as well — Vimeo and Youtube — via their URLs.

Handling Media in Drupal 8.6.0- New Media Type: Remote Video

In short: you're no longer constrained to settle for the default media types in Drupal 8. No sir, now you get to create new custom ones mentioning their media sources.

Summing up: embedding new media to your website content is nothing but a two-step process: Content-Add Media.

Handling Media in Drupal 8.6.0- Add New Media Type


3. Reusing Media Is Now Possible: Media Library

One of the much-awaited features for media handling in Drupal 8.6.0 had been reusable media.

Well, here it is now: Media Library! It's where you can save and store all your media assets to be further reused whenever needed.

Note: do keep in mind that this an experimental module and that you'll also need to enable the Media module first things first.

“And how does it work more precisely?”
 

  1. while in your content edit screen
  2. just browse through all the media assets stored in your Media Library
  3. select the one you need
  4. and simply “inject” it into your page
     

Note: it's the “Media library” widget, added to the Media field, that enables you to scan through all your media entities straight from the content edit screen.

Handling Media in Drupal 8.6.0- Media Library Widget


4. The New “Media” Field: A Quick Way to Embed Media in Your Content

Handling media in Drupal 8.6.0 is as simple as... adding a new field — “Media” —  to the content type in question (be it news, blog post, article and so on).

Handling Media in Drupal 8.6.0- Add a New Media Field

Once the new field is added on, just go through the 5 media types available in Drupal 8.6.0 and select the one you need to embed.

Next, you can simply integrate it into your content, while in your edit screen, positioning it to your liking.
 

5. New Media Handling in Drupal 8.6.0: Youtube & Vimeo Embeds

A new media management tool that significantly improves the whole content editing experience in Drupal.

You're able to embed remote videos from Youtube and Vimeo via URL, thanks to the now added oEmbed media support.

“How precisely?” Basically, you simply:
 

  1. add that new “Media” field to your content type, as previously stated
  2. select the “Remote Video” option from the “Media Type” drop-down menu
  3. enter your video's URL in the “Video URL” field, while in your “Add Remote Video” screen
  4. and click “Save”
     

And voila: you'll have your remote video integrated into your content!

The END!

As Steve Burge from OSTraining would say:

“Finally we're getting somewhere with media in Drupal!”  

What do you think about the new features for media handling in Drupal 8.6.0? What other options and tools are there on your wishlist?

To be able to embed remote videos right from the node create page, maybe? Or to have other video platforms, as well, supported in Drupal?

Sep 20 2018
Sep 20

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

As mentioned previously, Dries has offered his thoughts on the proposed timeline for Drupal 9 in a recent blog entry on his website (see below).

timeline: Drupal 9 will be released in 2020. Drupal 8 end of life is planned for 2021

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.

In terms of adoption, Drupal has picked up steam with 51% growth from April 2017 to April 2018.

Dries Keynote Drupalcon 2018

graph showing that as of April 2018, 241,000 sites run on Drupal

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

graph shows Drupal 7 adoption exceeds that of Drupal 8

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

Pantheon had two excellent presentations (also at Drupalcon Nashville) that dive deeper into Drupal’s position in relation to other projects, most notably Wordpress. I would recommend watching WordPress vs Drupal: How the website industry is evolving and What's possible with WordPress 5.0 for more information on this topic.

According to builtwith.com, Drupal still has a sizable chunk of Alexa’s Top Million Sites. It should also be noted that Drupal does better the higher you go up the list of those sites which underscores the project’s focus on the enterprise.

CMS market share (builtwith.com)

5% of Alexa's Top Million sites run on Drupal

Drupal usage statistics (builtwith.com)

8.5% of the top 10k websites run on Drupal

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

Javascript is the most popular language

Github projects 2018

2.3 million Javascript Github projects

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.

The State of Javascript report from 2017 is often referenced to illustrate React’s popularity (see below):

survey respondents indicated that they have used and would use Javascript again - more than other technologies

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)

React downloads (1 month) exceed angular and vue

Npm downloads by technology (1 year)

React downloads (1 year) exceed angular and vue

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

screenshot of empty 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?

The popularity of Netlify hosting and static generators has created some buzz in the Drupal community, particularly Gatsby.js, which we will examine in a moment.

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. 

Have questions or feedback? Hit me up at https://twitter.com/drupalninja/

Sep 19 2018
Sep 19

Spotlights shining on the Drupal 8 logo

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.

Screenshot showing direct editing in YAML

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.

Sep 16 2018
Sep 16

Privileged to be given the opportunity by organisers at Drupal Europe to share Peace Through Prosperity‘s journey with the Drupal community. Thank you!

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…

  1. 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!
  2. 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

#DrupalEurope #Agile #Transformation #Society #Entrepreneurs #InternationalDevelopment

Sep 14 2018
Sep 14

Illustration showing multiple components of an SEO strategy 

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.

Which CMS is best for your website?  Take our CMS Quiz and find out!

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.

 image with text offering access to our free CMS Selection quiz.

Sep 13 2018
Sep 13

Yesterday at Drupal Europe, Drupal founder and lead developer Dries Buytaert gave a keynote that 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.

Have more questions about Drupal 7 vs 8 vs 9? Contact us and we’d be happy to help with your project.

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.

So which way should I go?

So which approach is best? For starters, think about whether an upgrade benefits you in the immediate term. Read a little about Drupal 8, audit your site with our website checklist, and if you still aren’t sure, you can start with our quiz.

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.

Sep 13 2018
Sep 13

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. 

Accessibility = Key for Search

The release of D8 marked a big push toward improving web accessibility, including: 

  • Overall community commitment to accessibility 
  • Technical features for improved accessibility like controlled tab order and aural alerts 
  • All features conform with the World Wide Web Consortium (W3C) guidelines

This is important because, as we know, the relationship between web accessibility and SEO is closely intertwined.

Drupal 8 SEO Modules

Here are some top Drupal 8 SEO Modules to use when optimizing your site. 

  1. Pathauto - helps save you time from manually having to create URL path/aliases.
  2. Metatag - allows you to automatically provide structured metadata, aka "meta tags", about a website.
  3. Sitemap - provides a site map that gives visitors an overview of your site. It can also display the RSS feeds for all blogs and categories.
  4. Redirect - Almost every new site needs to incorporate 301 redirects for old page URLs. This gives site admins an easy interface for creating those redirects in Drupal.
  5. Google Analytics - This simple module allows site admins the ability to easily configure Google Analytics in Drupal.
  6. 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. 
  7. 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. 

Sep 13 2018
Sep 13

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?
  • Will you be able to support the site without developer support?
  • What is your project budget?  
  • What is your post-launch support budget?

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:

Lego Duplo set, simple with large building blocks like Wordpress

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. 

 

Lego Technic race car is complex like Drupal

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.

Screenshot of Wordpress user-friendly dashboard

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.

Screenshot of Wordpress admin interface for adding a new blog

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.

Wordpress.org ecommerce plugins

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.

Screenshot of Wordpress themes and layout options

Updates

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

screenshot of Wordpress plugin updates

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

Screenshot of managing roles in Drupal CMS

screenshot of permissions in Drupal

adding a new user in Drupal CMS

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.

screenshot of taxonomy terms in Drupal CMS

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. 

Drupal 8 multilingual configuration

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.   

Drupal.org security advisory

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.

Sep 12 2018
Sep 12

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: 

  1. The Digital Revolution at Chatham House
  2. BASF: Fostering a Contribution Culture Against a Backdrop of Secrecy
  3. Future of the Open Web and Open Source

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.

 Former Chatham House Website 2004The 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. 

String Translation SolutionDrupal 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.

The digital transformation here resulted in a tangible, code-based output, but also in a noticeable shift for the company’s mindset. Sometimes intellectual property can increase in value once it is shared.  

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.

 

You can catch the Drupal Europe speeches live streamed on Youtube

Or, to find out how you can undertake your own digital transformation with Drupal, speak to one of our Digital Strategy and Consultancy experts. 

Speak to an expert

 

Sep 11 2018
Sep 11

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!

Demo Drupal Commerce today! View our demo site.

Additional details:

Sep 06 2018
Sep 06


Full name


Email


Phone number


Company


Location


Website


Project type


Estimated budget


Tell us about your project or idea

SUBMIT

Sep 05 2018
Sep 05

[embedded content]

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.

Grab our FREE course on using core Media in Drupal 8.
(While you’re at it check out our list of free courses)

New Remote Video Media Type

When you install the Media module you get four media types by default: Audio, File, Image and Video. Now you get Remote video which can be used to embed YouTube and Vimeo videos.

Currently only YouTube and Vimeo are supported. If you need to support other video platforms look at using Video Embed Field.

Learn how to configure Video Embed Field with core Media module.

oEmbed Support

To handle the new Remote video media type, Drupal 8.6 also got oEmbed support (Drupal change record).

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.

Want to learn how to use Entity browser? Check out “How to Browse Media Assets using Entity Browser“.

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.

Check out our epic “Managing Media Assets using Core Media in Drupal 8” tutorial where you’ll learn how to use Entity embed, Entity browser, DropzoneJS and more.

Ivan Zugec

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.

Sep 05 2018
Sep 05
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

Drupal paragraph vs content type example

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.

live-component-guide_02
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.

[embedded content]

Contact us and learn more about our custom ecommerce solutions

Sep 03 2018
Sep 03

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

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

Co-Author: Ali Hover, Lead Drupal Developer at CTI Digital

Cover Photo Cred: @thenomadbrodie 

Interested in working with us? Check out our vacancies here.

Careers at CTI Digital

Sep 02 2018
Sep 02

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.

How it started in the community keynote photo by Amazee Labs

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.

Already interested in the line-up? Come and have a look at the diverse and interesting program.

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.

See you all in Darmstadt!

Image Darmstadium venue in Darmstadt, Germany
Aug 30 2018
Aug 30

Pelo Fitness spinning class

Pelo Fitness spinning class

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.

Want to keep your site secure? Contact us to get started. 

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 can subscribe via email or RSS on Drupal.org or follow @drupalsecurity on 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. The TFA module provides a pluggable architecture for using the authentication platform of your choice, and Google Authenticator integration is 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). The Password Policy module sets the gold standard for traditional password strength requirements, or you can check out the Password Strength module if XKCD-style entropy is 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 using http:// instead of https://, 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. The Encrypt module serves 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. 

Contact us at Kanopi if you need help keeping your site secure.

Aug 30 2018
Aug 30


Full name


Email


Phone number


Company


Location


Website


Project type


Estimated budget


Tell us about your project or idea

SUBMIT

Aug 30 2018
Aug 30


Full name


Email


Phone number


Company


Location


Website


Project type


Estimated budget


Tell us about your project or idea

SUBMIT

Aug 30 2018
Aug 30


We all love Drupal's granular permission and access control system! And yet: its life-saving hierarchy of user roles and permission levels is strictly for 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:

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

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

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

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

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

And here are 2 of its most common use cases:
 

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

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

It enables you to:
 

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

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

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

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

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

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

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

You can limit access to these nodes to:
 

  • specific user roles
  • certain individual user accounts
     

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

How do you set everything up?
 

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


And there's more to look forward to! 

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

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

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

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

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

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

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

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

5. Group         

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

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

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

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

Furthermore, it allows you to define:
 

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

… per group type. 

And the best is yet to come:

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

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

A user role-based access control...

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


The END! 

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

Aug 29 2018
Aug 29

Image of a task board with MVP tickets

Image of a task board with MVP tickets

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’s much earlier 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:

  1. Timeline: Maybe the deadline you need to hit, simply won’t provide enough time to complete all the work you have queued.
  2. Resource Availability: Perhaps there are scheduling conflicts, or limited resource availability during your project.
  3. Budget Constraints: Another possibility is that the budget just isn’t sufficient to get to everything you have on your list.

Regardless of the restraint you’re facing, an MLP can help you realign priorities, and expectations to compensate. But how do you go about evaluating your project for an MLP?

Need help with defining your MPL? Contact us.

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:

  1. What are the things a User sees?
  2. What copy does a User read?
  3. 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.

Aug 29 2018
Jay
Aug 29

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. 

Ready to get the most out of Drupal?  Schedule a free consultation with an Ashday Drupal Expert. 

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.

New Call-to-action

Aug 28 2018
Aug 28


Full name


Email


Phone number


Company


Location


Website


Project type


Estimated budget


Tell us about your project or idea

SUBMIT

Aug 27 2018
Aug 27

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

Knowingly or just recklessly...

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

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

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

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

  1. description
  2. page title
  3. tags
     

... is one rookie SEO mistake. 

And one costly neglect, too...

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

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

you hit 2 birds with just one stone:
 

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

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

2. Ignoring the Slow Page Loading Speed 

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

And could you blame them? 

Instead, you'd better:
 

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

How? By:
 

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

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

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

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

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

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

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

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

4. Broken Internal Images

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

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

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

The result(s)?
 

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

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

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

Here's why:
 

  • an XML sitemap would include all the URLs on your website
  • … as well as information 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.

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

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

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

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

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

The END! 

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

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

Aug 24 2018
Aug 24

Image showing the words Drupal Module Spotlight: Reroute Email“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.

Reroute email module screenshot

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:

$config['reroute_email.settings']['reroute_email_enable'] = TRUE; 
$config['reroute_email.settings']['reroute_email_address'] = '[email protected]';

So there you have it. A great module that trades embarrassment for confidence. (They really should put that phrase on their module page!)

Aug 24 2018
Aug 24

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

Just face it and... fix it! 

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

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

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

1. Overlooking or Misusing Header Tags

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

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

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

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

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

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

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

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

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

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

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

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

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

Here are 3 of the most common causes:
 

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

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

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

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

3. Optimizing for the Wrong Keywords

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

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

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

The result(s)?
 

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

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

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

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

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

Here's another way of confusing crawlers even more:

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

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

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

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

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

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

Now, before answering your otherwise valid question:

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

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

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

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

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

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

Aug 24 2018
Aug 24

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

For, in vain you:
 

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

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

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

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

Now, let's get you some answers:
 

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

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

1.1. Prevent SQL Injection Attacks Using The Database Abstraction Layer

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

Now, let's talk... code.

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

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

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

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

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

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

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

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

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

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

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

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

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

Drupal's highly vulnerable to cross-site scripting.

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

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

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

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

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

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

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

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

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

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

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

Here's why:
 

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

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

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

2.4. Testing Your Code Against XSS

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

4.1. How You Can Check for Access Bypass Issues

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

It's easy:
 

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

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

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

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

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

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

What does it take to write secure Drupal code? 

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

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

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

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

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

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

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

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

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

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

Aug 23 2018
Aug 23

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.

And once I'm proud of my Lambda function, I'll post that, too. Update: Here it is.

Conclusion

So the tradeoff is that my reporting is not real-time and there are some AWS costs, but this frees up our web server to do what it should be doing best: serving content to our readers.
Aug 23 2018
Aug 23

[embedded content]

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.

How to Install Drupal Console

Drupal Console can be installed into your Drupal site using Composer, follow the instructions over on the Drupal Console documentation page.

Use the links below to jump to a section of the video:

  • Drupal Console intro: 02:31
  • How to install Drupal Console: 04:29
  • Using Drupal Console launcher: 06:27
  • Overview of Drupal Console commands: 07:41
  • How to use debug commands: 08:33
  • Using debug:router command: 10:11
  • Using debug:container command: 11:49
  • Using debug:cron command: 15:08
  • Using debug:user command: 15:08
  • How to use generate commands: 17:15
  • Using generate:module command: 18:07
  • View module code generated by Drupal Console: 20:42
  • Using generate:entity:content command: 20:59
  • View code generated by generate:entity:content command: 24:43
  • Install module generated by Drupal Console: 27:21
  • How to download modules using Drupal Console: 31:10
  • Viewer question: What’s composer?: 34:45

Drush

Drush is the original CLI tool for Drupal. You can use it to interact with a Drupal site and generate boilerplate code.

How to Install Drush

Drush is just a PHP library and can be installed using Composer. For details read the Drush install documentation page.

Use the links below to jump to a section of the video:

  • Drush intro: 37:22
  • How to install Drush: 40:56
  • Using Drush: 42:11
  • Overview of Drush Commands: 43:00
  • Using Drush generate command: 44:11
  • Using generate module-content-entity command: 45:12
  • View module code generated by Drush: 46:23
  • Install module generated by Drush: 47:13
  • Overview of common Drush commands: 52:00
Ivan Zugec

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.

Pages

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web