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.

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.

Aug 23 2018
Aug 23
Image by LuckyStep @shutterstock
  • to revolutionize publishing, with a new rewarding model in an environment which can build trust and allows community governance.
  • to reshape open source communities, with a better engagement and rewarding system.
  • to free digital identity, thus killing the need of middlemen at the protocol layer.

Blockchain is an universal tool and can be applied in many different areas.

Communities, like the Drupal Community, can find new ways to flourish. Even larger and risky projects can be financed in new ways, with ICO (Initial Coin Offer). Taco Potze (Co-Founder Open Social) has a 10 year Drupal background and is an expert on Communities. He is working on blockchain technology to build a better engagement and rewarding systems for communities. Wouldn’t that be really nice for us?

See also Taco’s session: ICOs, a revolutionary way to raise money for your company

Publishing and its classic monetization model is challenged. Intermediates are about to disrupt the relationship between authors and publishers and their readers. This is based on a troublesome business model, with massive tracking and profile building, to turn our engagement in advertisement money. At the same time poor content and fake news has become a threat to our society. Gagik Yeghiazarian (CEO, Co-Founder Publiq) is looking for new ways to address these problems, with a non profit, distributed media platform based on blockchain.

See also Gagik’s session: Blockchain Distributed Media — A Future for good publishing

The Internet is broken and blockchain can fix it. The biggest promise with blockchain is to make middlemen obsolete, by creating trusted identities in an open protocol. This is to break the monopoly of the middlemen and to retain a free web. We recognize aribnb, amazon, ebay, netflix, itunes as middlemen. We understand, when we by or book, they get their share. With Google, Facebook and YouTube there are some other huge monopoly middlemen, they get their share based on our attention and personal data. They know how to transfer our attention into dollars, by selling it to advertisers. Ingo Rübe (CEO Bot Lab) is working on a protocol, which will allow people to gain control of their digital identity. It will be called KILT Protocol. (Ingo is well known in the Drupal Community and a Member of Drupal’s Advisory Board. As a former CTO of Burda he was the Initiator of the Drupal Thunder Distribution)

Our Panel will be moderated by Audra Martin Merrick, a board member of Drupal Association.

signed
Drupal Europe
Your Track Chairs

Aug 22 2018
Aug 22

At Mediacurrent, we hear a lot of questions — from the open source community and from our customers — about website accessibility. What are the must-have tools, resources, and modules? How often should I test? To address those and other top FAQs, we hosted a webinar with front end developers Ben Robertson and Tobias Williams, back end developer Mark Casias, and UX designer Becky Cierpich.

The question that drives all others is this: Why should one care about web accessibility? To kick-off the webinar, Ben gave a compelling answer. He covered many of the topics you’ve read about on the Mediacurrent blog: introducing WCAG Web Content Accessibility Guidelines, some the benefits of website accessibility (including improved usability and SEO) and the threats of non-compliance.

[embedded content]

Adam Kirby: Hi everybody, this is Adam Kirby. I'm the Director of Marketing here at Mediacurrent. Thanks everyone for joining us. Today we're going to go over website accessibility frequently asked questions. 

Our first question is: 

Are there automated tools I can use to ensure my site is accessible and what are the best free tools? 

Becky Cierpich: Yes! Automated tools that I like to use —and these are actually all free tools— are WEBAIM’s WAVE tool, you can use that as a browser extension. There's also Chrome Accessibility Developer Tools and Khan Academy has a Chrome Plugin called Tota11y. So with these things, you can get a report of all the errors and warnings on a page. Automated testing catches about 30 percent of errors, but it takes a human to sort through and intellectually interpret the results and then determine the most inclusive user experience. 

What's the difference between human and automated testing? 

Becky Cierpich: Well, as I said, the automated tools can catch 30 percent of errors and we need a human on the back end of that to interpret. And then we use the manual tools, things like Chrome Vox or VoiceOver for Mac, those are some things you can turn on if you want to simulate a user experience from the auditory side, you can do keyboard only navigation to simulate that experience. Those things will really help you to kind of drive behind the wheel of what another user's experiencing and catch any errors in the flow that may have come from, you know, the code not being up to up to spec. 

Then we also have color contrast checkers. WEBAIM has a good one for that and all these are free tools and they can allow you to test one color against another. You can verify areas that have too little contrast and test adjustments that'll fix the contrast. 

What do the terms WCAG, W3C, WAI, Section 508, and ADA Title III mean? 

Mark Casias: I'll take that one - everybody loves a good acronym. WCAG, these are Web Content Accessibility Guidelines. This is the actual document that gives you the ideas of what you need to change or what you want to a base your site on. W3C stands for World Wide Web Consortium - these are the people who control the web standardization. WAI is the Web Accessibility Initiative and refers to the section of the W3C that focuses on accessibility. 

Finally, Section 508 is part of the Rehabilitation Act of 1973, well it was added to that act in 1998, to require Federal agencies to make their electronic and IT  accessible to people with disabilities. ADA Title III is part of the Americans with Disabilities Act which focuses on private businesses, it mandates that they need to be fully accessible to individuals with disabilities. 

 What are the different levels of compliance? 

Tobias Williams: Briefly, the WCAG Web Content Accessibility Guidelines tell us that there are three levels - A, AA, and AAA, with AAA being the highest level of compliance. These are internationally agreed to, voluntary standards. Level A has the minimum requirements for the page to be accessible. Level AA builds on the accessibility of level A, examples include consideration of navigation placement and contrast of colors. Level AAA again builds on the previous level - certain videos have sign language translation and improved color contrast. 

To meet the standard of each level there are 5 requirements that are detailed on the WCAG site. Every every actionable part of the site has to be 100% compliant. WCAG doesn't require that a claim to a standard be made, and these grades are not specified by the ADA but are often referenced when assessing how accessible the site is.

Should we always aim for AAA standards?

Ben Robertson: How we approach it is we think you should aim for AA compliance. That's going to make sure that you're covering all the bases. You have to do an internal audit of who are your users and what are your priorities and who you're trying to reach. And then see out of those, where do the AAA guidelines come in and where can you get the biggest bang for your buck? I think that the smart way to do it is to prioritize. Because when you get to the AAA level, it can be a very intense process, like captioning every single video on your site. So you have to prioritize. 

What Drupal modules can help with accessibility?

Mark Casias: Drupal.org has a great page that lists a good portion of these modules for accessibility.  One that they don't have on there is the AddtoAny module that allows you to share your content. We investigated this for our work on the Grey Muzzle site and found this was the most accessible option. Here are some other modules you can try:

  • Automatic Alternative Text -The module uses the Microsoft Azure Cognitive Services API to generate an Alternative Text for images when no Alternative Text has been provided by user.
  • Block ARIA Landmark Roles -Inspired by Block Class, this module adds additional elements to the block configuration forms that allow users to assign a ARIA landmark role to a block.
  • CKEditor Abbreviation - Adds a button to CKEditor for inserting and editing abbreviations. If an existing abbr tag is selected, the context menu also contains a link to edit the abbreviation.
  • CKEditor Accessibility Checker - The CKEditor Accessibility Checker module enables the Accessibility Checker plugin from CKEditor.com in your WYSIWYG.
  • High contrast - Provides a quick solution to allow the user to switch between the active theme and a high contrast version of it. (Still in beta)
  • htmLawed  - The htmLawed module uses the htmLawed PHP library to restrict and purify HTML for compliance with site administrator policy and standards and for security. Use of the htmLawed library allows for highly customizable control of HTML markup.
  • Siteimprove - The Siteimprove plugin bridges the gap between Drupal and the Siteimprove Intelligence Platform.
  • Style Switcher - The module takes the fuss out of creating themes or building sites with alternate stylesheets.
  • Text Resize - The Text Resize module provides your end-users with a block that can be used to quickly change the font size of text on your Drupal site.

At what point in a project or website development should I think about accessibility? 

Becky Cierpich: I got this one! Well, the short answer is always and forever. Always think about accessibility. I work a lot at the front end of a project doing strategy and design. So what we try to do is bake it in from the very beginning. We'll take analytics data and then wecan get to know the audience that way. That's how you can kind of plan and prioritize your features. If you want to do AAA features, you can figure out who your users are before you go ahead and plan that out. Another thing we do is look at personas. You can create personas that have limitations and that way when you go in and design. You can be sure to capture those people who might be challenged by even things like a temporary disability, slow Internet connection or colorblind - things that people don't necessarily even think of this as a disability.

I would also say don't worry if you already have a site and you know, it's definitely not compliant or you're not sure because Mediacurrent can come in and audit, using the testing tools to interpret and prioritize and slowly you can get up speed over time. It's not something that you have to necessarily do overnight. 

How often should I check for accessibility compliance? 

Tobias Williams: I’ll take this one - I also work on the front end, implementing Becky’s designs. When you're building anything new for a site, you should be accessibility testing. test work, During cross-browser testing, we should also be checking that our code meets the accessibility standards we are maintaining.

Now that's easy to do on a new cycle because you're in the process of building a product that currently exists. I would say anytime you make any kind of change or you're focused on any kind of barrier of the fight, I would run a quick accessibility check. And then even if you don't address the changes straight away or at least you're aware of that, you can document them and work on them later. As far as an in-production site where you have a lot of content creators, or where independent groups work on features it is also a good idea to run quarterly spot checks. 

I've seen these on a few sites, but what is an accessibility statement and do I need one?

Becky Cierpich: An accessibility statement is similar to something like a privacy agreement. It's a legal document and there are templates to do it. It basically states clearly what level of accessibility the website is targeting. If you have any areas that still need improvement, you can acknowledge those and outline your plan to achieve those goals and when you're targeting to have that done. It can add a measure of legal protection while you're implementing any fixes. And if your site is up to code, it's a powerful statement to the public that your organization is recognizing the importance of an inclusive approach to your web presence. 

What are the legal ramifications of not having an accessible website? 

Ben Robertson: I'll jump in here, but I just want to make a disclaimer that I'm not a lawyer. Take what I say with several grains of salt! This whole space is pretty new in terms of legal requirements. The landmark case was  Winn-Dixie, the grocery store chain — it was filed under title III of ADA Act and they lost. It was brought up by a blind customer who could not use their website. The court order is available online and it's an interesting read but basically, there were no damages sought in the case. The court ordered that

they had to have an accessibility statement that said that they would follow WCAG 2.0. That's a great refresh for site editors to make sure that they're following best practices. They also mandated quarterly automated accessibility testing. 

I really think if you have these things in place already, you're really gonna mitigate pretty much all your risk. You can get out in front of it if you have a plan. 

If I have an SEO expert, do I need an accessibility expert as well? 

Tobias Williams: I'll explain what we do at Mediacurrent. We don't have one person who is an expert. We have a group of people. We have several developers, designers and other people on the team who are just interested in the subject and we meet once a week, we have a Slack channel where you just talk about accessibility. There are people who are most familiar with different aspects of it and that allows us to be better rounded as a group. 

I can see somebody being hired to be an accessibility expert but I think that the dialogue within a company about this issue is most important. The more people who are aware of it, the better. You can prevent problems before they occur. So, if I'm aware of the accessibility requirements of an item building, I'm going to build it the right way as opposed to having to be reviewed by the expert and then making changes. The more people who are talking about it and were involved in it and I'm the general level of knowledge, it goes a long way. We don't need to have experts as much as we need to have interested people. 

As a content editor, what's my role in website accessibility?

Mark Casias: Your role is very important in website accessibility. All the planning and site building that I do [as a developer] won't mean a thing if you don't attach an image alt tag to your images or you use a bunch of H1 title tags because you want the font size to be bigger and things like that. Content editors need to be aware of what they're doing and its impact on accessibility. They need to know the requirements and they need to make sure that their information is. keeping the website rolling in the right direction. Check out Mediacurrent’s Go-To-Guide for Website Accessibility for more on how to do this. 

Some of the technical requirements for accessibility seem costly and complex. What are the options for an organization?

Ben Robertson: Yeah, I totally agree. Sometimes you will get an accessibility audit back and you just see a long list of things that are red and wrong. It can seem overwhelming. I think there's really a couple of things to keep in mind here is that one, you don't have to do everything all at once. You can create an accessibility statement and you can create a plan and start working through that plan. Two, it really helps to have someone with experience or an experienced team to help you go through this process. There can be things that are a very high priority that are very easy to fix and there can be things that may be a low priority.

You can also think about it this way: if you got a report from a contractor that something you're building was not up to code, you would want to fix that. And so this is kind of a similar thing. People aren't going to be injured from using your website if it's inaccessible but it's the right thing to do. It's how websites are supposed to be built if you're following the guidelines, and it's really good to help your business overall. 

How much does it cost to have and maintain an accessible site? Should I set aside budget just for this? 

Adam Kirby: You will want to set aside a budget to create an accessible site. It is an expense. You're going to have to do a little bit more for your website in order to make sure it's successful. You're going to have to make changes. How much does it cost? That will vary and depend on where you are with your site build; if it’s an existing site, if you're launching a new site, the amount of content on your site and the variability of content types. So, unfortunately, the answer is it just depends. 

If you need help with an accessibility audit, resolving some known issues on your site, or convincing your leadership to take action on website accessibility, we’re here for you.  

Webinar Slides and Additional Resources 

Aug 21 2018
Aug 21

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

Have I guessed it?

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

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

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

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

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

1. Proper Planning: Get The Whole Team Involved

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

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

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

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

They're the (only) ones able to:
 

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

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

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

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

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

Refrain yourself from that...

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

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

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

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

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

And lead your project to... failure.

Instead:
 

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

By:
 

  • hiding
  • ignoring
  • “genuinely” underrating
     

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

And now speaking of encouraging good communication within your team, how about creating a dedicated open forum for them to use?

This could be the “place” where they'd share any issues that they will have detected in the project. Or the challenges they're facing and can't address by themselves.
 

4. Juggling with Resources, Timeline, and Unforeseen Events

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

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

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

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

And that of overburdening your team with unscheduled tasks.

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

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

5. Drupal Project Management Is 90% Good Time Management

And it all comes down to:

Breaking your Drupal project down into small, manageable tasks. 

Tasks that can be easily turned into goals and objectives:
 

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

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

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

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

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

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

Aug 17 2018
Aug 17

There are lots of situations in which you need to run a series of microsites for your business or organisation — running a marketing campaign; launching a new product or service; promoting an event; and so on. When you’re with Drupal, though, what options do you have for running your microsites? In this article I review and evaluate the options in Drupal 8, make a recommendation and build a proof of concept.

So, I want to run some microsites …

A client brought me an interesting problem recently, something they need to solve for their production Drupal site. They are an international humanitarian agency who, alongside their main production website, want to run some microsites for a number of their public campaigns. Although they could run them on the main site, they’ve found too many limitations in trying to do that. Campaign teams, frustrated with the lack of flexibility and slow protocols for getting changes made to support their bespoke needs, have often gone off with their small budget and dynamic team to create something quick that fits their campaign with Squarespace or Wordpress or something.

That made the campaigners really happy. But, when the campaign or event lapsed, the campaign site quickly got out of date and went unloved, the campaign team moved on and no-one could remember how to log into the system and it became abandoned.

Hearing this story was so familiar — the same thing often happened when I was a senior developer at Oxfam International.

So, they said, could something be done about it? What, if anything, could be done with Drupal to support campaigners get their microsites running? What would give them the fast, bespoke solution to their microsite problems, whilst still keeping all the content well-managed and being able to share that content with the main site or other microsites?

I scratched my chin and had a think.

How about Drupal multisites?

Since some of its earliest versions, Drupal has included a feature for multi-sites — running several sites from a single codebase installation, sharing the core system, contributed and custom modules and themes. Each multisite has its own database, its own settings and configuration, its own content, and so on. Ideally, it also means updates can be done once.

So, multisites could be an option. Many people find them to be a real workhorse for their context, and often they are right on the money.

Why use multisites

The Drupal.org documentation for multisites includes a simple rule-of-thumb for when to multisite:

As a general rule on whether to use multisite installs or not you can say:

- If the sites are similar in functionality (use same modules or use the same drupal distribution) do it.

- If the functionality is different don’t use multisite.

(DrupalCon Austin [June 2014] held a interesting debate on Drupal multi-sites, its pros and cons, gotchas and suggestions, which is available on YouTube.)

There’s several compelling reasons to use them.

First, having a single codebase to maintain is a huge plus. Forked codebases can soon become orphaned, and unloved codebases become fraught with problems too quickly.

Second, multisites often mean there is also a single hosting platform to maintain, which is also a major advantage.

That can often mean, thirdly, that multisite installations can make better use of resources, both the server resources and financial, personnel or other physical resources. For example, since multi-sites share the same core and modules, that code need only go into the opcode cache once, saving server resources.

Caveat: is the end of multisites support on the horizon?

It should be noted that a proposal has been made to deprecate support for multisites in Drupal, with a view to removing it in the future.

The basic argument for this is that it’s an ‘old skool’ way of thinking about handling multiple sites. Git and Composer create practices and codebase structures that point in other directions.

The modern approach to multi-site is: git — Same code, different sites. Under your control. And well-maintainable.

There are a number of positive reactions to that proposal, which are variations on a theme:

+1. Multisite is a historical oddity at this point and I’d never tell anyone to use it.

But there are many more negative reactions, which largely go along these sorts of lines:

-1. Multisite has been a workhorse for a ton of Drupal sites and is well established in our code.

In that light, Drupal’s multi-site feature is likely to stay around for a while.

Classic problems with Drupal multisites …

It’s not all a bed of roses, though. There are some classic sticking points when working with Drupal multisites.

First off, handling traffic. One site’s traffic spike can be another site’s nightmare when the hosting resources are all hogged by The New York Times tweeting a link to a page on a site of yours; one site’s ‘BEST DAY EVA!’ can be the worst of times for all the rest.

The load on your database server may also be an issue. Multisites often use a single database server, and heavy load or slow queries in one DB can impact the performance of others. This might even be caused in the normal running of your Drupal sites, such as when running cron.

Running updates often causes headaches. When you update code, you’re updating all your sites at once. That means the updates are deployed, well, instantly across all your sites, but if they need update processes to run, such as updating the database, that can throw unexpected problems or errors.

And the worst of the worst: a small piece of poorly written, inadequately reviewed or tested code mysteriously jumps itself onto production — that never happens, right? No one ever lets that happen, do they? *ahem* — and takes down all your sites at once! It’s just an urban myth, a story to scare the children with at night, right? Never happens.

… and how to mitigate them

There are of course a number of ways to foresee these things happening and be ready for them.

On the performance questions, with smaller demands you can just ride it out — sites on the same hosting platform are fairly tolerant of resources being shared around, and the spare capacity is there for times just like there.

For larger performance demands, handling the pressure is a challenge in any hosting set-up, dedicated hosting just as much as shared. With modern cloud infrastructure, the option of scaling up your infrastructure or spinning up a new cluster when you’re experiencing ongoing heavy demand is much easier than in the past, especially if you plan for it as a possibility.

The next set of mitigations are all about best practice.

For starters, test, test, test. Don’t let any code onto production that hasn’t been tested thoroughly.

Have a solid release process that you always follow. If possible, include dev, staging and quality assurance stages. This should give you lots of points to catch things before they’re released onto your production sites.

Automate all the things. There are lots of ways of automating things to ensure they run consistently and quickly too, from shell scripts up to continuous integration tools. Use them.

And finally, be intelligent. With code changes that need database updates, for example, design your code so that it can be deployed to handle an interval before the database is updated. Or, with important but more volatile updates, be smart about choosing the time of day and week that you deploy it. Don’t ever push something out at 5pm on a Friday afternoon if you want to stay friends with your colleagues, your customers and your family.

Well, yes, in short, kinda. You could run microsites using Drupal’s multi-site feature. Things would work fine, though of course you’d have all the problems described above and have to take the mitigating actions.

However, it wouldn’t solve all the needs described above without some smart thinking. Plus, I’d suggest that you would also have some other problems to solve.

First, multisites all use different databases (sharing databases and tables is possible with Drupal multisites, but really unadvisable!) so the need of a single place for managing all the site content wouldn’t really be satisfied. The way around that would involve using web services, posting and pulling content from one site to another.

Neither would we have a unified search. There are fairly straightforward ways around that, using a tool like Apache Solr. The sites would need to share an index, with each document in the index including a site field, and there’s a contrib module that does that already (although no Drupal 8 version yet).

Lastly, and maybe more pertinently, you would still have all the ‘Drupalisms’ to live with. First of those is the visual design layer, the public user’s interface for the sites, what gets called the ‘theme layer’ in Drupal lingo. Many designers really dislike Drupal’s theme layer, and would really prefer to work with the pure frontend tools they use in other contexts. Drupal 8 has made major strides forward with the theme layer so it’s not as tough for designers as it once was, it’s true, but many (most?) frontend specialists would still rather not work with it.

Some consider influential Drupal figures consider multisites as ‘not enterprise grade’ and opinions like that are worth considering if your situation is enterprise scale.

Other approaches with Drupal

There are a few other ways of supporting microsites with Drupal that might be worth considering.

Domain Access

The Domain Access project was created to support just this kind of functionality. The project overview says as much:

The Domain Access project is a suite of modules that provide tools for running a group of affiliated sites from one Drupal installation and a single shared database. The module allows you to share users, content, and configurations across a group of sites.

This might work. However, there are many of the same problems with core multisites described above with this approach, with one additional one: everything in one database.

Our experience of using it, and this is echoed by others too, is that with a small number of very similar sites Domain Access can work well. With a larger number of fairly different sites, it’s a right pain and actually makes things quite difficult, requiring lots of complicated custom code.

Organic Groups

The Organic Groups suite of modules could be a solution for building microsites. The project allows users to create a ‘group’ within a Drupal site. The group can have its own users, admins, content, menus, even its own visual design. However, it would need every microsite to sit internally, within the main site, so does not solve the need to supporting external sites on their own domain. So, not really the perfect fit.

Best practice: with Git

I quoted above from @sun in the discussion on deprecating multisite support about the modern best practice:

The modern approach to multi-site is: git — Same code, different sites. Under your control. And well-maintainable.

This is certainly my standard recommendation and will give you many advantages: independence of sites for performance, design, etc; single codebase to maintain (though you’ll have a challenge developing and maintaining the variations you’ll want or need for each microsite); better control over updates; and so on.

You might even look writing an install profile to make a full distribution, though with Drupal 8 there is less of a need to do this. With Drupal 8, I’d advocate that you use Drupal Composer to build your site and just export your full site config into your repo (being careful to remove any sensitive settings from the repo with your .gitignore file).

Or you might also consider using Aegir to manage your multiple sites — use Drupal to deploy Drupal, if that’s not too much Inception.

Microsites and Drupal

So if multisites could work but would be a bit of a pain, the other Drupal approaches are even less appealing, and you’d rather not keep multiplying Drupal installations, how else could we do microsites with Drupal?

Well, there are two major moves in modern web development that might help here: RESTful web services, and decoupled CMS architectures (a.k.a. ‘headless’ CMS). My proposal for managing microsites in Drupal 8 depends on both these ideas:

  • Treat your Drupal site as a pure content management system (CMS) — a content hub that allows authors, editors and administrators to create, update and manage the content for which they’re responsible, but doesn’t have any meaningful frontend presentation layer to it.
  • Present the data of the content in the hub CMS via a RESTful API.
  • Implement a separate frontend for the visual presentation layer that communicates with the content hub CMS via the API.

There need be no limit to the number of frontends that use the CMS’s API (though practically you may limit access with firewalls, CORS or some other means) so you could power a primary public site, other sub-sites, native mobile apps or even another CMS or two, each potentially with their own visual design. The limit is your own imagination and situation.

RESTful web services and Drupal 8

A new addition to Drupal 8 is the RESTful Web Services API. REST resources can be exposed to allow other things to talk to/consume/feed a Drupal site. Many core entities have REST resources, but it is also fairly easy to build custom REST resources. (There a number of interesting web services contrib projects that are worth considering, such as the GraphQL project that presents a GraphQL schema, and the RELAXed Web Services project that extends the core REST resources.)

Design your own web services API

The freedom to build custom REST resources in Drupal 8 allows a lot of freedom in designing a RESTful API.

In a forthcoming blog post I’ll write in more about designing an API. For now, all I need to say is you need to actually design your API. Don’t simply use the out-of-the-box Drupal core REST resources — think about the RESTful API that would best serve the frontend you want to have.

My heartfelt recommendation is you do this, designing your API, using the skills of those who’re best at designing things — your designers. They understand best what your users want to do on your sites, will be able to describe what data they want for the frontend (content with/without markup, etc.) and help you design the API that is most appropriate to your needs.

There are some API design golden rules and best practices that you should consider. Also I’d recommend using an API design tool like Apiary.io or Swagger.io. They’re invaluable for many reasons, not least of which is the lovely documentation they generate and mock data servers they include that can help frontend devs get going quickly.

Decoupled frontend

With the content hub now presenting the managed content as RESTful data, we just need a standalone frontend system to present your website to your users: one for your primary site, and one for each of your microsites. Your frontend specialists can then work with the right tools for the task, then.

There are several advantages to consciously uncoupling the content management and the frontend.

Freedom: frontend specialists are free to the implement the user experience with native tools that are built for the job.

Performance: everything in this architecture can be streamlined. The CMS simply presents the content data. The frontend focuses on the display logic.

Experience: the website can respond to users in real time, communicating back and forth with the CMS to give real-time interactions in the browser.

Future proof: it becomes much easier to replace any part of the system as you require, such as redesigning the website without re-building the CMS.

Microsites in Drupal 8

So, how might we do this practically in Drupal 8? Here’s how I tackled it.

First, I thought about designing a quick prototype API that could be used to describe microsites and their content. I used Apiary.io to design it, and you can view the API at docs.campaignmicrosites.apiary.io.

The final part is the standalone frontend tool. For this I used React. I used React to build my frontend app, but there’s obviously plenty of other options depending on what the frontend needs to do. React worked for me because I just wanted the view layer, but Angular or Ember could be more appropriate if the frontend needed to be a more substantial app. You’d need to evaluate the frontend options carefully.

I’m not a frontend specialist, so my prototyping code is pretty fugly. Despite that, we’re able to serve two microsites simultaneously on different URLs, with a different theme, just by switching the campaign ID in the API request.

Bingo!

Deploying to production

There’s a few things I might do to deploy this to a production system.

Secure serving

As a good internet citizen, I’d want to put everything on SSL.

Frontend deployment

To deploy the frontend, I’d be looking at options to run the apps on a NodeJS server so that most of the scripts can run server side.

I’d probably want to put an Nginx instance in front of it, for SSL termination, caching static assets and reverse proxy.

Use Drupal multisites ;-P

I think there is actually a neat way of using Drupal’s multi-sites feature here: use a different domain for the RESTful API. For example:

Editorial interface: hub.yourdomain.com
API interface: api.yourdomain.com

Both of these point to your Drupal codebase but you can then handle requests differently on each domain. For example, you might add an authentication provider that checks the domain to give you some access control, so there’s no access to the editorial interface on the API subdomain, and none to the API on the editorial domain.

Caching etc.

This would then allow you to do some smart things with caches and other parts of your hosting stack, offloading much of the pressure on the codebase to the caching architecture and removing the actions of editorial staff from affecting the RESTful API’s performance.

Databases

It might also be possible to configure GET requests to only use a slave database, which could be useful for performance — though may be more hassle than it’s worth. POST, PUT, PATCH and DELETE requests would still need to go to the master.

In summary

This prototype worked really well for me and I was very happy with the results, and it gave me something very interesting to discuss with the client.

The advances made in Drupal 8 to operate with current standard web practices are good news for developers and for web projects big and small. For this prototype, the particular improvements with providing RESTful resources means that I was able to create a decoupled Drupal system to support a main website and unlimited microsites in an amazingly short space of time.

… and something to take away

If you’re interested in following up this thought experiment with my Drupal 8 prototype, I’ve put the code into a repo in GitHub:

Just …

$ git clone [email protected]:ConvivioTeam/Convivio-ContentHub.git {some_empty_directory}
$ cd {some_empty_directory}
$ composer install

… and you’re away.

(My React code is shamefully dirty, so I’m not prepared to share that at moment. ;-) I may tidy it up in the future and share it here.)

Aug 17 2018
Aug 17

It's a robust, flexible and admin feature-packed CMS, there's no point in denying it. And yet: Drupal (still) lacks a modern UI that would make building rich web content —  such as landing pages — a breeze. But there is hope: the Gutenberg editor has been ported over, promising a better editing experience in Drupal 8.

The team behind this daring project? Frontkom, a Norwegian digital services agency that:
 

  • refused to just sit and wait (for a year or two) for the in-progress initiative of modernizing Drupal's admin UI to grow into a core solution
  • decided to capitalize on their experience in working with the Gutenberg page builder 
  • … and on this content editor's open source nature, too
  • … to bring it over to Drupal 8
     

Now, if you're determined to improve the editorial UX on your Drupal site, to “spoil” your editors with a modern, intuitive and flexible admin UI, keep on reading...
 

1. The Drupal Gutenberg Project: Aiming for a Modern Admin UI in Drupal 8

And by “modern” I do mean the opposite of the Panels & Paragraphs & Layout combo solutions currently available for editing text in Drupal.

Solutions which only manage to make the entire workflow... discouragingly complex.

Especially if it's rich web content that editors need to create via the Drupal admin UI.

And this is precisely the context where the Drupal Gutenberg project was born: Drupal desperately needed/needs a modern, JavaScript-based admin UI.

With WordPress 5 users already enjoying this fancy content editor and the Frontkom team's having gained experience in using it, the idea of porting it to Drupal started to form:

"Why wouldn't we make it possible for Drupal users, too, to benefit from this content editor?" 

And here are some of the original Gutenberg project's features that lead them into thinking that, once ported, the editor would significantly improve the editing experience in Drupal 8:
 

  • it's (highly) decoupled
  • it's open source
  • it's React.js-based 
  • it provides a simplified, smooth and cool functionality-packed admin UI
  • it's Medium and Squarespace's inspired
  • it turns the creation of complex landing pages into a breeze
     

Page editing in Drupal 8 wasn't going to be the same again!

Their initiative turned into a Drupal 8 module —  Gutenberg Editor —  currently still an experimental one. 

Curious enough?

The first step to satisfy your curiosity is to take a look at their live demo: an interactive glimpse into the Gutenberg text editor implemented in Drupal 8.
 

2. The New Gutenberg for Drupal: Top Features Improving the Editing Experience in Drupal 8
 

2.1. All the Page Elements Are... Content Blocks

That's right, the team behind this project capitalized on the “everything is a block” Drupal 8 concept when adapting the Gutenberg UI to Drupal.

The result?

Both the Drupal core blocks and 20+ Gutenberg blocks are available in the resulting admin UI.

Basically, a Drupal 8 editor can insert into the web page that he/she's creating any of the core Drupal blocks and of the Gutenberg blocks of choice.

Speaking of which, let me point out just a few:
 

  • Heading
  • Image gallery
  • Auto embedded social posts
  • Buttons
  • Custom Drupal blocks
  • Layout blocks
     

Needless to add that you're free to enrich this list with your own custom blocks, too.
 

2.2. Easy Switch from Visual to Code Editor

That's right, the Gutenberg UI enables you/your editors to quickly switch to code editor —  opening up a neat markup —  and to apply any needed tweaks on the output.
 

2.3. Positioning Content Is Straightforwardly Intuitive

Editors get to select precisely where they want to position different types of content on a page.

And the very same results that they generate while in the Gutenberg admin UI get instantly reflected on the live web page, as well.

And there's more! More great admin features improving editing experience in Drupal. For instance:

Full control over font sizes and colors; tweaking them becomes a breeze with the new editor.
 

2.4. There's a Blocks Search Box

And not only that:
 

  1. using this search box you can track down precisely those content blocks that you need to add to your page
  2. but you can access them inline, as well, using “/”.
     

2.5. Full Control of the Layout

Another great thing about the content blocks available in the Gutenberg UI is that: they can have child block, too!

This way, it'll get unexpectedly easy for your editors to split their used blocks into columns on a grid.
 

2.6. Auto Embedded Social Posts/Videos

And all it takes is pasting their URL.
 

The Story of a Real Challenge: Making Gutenberg CMS-Agnostic

Open source, but not fully CMS-agnostic... 

The team behind the Drupal Gutenberg project had to come up with a suitable solution for this challenge. And they did come up with a multi-step solution to make the fancy text editor work in Drupal 8, as well:
 

  • first, they created a fork and removed the WordPress specific features
  • they used the Gutenberg editor as a dependency at first
  • next, they set up a standalone NPM package
  • then they built the Gutenberg Editor module
     

In short: a fork of the initial Gutenberg project is still maintained while being used as a dependency of the new Drupal 8 module. Therefore, each time Gutenberg gets an updated, the corresponding Drupal module, too, gets a new release.

Now, digging deeper into the project's architectural design, we discover 2 elements that the team had to re-write for Drupal:
 

  1. the URL defining the editor routes (edit page route, new page route, preview page route)
  2. the api-request, now configured to “talk to” Drupal (instead of the WordPress API)
     

How does the new module work?
 

  • as a text editor, which can be easily enabled for each content type
  • all it takes is a long text field for it to work: it replaces the node edit UI for that specific content type
     

Note: the Frontkom team also “promises” us to re-use as many Drupal-specific styling for the editor's UI elements in order to add a familiar Drupal feeling to it.
 

What Next? What's The Project Roadmap

Ok, so what we know for sure now, regarding this ambitious initiative turned into a Drupal module is that:
 

  1. the Drupal Gutenberg module is downloadable, yet still experimental (for developer use only)
  2. the team's still working on the project, implementing new features and functionalities aimed at making it feel more... Drupal native
  3. the final version will be presented to the eager/intrigued/curious/skeptical Drupal users and developers in the coming months
     

The END! Can't hide that I'm more than curious what you think about this contrib solution for improving the editing experience in Drupal 8:
 

  1. Are you looking forward to using it, hoping that this editor would make up for the inconveniences of working with Drupal's current admin UI?
  2. Are you skeptical about the perspective of being tied up to a WordPress page builder?
Aug 15 2018
Aug 15

Business person looking at Drupal logo, deciding on a CMS

You may have heard of Drupal in passing, but you have not ever been given a straight answer on what it is and why you should care. The truth is that even if you have worked with Drupal, you might not actually know what to say when asked what it is. Looking around there doesn’t seem to be a lot of great answers to this question out there either. It would be difficult to tell if you need Drupal as a solution for your website if you aren’t even sure what it really is to begin with. 

The Basics

To say we talk about Drupal a lot is an understatement. It’s non-stop Drupal all day long here at Ashday, but what is Drupal? Simply put Drupal, is an open source content management system. It's primarily built in the PHP programing language, and designed to create websites for use on a variety of different web servers.

Okay, but what is a content management system? A typical definition of a content management system or CMS is an application that is often used for creating websites that focuses on publishing workflows, user management, and content delivery. These dynamic and database driven websites usually allow for multiple editors and templating for streamlined content development. This is different than a plain old web page that is written in HTML and styled in CSS. A content management system allows you to compose and edit just the content without having to adjust the HTML. It makes it easier for non-technical users to publish text and images on the web to use that content in more than one place. With a CMS you can display your blog post on the homepage and in your blog, without needing to write the same content twice.

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

What does it mean to be open source? Open source means that all of the core code that makes the software tick is free and open to view. Open source programs are typically free to download and use. They aren’t exclusively developed by one person or corporation and they rely on an open community of peers to maintain and improve the core code. This means that the software can be rapidly developed with a large pool of contributors. Another benefit of open source is the adaptability of custom code, since everything is open we can extend the core code to do more and behave based on the business needs of the project.

Other Popular Content Management Systems

There are many open source software CMS tools available on the internet. Drupal is often mentioned in the company of other popular CMS such as WordPress. It even gets lumped together with SaaS (Software as a Service) based site builders like Squarespace and Wix. While it's true that Drupal serves a similar role as a means to building websites, it is far different from these other systems. WordPress for example, is primarily a blogging platform but people have stretched it far beyond its intended use. Because of this, complex sites built with WordPress often consist of a lot of custom code of varying quality. Drupal’s real contemporaries are more along the lines of a framework like Laravel. These frameworks are much more customizable and robust, but often lack the pre-built setup of users, content types, and management features. This results in a much longer time to market for projects built on a bare framework.

What are the use cases for Drupal?

Drupal is best suited for building websites that are medium to large in size with a focus on future scalability. That isn’t to say that Drupal can’t be used for smaller sites, it does fine for this sort of thing all of the time, but it is built to handle much more and can incur more overhead than is necessary. It is a bit subjective to use terms like medium and large for a website, but when we think of large we typically mean websites used for enterprise applications.

Drupal is great at storing, managing and delivering huge amounts of content. If you have a lot to publish, then Drupal can’t be beat. The admin interface allows for creation of custom management tools that make the whole publishing workflow tailored to how your business runs. Drupal is built around being able to have many levels of users with defined roles. Permissions can be fine-tuned to create a system with a publishing workflow that won’t slow down content creators and will save time for editors and curators.

In the world of web apps, Drupal is king. Drupal 8 is a very extensible framework capable of integrating with the vast ecosystem of services offered across the internet. If you need to build a product for others to connect to, Drupal is a great choice with its core RESTful API. The object-oriented framework within Drupal makes creating large-scale applications inexpensive with a reasonable timetable.

Why do organizations choose Drupal?

Large organizations both corporate and non-profit trust Drupal to run their sites and applications. Drupal has earned this trust through its open source community that provides contributed modules and timely core updates. The security team, which is world class, keeps Drupal a bit safer by finding and writing patches vulnerabilities before they can become a problem. Part of the Drupal community is the Drupal association that pushes cutting-edge initiatives to keep Drupal modern, innovative and thoughtful.

The large open source community behind Drupal provides thousands of modules to extend the core functionality of Drupal, all for free. Contributed modules are reviewed by the community and given a stamp of approval if they are stable and safe to use. This is very different than many other open source communities where contributed code can be malicious or come at a cost. When you use Drupal and its contributed modules, you are benefiting from the hundreds of thousands of development hours from a giant group of developers across the globe.

How do I start a Drupal project?

Drupal can be used to run just about anything you would want on the web. Because of this flexibility, Drupal doesn’t do a whole lot on initial install without more configuration and setup. This is not a simple task for the amateur site builder, Drupal is not known as the easiest of the frameworks to learn. If you are building a medium to large site or a web application, you may want to hire professional web developers with the right technical skills. This can be accomplished by an internal team of Drupal developers or outsourced to a Drupal development agency. Check out this article we wrote to help you determine if you should build with an in-house team or outsource. 

Popular examples of Drupal websites

You have most likely seen or used a site built on Drupal and didn’t even realize it. There are a lot of very influential sites out on the web that leverage Drupal to deliver content. Here is a small list of those:

ncaa.com

Harvard.edu

Taboola.com

ed.gov

economist.com

Billboard.com

Drupal is very popular in higher education with many universities and colleges running their sites on Drupal 7 & 8. Drupal also has a large share in local government sites and in the publishing industry. Drupal is everywhere you look but its flexible structure allows it to power a variety of types of sites while being invisible and allowing the content it serves to be visible.

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

Aug 15 2018
Aug 15

As marketers, we understand the importance of having a system that promotes ease and efficiency when it comes to implementing marketing processes. You want to create content once and use it over and over in different ways to create contextual user experiences. 

Drupal provides you with a variety of powerful, integrated tools to not only help you understand who your visitors are and what they want to accomplish, but to also dig deeper into their interactions, engagements, and habits with your site. 

Here are just a few reasons why enterprise marketers adopt Drupal. 

1. Enormously scalable - you can’t outgrow Drupal!

Some of the biggest, most visible, and highest-trafficked sites in the world run on Drupal, including, The NBA, Johnson & Johnson, and The Weather Channel. Drupal has proven itself on enterprise websites with over 1M pages and over 20,000 requests per second. In short, you can’t “outgrow” Drupal but can continually add new content and features to your enterprise website.

2. Easily execute your content marketing strategy

A big part of a marketing strategy is content creation, so it is important that marketers are easily able to add new pieces to their website. Drupal allows marketers to quickly add blog posts, videos, and landing pages to their website by filling out a “form” with all of the relevant information and then publishing it. For example, if I want to add a post to the Mediacurrent blog, I can be in and out in less than 7 clicks. In-page editing with Drupal 8 makes the publishing process even faster.  

3. Integrate with Marketing Automation 

Every major marketing automation platform has a custom module created for easy integration into a Drupal website. How do I know? Mediacurrent developed most of them - including the Hubspot, Pardot & Silverpop module!

4. Establish an efficient workflow

A planned workflow is the underpinning of every efficient business process. Whether a business is processing leads, updating a web page, evaluating a capital purchase, or approving new hires, certain actions must take place in order for the function to be completed. Workflow involves the passing of content between people in a chain that abide by a predefined set of rules.  Drupal allows you to easily create a workflow that is customized to your company's processes and team.

5. Create dynamic digital experiences….easily

Drupal fully integrates content, community, and commerce in a single platform. If you’re staying competitive, you’ve likely made a significant investment in creating a dynamic website that really tells the story of your brand and what you have to offer. With Drupal as the backbone for your digital strategy, the options for creating personalized web experiences are endless. Drupal’s architecture makes it the ideal platform for creating and delivering segmented content. 

6. Don’t waste your marketing budget on licensing fees

As open source software, the Drupal package has no license fees, it’s free for you to download, modify, etc. Which means your marketing budget goes towards the things that make your site unique, not towards fees for a large software company.

7. Bridge the gap between IT And marketing

When building a Drupal site, the amount of coding required to maintain or build the site is up to you. A full-featured site can be built fulfilling many business requirements with point and click ease. For us “non-coding” marketers, Drupal allows us to go into each page and easily edit the content while still maintaining the consistency of our branding—without the need to know HTML or CSS.   

8. Benefit from the thriving development community

When a business chooses Drupal, a vast community of support becomes available. Whether it be Drupal’s extensive project issue queues, thousands of nationwide meet-ups and Drupalcamps, or IRC channels, the chances are the problem encountered has been faced before, documented, and has a community willing to help you solve it.

9. You’ll have search engine optimization nirvana 

Drupal gives you control over everything you need to optimize your website for search engines. That includes custom page titles, meta descriptions, URLs, copy, and it plays well with Google Analytics.

10. Security - it’s good enough for over 1 MILLION websites

When deciding on a software solution for your company's digital needs, security is often one of the top concerns. Open source software, like Drupal, has the added bonus of having thousands of talented individuals work on a particular problem. With entire teams and methodology devoted to ensuring its steadfast reputation as a secure CMS. Drupal also have an official “SWAT team” that is well-versed in online software best practices and serves as a resource for all custom module maintainers and code contributors to utilize when submitting custom projects. What passes today as secure code may not stay the same tomorrow when new vulnerabilities surface. There's peace of mind in knowing not only is your online software secure, but that it's also in an active state of safeguarding against security attacks, both past and present.

Because Drupal is not tied to a proprietary vendor’s roadmap, it’s advancing based on the work of thousands of developers around the world. Drupal organically evolves at the speed of the web, offers the cost savings and agility of the open source model, and gives you the ability to integrate content across a range of channels and campaigns.  

In the next blog of the series - we’ll hear from the Chief Marketing Officer at Acquia, about how she is leveraging Drupal 8 to achieve her business goals. 

Aug 15 2018
Aug 15

Digital Assets Management in multi-channel publishing environments

Drupal Europe offers up a plethora of cases and solutions to help you with your DAM integration.

Multichannel publishing by Oleksiy Mark on Shutterstock

With so much to organize and store, publishers typically use Digital Asset Management Systems (DAM) to manage their assets. Add multiple channels to the mix and you have big operational hurdles. Thanks to the Media Initiative, Drupal now has a well-defined ecosystem for media management and its architecture is designed to play well with all kinds of media, media management systems, and web services that support them. The system is highly adaptable — the media management documentation outlines 15 modules shaping Drupal’s new ecosystem for media assets.

The Drupal Europe program offers several sessions to help you learn more about solutions building on this foundation. Case studies of demanding media management projects around the publishing industry include:

Blockchain — why should publishers care?

How Publiq is using blockchain to tackle urgent challenges for publishers

What industries come to mind when you hear blockchain? Banking? Trading? Healthcare? How about publishing? At Drupal Europe publishers will gain insights into the potential blockchain technology offers and learn how they can benefit. Meet Gagik Yeghiazarian, founder of the nonprofit foundation Publiq, and learn how he wants to fight fake news and build a censorship-resistant platform — using blockchain.

The publishing world is changing. Publishers no longer solely control media distribution. Big players like Facebook and Google are middlemen between the publishers and their readers, and technology built to entice publishers — Google’s AMP (Accelerated Mobile Pages) and Facebook Instant Articles — has strengthened social platforms as distribution channels. Additionally, publishers have lost money making classifieds business as employment and real estate markets create their own platforms and portals to reach the audience.

Photo by Ian Schneider on Unsplash

As a result of these developments, publishers are losing direct relationships with their readers as well as critical advertising which traditionally supported the editorial and operational costs. The platforms act as middlemen, using the content of the publishers for collecting data and selling them to advertisers. The publishers are left out in the cold.

Critically, publishers are also facing a crisis of confidence. As social platforms are used to spread fake news and poor content, mistrust in journalism grows.

The nonprofit foundation Publiq wants to face these challenges with a blockchain-powered infrastructure. It aims at removing unnecessary intermediaries from the equation and helping to create an independent, censorship-free environment. Gagik Yeghiazarian, CEO and Co-Founder of Publiq, is convinced: “Blockchain infrastructure allows content creators, readers and other participants to build a trusted relationship.”

You can learn more about Publiq and its blockchain infrastructure at Drupal Europe in Darmstadt: Gagik Yeghiazarian’s session “Blockchain Distributed Media — A Future for good publishing” will give you a glimpse into this new technology and a real-world application of it.

While you’re at Drupal Europe, be sure to check out the exciting blockchain panel discussion where Gagik, Ingo Rübe of Botlabs, and Taco Potze of Open Social, will share insights and use cases for blockchain technology. Don’t miss this!

Drupal Europe
Publishing & Media — Track Chairs

Aug 14 2018
Aug 14

Drupal Europe: Publishing + Media Special Focus

What industries come to mind when you hear blockchain? Banking? Trading? Healthcare? How about publishing? At Drupal Europe publishers will gain insights into the potential blockchain technology offers and learn how they can benefit. Meet Gagik Yeghiazarian, founder of the nonprofit foundation Publiq, and learn how he wants to fight fake news and build a censorship-resistant platform — using blockchain.

The publishing world is changing. Publishers no longer solely control media distribution. Big players like Facebook and Google are middlemen between the publishers and their readers, and technology built to entice publishers — Google’s AMP (Accelerated Mobile Pages) and Facebook Instant Articles — has strengthened social platforms as distribution channels. Additionally, publishers have lost money making classifieds business as employment and real estate markets create their own platforms and portals to reach the audience.

Photo by Ian Schneider on Unsplash

As a result of these developments, publishers are losing direct relationships with their readers as well as critical advertising which traditionally supported the editorial and operational costs. The platforms act as middlemen, using the content of the publishers for collecting data and selling them to advertisers. The publishers are left out in the cold.

Critically, publishers are also facing a crisis of confidence. As social platforms are used to spread fake news and poor content, mistrust in journalism grows.

The nonprofit foundation Publiq wants to face these challenges with a blockchain-powered infrastructure. It aims at removing unnecessary intermediaries from the equation and helping to create an independent, censorship-free environment. Gagik Yeghiazarian, CEO and Co-Founder of Publiq, is convinced: “Blockchain infrastructure allows content creators, readers and other participants to build a trusted relationship.”

You can learn more about Publiq and its blockchain infrastructure at Drupal Europe in Darmstadt: Gagik Yeghiazarian’s session “Blockchain Distributed Media — A Future for good publishing” will give you a glimpse into this new technology and a real-world application of it.

While you’re at Drupal Europe, be sure to check out the exciting blockchain panel discussion where Gagik, Ingo Rübe of Botlabs, and Taco Potze of Open Social, will share insights and use cases for blockchain technology. Don’t miss this!

Drupal Europe
Publishing & Media — Track Chairs

Aug 13 2018
Aug 13

Just imagine: putting together the powerful UI creation tools of a static site generator — more of a modern front-end framework rather —  built for high speed, like Gatsby.js, with Drupal 8's content modeling and access system! Putting their powers together into a blazing-fast website! But how to get Gatsby to work with Drupal?

How do you build a plugin that fetches data from API-first Drupal? In short: a static, conveniently simple, yet robust Gatsby site powered by a powerful, decoupled Drupal back-end?

You've got the questions, we've got the answers...

And we've grouped all our answers to your questions regarding “API-first and decoupled Drupal in connection with Gatsby” in a straightforward 4-step tutorial. One on building a high-speed Gatsby website backed by a versatile headless Drupal CMS.

Shall we dig in?
 

1. But What Is Gatsby.js More Precisely?

The standard, rather rigid definition would be:

“It is a GraphQL-fueled, React-based static site generator.”

Now if the words “static site generator” just make you... cringe, here's a more nuanced definition for you:

“Gatsby's more of a modern front-end framework —  one pulling together the best parts of GraphQL, React, webpack, react-router — built with the developer experience in mind.”

In short: it's a static site that this “more than just a static site generator” helps you build, leveraging its out-of-the-box front-end tools. A website geared to reach fast page loads while pulling data from a decoupled Drupal CMS.

And there are the 2 basic steps for getting started with Gatsby; you simply write your site's code structure and let Gatsby handle the rest:
 

  1. turn it into a directory with a single HTML file
  2. … along with all your static assets


2. 3 Reasons Why You'd Want to Use Gatsby

… instead of Jekyll, your webpack config or create-react-app.
 

a. Because of the richness of the Gatsby ecosystem

With rich documentation at hand and backed by an already large community of starters, you'll get your Gatsby site up and running in no time.
 

b. Because it leverages GraphQL' power to build its data layer.

And this is one of those heavy-weighting reasons for using Gatsby over other competing alternatives:

Gatbsy's built to fetch data from... pretty much anywhere — your CMS of choice, Markdown, third-party APIs, Markdown — using “source” plugins. When creating its data layer, it relies on GraphQL, which builds an internal server of all this pulled data.

In short: when questioning yourself “how to get Gatsby to work with Drupal”, do keep in mind that in your future Gatsby & decoupled Drupal setup data gets queried from the same place, in the same way, via GraphQL.
 

c. Because it's built for high speed.

And this is one of Gatsby's hardest-to-resist-to advantage:

It's just... fast.

And that gets reflected in your final Gatsby & decoupled Drupal site while bubbling up to the user experience, as well.

Summing up, these are the 3 strongest reasons why you would be tempted to use Gatsby with Drupal CMS. 

I'm not going to engage in dynamic sites vs static sites debate now. The internet's overcrowded with such comparisons.

I'll just end this “pledge” on using Gatsby with just a non-debatable statement:

Since a static site generator pre-generates the pages of your website, the performance vs maintenance costs scales gets unbalanced. And guess which one's going up and which one down!
 

3. And Why Would Pair Gatsby with Drupal?

If there are strong reasons why you should be getting started with Gatsby, why is there any need to consider decoupled Drupal CMS for its back-end?

Because static site generators don't “care” much for the authoring experience. Content editors have to get themselves tangled up in Makdown for creating content.

True story!

And this is where powerful CMSs, such as Drupal, step in, “luring” you with their:

  • WYSIWYG editors
  • content types 
  • content modeling capabilities
  • access workflow capabilities

… to make your content team's lives easier!

And now your “How to get Gatsby to work with Drupal” dilemma turns into a new legitimate one:

How to make your Gatsby website cope with a decoupled Drupal setup without adding the “dread” of a database and web server to the equation?


2 elements that “pave the path” for performance and security issues.

Well, this is precisely what this “decoupling Drupal with Gatsby scenario means to avoid:

  • you'll get to host your Drupal CMS in-house
  • … and thus take full advantage of the robustness and versatility of a decoupled Drupal CMS back-end
  • your Gatsby website will fetch data from its Drupal back-end and generate content “the static way” (which translates into “incredibility fast page loads”)
     

4. How to Get Gatsby to Work with Drupal More Precisely

Or simply put: how to pull data/content from Drupal into your Gatsby website?

Here's a straightforward tutorial in 4 steps on how to integrate Drupal with Gatsby:
 

4.1. First, Build Your Drupal Server 

Assuming that you have a Drupal 8 website installed, the very first step to take is to:
 

a. Create a new content type 

For this exercise, it's a blog — including all its blog posts — that we'll try to transfer from Drupal to Gatsby. So, we'll name our content type: “Blog”.

It will include 3 basic fields:

  • title
  • body
  • image

For this, just navigate to Home>Administration>Structure>Content Types.
 

b. Turn Drupal into an API Server 

For this, there are 2 key modules that you'll need to install:
 

  1. jsonapi_extras: for gaining more control over the API (to disable resources, to change the default endpoint, to enhance field output etc.)
  2.  jsonapi, which will turn your Drupal website into an API server (one having a default endpoint)
     

c. Grant Anonymous User Permission to Access the JSON API resource list

If you overlook this step, you'll end up with an “Error 406” message, which will just sabotage your whole “decoupling Drupal with Gatsby” mission.
 

d. Check How Your Drupal API Server Works 

You can do this by navigating to http://[your-site]/jsonapi logged in as an Anonymous user.

If the page that you'll get displays all the information regarding your API server, then you'll know you're on the right track.
 

4.2. Then, Create a New Gatsby Site

But before you jump to building your new static website, check whether you have npm and node installed on your PC. 

How? By entering “npm  -v” and “node  -v” into your terminal.

Next, you'll need to install Gatsby's CLI:
 

npm install --global gatsby-cli 

Then, just build and get your Gatsby site up and running.

Note: by default, it will be accessible at localhost:8000.

How to Get Gatsby to Work with Drupal: building a new Gatsby site

4.3. Decouple Drupal with Gatsby: Pulling Data from the API Server
 

a. Set up the (/blog) page

Solving your “How to get Gatsby to work with Drupal”  type of dilemma starts with... the creation of a new page on your Gatsby website.

And is as simple as... setting up a new JS file.

Note: all your Gatsby pages will get stored under /src/pages.

Now here are the basic steps to take:
 

  1. create the blog.js in /src/pages
  2. then add this code: import React from "react" const BlogPage = () => ( <div> <h1>Latest from our bog</h1> </div> ) export default BlogPage 
     

Voila! You've just created a new page at /blog.
 

b. Pull Content from the Drupal 8 site using GraphQL

The “gatsby-source-drupal” plugin, to be more specific.

It's this source plugin that will be “in charge” with all the data (images here included) pulling from decoupled Drupal back-end to your Gatsby site.

Note: do keep in mind that in this case, the JSONAPI module plays a crucial role.

And here's how you install your “power” plugin:
 

// in your blog.gatsby folder npm install --save gatsby-source-drupal 

Next, just configure your newly installed plugin:
 

// In gatsby-config.js plugins: [ ... { resolve: 'gatsby-source-drupal', options: { baseUrl: 'https://goo.gl/Cc5Jd3 apiBase: 'jsonapi', // endpoint of Drupal server }, } ], 


Tada! Now your site should be functioning properly.

If... not quite, here are the causes of the 2 most common error messages that you could get:
 

  • “405 error”, check whether the jsonapi_extras module is enabled
  • “ 406 error”, have a closer look at the permission on your Drupal site
     

c. Configure GraphQL to Pull Specific Pieces of Content from Drupal

In other words: to query all the “blog” nodes from Drupal and request specific data from the API server.

Another strong reason for using Drupal CMS with Gatsby is that the latter provides an in-browser tool for testing GraphQL queries names, for writing and validating them. You can access it at localhost:[port]/___graphql, whereas in our particular case here at: localhost:8000/___graphql.

Now, as you're solving this “How to get Gatsby to work with Drupal” type of puzzle, just try to query all the blog nodes.

Next, navigate back to your blog.js file and run this query:
 

export const query = graphql` query allNodeBlog { allNodeBlog { edges { node { id title body { value format processed summary } } } } } ` 


Then, update your const BlogPage so that it should display the body, content and title:

const BlogPage = ({data}) => ( <div> <h1>Latest from our blog</h1> { data.allNodeBlog.edges.map(({ node }) => ( <div> <h3>{ node.title }</h3> <div dangerouslySetInnerHTML={{ __html: node.body.value }} /> </div> ))} </div> ) 


Next, save your file and... “jump for joy” at the sight of the result:

All your blog posts, nicely displayed, pulled from Drupal and published on your Gatsby site!
 

4.3. Finally, Just Go Ahead and Publish Your New Gatsby Site

And here you are now, ready to carry out the last task of your “How to get Gatsby to work with Drupal” kind of “mission”. 

This final task is no more than a command that will get your Gatsby website running:

gatsby build 

Next, just run through your /public folder to see the “fruits of your work”.

At this point, all there's left for you to do is to copy/push content in /public to server and... deploy your new website using Gatsby with Drupal CMS.

The END! This is how you do it: how you use Gatsby.js in a decoupled Drupal setup so you can benefit both from:

  1. a modern static site generator's robustness and high performance, built with developer experience in mind 
  2. a powerful CMS's content managing capabilities, built with the editorial experience in mind 
Aug 08 2018
Aug 08

Alan Onnen is the Associate Director of Marketing for the Shirley Ryan AbilityLab. Recognized as #1 in rehabilitation for 27 years in a row. AbilityLab introduces its revolutionary care through 5 Innovation Centers - state-of-the-art hospital facilities and equipment for exceptional patient care provided by the best medical and nursing support.

With 15 years of experience in the marketing industry, the past 5 being with SRA and being a part of the team that helped adopt Drupal, Onnen has seen firsthand how Drupal 8 powers digital strategy. 

Mediacurrent Interview with Alan Onnen 

Mediacurrent: What does “digital transformation” mean for you? 

Alan Onnen: Digital transformation means a constant evolution. There’s no single transformation; it’s a constant state of change, staying on top of trends at once. As a digital marketer, you need to know a little bit about everything, UI, UX, nerdy stuff, best practices, changes in the digital environment, what people expect from websites in your vertical, etc. Some people think transformation is a binary term - something new - but it's not.

Mediacurrent: How does open source fit into the equation?

AO: Open source is something that’s not new but it’s getting so mainstream its part of that digital transformation. It’s about adjusting to the new worlds where open source doesn't mean unsecure - it means that it’s open and honest. We had to get buy-in from stakeholders. They dismissed it at the beginning of the RFP bc they thought you needed a Sitecore or an AEM. It took a long time and a lot of agency people to show how safe it is to help make them believe that open source isn’t a dirty word.

Mediacurrent: What current challenges are you trying to solve for?

AO: It is a constant struggle to keep up with Google - making sure our content is optimized for search algorithms. Our overall challenge is to keep our content fresh, navigating innovative best practices for our website while keeping up with legal and social constructs.

Mediacurrent: How are you using Drupal 8 to solve those problems? 

AO: One of the big reasons we chose Drupal was because of its customization ability. Our knowledge base is spread across so many people so Drupal’s ability to customize the backend experience and offer the fields and plain English way we need to talk about things is really important. Even just the simple need for content creators to be able to edit things and be able to customize that experience.

Another big reason was the fact that its open source and the community surrounding Drupal. If you have an idea you can find someone who has half baked or full-baked into that particular module or idea to help give your devs a headstart solution. With Drupal, you don’t have to start from scratch when you need something new to move the website forward. Chances are, someone has had a similar idea you can pull from.

Mediacurrent: Has this been your first experience with Drupal or have you worked with previous versions of Drupal in the past? What did Drupal 8 give you from a marketers/content editors perspective?

AO: I came to SRA on a proprietary healthcare based CMS. It was designed to serve mid to small hospital systems and we didn’t have access to the backend part of the site before. SRA put out an RFP for a replatforming and redesign of our website . We talked to different agencies, and Drupal kept coming up - there were no licensing fees with open source. The spin up on Drupal is more robust than most paid CMS experiences. The cost point of view is having it be free and open was very appetizing and Drupal had other features that appealed to us. 

Mediacurrent: Since launching on Drupal 8 have you noticed an increase in website conversions?  What would you attribute to that success (or lack of success)? By use of marketing automation strategies? Bc of easy integration?

AO: Drupal can be leveraged any which way you want it to be. We take advantage of the extensive list of modules. We have seen nice conversions off the YAML module & the webform module. It’s true of the module philosophy to be able to build how you want them too. 

With Drupal, our web traffic has been up. We have 3 very different facets of our site - rehab measures database, research educational platform, home site - and Drupal can support them all very well. It’s a testament to Drupal - with a flexible CMS, reporting, user interfaces, and a back end that can be robust enough to bring things together in an organic and seamless way. 

Mediacurrent: What are 3 factors you look at when evaluating an agency? Cost? Reputation? Their own web design? Logos they've sold? 

AO: With our RFP out, we began evaluating the superficial - books, examples, case studies, white papers, if their leadership had given talks and what they had talked about, the look and feel for brand consciousness, - exploring that space of ability. We didn’t want someone who was making cookie cutter websites and we didn’t want to stay looking just in the healthcare vertical. Our list was narrowed down to those whose work we respected and admired. 

In the RFP, the CMS wasn’t a consideration. We didn’t tell people which platform you needed to be on. We asked for the cost, their preferred CMS and why, and we never cared about where the agency was located. It’s important to know the the people are the agency - communication is critical. For instance, in their responses to those RFP’s are there timelines? Are they realistic? Do they make sense? It’s easy to see how much effort they did.

No one else did research like you guys [Mediacurrent] did before they got there for a face to face meeting. Your team said “oh, well we’ve already talked to discharge managers, nurses, planners.” They went through example personas, guessing on journeys, patients - and they were smart with how they handled it and took the initiative that early in the process. That showed us a lot about them. It wasn’t a giant new business budget and they didn’t ask for money up front. 

In all, the RFP process was about 4 months.

Mediacurrent: As a marketer using Drupal, what are some of the hot topics you'd like to know more about today? Personalization, marketing automation, etc.

AO: I’d like to know more about:

  • Integrations with personalization
  • Integrating with Google Analytics, tracking to AEM, adwords, & api that moves page data to backend sites
  • Marketing Automation capabilities

Mediacurrent: What advice would you give other CMO’s/VP’s/Director’s who are hesitant to move to Drupal 8?

AO: I would say it depends on what their hesitation is. You have to be committed to the build of your site. You need to be able to really understand your content creators, the users of your CMS, the scope of what they want to be doing, and understand what they could be doing on the front end. It’s important to know the ingredients - you can muck up Drupal and waste dev hours if you don’t know how the workflows to go and to know your taxonomy and pathing modules. 

Drupal requires a Digital Marketer to have a vision for what they want it to be before they start developing - or else they risk having to go back and retrofit into their CMS environment that they could have efficiently put in the first time.

The journey of CMS and Drupal needs to be a thoughtful one.

______________________________________________________

We want to extend a big THANK YOU to Alan for participating in this interview. In the next part of the blog series, we will dig into the top reasons for Drupal 8 and why enterprise marketers choose Drupal.

Aug 08 2018
Aug 08

Security maintenance — and the ability to apply security updates quickly — is part and parcel to open source project success. 

Updating is typically done as part of the normal software release cycle, however, there are times when a security advisory needs to be released ASAP. A strong incident response plan builds a first defense line to mitigate and patch vulnerabilities. 

But what does a successful security response look like in action?

On the heels of a recent Drupal security update on August 1, 2018, Mediacurrent’s Senior Project Manager Christine Flynn had the same question. To find out, she interviewed our Open Source Security Lead, Mark “shrop” Shropshire, to get a layperson’s perspective on the security team’s approach.

Christine and Shrop on a call

 

“An off-cycle Drupal security advisory dropped on August 1, 2018. What does that mean for folks who aren’t developers?”

Flynn: I was watching the Slack channel as our team fixed sites, and I got some idea of what was happening. I’m not going to jiggle anybody’s elbows while they’re applying a security update, but I’m really curious now that the fixes are all in. 

Shrop: The official Drupal Security Advisory came out late in the day, after Symphony published their announcement in the morning. There was also one from Zend.

Flynn: I read all of those links while the team was applying the security update, but I feel like I didn’t totally understand the implications. I’d love to get a better picture from you of what they mean.

Shrop: You bet! I hope you can hear me, I’m at a coffee shop right now.

Flynn: Are you on their unsecured WiFi?

Shrop: Nope! I’m on a hotspot and on VPN. It’s funny, the more you know about security, the more it changes what you do. Other people think you’re paranoid. But you’re not! You just understand the realities. 

Flynn: Ha! Why am I not surprised? All right, let’s dig in.

“What was the security update for?”

Shrop: Drupal Core was updated because there were some security releases for Symfony. We call those “upstream” in the biz, which means that Drupal depends on them, and they are actively worked on outside of Drupal. I understand the Symfony project worked closely with the Drupal Security Team to make sure Symfony and Drupal were both updated and ready to be announced publicly at the same time. Drupal version 8.5.6 pulls in the Symfony updates as part of the Drupal update process. 

Flynn: Was that the only update?

Shrop: No, at the same time, there was also an update to Zend Framework, but that was only an issue for users who were making use of modules or sites that used Zend Feed or Daictoros. There is a core issue to update the related Zend libraries for those who require or need the updates. 

“If not updated, what could a malicious user do to a site?”

Shrop: This is a hard one to answer this soon after the release of the security advisory. I’m going to do some checking to see if I can get more information on this for academic purposes, but the Drupal Security Team is not going to make any statements that could help someone attack a site. It is up to security teams and researchers to dig into the code and determine more about the risks involved.

Based on the Symfony project’s blog post, it appears that a specially crafted request could allow a user access to a URL they do not have access to, bypassing access control provided by web servers and caching mechanisms. That’s a fancy-pants way of saying that a website visitor could gain access to pages you don’t want them to see.

“When will we know more?”

Shrop: Within days - sometimes hours - we might start to see exploit methods posted on the Internet. Taking security seriously and responding quickly once a drupal.org security advisory is announced is a way to stay ahead of these concerns.

Mediacurrent doesn’t want to fearmonger, but it is better to be safe than sorry. That’s why I always push to update as soon as possible while weighing in on mitigating factors that may lessen the severity of the issue for a particular application. But I will keep digging. I’m curious! 

“If you had to tell a CEO or CFO the value that implementing this security update swiftly provided, what would you say? Let’s say this CEO does not have a strong background in technology or security.”

Flynn: I could see an executive with a strong public safety or physical security background being pretty understanding of why you want to apply a security update for a potential vulnerability quickly, but what if it’s someone who doesn’t have that experience, and isn’t a technologist?

Shrop: Check out this link from Acquia about the security update. This helped me so much. They published this shortly after the PSA came out, and although they’ve updated the text since then, they said at the time, “It is advised that customers set aside time for a core upgrade immediately following.” When I read, “immediately,” I knew that we had to get the update out within hours. If I was asked to get on a call with the executives from any company, at that point, I am confident. If Acquia is saying it, we need to do it. That’s enough to stand on with anybody. I’m not saying that the Acquia team has more information, but they have a very robust security team. They always dig in quickly. They have to, to know if they can mitigate the issue by adding web application firewall rules.

Flynn: Firewall rules? How does that work? 

Shrop: The last few core updates, Pantheon and Acquia put mitigations into their WAF - that’s Web Application Firewall. Pantheon confirmed the night of the security advisory release that they were blocking attempts on their platform, and Acquia did the same thing. So if someone tried to exploit a site that was hosted there before Drupal was updated, they were there, helping to prevent that site from being attacked successfully. It’s a great extra layer of protection. Now, me and Acquia and Pantheon will always still want to update Core on each site, because WAF-level mitigation might not catch everything. But I am super happy when I see it because there’s a good chance that it will catch anything that happens while a team is still implementing a security update.

Security is all risk assessment and mitigation. You want to layer defenses. And something like this, we are going to make sure we deal with this problem. That’s why Acquia, Pantheon, Platform.sh, and others in the community immediately add those extra mitigations to their firewalls. It’s to buy time so that people can get their updates in. That’s not where mitigation ends, but it helps. 

“What type of sites were affected by this? Does everyone use Symfony?”

Flynn: When I first read about the upcoming security advisory, I saw that it affected “third party libraries.” That made me think that some of our clients might not be affected because it would only affect certain modules. Can you tell me what types of sites were affected?

Shrop: Got a link for you, but basically, anything on Drupal 8 was affected. Drupal 8 uses components from the Symfony project. The Drupal community made the decision to use Symfony so that we didn’t have to maintain everything ourselves. So this is a great example of the power of open source, with the Symfony and Drupal security teams working together to release this fix. We all end up benefiting from having a larger community to fix issues. There’s no way an internal team working by themselves can write as secure applications on their own compared to open source software, in my opinion. It has nothing to do with how good you are, it’s the nature of development. With open source, you have a greater team with Drupal and then again, with Symfony, an even greater team to lean on. With each community that is included you are expanding your team and your ability to detect and prevent threats. 

“How was the security vulnerability discovered?”

Shrop: That’s generally never disclosed because you never want to tell malicious users how you found an opening. 

But we do have a few people to thank: Michael Cullum and @chaosversum were thanked by Symfony for separately reporting the two issues addressed in Symfony security releases. They also thanked Nicolas Grekas for implementing the fix. I would also give a huge thanks to Symfony and the Drupal Security Team for coming together to implement the fix and for coordinating the announcements. It’s hard work, and it shows the community at its best.

“So when we have an off-cycle security release, first the PSA comes out. Can you tell me a bit about what Mediacurrent does from the time the PSA comes out to just before the security advisory drops?”

Flynn: As someone on the team at Mediacurrent, I can see some of the things you do. But I’m wondering what else happens behind the scenes? 

Shrop: The first thing that happens is that I’m notified about the PSA coming out. I’m signed up for updates via email, Twitter, and RSS feeds from https://www.drupal.org/security, and so are a lot of other folks at Mediacurrent. Internally, we have some processes that we have standardized over time for how to deal with security updates that we follow across the company. We centralize information we have on the security PSA/advisory, recommend client communications, and talk about how to prepare as a team. We have multiple communication threads internally, as well, so no one can miss it. I send an email to the staff and I post in our Slack in a few places to get us ready.

Flynn: I know that we often clear time in advance for the team to implement the security updates.

Shrop: Yep. All of us share more information as a team as official information is released or as our own investigations reveal information. For example, early on the day the security advisory was released, our DevOps Lead, Joe Stewart, noticed that Symfony had put out a notice that they were also going to be releasing a security update that day, so that gave us a heads up that it might be related. We couldn’t know for sure until the security advisory actually came out, though. No one can do it by themselves, which is why we have a whole team working on it - it’s the only way to handle these things. ​​​​​​

Christine and Shrop on another call

“So then the security advisory drops. How did we go about fixing the issue?” 

Shrop: First, we reviewed the advisory to assess risk and for any mitigations that help determine how quickly we need to perform updates. With this advisory, it was needed pretty much immediately, so we started to update Drupal core for our clients and pushed to test environments. Our QA team performed regression testing related to the update. Once QA approved each update for each client, we worked with folks to approve the updates and release them to the live environments. 

The important points are to line everyone and everything up in advance, have the talent in-house who can work on clients of all shapes and sizes and needs, and then to work as a team to resolve the issue on every client site as quickly as possible. 

“Were there any sites that were trickier to update? Why?”

Shrop: Clients that were on older versions of Drupal Core, who had delayed upgrading, were harder to update. Every site was updated within a short time, regardless, but even though they started at the same time, those clients did not finish first, because there was more development and testing needed on each site.

Flynn: What was different about the process to update those sites? 

Shrop: If a client wasn’t on version 8.5.x, the lead technologist on the project had to work on an alternative update to secure the site or application, since there wasn’t a security update released for it. Figuring out an alternative process on the fly always introduces risk. It’s part of the value that we bring, that we have team members that have the expertise to evaluate that sort of thing. For example, we had one new client that was on an older version of Drupal 8 core. So one of our Senior Drupal Developers, Ryan Gibson, had to go in and determine what to do. He ended up updating Symfony itself to mitigate the risk. 

Flynn: I’m guessing that we are going to recommend to that client that we update Drupal core for them very soon?

Shrop: Yes. The big takeaway is you’re lowering your risk of problems by staying on the most recent, up-to-date minor version of Drupal 8. Version 8.5.x is current and stable right now, so you should be on that.

Flynn: Why would a client not update?

Shrop: There are always dynamics. I hear lots of good excuses, and I’m not exaggerating, they are good, real reasons! The client is busy, the client has multiple workstreams, it’s hard - but it is getting to a point where I want to recommend even more strongly to clients that it is more expensive to not upgrade. It is going to cost them more when there is an update because we have these additional evaluation and update tasks. The whole point of Drupal 8’s release cycle is to spread the maintenance cost over years rather than getting hit all at once. 

Flynn: And it introduces greater risk. A security breach is an order of magnitude more expensive than extra mitigation steps.

Shrop: Definitely.

“When is the next version of Drupal Core coming out?”

Shrop: Version 8.6.0 will be released in September. Our teams are already starting to test the early versions of this release on some of our projects. If a security update comes out in September, we want all of our clients to be prepared by being on the currently supported version of Drupal core. That way, they will receive security updates.

Flynn: One of the nice things about the Drupal development community is that they provide the betas of the next version of Drupal core so you can get ahead of the next release, right?

Shrop: Yes. When the community starts releasing betas or release candidates, especially release candidates, you want to start testing ahead of time. If you have a Drupal site, you can get your developers to test. If you find a problem, it may not be with your site, it might be an issue with Drupal core and this is a great opportunity to contribute your findings back to drupal.org and help the greater community. There might be a security release weeks after a version comes out and you want to be prepared to implement it.

Flynn: It goes back to risk mitigation.

Shrop: If you are on, say, an 8.2 site right now, you’re on the higher risk side, unfortunately. We advise our clients that it is in their best interest to be on the current, stable version. It costs our clients more in the long run if they don’t update on a steady basis.

Flynn: So if you’re on an older version of Drupal Core, you might not get an easy-to-implement security update when a vulnerability is discovered?

Shrop: The quotes from the Drupal Security team I really want to emphasize are, “Previous minor releases will become unsupported when a new minor release is published,” and, “Any additional security updates for officially unsupported branches are at the sole discretion of the security team.” This is important to understand. For the SA Core 2018-002 fix earlier this year they provided release updates for older versions of Drupal… but they didn’t have to. In the case of the fix last week, they did not.

“What was the best gif exchange of the Drupal core security update process?”

Flynn: I nominate this one, from mid-afternoon:

Slack Gif Example

Shrop: Definitely! 

“What story didn’t we tell yet?”

Shrop: I think we covered most of it. The last thing I’d put out there is for the technical folks reading this. You need to read the security advisories, join Drupal Slack, read what Acquia, Pantheon, and others are saying about each announcement. Then, you take all of that in and make your assessment of what actions you are going to recommend your organization take. This should lead your organization to a documented security plan that you follow. But, you know… 

Flynn: “Update all the things”?

Shrop: Exactly!

Other Resources
7 Ways to Evaluate the Security and Stability of Drupal Contrib Modules | Mediacurrent Pantheon Guest Blog 
Security by Design: An Introduction to Drupal Security | Mediacurrent Webinar

Aug 03 2018
Aug 03

We all have heard the debate about Open Source Software and Closed or Proprietary; but what is the real difference?

Simply: 

Open source software is available for the general public to use and modify from its original design free of charge. 

versus

Closed source where the source code is not shared with the public for anyone to look at or change. 

One of the main advantages of open source software is the cost; however, when applied to OSS, the term "free" has less to do with overall cost and more to do with freedom from restrictions. 

90% 
According to Forrester Research 90% the code in a typical application is Open Source.  

For a Closed Source CMS, depending on the choice of software, the cost can vary between a few thousand to a few hundred thousand dollars, which includes a base fee for software, integration and services, and annual licensing/support fees. 

Open Source Software vs Proprietary Graphic

In a 2017 report by Black Duck Software by Synopsys, nearly 60% of respondents said their organizations’ use of open source increased in the last year citing: 

  • cost savings, easy access, and no vendor lock-in (84%)
  • ability to customize code and fix defects directly (67%)
  • better features and technical capabilities (55%)
  • the rate of open source evolution and innovation (55%).

1M+ 

Websites across every industry vertical —from Georgia.gov to Harvard— trust Drupal as a secure open source CMS platform. 

Open Source Software has a long-term viability and is always on the cutting edge of technology.  Selecting technologies means committing to solutions that will support an active, growing business over the long term, so it requires careful consideration and foresight.  Here are some of the benefits of open-source to consider:

1. Value for cost 
       Worried about your marketing budget when looking at changing your CMS? Open source software has no licensing fees! It’s free, which means room to spend your $ on other initiatives.
2. Added Security
       Open source - means community. The more people (developers) looking at the source code, the more fixes and regular updates will be available. What can sometimes takes weeks or months to resolve with proprietary software takes just hours or days with open source. This will help give your marketing team a piece of mind knowing that if you don’t have time to look at the code of your site - or you don’t know how - then there are developers all over the world continuously checking for bugs & fixes.
3. Customizability
       Have a really customized idea for your site that you’ve never seen elsewhere? Open Source can help. By customizing the code to fit your needs, it provides a competitive advantage for your business.
4. Flexibility
       Open-source technology naturally provides flexibility to solve business problems. Your team and organization can be more innovative, and it gives you the ability to stay on the cutting edge of latest trends & designs.
5. Integrations
       With open source, especially Drupal, you can Integrate the best-of-breed marketing technology. It is architected for easy integration with your tools - Marketing automation, email service providers, CRM, etc… Drupal 8 gives you the foundation for your digital experience ecosystem.
6. Speed
       This isn’t just about site speed, but the ability to get your site up and running - with full marketing capabilities - on time & within budget. Open source allows you to deliver value right away.
7. Scalability 
       Drupal and other open source platforms give you the advantage of being able to scale your digital presence for the future. You're not confined to stick with what you already have. You can continue to evolve and build long-term with open source.

The Benefits of Open Source can go on for pages but it’s important when evaluating your options to think about your business and its goals. Once consistent need we see is having access to a CMS that is easy for you and your team to manage on a day-to-day basis.

In the next blog of the series - we’ll hear from the Associate Director of Digital Marketing at Shirley Ryan Abilitylab, about how he is leveraging open source - particularly Drupal - to achieve his business goals. 

Aug 03 2018
Aug 03

If you haven’t heard of the phrase “Natural Language Processing” by now, you soon will. Natural Language processing is an expanding and innovative use of technology to analyze large amounts of data or content and derive meaning from it, short-cutting a tremendous amount of manual effort needed to do that ourselves. It’s been around in some form for quite a while, but it was often relegated to complex enterprise systems or large corporations with a vested interest in automating the data mining of huge amounts of data to figure out what the patterns were, for example, in consumer purchasing trends or social media behavior. It’s a cool idea (it’s a form of artificial intelligence after all) and fuels a lot of our online experience now whether it’s product recommendations, content recommendations, targeted ads, or interactive listening services like Siri or Alexa. What’s even better is that this sort of thing is becoming more and more accessible to use in our own software solutions as many of these now provide services with APIs. This allows us to provide a more personalized or meaningful experience for site visitors on web projects that likely don’t have the budget or requirements to justify attacking natural language processing itself and can instead find accessible ways to benefit from the technology.

One such use case that we’re talking about today is using the Google Natural Language Processing APIs on our own Drupal sites. We can use it to analyze our own site content and even autotag based on a common taxonomy. We really dig integrations here at Ashday, so we’ve just released two new Drupal modules to help you get hooked up with Google’s service. They are the Google NL API and Google NL Autotag modules.

The Google NL API Module

This module is intended to be your starter module to get things going. It provides functionality to connect to Google's Natural Language API and run analysis on text, including sentiment, entities, syntax, entity sentiment and content classification. It doesn’t decide what to do with this analysis, but it provides a service with a number of methods to analyze your content and then you can decide what to do with the information. All you need to get going is a Google NL API account. Full details of installation and usage can be found here.

Here is a brief outline of what each method provides, provided by Google.

Sentiment Analysis

“Sentiment Analysis inspects the given text and identifies the prevailing emotional opinion within the text, especially to determine a writer's attitude as positive, negative, or neutral. Sentiment analysis is performed through the analyzeSentiment method.” (from Analyzing Sentiment)

Entity Analysis

“Entity Analysis inspects the given text for known entities (proper nouns such as public figures, landmarks, etc.), and returns information about those entities. Entity analysis is performed with the analyzeEntities method.” (from Analyzing Entities)

Syntax Analysis

“While most Natural Language API methods analyze what a given text is about, the analyzeSyntax method inspects the structure of the language itself. Syntactic Analysis breaks up the given text into a series of sentences and tokens (generally, words) and provides linguistic information about those tokens.” (from Analyzing Syntax)

Entity Sentiment Analysis 

“Entity Sentiment Analysis combines both entity analysis and sentiment analysis and attempts to determine the sentiment (positive or negative) expressed about entities within the text. Entity sentiment is represented by numerical score and magnitude values and is determined for each mention of an entity. Those scores are then aggregated into an overall sentiment score and magnitude for an entity.” (from Analyzing Entity Sentiment)

Content Classification 

“Content Classification analyzes a document and returns a list of content categories that apply to the text found in the document. ” (from Classifying Content)

The Google NL Autotag Module

This module is the first step in actually doing something with the natural language analysis results provided by the API module. It provides a Google NL Autotag taxonomy that you can attach to whichever content types you choose and then will automatically create the relevant taxonomy terms and relate content whenever that content is saved. So a few clicks is all you need to have a nice auto-classification system in use on your site. You can even configure which text-based fields on your content should be used for the analysis as well as specify the confidence threshold, which determines at what confidence level you consider a Google classification as valid. So Google may say that the content matches the category /Home & Garden/Bed & Bath/Bathroom, with a confidence of .4 (on a scale of 0 to 1). You can decide what confidence level is good enough to categorize your content since different use cases may justify different approaches. A full list of Google’s content categories can be found here.

That’s all this module essentially does, but it’s meant to be a simple solution for sites to easily start benefiting from Google’s natural language services. You can, of course, extend the service or add your own functionality to use these APIs however you find beneficial because it’s Drupal 8, and Drupal 8 rocks when it comes to flexibility. So install these modules and start tinkering and don’t hesitate to ask if you have any questions or suggestions for future functionality.

Aug 02 2018
Aug 02
Have you seen the latest changes for DrupalCon? They have replaced a day of sessions with an additional workshop/summit day (for an additional expense) and have increased the early-bird basic ticket price from $450 to $800. I went to DrupalCon Nashville and it was a good conference, but it felt more commercial and like a trade show with sponsors everywhere you look. I've also been to DrupalCamp Asheville (didn't get to go this year because of a scheduling conflict) and for me, I believe camps are a better bang for the buck and where I'll be focusing for continuing education.
Aug 02 2018
Aug 02

One of the most popular components on any website I've worked on is the card component.  Depending on the website, the card component is used to group various pieces of content into a container which can be used throughout your website.  Here’s an example of a card component in one of our projects.

In some instances, a card can be a user profile, content teaser/excerpt, latest news or events.  Today we will build a card component which will contain the information for the latest events.  This card can be used in the /events page to list all the latest events taking place.  The card can also be used in other pages and it may need to be displayed slightly different than the original card, this transformation is called "variations" and is usually achieved by passing a modifier CSS class to the original component which we can use to write different styles for the card.  More on this later.

Let's get started

First, let's take a look at what we are building so we have a visual of the code we will be writing.

Component Example 1

As you can see from the images above, our card takes different shapes but the information in it remains the same or similar.  This is a common practice to modify components based on where and how they are being displayed.

Let's build the card

Identify component's fields

Before starting to write any code, let's take a close look at the card images to identify the fields or data elements the card needs.  From the images above we can see the following fields will be needed:

  • Image
  • Title
  • Subtitle
  • Excerpt
  • Label or category
  • Label for comments
  • Label for time posted

Typically, components are built following the Atomic Design approach which basically means breaking things down into small pieces (atoms) and then combining those pieces to build more elaborate components.

In the interest of time, we are going to skip building each piece as its separate component and instead we will build the card as a whole.  I recently wrote a blog post on building flexible headings which demonstrate the approach I usually take when building components.

Architecting the component fields

We know the fields we need but it is helpful to determine what type of fields they are and what they will be called.  The table below gives us a good visual of our fields architecture.

List of Example Component Fields

Writing the code

1. In your components or patterns directory in your project, create a new folder called `card`

2. Inside the Card folder create two new files
          -  card.html
          -  card.css (we're using CSS to keep things simple.  Feel free to use Sass if you'd like).

3. In your card.html we'll start with the basic structure of the card

<article class="card">...</article>

So we've created an article tag as the card's container.  Why <article>  and not <div>?  Well, since the card is intended to contain an event's info, if we place a bunch of cards together it makes sense that each card is an individual event article.

4. Next we are going to create wrappers for the two types of data the card will hold.  The two types of data as we have seen from the table above are: Image/media and text or content.  Let's modify our code so it looks like this:

<article class="card">
 <div class="card__media">...</div>
 <div class="card__content">...</div>
</article>

The reason for splitting the image and the rest of the content is that this allows us to move things around independently of each other to create different variations of the card.  More on this later.

Let's pause to review how content will be laid out

If we look at the card images above, we see that some of the fields are either on the image side and others are grouped together separate from the image.  Although we could potentially place fields in the image or content wrappers, it makes sense to place them in the wrapper where they visually appear.

For example, the date and label fields (Photos), look like they belong in the same group as the image.  The rest of the fields will go in the Content wrapper.

5. Let's start with the image wrapper:

<article class="card">
 <div class="card__media">
   <img src="http://placehold.it/300x300" alt="Card image" />
   <div class="card__date">
     <span class="date--day">27</span>
     <span class="date--month">Mar</span>
   </div>
   <span class="card__category">Photos</span>
 </div>

 <div class="card__content">...</div>
</article>

So let's focus in the fields inside card__media. We see we have our image, which in this case is rendering a placeholder image.  Then we have a wrapper to hold the date fields (day and month).  Again, wrapping these two together makes it easy to manipulate them as a single item rather than two separate fields.  Lastly, we have the category for this content (Photos).  Since all these fields seem to belong together, it makes sense to place them the way we have.  Later on, we will use CSS to place each of the fields in their right position.

6. Now let's place the remaining fields inside the .card__content wrapper.  We will temporarily hide the fields in the .card__media wrapper to focus on the other fields.  Modify your markup to look like this:

<article class="card">
 <div class="card__media">...</div>

 <div class="card__content">
   <header class="card__header">
     <h2 class="card__title">City Lights in New York</h2>
     <div class="card__subtitle">The city that never sleeps</div>
   </header>
   <p class="card__excerpt">New York, the largest city in the U.S., is an architectural marvel with plenty of historic monuments, magnificent buildings and countless dazzling skyscrapers.</p>

   <footer class="card__meta" role="contentinfo">
     <span class="card__post-date">6 min ago</span>
     <span class="card__comments">39 comments</span>
   </footer>
 </div>
</article>

So the first thing we did was add a `<header>` tag to wrap the title and subtitle fields.  The header tag is a great way to indicate the role content plays in our component.  In addition, using semantically correct markup makes this component SEO friendly as well as accessible.  Next we have the teaser content wrapped in a <p> tag and finally, we add another semantic tag which is `footer` to wrap the publish date and comments fields.

Why this markup?

I'd like to bring up a couple of things to your attention regarding how I arrived at the markup above.  First, we are using BEM for naming CSS classes (card__title, card__comments, etc.).  BEM is great for creating associations on your component fields.  By looking at the markup you know where each field belongs.  This makes it easier to identify where you would find the styles or other assets for the component within your project when you have tons and tons of components.  The class card and all the other field classes are unique not only to this component but in the entire project.  This gives us the peace of mind that our styles will not inadvertently affect other areas of the website.

Notice I created two containers within the card (`card__media` and `card__content`). This allows me to split the card content into groups I can manipulate individually and independently of each other.  This will come in handy when we need to create a long or wide card.  In addition, by grouping multiple fields into a single container it is easier to manipulate the fields with CSS as a group rather than individually.

Atomic Design

If you are familiar with Atomic Design, you know the recommended way for building components is to break things down into the smallest pieces possible.  For example, in the card structure above, each of the fields that make up the card can actually be its own individual component.  Then we would combine them all into a whole new component (card).  In the interest of time/work, I am not breaking the card component into atoms. However, if I were building the card for a project I would definitely do that as this allows for components to be reused and save time/work in the long road.

Putting the entire card together

Now that we have built each piece of the card, your **card.thml** file should look like this:

<article class="card">
 <div class="card__media">
   <img src="http://placehold.it/300x300" alt="Card image" />
   <div class="card__date">
     <span class="date--day">27</span>
     <span class="date--month">Mar</span>
   </div>
   <span class="card__category">Photos</span>
 </div>

 <div class="card__content">
   <header class="card__header">
     <h2 class="card__title">City Lights in New York</h2>
     <div class="card__subtitle">The city that never sleeps</div>
   </header>
   <p class="card__excerpt">New York, the largest city in the U.S., is an architectural marvel with plenty of historic monuments, magnificent buildings and countless dazzling skyscrapers.</p>

   <footer class="card__meta" role="contentinfo">
     <span class="card__post-date">6 min ago</span>
     <span class="card__comments">39 comments</span>
   </footer>
 </div>
</article>

Card Styles

Now that we have the markup ready for the card component, we can begin writing our Sass/CSS to style it.  I am not going to go into detail about the styles as I have commented the parts that may need some explanation and should be easy to understand.  The main take away from writing styles for components with unique names is that there is little to no CSS nesting.  This makes overriding styles an easy task if there is ever a need to do so.  In addition, styles written for a component like this, don't run into the risk of leaking into other areas of the website.

That's a lot of CSS but it's all necessary to achieve the look and feel of the card.  It is important to know that your markup file (card.html), needs to reference your styles file (card.css) for things to work.  This may be obvious but if you are following along that's an extra step that needs to be done.
Creating a card variation

If  you would like to see the card displayed wide or horizontally, modify your card wrapper to look like this:

<article class="card card--wide">...</article>
 

Component Example 2

Notice that by passing the CSS class of `card--wide` to the original card component we are able to change the orientation of the card from long to wide giving us an alternative variation to use without having to rebuild the card from scratch.  These variations are pretty powerful and present many advantages.

If you look at the styles, you will notice there is a block of CSS in which the card--wide is changed to move the card's content to the right of the image.  This is a great way to provide alternative views of a component without having to recreate the markup or styles for a component.

In closing

Building components is one of my favorite things to do as a developer and there are many advantages to this style of theming.  It's important to think through how components will be used so you can plan ahead how to best build a component that can be reused.  Rushing through building components without having a full understanding of where and how a component may be used can lead to duplicating code or redoing your work to accommodate new project requirements.

Aug 01 2018
Aug 01

This is part two of a two-part series.

In part one, we cogently convinced you that regardless of what your organization does and what functionality your website has, it is in your best interest to serve your website securely over HTTPS exclusively. Here we provide some guidance as to how to make the move.

How to transition to HTTPS

To fully transition to HTTPS from HTTP means to serve your website HTML and assets exclusively over HTTPS. This requires a few basic things:

  • A digital certificate from a certificate authority (CA)
  • Proper installation of the certificate on your website’s server
  • Ensuring all assets served from your website are served over HTTPS

Let’s break these down.

Acquire a digital certificate

As briefly discussed in part one, to implement HTTPS for your website you must procure a digital certificate from a certificate authority. Just like domain name registrars lease domain names, CAs lease digital certificates for a set time period. Each certificate has a public and private component. The public component is freely shared and allows browsers to recognize that a “trusted” CA was the one to distribute the certificate. It is also used to encrypt data transmitted from the browser. The private complement is only shared with the purchaser of the certificate, and can uniquely decrypt data encrypted by the public key. CAs use various methods through email or DNS to “prove” that the person who purchased the certificate is a rightful administrator of the domain for which they purchased it. Once you’ve received the private key associated with the certificate, you’ll need to install it on your server. Annual certificate costs can be as much as $1,000 or as little as nothing. More on that in a moment.

Install the certificate

Lots of wires

Installing an HTTPS certificate manually on a server is not a trivial engineering task. We explain this at a high-level in part one. It requires expertise from someone who is experienced and comfortable administering servers. There are many different installation methods unique to each permutation of server software and hosting platform, so I won’t expend any real estate here attempting to lay it out. If you have to do a manual installation, it’s best to search your hosting provider’s documentation. However, depending on the complexity of your website architecture, there are ways to ease this process. Some hosting platforms have tools that substantially simplify the installation process. More on that in a moment as well.

Serve all resources over HTTPS: avoid mixed content

Once you’ve installed your certificate, it’s time to ensure all assets served from your pages are served over HTTPS. Naturally, this entire process should be completed in a staging environment before making the switch to your production environment. Completing a full transition to HTTPS requires attention to detail and diligence. “Mixed content”, or serving assets from a page over both HTTP and HTTPS, can be both tedious and insidious to rectify. The longer your site has been around, the more content there is and the more historic hands have been in the pot of content creation, the more work there will be to make the switch. Depending on your platform (CMS or otherwise) and how it was designed, there may be many avenues for different stakeholders to have included assets within a page over time. Developers, site admins, and content editors usually have the ability to add assets to a page. If any assets start with http://, they’ll need to be updated to https:// to prevent mixed content warnings.

We have recently helped a client who has been publishing articles at a high cadence for over 10 years with many different stakeholders over that period. Practices weren’t consistent and uncovering all the ways in which HTTP resources were served from the page was a substantial undertaking. Therefore, be prepared for a time investment here – there may be many areas to audit to ensure all assets from all your pages are being served over HTTPS. Some common ways mixed content HTTP assets are served from a site whose HTML is served over HTTPS are:

  • Hard-coding a resource: e.g. http://www.example.com/img/insecure-image.jpg
  • Using a 3rd-party library or ad network reference: http://www.example.com/js/analytics.js
    • This is common for libraries that haven’t been updated in a while. Most all of them now serve the same assets over the same path securely with HTTPS.

Even practices that were previously encouraged by Paul Irish, a leading web architect for the Google Chrome team, may have contributed to your mixed content problem, so don’t feel bad. Just know, there will likely be work to be done.

The risk of mixed content

These “not secure” bits of mixed-content expose the same risk that your HTML does when served over HTTP, so browsers rightfully show the user that the experience on your site is “not secure”.

Mixed content is categorized in two ways: active and passive. An asset that can contribute to passive mixed content would be an image; it doesn’t interact with the page but is merely presented on the page. An example that can be an active asset of mixed content is a javascript file or stylesheet since its purpose is to manipulate the page. Passive mixed content, albeit categorically less severe than active, still exposes opportunities for an attacker to learn a lot about an individual’s browsing patterns and even trick them into taking different actions than they intend to on the page. Therefore passive mixed content still constitutes enough of a threat for the browser to issue a warning display.

mixed content browser errors

In the case of an active asset that is compromised, if it were a javascript file, an attacker can take full control of the page and any interaction you may have with it like entering passwords, or credit card information. The mechanism behind this is a somewhat sophisticated man-in-the-middle attack, but suffice it to say, if the browser recognizes the vulnerability, the best scenario is the poor user experience we discussed in part one, the worst is total data compromise. Your audience, and by association your organization, will be seeing red.
Chrome misconfigured HTTPS

The good news about moving to HTTPS

Ensuring your website serves assets exclusively over HTTPS is not as hard as it used to be, and is getting easier by the day.

There are free digital certificates

There’s no such thing as a free lunch, but a free certificate from a reputable CA? It would seem so. People are just giving them away these days… Seriously, many years in the making since its founding by two Mozilla employees in 2012, the Let’s Encrypt project has vowed to make the web a secure space and has successfully endeavored to become a trusted CA that literally does not charge for the certificates they provide. They have shorter lease cycles of 60 to 90 days, but they also offer tooling around automating the process of reinstalling newly provided certificates.

There are easier and cheaper ways to install certificates

With the advent of the aforementioned free certificate, many platform-as-a-service (PaaS) hosting options have incorporated low cost or free installation of certificates through their hosting platform sometimes as easily as a few clicks. Let’s Encrypt has been adopted across a broad range of website hosting providers like Squarespace, GitHub Pages, Dreamhost, all of which we use alongside many others.

For many of our Drupal partners, we prefer to use a platform as a service (PaaS) hosting option like Pantheon, Acquia, or Platform.sh. Both Pantheon and Platform.sh now provide a free HTTPS upgrade for all hosting plans; Acquia Cloud, another popular Drupal PaaS, is still a bit behind in this regard. We have found that the efficiency gains of spending less time in server administration translates to more value to our clients, empowering additional effort for the strategy, design, and development for which they hired us. In addition to efficiency, the reliability and consistency provided by finely tuned PaaS offerings are, in most cases, superior to manual installation.

A good example of the evolution of hosting platforms maturing into the HTTPS everywhere world is our own Jekyll-based site, which we’ve written about and presented on before. We first set up HTTPS over GitHub pages using CloudFlare guided by this tutorial since we found it necessary to serve our site over HTTPS. However, about a year later GitHub announced they would provide HTTPS support for GitHub pages.

Similarly, we had previously implemented Pantheon’s workaround to make HTTPS on all of their tiers accessible to our clients on their hosting platform. Then they announced HTTPS for all sites. We’re thankful both have gotten easier.

There are tools to help with the transition to HTTPS

Through its powerful Lighthouse suite, Google has a tool to help audit and fix mixed content issues. Given the aforementioned tedium and potential difficulty of tracking down all the ways in which people have historically added content to your site, this can be an invaluable time saver.

You can also use tools like Qualys SSL Labs to verify the quality of your HTTPS installation. See how our site stacks up.

Wrap-up

Given the much greater ease at which many modern hosting platforms allow for HTTPS, the biggest barrier, primarily a matter of effort, is to clean up your content and make sure all assets are served over HTTPS from all pages within your website. So, if you haven’t already, start the transition now! Contact us over the phone or email if you need assistance and feel free to comment below.

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