Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Mar 05 2020
Mar 05

This post is part of our Drupal 9 upgrade series. If you're on Drupal 8 already, there's lots of useful advice below; we'll also have a post just for you soon.

Drupal 7 will be unsupported past 2021. Consider this post your 18 month friendly nudge  :-)

With end-of-life for Drupal 7 security support set for the end of 2021 and the release of Drupal 9 this summer, it's time to make a plan.

You've likely already been thinking about what to do with your current Drupal 7 site. Starting with a formal review that we outline below now (ideally by sometime in Q2 2020), gives you time to audit your existing site, evaluate needs and options, and create a budget and process plan for upgrading to Drupal 9 before D7's security updates reach end-of-life status.

And since you've been on D7 for a few years, your site's design, content and features may be due for a refresh. It's a good time to assess all these things -- and create a plan that is manageable for your team and doesn't leave frustrated and stressed in 2021. 

And here's a brief overview (our cheat sheet) of an 18 month plan: 

  • Q2 - Q3 2020: Technical audit and resource / scope planning

    • Document the Drupal infrastructure (modules, content types, features) that constitute your current site.

    • Understand what modules are core v. contributed and their equivalents in D8 / D9

    • Do a qualitative assessment of whether the site is still "working" for you. Are there current site features that have fallen out of use? Is there new functionality that you'd like to build?

    • Do we want to just replatform to Drupal 9, or take the opportunity to redesign our site as well?

    • What's a realistic budget for a redesign / replatform? 

    • Who will be on your project team when you move forward? 

  • Q3 - Q4 2020: Finalize the scope of your project, your available budget, and get started

    • Now that you know what you want, secure the appropriate resources for the scope of work.

    • Remember, major technology projects like these take time. So if possible, start your replatform / redesign sooner rather than later. This will give you time to make adjustments to your new site's features, design and content without the threat of delaying your transition off of Drupal 7.

    • Our *general* guidance is that a replatform / redesign can take anywhere from 4-6 months or more, depending on complexity and your team's availability to contribute actively to the project. 

  • Q1 - Q2 2021: Design & development is well underway

    • Depending on project start and scope, you'll likely have design finalized and development well underway in Q1.
  • Q2 - Q3 2021: Launch your new site

    • Our recommendation is that your new site launch no later than Q3 2021. You'll give yourself enough wiggle room in case anything takes more time than you thought it would. ;-)
Drupal 7 to Drupal 9 Quick Guidance Drupal.org: If you start now, we'll be moving to Drupal 8 first to allow a seamless upgrade to Drupal 9. If the project starts next year, we're likely to start building directly in D9.

Am I going to Drupal 9 directly or Drupal 8 first? 

Well, it depends on two things: when you start your rebuild project and where Drupal 9's release schedule stands. If you were to start your move now, we'd migrate your site to 8.8 first, and then transition you to Drupal 9. If your project starts next year, we'll likely build the site directly in D9. (note: the D9 release date depends on when beta requirements are met. Current plan is to release on June 3, 2020, but it could be as late as December (https://www.drupal.org/core/release-cycle-overview).

Whether replatform or redesign, the initial audit and further evaluation of your features and functions for the new site will be critical to how and when we start the build in D8 or D9. The overall level of effort in either case is directly related to how complex your current site is -- and what new specs your team wants. Whatever the case, the Chapter Three team are experts at Drupal 7 to Drupal 8 migrations (we’ve done well over a hundred!) and we'll help your team navigate the process from 7 to 8 or 9. We're active contributors to Drupal 9 and are closely monitoring progress of core and contributed modules for all of our clients. 

The best way to get your upgrade done is to work with us! Chapter Three's contributions to Drupal 8 helped build much of the infrastructure that Drupal users see today. We know how to manage an effective transition. Contact us today and let's get your customized 18 month plan in motion.  

Mar 03 2020
xjm
Mar 03

This week is the first target release window for the Drupal 9 beta.

We’ve made significant progress on the beta requirements during the last couple of months thanks to the tremendous amount of work by the community. Based on the outstanding tasks in the meta issue, we are close to completing beta requirements, but not close enough to release it this week.

When will Drupal 9.0.0-beta1 be released?

Given how close we are to completing the beta requirements, we are considering releasing the beta in mid-March if the requirements are complete by March 13. If we do release the beta in 1-2 weeks, Drupal 9.0.0 will still be scheduled for release on June 3, 2020. We will make a final announcement by March 16 about whether there will be a June release.

If any must-have issues remain unresolved by March 13, we will move the beta target window to the first week of May, and Drupal 9.0.0 will be scheduled for August 3, 2020.

This does not affect the expected release date of Drupal 8.9.0 (scheduled for June 3, 2020) nor that of Drupal 9.1.0 (planned for December 2, 2020). The Drupal 8 and 7 end-of-life is also still November 2021.

We need your help to meet the beta deadline, whether it is March 13 or April 28! Drupal 9 readiness meetings are every Monday at 7pm UTC in the #d9readiness channel on https://drupal.org/slack. Help us with the issues below.

Current status and issues left for Drupal 9.0.0-beta1

Dependency updates

All PHP dependencies (Symfony, Laminas, Twig) have been updated to the versions we intend to use for Drupal 9.0.0, although we will continue to keep up to date with bugfix releases.

Nearly all JavaScript and CSS dependencies have been updated, with just two issues to go:
jQuery Cookie (needs review and testing from JavaScript developers!) and Normalize.css (RTBC and awaiting committer review).

Upgrade paths

In addition to deprecations, we are improving and simplifying in-place updates with update.php to ensure the Drupal 8 to 9 update is smooth and reliable. Four issues remain and could use additional help from experienced contributors:

We are also ensuring that all known critical Drupal 8 upgrade path bugs that may prevent updates from older Drupal 8 versions are fixed in 8.8 and 8.9. Only three remain. These technically difficult issues are critical for Drupal's data integrity:

Platform requirement changes

Drupal 9 has already raised the minimum PHP version to 7.3. We also want to increase MySQL, PostgreSQL, and SQLite requirements. This includes:

  • MySQL, MariaDB, and Percona (required prior to beta1)
  • PostgreSQL (Beta deadline; help needed! If you use Postgres, document what versions are available from your hosting provider.)
  • SQLite (Might be completed during the beta phase)

Drupal 9 base theme API

We want to add an up-to-date Drupal 9 version of the 'Stable' base theme. This issue and the related issues to decouple core themes from Drupal 8 base themes could use review and feedback from theme contributors.

Once all the above issues are complete, Drupal 9 is beta-ready. That means that we will have completed all of the significant code changes we intend to make, and that it should be possible to test updates of real sites against it if contributed and custom code has been ported. Site owners can use the Upgrade Status module to check the Drupal 9 readiness of their modules and themes; see the guide on updating to Drupal 9 for more information.

Other issues to complete prior to final release of Drupal 9

There is a second category of issues that we want to complete before Drupal 9.0.0 is released. Since we have fixed release windows, these also need to be either complete or close to completion, especially for the first beta window, since this gives the shortest amount of time to finish them.

Complete migrations for multilingual content so that all Drupal 7 sites can migrate before Drupal 7 reaches EOL.

Drupal.org and Drupal core should be able to fully handle contributed projects that are compatible with both 8.x and 9.x and not assume core compatibility based on the version or branch name. This requirement spans multiple projects and areas including project listings, the Composer façade, update.xml from Drupal.org, and localization files. Most of the minimum required changes for Drupal core and Drupal.org are already complete; however, there remains one outstanding core regression related to module compatibility as well as a number of followup issues.

Finally, Drupal 9 currently relies on Node.js 8 for transpiling and linting frontend assets. This is core-developer-facing only so we may raise the Node.js requirement after beta.

Mar 03 2020
xjm
Mar 03

This week is the first target release window for the Drupal 9 beta.

We’ve made significant progress on the beta requirements during the last couple of months thanks to the tremendous amount of work by the community. Based on the outstanding tasks in the meta issue, we are close to completing beta requirements, but not close enough to release it this week.

When will Drupal 9.0.0-beta1 be released?

Given how close we are to completing the beta requirements, we are considering releasing the beta in mid-March if the requirements are complete by March 13. If we do release the beta in 1-2 weeks, Drupal 9.0.0 will still be scheduled for release on June 3, 2020. We will make a final announcement by March 16 about whether there will be a June release.

If any must-have issues remain unresolved by March 13, we will move the beta target window to the first week of May, and Drupal 9.0.0 will be scheduled for August 3, 2020.

This does not affect the expected release date of Drupal 8.9.0 (scheduled for June 3, 2020) nor that of Drupal 9.1.0 (planned for December 2, 2020). The Drupal 8 and 7 end-of-life is also still November 2021.

We need your help to meet the beta deadline, whether it is March 13 or April 28! Drupal 9 readiness meetings are every Monday at 7pm UTC in the #d9readiness channel on https://drupal.org/slack. Help us with the issues below.

Current status and issues left for Drupal 9.0.0-beta1

Dependency updates

All PHP dependencies (Symfony, Laminas, Twig) have been updated to the versions we intend to use for Drupal 9.0.0, although we will continue to keep up to date with bugfix releases.

Nearly all JavaScript and CSS dependencies have been updated, with just two issues to go:
jQuery Cookie (needs review and testing from JavaScript developers!) and Normalize.css (RTBC and awaiting committer review).

Upgrade paths

In addition to deprecations, we are improving and simplifying in-place updates with update.php to ensure the Drupal 8 to 9 update is smooth and reliable. Four issues remain and could use additional help from experienced contributors:

We are also ensuring that all known critical Drupal 8 upgrade path bugs that may prevent updates from older Drupal 8 versions are fixed in 8.8 and 8.9. Only three remain. These technically difficult issues are critical for Drupal's data integrity:

Platform requirement changes

Drupal 9 has already raised the minimum PHP version to 7.3. We also want to increase MySQL, PostgreSQL, and SQLite requirements. This includes:

  • MySQL, MariaDB, and Percona (required prior to beta1)
  • PostgreSQL (Beta deadline; help needed! If you use Postgres, document what versions are available from your hosting provider.)
  • SQLite (Might be completed during the beta phase)

Drupal 9 base theme API

We want to add an up-to-date Drupal 9 version of the 'Stable' base theme. This issue and the related issues to decouple core themes from Drupal 8 base themes could use review and feedback from theme contributors.

Once all the above issues are complete, Drupal 9 is beta-ready. That means that we will have completed all of the significant code changes we intend to make, and that it should be possible to test updates of real sites against it if contributed and custom code has been ported. Site owners can use the Upgrade Status module to check the Drupal 9 readiness of their modules and themes; see the guide on updating to Drupal 9 for more information.

Other issues to complete prior to final release of Drupal 9

There is a second category of issues that we want to complete before Drupal 9.0.0 is released. Since we have fixed release windows, these also need to be either complete or close to completion, especially for the first beta window, since this gives the shortest amount of time to finish them.

Complete migrations for multilingual content so that all Drupal 7 sites can migrate before Drupal 7 reaches EOL.

Drupal.org and Drupal core should be able to fully handle contributed projects that are compatible with both 8.x and 9.x and not assume core compatibility based on the version or branch name. This requirement spans multiple projects and areas including project listings, the Composer façade, update.xml from Drupal.org, and localization files. Most of the minimum required changes for Drupal core and Drupal.org are already complete; however, there remains one outstanding core regression related to module compatibility as well as a number of followup issues.

Finally, Drupal 9 currently relies on Node.js 8 for transpiling and linting frontend assets. This is core-developer-facing only so we may raise the Node.js requirement after beta.

Mar 02 2020
Mar 02

As of Drupal 8.7, the Media and Media Library modules can be enabled and used out-of-box. Below, you'll find a quick tutorial on enabling and using these features.

out-of-box before media and media library

In the past there were two different ways to add an image to a page.

  1. An image could be added via a field, with the developer given control over its size and placement:
     

    Image field before media library
  2. An image could be added via the WYSIWYG editor, with the editor given some control over its size and placement:
     

    Image field upload choices screen

A very straightforward process, but these images could not be reused, as they were not part of a reusable media library.

reusing uploaded media Before Drupal 8.7

Overcoming image placement limitations in prior versions of Drupal required the use of several modules, a lot of configuration, and time. Sites could be set up to reference a media library that allowed editors to select and reuse images that had previously been uploaded, which we explained here.

This was a great time to be alive.

What is available with Media Library

Enabling the Media and Media Library modules extends a site's image functionality. First, ensure that the Media and Media Library core modules are enabled. 

Enable media library in drupal

A media entity reference field must be used with the Media Library. It will not work with a regular image field out-of-box.

Image field on manage display page

On the Manage form display page, select "Media library" widget. 

Media library widget on manage display page

On the "Node Add" and "Node Edit" forms, you’ll see the below difference between a regular image field and a field connected to the media library.

Media library field on node edit

Click on “Add media” and you’ll see a popup with the ability to add a new image to the library or to select an image that is already in the library.

Media field grid

With a simple configuration of the field, if multiple media types are allowed in the field, you’ll see vertical tabs for each media type.

Media grid with multiple media types

WYSIWYG configuration

The WYSIWYG editor requires a few steps when configuring the media library for a specific text format. First, a new icon will appear with a musical note overlapping the image icon. This should be added to the active toolbar and the regular image icon should be moved to the available buttons.

wysiwyg toolbar configuration

Under “Enabled filters,” enable “Embed media."  Under the filter settings, vertical tab settings can be chosen for media types and view modes. Once that configuration is saved, you’ll see on a WYSIWYG editor that you have the same popup dialog for adding a new image to the media library, or selecting an already-uploaded image.

wysiwyg media configuration

Once you are on a "Node Add or "Node Edit" page with a WYSIWYG element, you’ll see the media button (image icon plus musical note).

Media button on wysiwyg editor

Clicking on the media button brings up the same, familiar popup that we saw earlier from the image field:

media library grid

This article is an update to a previous explainer from last year. 

Feb 24 2020
Feb 24

A month ago, Matt Mullenweg, co-founder of WordPress and founder of Automattic, visited me in Antwerp. While I currently live in Boston, I was born and raised in Antwerp, and also started Drupal there.

We spent the morning together walking around Antwerp and visited the Plantin Moretus Museum.

The museum is the old house of Christophe Plantin, where he lived and worked around 1575. At the time, Plantin had the largest printing shop in the world, with 56 employees and 16 printing presses. These presses printed 1,250 sheets per day.

Today, the museum hosts the two oldest printing presses in the world. In addition, the museum has original lead types of fonts such as Garamond and hundreds of ancient manuscripts that tell the story of how writing evolved into the art of printing.

The old house, printing business, presses and lead types are the earliest witnesses of a landmark moment in history: the invention of printing, and by extension, the democratization of publishing, long before our digital age. It was nice to visit that together with Matt as a break from our day-to-day focus on web publishing.

An old printing press at the Plantin Moretus Museum

Dries and Matt in front of the oldest printing presses in the world

An old globe at the Plantin Moretus Museum

February 20, 2019

47 sec read time

db db
Feb 24 2020
Feb 24

The Drupal Association is seeking partners to help us advance the next phase of the Automatic Updates initiative.

The first phase of this work was generously sponsored by the European Commission, and supported by other partners including: Acquia, Tag1Consulting, Mtech, and Pantheon.

In this first phase, we accomplished a great deal:

  • Display of security PSAs directly in Drupal's admin interface
  • Automated readiness checks, to ensure that a site is prepared for updates
  • Automatic updates for Drupal Core in both Drupal 7 and Drupal 8.

But while this work laid the foundation, a great deal of work yet remains. The next phase hopes to add support for:

  • Sites managed using Composer
  • Automatic updates with Contributed modules
  • A front-end controller providing support for easy roll-back

The Drupal Association needs partners in order to move this work forward. We're looking both for organizations who can provide financial support, and teams who have expert developers who can contribute to development.

If you are interested, you can find a detailed scope of the remaining work attached to this post.

Download the Request for Sponsors

Contact: [email protected] with questions.

Feb 21 2020
Feb 21
Reading time 3 mins clock

Mobile apps.

Why are they still such a popular request when we’re well served by web browsers and responsive themes these days?

Is delivering a mobile app a huge amount of work to develop and maintain?

The many forms of mobile application

Any website being developed these days is built on top of a responsive framework allowing pages to adapt and re-layout content based on the size of the viewing device. 

Perfect for mobile and tablet devices alongside traditional desktop screens. 

So why are mobile apps still chased after by people?

What’s wrong with their responsive website?

Often the case is simply about being present on a person’s phone screen - an icon shining back at them as a reminder about the service available. Many website companion mobile apps are nothing more than a re-purposed pile of content from the website or a form-based user interface to search the information from the website.

So if the desired mobile app isn’t technically demanding what’s the best way to get it built and deployed so that your customers or visitors can benefit? There are three directions you can take...
 

Native

Apple (iOS) and Android devices have their own flavour of a mobile app, also known as a native app, which is the best possible way to deliver a great mobile experience making full use of the hardware in someone’s pocket.

However, the time and cost to find dedicated skilled developers and maintain two versions of a mobile app, which is often a simple companion to a website, is often out of the reach of most project budgets.

Hybrid

The solution to the double development time and cost is building the application using the same technologies as the website (HTML5, JavaScript, CSS) and embedding it inside of a web browser wrapped in a native application for Android and iOS.

It’s one set of code and a much simpler development process that can often be implemented by the same team that built the website. There are many toolkits and templates to generate simple applications such as Cordova and ReactNative.

PWA

Progressive Web Applications (PWA) are being pushed as the future direction that mobile apps should be heading in - a fusion of the existing websites responsive theme with additional JavaScript to speed up the reaction of pages for the user and handling times when there’s no Internet connection on the device.

It’s the quickest way to get a mobile app deployed and your icon on a user’s phone screen.
 

If your app is not particularly useful, unique, or “app-like,” it doesn’t belong on the App Store.

Apple Inc.

Where does a CMS like Drupal fit into this?

A digital experience platform (DXP), such as Drupal 8, works as a great content store thanks to its built-in data modelling toolkit. But what makes the Drupal CMS shine is the ability to expose the data model via industry-standard API formats such as RESTful, JSON and GraphQL - meaning whatever type of mobile app is decided on - the backend content that powers your mobile app can be driven by Drupal and kept separate from your app. 

This is commonly known as running the CMS in Headless mode if it is not also powering the website.

Two people on phones by You X Venture on Unsplash

Where to go first?

Drupal has a variety of mobile app approaches freely available to use, modify and learn from. Although some of the content is a little out of date, the Drupal.org site has a reasonable summary of options. Some pointers to get going for each type of mobile app are:

No matter what form of mobile app you decide on, Drupal 8 provides a solid platform for serving your data to a multitude of user interfaces - be in mobile apps, websites, smart televisions, information boards or simple input into another system.

The components and plugins needed are mostly bundled with the default Drupal install - or a free simple module installation away. There’s nothing stopping you getting stuck in with some experimentation to decide where you want to head with Drupal as your backend.
 

Struggling to know what's best for you? We'd love to chat with you and explore options relevant to you and your business.

Let's Chat

Feb 19 2020
Feb 19

Our normally scheduled call to chat about all things Drupal and nonprofits will happen TOMORROW, Thursday, February 20, at 1pm ET / 10am PT. (Convert to your local time zone.)

This month, in addition to our usual free-for-all, we'll be talking about hosting on Pantheon. There has been a lot of discussion in the community and on the Drupal Slack #nonprofits channel about some of the pricing changes they have implemented. If you would like to discuss and contribute to the conversation, please join us.

We will also have an update on our community's plans for the upcoming Nonprofit Technology Conference (20NTC).

All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.

Feel free to share your thoughts and discussion points ahead of time in our collaborative Google doc: https://nten.org/drupal/notes

This free call is sponsored by NTEN.org but open to everyone.

REMINDER: New call-in information -- we're on Zoom now!

  • Join the call: https://zoom.us/j/308614035
    • Meeting ID: 308 614 035
    • One tap mobile
      • +16699006833,,308614035# US (San Jose)
      • +16465588656,,308614035# US (New York)
    • Dial by your location
      • +1 669 900 6833 US (San Jose)
      • +1 646 558 8656 US (New York)
  • Follow along on Google Docs: https://nten.org/drupal/notes
  • Follow along on Twitter: #npdrupal

View notes of previous months' calls.

Feb 11 2020
Feb 11

1) Built-in support for multi-language sites and admin portals

Let's jump right in! For business owners, ecommerce eliminates many restrictions of traditional business practices. One opportunity is the ability to sell your product to overseas consumers, expanding your possible market to contain, well virtually, the whole world. Of course, one of the barriers to entry into certain markets may be the language.

Imagine this: You are a Brazilian business owner who just invented chewing gum that never loses its flavour. Obviously, the demand for this product is worldwide. The only problem is that you do not feel comfortable writing the script for your new online product page in English or any language other than Portuguese for that matter. In a perfect world, the ideal solution might be to hire translators for every language of each country that you want to sell this amazing gum in. However, the costs of such an endeavour are enough to make even those with even the deepest of pockets think twice.

In my opinion, the next best and completely viable option is to choose to develop your chewing gum site using Drupal then make use of the many multilingual modules to automatically translate your content (just Google “Drupal automatic translate” for a list of options). The advantage of these Drupal translation modules is that, first, it can appear as an option at the top of the page and is therefore easily accessible to the customer. Second, additional modules can allow you to automatically show the users local language based on their browser’s set language. Third, you can choose which blocks of text you want to translate and which you do not; so let us say for aesthetic reasons or brand awareness you do not want a certain block of the site to be translated, you simply do not enable the translation for that block in the admin portal. Additionally, while your site frontend is being translated for your visitors, as an admin you can maintain Portuguese as the primary language to run your backend admin portal.

Read the full Gartner reportSpeaking from my own experience, I shop online for bicycle components quite often. The problem is many of the unique manufacturers I am looking to buy from are based out of Italy and Germany. Google translate can do an adequate job of helping you navigate the site, but when it comes to the finer details like product specifications or return policies I quickly find myself out of my depth. The great thing about using Drupal Translate is that you can manually enter the translation for each language of every block on your website. So for example, instead of paying for a full site translation in each language, you could hire professionals to translate the important areas like the fine print and leave the less critical areas up to Drupal.

2) Features on features

Okay, Drupal is not exactly an episode of Pimp My Ride, but it can pretty much do anything you can dream of. If, for some reason, you want to design a site that sources all of the types of chicken wings sold in restaurants across your city. Then create a catalogue that breaks down the various chicken wings by texture, flavour, price, size, messiness, etc. Now you want to integrate a system that uses logic and intelligence to recommend the best beer your company sells to accompany any wing selection made. This is all possible with Drupal.

The cost to develop such a unique site with these custom modules on Drupal would not be cheap. However, the point remains that a feature such as the one mentioned above is quite crazy, but completely possible. If there is functionality that you need, it can be built on Drupal. The other big takeaway is that once you have paid for the development of the module you are now the owner and do not have to worry about any ongoing licensing costs. For reasons like these, it is my opinion that Drupal is the best CMS for such robust and custom site requirements.

3) Security

Of course, nothing can ever be fully secure especially without regular upkeep, but Drupal does a few things differently that should help you sleep better at night. Unlike the many popular SaaS platforms, Drupal is open source and non-proprietary. This means that you are the owner of your data and you are the one who decides how it is managed, meaning you can fine tune every aspect of your Drupal site from the site itself to your hosting environment. If you have a security team or security-focused partner that you work with, Drupal provides the flexibility they need to keep your data safe.

The official Drupal Security Team is also thoroughly on top of the security of the core Drupal software’s code and helps module developers keep their modules secure. This team frequently releases security patches that address any vulnerabilities that come up. In addition to the official Drupal team, the large Drupal community of developers donate their time to develop and monitor Drupal’s code. Drupal and all of it’s modules are built using a core set of coding standards, so the many thousands of developers working with Drupal’s code ensures security issues are found and addressed quickly.

Lastly, one of the features of Drupal that is best known is its ability to integrate into third-party applications. As such, Drupal is also capable of easily integrating into other security systems and platforms on the market. You’re not restricted to Drupal alone.

4) Open source community

In my mind, there are two main reasons that the open-source nature of Drupal and the community that surrounds it are such an advantage.

First, because of the large community of developers and its open-sourced nature, there are countless plug-and-play ready modules available free of licensing fees just waiting to be added to your website. This means, in addition, you are the owner of your own code and data. Furthermore, you never have to worry about losing development support for your website. There will always be another Drupal agency out there waiting to pick up the pieces if something were to go wrong.

Second, because there is such a large community of developers behind the expansion of Drupal, you have a veritable fusion of diverse ideas and designs. Instead of a single organization pushing code in a certain direction, you can find incredibly creative and unique libraries of code. This means a deeper pool of free talent to pull from. Even with the creative minds driving the development of Drupal, there is still consistency in the underlying code. This enables easier upkeep of the code itself and allows a lower barrier of entry when onboarding new developers. The advantage to the end-user is that, when compared to a fully custom build, using Drupal means that should your partner agency ever go out of business or the relationship deteriorates, you will have other experts in Drupal to turn to.

5) Future-proof

I keep bringing this up, but it really enables so many possibilities; because Drupal is so open to API integrations, you can design Drupal to work as a modular middleware behind the scenes. This means as you acquire new technology and software, it really is as simple as plugging it in and configuring an API hook.

Furthermore, as long as Drupal is paired with the right server, it can handle endless amounts of traffic and scale from small business to enterprise. This is a reason why Drupal is such a popular CMS of choice for medium-sized to enterprise-level organizations.

Finally, Drupal as a CMS is kind of like Play-Doh. You can build out your frontend experience for the market you are presently targeting using Drupal’s built-in theming layer or by using one of the many other frontend frameworks. Drupal’s APIs allow it to run headless, so it can hold your backend data but you’re not tied down to any specific way of building your frontend. Ten years down the road, though, you may have a completely different set of needs for your frontend framework. No problem, you can rest assured that Drupal won't get in your way.

Are you considering options for your digital experience platform?

Choosing the right DXP now is important to your business now and in the future. Protect your tech investment by assessing the trade-offs of buy or build deployment options and how they relate to your digital experience goals and business outcomes. This Gartner report has been made available to our readers for a limited time and will help you get started. Check it out.

Click to access the Gartner report today

Feb 11 2020
Feb 11

The workshop is currently on hold until the status of DrupalCon Minneapolis is resolved.

The Drupal Community Working Group (CWG) is pleased to announce that registration is now open for a full-day Mental Health First Aid workshop on Sunday, May 17, 2020 (the day before DrupalCon Minneapolis begins) in Bloomington, Minnesota. 

The workshop will be held "field trip" style; it will be held off-site, at the Health Counseling Services facility in Bloomington, Minnesota, from 8:30am-5pm. Transportation will be provided to and from a location near the Minneapolis Convention Center (the site of DrupalCon) to the workshop. Following the workshop, attendees are invited to (optionally) attend a pay-on-your-own group dinner to decompress and discuss the day's workshop.

The CWG believes that these types of proactive workshops will help improve our community's mental health literacy and awareness, as well as making it easier for us to have open, honest, and respectful conversations and potentially spotting signs of when community members are in need of assistance.

The Drupal Association is generously sponsoring the workshop by providing funding to help defer the cost of the workshop as well as providing transportation. 

From the Mental Health First Aid website:

Mental Health First Aid is a course that gives people the skills to help someone who is developing a mental health problem or experiencing a mental health crisis. The evidence behind the program demonstrates that it does build mental health literacy, helping the public identify, understand, and respond to signs of mental illness.

Mental Health First Aiders learn a single 5-step action plan known as ALGEE, which includes assessing risk, respectfully listening to and supporting the individual in crisis, and identifying appropriate professional help and other support. Participants are also introduced to risk factors and warning signs for mental health or substance use problems, engage in experiential activities that build understanding of the impact of illness on individuals and families, and learn about evidence-supported treatment and self-help strategies.

Over the past few years, the CWG has organized proactive community health events, including on-going Code of Conduct contact training, as well as previous DrupalCon North America trainings on leadership, teamwork, and communications. 

In order for the workshop to proceed, we need at least ten community members to register by April 1, 2020 at https://healthcounselingservices.com/events/adult-mental-health-first-aid-11/

When registering:

  • Choose the "Pay now" option (do not select the "Bill my organization" option.
  • Use the coupon code: MHFA30 to receive $30 off the regular price.
  • For the "Name of organization", "Name of site", "Supervisor's name", and "Supervisor's phone" fields, feel free to use "not applicable".
     
Feb 07 2020
Feb 07

Read our Roadmap to understand how this work falls into priorities set by the Drupal Association with direction and collaboration from the Board and community.

Project News

Get Ready for Drupal 9

Are you wondering what it will take to upgrade to Drupal 9? Good news - it's going to be easier than any other major version upgrade in Drupal's history.

The upgrade to Drupal 9 is just like any other Drupal upgrade, except that the new codebase has updated key dependencies Drupal relies on and removed deprecated code. As long as all the modules and custom code you use don't rely on deprecated code - you should be good to go.

As it turns out, many contributed or even custom modules only need a one-line change to be ready for Drupal 9. You can use these community created tools to check the status of your modules: the upgrade status module, or the Drupal Check command line tool. In many cases, you may just need to remove some deprecated code in favor of the more modern implementations. Drupal Rector can provide you with automated fixes for many of these deprecations. 

Still getting to grips with Composer?

Composer

If you're still getting to grips with using Composer after the changes in Drupal's 8.8.0 release, don't worry - there's help to be found. The community has extensively documented the different scenarios a site owner may find themselves in with this update.

If you've previously used one of the community created templates to manage your site to composer, there are instructions to migrating to the officially supported method.

If you've never used Composer at all - you're in luck - with 8.8.0 and beyond everything you need is already in place. 

Drupal.org Update

Drupal.org Packaging updates

As mentioned in our December update, we've been making major improvements to the Drupal.org packaging pipeline, to support packaging Drupal using Composer create project. We reached a major milestone at DrupalCamp New Jersey, allowing our packaging pipeline to properly support the Composer create project command when generating tar and zip files, and paving the way for enhancements to the core subtree splits.

Updating this pipeline is critical for ongoing releases of Drupal, and is part of paving the way for the Drupal 9 alpha release. We want to thank Acquia for donating time to help us get this work ready.

Preparing for contrib Semver

Per our roadmap for supporting Semver for contributed projects on Drupal.org, we have updated the way contrib version numbers are stored, making existing version numbers parseable when we convert to full semver. We also collaborated with core contributors at DrupalCamp New Jersey to identify and resolve a number of other related issues.

Drupal.org now has an example project which uses semantic versioning, which we are using as the testbed for this support, and to prove out any additional UI changes that we want to make before rolling this out to all other contributed projects.

Want to learn more about Semantic Versioning and how to use it properly within your projects? Semver.org can walk you through it.

More accessible formatting for the DrupalCon program schedule

It's almost time for the DrupalCon Minneapolis program to be published! To prepare for this launch, we've made updates to the program schedule to improve accessibility and readability for attendees.

In particular these updates have focused on line weights, spacing, and other formatting changes that should improve readability. With the accepted sessions being announced soon,  we're excited to see what you think!

Better social event submission tools for DrupalCon events

DrupalCon Minneapolis | May 18-22 2020Some of the best parts of DrupalCon are the social events that take place around it. They're a chance for the community to celebrate and build camaraderie, and an established tradition. We've made updates to the social event submission process to make getting your event listed easier than ever. 

Join the Drupal Community in person! 

By the way… have you registered for DrupalCon yet?

DrupalCon is the best place to come together with other members of the Drupal community in person. It's also the central meeting point for all of facets of the Drupal business ecosystem, so if you are end-user looking for training or a vendor to support your Drupal deployment - there's no better place to be than DrupalCon.

DrupalCon Minneapolis is going to be here any day now - so get your tickets before prices go up!

Can't make it to Minneapolis? Join us at DrupalCon Barcelona 2020 in September.

———

As always, we’d like to say thanks to all the volunteers who work with us, and to the Drupal Association Supporters, who make it possible for us to work on these projects. In particular, we want to thank:

If you would like to support our work as an individual or an organization, consider becoming a member of the Drupal Association.
Follow us on Twitter for regular updates: @drupal_org, @drupal_infra

Feb 04 2020
Feb 04

Enjoy a random 404 video.

Or explore more of what we do.

We offer strategy, design and development services across industries and using a wide array of tech.

Read more about each below.

  • Business
  • Branding
  • User Research
  • Content Strategy
  • SEO
  • Accessibility
  • Responsive
  • Experience
  • Styleguides
  • Performance
  • Security
  • Migrations
  • Support
  • Training

Industry.

  • Finance
  • Healthcare
  • Higher Ed
  • Nonprofit
  • Tech

Technology.

  • PHP
  • Drupal
  • WordPress
  • Laravel
  • Javascript
  • Node
  • Vue
  • Nuxt
  • Electron
  • DevOps
  • Docker
  • Lando

Other.

  • Magic
  • Localdev
  • Testing
  • Events
  • Webinars
Feb 01 2020
Feb 01

Working with custom datetime elements in Drupal can sometimes be a bit tricky when you need a very specific date format to render. Even trickier can be date ranges that span multiple days. Add on top of that, date ranges that span over 2 different months and you might have your work cut out for you.

I am currently working on theming a Drupal 8 site that will feature events and event dates in a prominent way. In this article, I will create a recipe for how I am coding this within a Twig template. The context here is a landing page view where we show a listing of events with a basic date - month, day, and year.

The format I want to achieve in the end is:

  • Multi-Day Event - e.g. Jan 29 - 31 2020
  • Multi-Day Event (spanning over 2 different months) e.g. Jan 29 - Feb 03 2020
  • One Day Event - e.g. Jan 29 2020

We'll be using Twig's date formatter so if you need a worldwide date format, i.e. non-American, it will be a case of just re-arranging when we code up our custom formats. For example:

format_date('custom', 'M d Y') 

would be:

format_date('custom', 'd M Y') 

Getting started

For this project, I am using Drupal 8, a few core modules, and one contrib module. This article assumes the following knowledge:

  • Installing Drupal modules with Composer
  • Setting up a local development environment (I use Docksal)
  • Using Xdebug in your IDE (I use PHPStorm)
  • Knowledge of writing Twig code
  • Knowledge of basic Drupal 8 site building

Core

  • Drupal core 8.7.11
  • Datetime
  • Datetime Range

Contrib

  • Twig Xdebug (Optional)

As you can see, we have Datetime as well as Datetime Range which allows us to have a field formatter for event dates that span over multiple days. Once you're up and running, get twig_xdebug module with composer:

composer require drupal/twig_xdebug

Now, enable the modules:

drush en datetime datetime_range twig_xdebug -y

Create an event content type with date field

The next step is to create an event content type, Events, with a date field using Date range as the type. We don't need to be concerned with the display settings here as we will be doing our formatting in our Twig template.

The image above shows the datetime range formatter in the Drupal 8 UI. The image above shows the datetime range formatter in the Drupal 8 UI.

Create a custom view mode / events view

The next step is to create a custom view mode for our events landing page. I'll call it "Event List." That custom view modes are now a part of D8 core is a nice plus here. Now create a basic view for the event content type and set the format to Content > Event List, whereby we use the new view mode just created. For the view, we can choose either a page or block display depending on the use case.

Create a custom Twig template

The next step is to create a few event nodes so we can load up our new events list landing page and start to debug. The first thing is to make sure you have Twig template debugging enabled in your local development environment. Since we want a custom template for theming, I look at the twig template suggestion debugging output and see this:

<!-- FILE NAME SUGGESTIONS:
   * node--view--events--block-1.html.twig
   * node--view--events.html.twig
   * node--3--event-list.html.twig
   * node--3.html.twig
   * node--events--event-list.html.twig
   * node--events.html.twig
   * node--event-list.html.twig
   x node.html.twig
-->

As you can see from the debug output above, we have a nice variety of template suggestions to choose from. I'll use node--events--event-list.html.twig which is specific to the content type, view, and view mode we are using.

Note that a huge advantage of theming views in this manner using view modes is that you can theme as if it were a regular node template. In that regard, I grab Classy's basic node.html.twig file and place it in my custom theme's templates folder using the custom name as above. Now run drush cr and re-check the Twig template output and ensure that the new template has taken effect.

Debug with Twig Xdebug

For debugging with Twig, I like to use Twig Xdebug as mentioned above, which piggybacks on top of Xdebug so you can debug right in your Twig template with one line of code, {{ breakpoint() }}.

When I start to debug, the output provides me with a wealth of information that we can leverage to create some custom date variables right within our twig template. (Note that you could also use standard Xdebug within a .theme or .module file via a preprocess function.)

$context["content"]["field_event_date"][0]["start_date"]["#attributes"]["datetime"] = 2020-02-19T12:00:00Z

The image above shows Twig Xdebug printing out variables in PHPStorm. The image above shows Twig Xdebug printing out variables in PHPStorm.

From the above debugging output, we have the date and time in what's known as UTC Time ISO-8601 Format. We'll be converting that later to a Unix timestamp with Twig so that in turn, we can create custom, nicely formatted dates.

Setting variables in Twig

Now that we have debugging info, we can set some variables right in Twig like this:


 {# Define event start / end dates. #}
    {% set event_start_date = content.field_event_date.0.start_date["#attributes"]["datetime"] %}
    {% set event_end_date = content.field_event_date.0.end_date["#attributes"]["datetime"] %}


Now we will do some comparisons to check if the event is a single day, muti-day, or a muti-day event that takes place in two different months.

First we will check for a single day event by comparing the start and end day.


{% if event_start_date | date('U') | format_date('custom', 'd') == event_end_date | date('U') | format_date('custom', 'd') %}


From the above code, we are doing a few things. First, we convert the UTC ISO formatted date into a Unix timestamp and then from there, we leverage a custom format to compare the event start and end day using Twig's comparison operator, ==.

If this is true, then we write the twig code as:


{# Check for and render a single day date. #}
  {{ event_start_date | date('U') | format_date('custom', 'M d Y') }}


… which will render like this Feb 29 2020. Next, we will add some logic if the event is muti-day and takes place within the same month:


{# If the start date month and end date month match. #}
{% elseif event_start_date | date('U') | format_date('custom', 'M') == event_end_date | date('U') | format_date('custom', 'M') %}
  {{ event_start_date | date('U') | format_date('custom', 'M d - ') }}
  {{ event_end_date | date('U') | format_date('custom', 'd Y') }}


For the above code, we once again use a comparison operator to check if the month start and end date is the same. If so, then the date renders within here as Jan 12 - 16 2020. Finally, if the event takes place within two different months, we add the end date month to our custom date formatter:


{# If the start date month and end date month DO NOT match. #}
    {% elseif event_start_date | date('U') | format_date('custom', 'M') != event_end_date | date('U') | format_date('custom', 'M') %}
      {{ event_start_date | date('U') | format_date('custom', 'M d - ') }}
      {{ event_end_date | date('U') | format_date('custom', 'M d Y') }}


This will render as Jan 29 - Feb 03 2020. And there you have it, nicely formatted custom event dates all within a Twig template.

The image above shows the finished event listing The image above shows the finished event listing

Summary

I should note that Twig's custom date formats draw from PHP datetime so when you see something like format_date('custom', 'M d Y'), those time formats might seem familiar. Coding up dates in Twig in this manner was a great learning experiment for me. As with all things Drupal, there are so many different ways to achieve the same end result so I am sure there are no doubt other ways to do this. In fact, probably the Date and time UI within Drupal would probably suffice in most cases as you can create custom date formats in there as well. In the end, this was a great learning experience for me.

Resouces

Tags

Drupal 8 Campaign Builder

Jan 30 2020
Jan 30
Jan 29 2020
Jan 29

With growth comes changes and today we're introducing changes to our legal terms and pricing. The basic susbcription remains the same at $78 USD per year and the Professional subscription was bumped from $249 to $360 USD per year. The Enterprise subscription now starts at $3000 with a $1000 USD set-up fee which is needed for the one-time job of collecting brand logos and brand names and setting up our scripts to produce the white-labeled/re-branded products automatically. The Enterprise subscription will now be charged per month rather than per year.

New terms of service: https://www.sooperthemes.com/legal/terms
Services catalog:  https://www.sooperthemes.com/legal/services-catalog

Drupal is becoming more valuable but more expensive

3 years after Drupal 8's release the results are in: Drupal is still relevant but Drupal 8 is more expensive to implement and Drupal's adoption curve has tapered off. I don't think this is necessarily bad. Drupal's leadership made a decision to make Drupal the best Enterprise-grade CMS, not the best everyman's CMS. The result is that Drupal's steep learning curve became steeper yet, and costs of training and hiring Drupal developers increased accordingly. Our price bump is not merely a reaction to a decrease in the volume of Drupal websites in need of our solutions, it is also part of our learning process. 

Sooperthemes is growing but it is not growing enough

Since our Drupal 8 launch last year business at Sooperthemes is better than ever. But with our growing popularity comes a big increase in workload from the customer support forum, customer success tasks, and managing simple tasks like account administration, taxes, sales questions. It adds up to a lot of work. Currently our prices are too low for the increase in customers to pay for new staff to take on the additional workload. We have been investing a lot of effort in training interns but the time has come to move to a more sustainable solution.

Without changes Sooperthemes is not ready for the future. This price increase in the Professional subscription is one part of our strategy for sustainable growth.

Another change is getting better at charging big clients more than small clients. We want to keep our products accessible to the entire Drupal community. While we love our enterprise clients. we don't want to develop an amazing product just for the Drupal elite who can afford hundreds or thousands of dollars per month per site. Therefore we're introducing new licensing terms to charge users based on the scale of their usage of our flagship product Glazed Builder.

We updated our terms for us to be able to charge websites fairly not just by the number of domain (site) licenses, but also by the number of users who are using our Glazed Builder product. Some examples to illustrate why I think this is fair.

  1. Freelance Music teacher's website with 1 domain license: $78 USD per year including updates and support.
  2. An Drupal agency with currently 10 clients on our products: $360 USD per year.
  3. A fast-moving consumer goods enterprise with 40 enterprise domain licenses: ~3000 USD per month.
  4. If Tesla.com would use our products for their marketing content, job portal, community forum, online stores, online tools, in 37 languages: $78 USD per year, or 6 dollars and 50 cents per month.

I think the last example illustrates why it makes sense to introduce this new lever to help Sooperthemes grow sustainably.  To learn how exactly our new licensing term works make sure to read our services catalog.  

Provide More Value To Enterprise Clients

In order for Sooperthemes to be successful in the future we will need to work on signing on more Enterprise clients. We're going to work on adding more features that are important to enterprise clients. Starting today we offer better support options and dedicated support developers to cases in the Enterprise tier. If you want to share ideas on what you think should differentiate the Enterprise subscription tier from the other tiers don't hesitate to send me an email here: https://www.sooperthemes.com/contact

I would be especially interested in hearing what it would take for your business to purchase an enterprise subscription.

Jan 28 2020
Jan 28

Due to the nature of B2B sales, one of my roles is cold outreach. Most of the time my first method of outreach garners no replies. However, every so often I will receive a prompt email message or reply over the phone. It usually goes something along the lines of: “We already have a web development agency.” or “We are not interested.” I often wish I was at a sit-down meeting when these situations arise. This is because I simply cannot describe the multi-faceted solutions Drupal can provide, far and above a typical web development agency. “You should absolutely stay with them” is my typical response to prospects that have an agency they are happy with. I say this because there is so much more that Drupal, as a business solution, can provide without even interacting with the frontend of their website. What we often promote with Drupal is its capability to create a more complete digital experience platform (DXP), not just a website.

What Gartner has to say about the DXP

In a 2019 report, Gartner has this analysis about DXPs:

“Driven by digital transformation efforts, organizations are moving beyond the traditional audience engagement resources of websites and mobile apps. There is a growing acceptance of the idea of digital experience platforms as vital to these efforts. DXPs provide a scalable foundation for creating, optimizing, integrating, delivering and managing a range of digital experiences for different audiences, both internal and external.1”

So let me unpack that a little bit in my own words. Essentially, your website and mobile apps are still very much at the forefront of digital marketing. Moving forward, though, more organizations have and will continue to create a more cohesive, single platform (DXP) in order to cater to all stakeholders of the company. This not only includes said organizations’ customers but also their teams and employees, allowing for a more comprehensive snapshot of the company from the outside and inside. In the same report, Gartner estimates that:

“Through 2021, 85% of the effort and cost involved in a digital experience platform (DXP) program will be spent on integrations with internal and external systems, including the DXP’s own, built-in capabilities.1”

In my opinion, this assumption by Gartner indicates that organizations are already well aware of the advantages a DXP can provide. 

Don't wreck digital engagement with bad deployment decisions Use Drupal and Drupal Commerce for your digital experience platform >

An imaginary business case for a DXP

Imagine you started a business selling gadgets. Your gadgets were better for target market X because they were less complicated than the gadgets that were available on the market at the time. So first off, you rented a storefront and sold the gadgets in your store, but you also realized you could scale your business by selling the same gadgets online. So in addition to your point of sale system (POS), you now had to adopt an appropriate ecommerce platform and build a website to sell the gadgets online.

Now that you were selling gadgets online you also had to have a shipping channel and a returns channel for replacing defective gadgets. As demand for your product began to grow you needed more gadgets on hand at any given time. The obvious solution was a warehouse, but you also needed a product information management (PIM) system to keep on top of your inventory and distribution channels.

As your product created a name for itself you opened a few more gadget stores and to satisfy demand across the globe you began selling your product through Amazon. With increased demand came competition, so in response, you invested in marketing software to stay on top of the industry trends. You began to diversify in order to make your business more resilient to market volatility. The diversification led to custom gadgets in addition to a gadget service and repair business.

In order to keep track of what your customers had purchased and to identify opportunities for cross-selling and up-selling, you invested in a customer relationship management (CRM) system. Finally, just under a year ago you invested in a new enterprise resource planning (ERP) system. This way all of your new departments had the information they needed to operate efficiently.

So we are now in the present day. Like many other businesses that grew at a rapid pace, you find yourself in a situation where all of your technology has become siloed. In this analogy, your data and information all exist, but it is locked away in separate silos. Each silo represents a piece of software, a distribution channel, a legacy POS system, or that missing Amazon integration that can only be accessed from one place. You can run a business this way, and many organizations do just that, without realizing that there is actually a more efficient way to do things. This is where the DXP comes into play. What you would prefer rather than individual silos would be a horizontal technology architecture with open lines of communication between everything. This, as one could imagine, can save a tremendous amount of time and manual workflows, eliminating what we call swivel-chair processes. Simply stated it is a more efficient way of doing business. The problem is many business owners and decision makers may not even realize this is happening because they live in their own silos and no one has pointed it out to them.

How does Drupal come into play?

Drupal is a content management system (CMS), but at the same time, Drupal can do so much more than a traditional CMS. Through API integrations, also known as API hooks, Drupal has the ability to be used as middleware. As middleware, Drupal can act as a modular engine that connects all the data from the aforementioned gadget business’ technology. Data can flow forwards and backward between the various pieces of technology and even integrate into legacy systems like the POS in the gadget example. Furthermore, the modular nature of Drupal middleware essentially future proofs your business allowing for business scalability.

Drupal as middleware example

To give an analogy, you can think of Drupal middleware as a computer with unlimited USB ports. The computer acts as the brain passing information back and forth between systems and the USB ports are the API hooks. USB ports are non-proprietary and you can, therefore, unplug cables you no longer need and replace them with new cables. You can also add or remove cables as necessary and the computer keeps on functioning as long as you configure the drivers. So as you outgrow software systems or you decide to replace that legacy POS, no problem because you can just plug in the new software, install the drivers, and you are back up and running again.

Connecting it all together

How to patch digital gaps in a growing business Find out how Drupal can improve customer experiences and streamline backend operations.So to return to my statement at the beginning of this blog post, the reason I wish I could sit down with those who respond so quickly to my first cold outreach is that I do not want to be typecast as just another web development agency. In actual fact, because our expertise lies in Drupal we are far better positioned to provide solutions that lay beyond the scope of the traditional idea of a website. Sure we can develop an incredibly robust frontend experience and, likewise, a flexible scalable ecommerce engine. But, we can also use Drupal as middleware that allows for seamless flow of information between systems.

If you've read this and would like to have a quick chat, let us know! We're happy to help. I also mentioned a Gartner report from 2019 that is a great introduction for anyone trying to nail down their digital experience platform.

While this report is no longer available, we invite you to reach out to us at any time to discuss how connecting your systems through middleware can improve your business operations and income. 

1 - Gartner, "Don’t Wreck Digital Engagement With Bad Deployment Decisions for Your Digital Experience Platform,” 31 July 2019, Gene Phifer.

Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

Jan 23 2020
Jan 23

Due to the cancellation of DrupalCon Minneapolis and the announcement of DrupalCon Global, nominations for the 2020 Aaron Winborn Award will remain open until June 1, 2020. The winner will be announced during DrupalCon Global.

The Drupal Community Working Group is pleased to announce that nominations for the 2020 Aaron Winborn Award are now open. 

This annual award recognizes an individual who demonstrates personal integrity, kindness, and above-and-beyond commitment to the Drupal community. It includes a scholarship and stipend for the winner to attend DrupalCon and recognition in a plenary session at the event.

Nominations are open to not only well-known Drupal contributors, but also people who have made a big impact in their local or regional community. If you know of someone who has made a big difference to any number of people in our community, we want to hear about it. 

This award was created in honor of long-time Drupal contributor Aaron Winborn, whose battle with Amyotrophic lateral sclerosis, or  ALS (also referred to as Lou Gehrig's Disease)  came to an end on March 24, 2015. Based on a suggestion by Hans Riemenschneider, the Community Working Group, with the support of the Drupal Association, launched the Aaron Winborn Award.

Nominations are open until Monday, June 1, 2020. A committee consisting of the Community Working Group core team as well as past award winners will select a winner from the nominations. Current members of the CWG's core team and previous winners are exempt from winning the award.

Previous winners of the award are:

  • 2015: Cathy Theys
  • 2016: Gábor Hojtsy
  • 2017: Nikki Stevens
  • 2018: Kevin Thull
  • 2019: Leslie Glynn

Nominations for the 2020 award are now closed.

Jan 23 2020
Jan 23

In the Drupal support world, working on Drupal 7 sites is a necessity. But switching between Drupal 7 and Drupal 8 development can be jarring, if only for the coding style.

Fortunately, I’ve got a solution that makes working in Drupal 7 more like working in Drupal 8. Use this three-part approach to have fun with Drupal 7 development:

  • Apply Xautoload to keep your PHP skills fresh, modern, and compatible with all frameworks and make your code more reusable and maintainable between projects. 
  • Use the Drupal Libraries API to use third-party libraries. 
  • Use the Composer template to push the boundaries of your programming design patterns. 

Applying Xautoload

Xautoload is simply a module that enables PSR-0/4 autoloading. Using Xautoload is as simple as downloading and enabling it. You can then start using use and namespace statements to write object-oriented programming (OOP) code.

For example:

xautoload.info

name = Xautoload Example
description = Example of using Xautoload to build a page
core = 7.x package = Midcamp Fun

dependencies[] = xautoload:xautoload

xautoload_example.module

<?php use Drupal\xautoload_example\SimpleObject; function xautoload_example_menu() { $items['xautoload_example'] = array( 'page callback' => 'xautoload_example_page_render', 'access callback' => TRUE, ); return $items; } function xautoload_example_page_render() { $obj = new SimpleObject(); return $obj->render(); } useDrupal\xautoload_example\SimpleObject;functionxautoload_example_menu(){  $items['xautoload_example']=array(    'page callback'=>'xautoload_example_page_render',    'access callback'=>TRUE,  return$items;functionxautoload_example_page_render(){  $obj=newSimpleObject();  return$obj->render();

src/SimpleObject.php

<?php namespace Drupal\xautoload_example; class SimpleObject { public function render() { return array( '#markup' => "<p>Hello World</p>", ); } } namespaceDrupal\xautoload_example;classSimpleObject{  publicfunctionrender(){    returnarray(      '#markup'=>"<p>Hello World</p>",    );

Enabling and running this code causes the URL /xautoload_example to spit out “Hello World”. 

You’re now ready to add in your own OOP!

Using Third-Party Libraries

Natively, Drupal 7 has a hard time autoloading third-party library files. But there are contributed modules (like Guzzle) out there that wrap third-party libraries. These modules wrap object-oriented libraries to provide a functional interface. Now that you have Xautoload in your repertoire, you can use its functionality to autoload libraries as well.

I’m going to show you how to use the Drupal Libraries API module with Xautoload to load a third-party library. You can find examples of all the different ways you can add a library in xautoload.api.php. I’ll demonstrate an easy example by using the php-loremipsum library:

1. Download your library and store it in sites/all/libraries. I named the folder php-loremipsum. 

2. Add a function implementing hook_libraries_info to your module by pulling in the namespace from Composer. This way, you don’t need to set up all the namespace rules that the library might contain.

function xautoload_example_libraries_info() { return array( 'php-loremipsum' => array( 'name' => 'PHP Lorem Ipsum', 'xautoload' => function ($adapter) { $adapter->composerJson('composer.json'); } ) ); } functionxautoload_example_libraries_info(){  returnarray(    'php-loremipsum'=>array(      'name'=>'PHP Lorem Ipsum',      'xautoload'=>function($adapter){        $adapter->composerJson('composer.json');      }

3. Change the page render function to use the php-loremipsum library to build content.

use joshtronic\LoremIpsum; function xautoload_example_page_render() { $library = libraries_load('php-loremipsum'); if ($library['loaded'] === FALSE) { throw new \Exception("php-loremipsum didn't load!"); } $lipsum = new LoremIpsum(); return array( '#markup' => $lipsum->paragraph('p'), ); } usejoshtronic\LoremIpsum;functionxautoload_example_page_render(){  $library=libraries_load('php-loremipsum');  if($library['loaded']===FALSE){    thrownew\Exception("php-loremipsum didn't load!");  $lipsum=newLoremIpsum();  returnarray(    '#markup'=>$lipsum->paragraph('p'),

Note that I needed  to tell the Libraries API to load the library, but I then have access to all the namespaces within the library. Keep in mind that the dependencies of some libraries are immense. You’ll very likely need to use Composer from within the library and commit it when you first start out. In such cases, you might need to make sure to include the Composer autoload.php file.

Another tip:  Abstract your libraries_load() functionality out in such a way that if the class you want already exists, you don’t call libraries_load() again. Doing so removes libraries as a hard dependency from your module and enables you to use Composer to load the library later on with no more work on your part. For example:

function xautoload_example_load_library() { if (!class_exists('\joshtronic\LoremIpsum', TRUE)) { if (!module_exists('libraries')) { throw new \Exception('Include php-loremipsum via composer or enable libraries.'); } $library = libraries_load('php-loremipsum'); if ($library['loaded'] === FALSE) { throw new \Exception("php-loremipsum didn't load!"); } } } functionxautoload_example_load_library(){  if(!class_exists('\joshtronic\LoremIpsum',TRUE)){    if(!module_exists('libraries')){      thrownew\Exception('Include php-loremipsum via composer or enable libraries.');    $library=libraries_load('php-loremipsum');    if($library['loaded']===FALSE){      thrownew\Exception("php-loremipsum didn't load!");

And with that, you’ve conquered the challenge of using third-party libraries!

Setting up a New Site with Composer

Speaking of Composer, you can use it to simplify the setup of a new Drupal 7 site. Just follow the instructions in the Readme for the Composer Template for Drupal Project. From the command line, run the following:

composer create-project drupal-composer/drupal-project:7.x-dev <YOUR SITE DIRECTORY> --no-interaction

This code gives you a basic site with a source repository (a repo that doesn’t commit contributed modules and libraries) to push up to your Git provider. (Note that migrating an existing site to Composer involves a few additional considerations and steps, so I won’t get into that now.)

If you’re generating a Pantheon site, check out the Pantheon-specific Drupal 7 Composer project. But wait: The instructions there advise you to use Terminus to create your site, and that approach attempts to do everything for you—including setting up the actual site. Instead, you can simply use composer create-project  to test your site in something like Lando. Make sure to run composer install if you copy down a repo.

From there, you need to enable the Composer Autoload module , which is automatically required in the composer.json you pulled in earlier. Then, add all your modules to the require portion of the file or use composer require drupal/module_name just as you would in Drupal 8.

You now have full access to all the  Packagist libraries and can use them in your modules. To use the previous example, you could remove php-loremipsum from sites/all/libraries, and instead run composer require joshtronic/php-loremipsum. The code would then run the same as before.

Have fun!

From here on out, it’s up to your imagination. Code and implement with ease, using OOP design patterns and reusable code. You just might find that this new world of possibilities for integrating new technologies with your existing Drupal 7 sites increases your productivity as well.

Jan 19 2020
Jan 19

The Drupal Community Working Group is happy to announce that we are once again teaming up with Otter Tech to offer live, monthly, online Code of Conduct enforcement training for Drupal Event organizers and volunteers in 2020.

During the second half of 2019, 17 Drupal community members completed the training (see full list), helping to ensure Drupal events world-wide have qualified Code of Conduct contacts. We are excited to be able to provide support for the training in 2020.

The training is designed to provide "first responder" skills to Drupal community members who take reports of potential Code of Conduct issues at Drupal events, including meetups, camps, conventions, and other gatherings. The workshops will be attended by Code of Conduct enforcement teams from other open source events, which will allow cross-pollination of knowledge with the Drupal community.

Each monthly online workshop is the same; community members only have to attend one monthly workshop of their choice to complete the training.  We strongly encourage all Drupal event organizers to consider sponsoring one or two persons' attendance at this workshop.

The monthly online workshops will be presented by Sage Sharp, Otter Tech's CEO and a diversity and inclusion leader in the open source community. From the official description of the workshop, it will include:

  • Practice taking a report of a potential Code of Conduct violation (an incident report)

  • Practice following up with the reported person

  • Instructor modeling on how to take a report and follow up on a report

  • One practice scenario for a report given at an event

  • One practice scenario for a report given in an online community

  • Discussion on bias, microaggressions, personal conflicts, and false reporting

  • Frameworks for evaluating a response to a report

  • 40 minutes total of Q&A time

In addition, we have received a Drupal Community Cultivation Grant to help defray the cost of the workshop for those that need assistance. The standard cost of the workshop is $350, Otter Tech has worked with us to allow us to provide the workshop for $300. To register for the workshop, first let us know that you're interested by completing this sign-up form - everyone who completes the form will receive a coupon code for $50 off the regular price of the workshop.

For those that require additional assistance, we have a limited number of $100 subsidies available, bringing the workshop price down to $200. Subsidies will be provided based on reported need as well as our goal to make this training opportunity available to all corners of our community. To apply for the subsidy, complete the relevant section on the sign-up form. The deadline for applying for the subsidy is end-of-business on Wednesday, July 1, 2020 - those selected for the subsidy will be notified after this date (in time for the July 8, 2020 workshop).

The workshops will be held on:

Those that successfully complete the training will be (at their discretion) listed on Drupal.org (in the Drupal Community Workgroup section) as a means to prove that they have completed the training. We feel that moving forward, the Drupal community now has the opportunity to have professionally trained Code of Conduct contacts at the vast majority of our events, once again, leading the way in the open source community.

We are fully aware that the fact that the workshops will be presented in English limit who will be able to attend. We are more than interested in finding additional professional Code of Conduct workshops in other languages. Please contact us if you can assist.

Jan 14 2020
Jan 14

Content management systems (CMSs) are the engine that drive content creation on the web today. They form the foundation that we build on for publishing and sharing information, creating digital experiences and conducting online retail. WordPress and Drupal are staples in the CMS world and they have both been around a long time. WordPress is known for its intuitive and easy-to-use interface. Drupal is known for its flexibility and complexity. While both have their strengths and weaknesses, the usability gap between WordPress and Drupal is changing. This article will show you the current state of Drupal’s admin user experience in a side-by-side comparison with WordPress, the most widely used CMS. If you’re familiar with one CMS but not the other, this comparison is also a good introduction to the other.

TL;DR: The primary goal of this article is to dispel the perception that Drupal is widely different and harder for administrators to use than WordPress. If you don’t care about the background behind this perception, just skip down to the direct comparison.

WordPress is easy, Drupal is hard… why does this perception exist

But first, a little background. The dominant CMS in terms of number of sites running on it is WordPress. It’s estimated to power about 62% of all websites that use a CMS, meaning multiple millions of websites are using it. Why is WordPress so popular? WordPress started as a blogging engine with a focus on being easy-to-use. This proved to be incredibly important because it meant that nearly anyone could get a WordPress site up and running fast and be able to use it with little-to-no training. The idea caught fire with both individuals and local businesses who just wanted a simple, low-cost website that others could find online. Web developers and agencies also finally had a framework that allowed their clients to make simple content edits within an admin environment that was friendly. Of course, WordPress today can be used for much more than a simple website, but it is still ideal for simple websites. Another key takeaway here is this perception of WordPress as being easy-to-use. This reputation holds true just as much today as it ever did in the past.

This article isn’t actually meant to praise and promote WordPress. Instead, much of this article will focus on another popular CMS, Drupal. Drupal is a fantastic CMS and is incredibly powerful when used correctly. In many web development circles, Drupal is the go-to solution for providing a robust solution for today’s CMS driven website development. It’s thriving both in usage and as a community of enthusiasts, but while WordPress sits in #1 spot with 62% of the market share, Drupal holds steady at #3 with about 3%. It still means there are many hundreds of thousands of websites powered by Drupal, but the number of websites using it pales in comparison to WordPress.

Why isn’t Drupal more popular? Well, anyone who knows Drupal (and even many who don’t) will tell you that Drupal is best suited for large websites with high traffic and complex requirements. Universities, government, nonprofits and online retailers are a sample of who uses Drupal. Drupal out-of-the-box isn’t as ready to use as WordPress, so it’s unlikely a suitable fit for simple websites. For individuals, configuring Drupal is a steep learning curve. For local web agencies, it takes more time to setup which means they must charge more. These reasons alone largely take Drupal out of the running for many websites, so for Drupal it’s more about use case than mass adoption.

With that said, Drupal’s ability to be configured and developed on literally means it can handle nearly any situation required of it, whether that means selling products for enterprise businesses or being the integration layer between multiple platforms. While this inherent flexibility is great for software developers, Drupal’s perception of complexity combined with a historically underwhelming admin experience has cemented a reputation that Drupal is unintuitive and difficult to use for the end user, the people who will be using it every day. While in my opinion this isn’t true of today’s Drupal, like WordPress it’s reputation precedes it. In Drupal’s case, however, this reputation isn’t as flattering and it’s something that our sales and outreach teams battle with often.

For Drupal, it’s time for change

Like WordPress, Drupal is open source software. It’s free to use and anyone has full access to the underlying code to modify and build upon. Both platforms have a core team for advancing key initiatives and a massive community of individuals and organizations that support the initiatives while also adding additional functionality through plugins (WordPress lingo) or modules (Drupal lingo).

While usability has always been important to WordPress (since it started as a blogging platform), Drupal was historically more focused on being open and flexible. It’s user experience has continuously improved with each version release, but late in 2018 marked the beginning of a big push towards modernizing the Drupal admin user interface (UI). Drupal is really amazing software and it’s time that the admin experience catches up.

Introducing Claro, Drupal’s new admin UI

Drupal 8 Claro admin theme
Claro interface design mockup courtesy of Drupal.org

Claro is the new admin theme being built as part of the Admin UI Modernization initiative. It’s included with every Drupal 8 site, new and old, and can be enabled right now if you so choose. Just be aware that it is currently considered “experimental” while progress continues to be made. It’s not yet in its finished state, but you can view the development roadmap here to see what is still left to do.

Side-by-side: WordPress & Drupal Admin UI Comparison

On to the comparison!

For WordPress, I’m using version 5.3.2 (released Dec. 18, 2019) which comes with its own Twenty Twenty default theme and content.

For Drupal, I’m using version 8.8.1 (also released Dec. 19, 2019. How about that!) and the new, but experimental, Claro admin theme. If you’re looking at this at a later date, some aspects may be different (for the better!) as development of the theme continues. I’ve also installed Drupal using the official Umami demo install profile so that I have a theme and some content to work with.

In each of the 10 comparison categories below, I’ll give my opinion on which CMS has the edge out-of-the-box and why I think this. I’ve used both platforms and do have some bias towards Drupal, but I’ll do my best to keep that in check.

Category quicklinks
  1. Admin toolbar
  2. Login dashboard
  3. Managing media
  4. Creating pages
  5. Editing pages
  6. Managing widgets and blocks
  7. Managing menus
  8. Managing users, roles and permissions
  9. Site status report
  10. Plugins and modules
  11. WordPress & Drupal comparison summary

1. Admin toolbar

The admin toolbar is always present on the page of both WordPress and Drupal.

WordPress

WordPress admin toolbar

In WordPress, a single toolbar is used as a jump-off point for common admin pages, but you can also start the content creation process and access your account profile and information.

Drupal

Drupal 8 admin toolbar

Drupal has a similar admin toolbar except you have access to everything including creating new content. Every admin page that your user role has permission to view is available through this menu. While it’s more to look at initially, experienced users enjoy fewer clicks to get where they want to go.

Edge: Drupal

While the learning curve to know where everything is might be a bit steeper, experienced Drupal users enjoy being able to access everything in one familiar way. With that said, new users may find this larger menu intimidating.

2. Login dashboard

After logging in, the login dashboard is the first page you see. WordPress and Drupal both take a different approach to their login dashboard.

WordPress

WordPress login dashboard

WordPress has a robust dashboard right out of the gate. This dashboard takes admins away from the site frontend and into an interface that only they can see. The left side has a larger menu for accessing the rest of the admin interface. The main content area mix of useful information about your site and information specific to WordPress as a whole, such as training resources and upcoming WordPress events. The panes on this page can be toggled on and off and plugins can add new panes.

Drupal

Drupal 8 login dashboard

This is the first area where Drupal takes a different approach. Instead of a robust dashboard, you don’t actually get much of anything. The admin toolbar already gives you access to the entire site, so Drupal keeps you on the website frontend and instead shows you your “user page”. This page is entirely customizable although you will most likely need third-party or IT support to do so. It’s an open canvas to do with as you like. For ecommerce, you might show a customer their information, recently viewed products and their last order placed. For content creators, you might show a custom dashboard with quick links to their common tasks. What you do here is entirely up to you.

Edge: WordPress

Although it’s not entirely useful, WordPress actually has a dashboard which is a nice touch for new users. Drupal's clean slate offers a lot of exciting potential for admins and visitors alike, but any potential must first be realized before this page is useful.

3. Managing media

Images, videos, documents and more are uploaded and organized within a media manager. Both WordPress and Drupal offer a convenient content editor plugin which makes selecting and adding media into content easy.

WordPress

WordPress media manager

WordPress really defined the way media can be managed within a CMS. Their interface for managing media contains a handy drag-to-upload feature and each piece of media is shown in a grid format by default. Media can be filtered by date, type and name.

Drupal

Drupal 8 media manager

Drupal admittedly isn’t as clean as WordPress in this interface yet but it’s functionality is essentially the same and solid for most users. The visual interface will improve as the development of Claro progresses. By default, Drupal displays media in a list, but you can toggle between list and grid. There are also similar filtering options. Like all other aspects of Drupal, advanced users can customize media types beyond what you see here and entirely new media types can be created. This advanced functionality is unique to Drupal and isn’t as easily done in WordPress.

Edge: WordPress

WordPress does a great job of making media easy to manage. Drupal will continue to see improvements in the near future, but right now it still feels clunky.

4. Creating pages

Creating new pages, such as general content pages and blog posts, is a common interaction that most admin users will need to do.

WordPress

WordPress new page Gutenberg editor

As of version 5.0, WordPress includes their much anticipated Gutenberg editor experience. This editing format is sleek, modern, and very intuitive. You start with a title and then continue piecing together chunks of content by selecting various types of “blocks” to build the page with. Blocks are a single, reusable type of content such as a heading or paragraph of text, an image or gallery, a list, a quote, etc. Custom blocks can be created and plugins may also add additional blocks that content creators can use. Along the right side of the page is a settings pane. This pane provides various page specific settings and customizations such as page visibility, featured image, an option to allow comments, etc. Additional settings for the currently selected content block also appears here.

Drupal

Drupal 8 new page creation

Out-of-the-box, creating a new piece of content looks like the screenshot above. Content in Drupal could potentially be something wildly different than just a basic page, so Drupal defaults to a standard “field based” editing interface where the different fields that are configured to make up the content are laid out on the page. All editors need to do is fill in the blanks. Field types can be text (with an optional WYSIWYG editor), and image, a file upload, a date, and anything else you can imagine. This again is where Drupal’s flexibility is both an advantage and a curse. The advantage is that a type of content can be anything you can imagine, but the downside is that someone has to configure that content type first. The field based editing experience is provided by default to ensure the editing experience is consistent across different content types.

Here’s the important thing to know about Drupal. Drupal doesn’t like to make assumptions as to what your editing experience should be. As an example, a used car dealership, a national newspaper, and an online retailer will all have entirely different content editing requirements. Drupal doesn’t want to get in your way and it doesn’t try to. What it does do is give you a solid foundation to create YOUR ideal editing experience. This might not be ideal for organizations and businesses with simple website requirements, but for those with complex workflows and unique requirements, Drupal is ideal.

One last important note to make on this topic is that Drupal does also have a Gutenberg editing experience, it just doesn’t come packaged with Drupal out-of-the-box. This module and other editing interface modules and initiatives can be installed in Drupal to make the default editing experience more capable and modular.

Edge: WordPress

When based solely on out-of-the-box functionality, WordPress pre-packaged Gutenberg editing experience is modern and intuitive for new and experienced users. However, it’s important to note that Drupal modules exist that greatly improve Drupal’s default experience. You can even add the same Gutenberg experience.

5. Editing pages

Once a page has been created, sometimes you still need to go back and edit it once in a while. This is a different experience from creating new content, so let’s now look at how it works with each CMS.

WordPress

WordPress editing existing pages

Pretty standard, as a logged in administrator you have access to editing content by viewing the page on the website frontend and using one of the various “edit” buttons. You’re then brought to the same Gutenberg interface that you see when creating content.

Drupal

Drupal 8 edit existing pages

I would say Drupal has the upper hand for editing existing content. Similar to WordPress, as a logged in administrator you have access to page edit links when viewing the content which brings you back to the same interface as when the content was created. However, in Drupal you also have additional links to view content revisions as well as the view and edit page translations for multi-language sites.

Drupal 8 inline page editor

The current version of Drupal, Drupal 8, also includes an additional edit icon that contains a new “quick edit” option. Depending on the content, the quick edit allows on-page inline editing (shown above) instead of taking you to a separate page! This makes simple edits quick and easy. Furthermore, the edit icon also appears when administrators hover over menus and other configurable page elements too, giving you a quick way to access their configuration.

Edge: Drupal

While WordPress has the edge when creating new content, Drupal’s on-page inline editing feature makes editing existing content quick and easy by keeping content editors on the website frontend.

6. Managing widgets and blocks

Widgets (WordPress lingo) and blocks (Drupal lingo) are two words for essentially the same thing. While not limited to these locations, the header, footer and often left and right columns beside the main content area contain defined regions where certain elements can be placed. I’m talking about slogans, menus, a search bar, your copyright, recent posts, social feeds, etc. WordPress and Drupal have similar but different ways to manage these elements.

WordPress

WordPress widgets page

WordPress includes a backend and frontend methods for editing page widgets, both of which are quite basic and lack a lot of real capability.

The backend method (shown above) is accessed through the backend Appearance menu. This page gives you a nice list of available widgets on the left side and another list of active widgets within the available regions on the right. A simple drag and drop interface lets you move elements around and opening each widget allows for basic configuration.

WordPress widgets live editor

The frontend method is through a "Live Preview" mode (shown above) where a version of the site theme is presented and widgets are managed through the left column. Settings for existing widgets can also be quickly opened by clicking its blue edit icon, as you can see in the image above.

Out-of-the-box, it’s difficult to understand exactly where a widget will appear throughout the site because you don’t have the ability to see or control which pages accept the widget. Some third-party plugins are available to give you this functionality, but they must be added. New widgets are also a bit more difficult to add as they must be created by a developer or added though a plugin.

Drupal

Drupal 8 block layout page

Like WordPress, Drupal has the ability to manage blocks from both the backend and frontend of the website, although Drupal handles both situations better.

The backend method (shown above) is accessed through the admin toolbar’s Structure menu. Here you can view all available regions and the blocks contained within each. Regions are a big part of Drupal theme creation, so you will often see 10+ available regions to choose from. If you’re not sure of your themes regions, the “Demonstrate block regions” link above the list of regions will give you a preview. Each region has a “Place block” button for adding new pre-configured blocks. Existing blocks can be moved dragged between regions and each block can be configured independently. Block configuration in Drupal is very robust, including but not limited to control over what pages the block is visible on and what account roles can view it. Like content, blocks can be translated and even have revisions.

Custom blocks can also be created by more advanced Drupal users in a similar way that new media and content types are created. In the screenshot above there is a link to the “Custom block library,” which is where new blocks can be created. Like WordPress, modules can also be installed which will add new blocks.

Drupal 8 frontend block quickmenu

Drupal’s frontend method for managing blocks takes on the same familiar editing experience that we discussed for editing content. When logged in and viewing the website frontend, navigating to a page and hovering your cursor over an element will reveal an edit icon if that element is a configurable block. Options for the block are then given. The block in the screenshot above contains a menu, so we see options to configure the block and edit the menu. In this case, clicking one of these options will take you to the backend page for performing these actions. If the block contained text, we would also be given an option to edit the text directly on the page, just like we can with content.

Edge: Drupal

Simply put, Drupal’s block management is robust yet not too difficult. Being able to manage existing blocks directly from the website frontend is both user friendly and familiar given that existing pages can also be managed in the same way.

7. Managing menus

Menus connect the pages within a website. Commonly you’ll find a primary navigation and some sort of footer menu, but menus are used in many other places as well.

WordPress

WordPress menu management

The menu system in WordPress is a bit strange at first, but overall it’s pretty simple. You create a menu (or select an existing one using the menu selection dropdown), then add links by selecting pages, categories, or by creating custom links (add menu items in image above), then use a drag and drop interface for moving and nesting the menu items (menu structure in image above). Each menu item within the menu structure can be opened for a bit of customization.

The menu settings area controls where the menu is displayed within predefined template locations. Just check the box and the menu will appear once saved. Any menu created here can also be assigned to region as a widget or through the template live preview screen.

One odd thing I’ve found with WordPress is that, when editing a page, you’re not able to add it into a menu. I’m sure there are plugins that allow this, but out-of-the-box you have to add the page through the menu system or check a setting within the menu that all new pages get added… but then you might have to remove some.

Drupal

Drupal 8 menu management

Drupal’s approach to menus is what I would consider more standard. You navigate the “menus” page which lists all of the menus that have been created, then you create a new menu or edit an existing menu. The screenshot above is what you see when editing a menu. Here you manage this menu’s links by either adding a new one or manipulating the existing ones. When adding a new link you can easily search for content that the link will link to or specify a custom link.

Pages can also be added to a menu when the page is being created or edited. Within the page settings, all you do is select the menu and specify a link title.

Like WordPress, once you create a menu you can then add it into a region of the site as a block. However, within the menu itself you don’t have the ability to put the menu anywhere.

Edge: Drupal

A more standard approach makes managing menus clearer and more user friendly. Also being able to choose if a page should be included in a menu while creating the page is a nice feature. That said, I appreciate being able to manage a menu in its entirety on a single page like you do in WordPress.

8. Managing users, roles and permissions

Managing users is common for both controlling who can edit the website and who can login for other reasons, such as non-admin accounts for an online store or community.

WordPress

WordPress user management

WordPress has six predefined user roles: Super Admin, Administrator, Editor, Author, Contributor, and Subscriber. Each has varying degrees of what they can do, but it’s pretty clear for the most part and goes back to when WordPress was mainly a blogging platform. Users can be created and managed through a “users” page (shown above), which is laid out in a straightforward manner displaying

But WordPress has some major drawbacks here. First, WordPress doesn’t have any frontend user self-management, meaning users can’t view or edit their own profiles. Second, the predefined roles and their associated permissions don’t work for everyone and actually complicate user management when you don’t need it. Third, there is nowhere to really manage role permissions in a granular way. These drawbacks can be fixed through custom development and/or various plugins, but many consider this to be a general weak point of WordPress.

Drupal

Drupal 8 user management

User management is another area where Drupal shines. In contrast to WordPress, Drupal only starts with three default roles: Anonymous, Authenticated and Administrator. Anonymous is a user who is not logged in, authenticated is a user who has an account but isn’t someone who typically isn’t managing content and site configuration, and administrator is a user with full site and admin access. These three roles are minimal, clear and cover all of the basic needs of most sites. If and when another role with different permissions are created, this is easy to do right out-of-the-box.

The image above shows Drupal’s version of the current list of users. It follows a similar look and style to the rest of the admin pages, giving administrators a place to add and manage user accounts, including assigning users to specific roles. Anonymous and authenticated users can also create or manage their own account through the website frontend (although this functionality can be turned off if desired).

Drupal 8 user permissions page

Drupal’s strength in user management comes in the form of roles and permissions. When a role is created, a column of permission checkboxes for the role is added to the Permissions page (shown above). Almost every piece of functionality within Drupal has an associated permission. Simply checking the boxes determines what each role can and can’t do. It’s powerful and easy.

Edge: Drupal

A simple yet powerful user management system combined with frontend self-service functionality gives Drupal a clear edge over WordPress.

9. Site status report

Both WordPress and Drupal include a site status page that gives you information about the website and server configuration as well as an overall health report that outlines any issues. These automated health checks help keep your CMS up-to-date and secure.

WordPress

WordPress site health page

The “Site health” page (shown above) gives you an overall health status and list of any issues. This status page is clean and each item can be expanded for more information, but there is no visual urgency that makes the “2 critical issues” stand out. In my opinion, critical issues should be resolved and so highlighting these issues in some way is a necessary UX improvement.

An info tab at the top of the page can be opened which gives more information about your installation of WordPress, the server, the PHP version, and the database.

Drupal

Drupal 8 status report page

Drupal contains both site information and site health in one “Status report” page (shown above). Like WordPress, this page gives you everything you need to know at a glance about your Drupal installation and the other components that make it run. Here we can also clearly see what errors and warnings have been found and some information on how they can be resolved.

Edge: Drupal

While both WordPress and Drupal have similar pages that show similar information, Drupal’s status report does a better job at laying out the information and visually capturing the severity of any issues.

10. Plugins and modules

Plugins (WordPress lingo) and modules (Drupal lingo) extend core CMS functionality and add new features. Extensions are usually created by third-party developers and released to the platform communities for anyone else to use. Whether it’s to increase performance, enhance SEO capabilities or create an online store, extensions are a powerful way to improve and adapt the CMS platform.

WordPress

WordPress plugins page

Visiting the “Plugins” page (shown above) is a quick way to see what additional plugins are currently packaged with your WordPress installation and can be activated if desired. Plugins shown here all provide some sort of new functionality or feature that is not part of the core WordPress software.

WordPress plugin search page

When you need new functionality, WordPress provides an excellent and convenient plugin library browser (shown above) accessible within the website backend. Here you can search for, view, and install plugins easily with the click of a button.

Drupal

Drupal 8 extend page

Drupal’s module list is where you can see all current extensions, activated or not, for your Drupal installation. The big difference here between WordPress and Drupal is that for Drupal you are able to see all modules installed, even those that are part of the core software. Modules are also nicely grouped which nicely organizes the large list.

Installing new modules isn’t nearly as easy in Drupal. Unlike WordPress, Drupal doesn’t include a module library browser within the backend interface. Instead, users must search for modules within a web browser and manually install them. Finding modules can be difficult if you’re not familiar with the process.

Edge: WordPress

While both platforms have a massive library of extensions, WordPress offers users a much friendlier and intuitive way of finding and installing extensions that users of any skill level can appreciate. This may or may not be an issue for you if you have a capable IT team or development partner, but for small teams WordPress has the clear edge.

WordPress & Drupal comparison summary

I hope after going through this comparison you now have a good understanding of the differences and similarities between WordPress and Drupal. As you can see, both platforms out-of-the-box have different strengths and weaknesses, but it’s important to know that all of the weaknesses can be overcome through platform extensions and experience. In extreme cases, both platforms support custom development to overcome unique problems.

For convenience, here is a quick summary showing which CMS has the edge in the 10 categories compared. However, I would recommend that you go back and read the edge summary for each category, if you haven’t done so already.

Comparison category WordPress Drupal Admin toolbar   ✓ Login dashboard ✓   Managing media ✓   Creating pages ✓   Editing pages   ✓ Managing widgets and blocks   ✓ Managing menus   ✓ Managing users, roles and permissions   ✓ Site status report   ✓ Plugins and modules ✓  

A final word of advice

In my opinion, you shouldn’t be turned off from one platform or the other simply because you’ve heard that one is better or easier to use. Both platforms are mature and constantly improving, user experience is top of mind, and usability gaps have become less of an issue in recent years.

My advice, select the platform you use based on your requirements. WordPress is a great authoring tool and is good for small and medium sized organizations. Drupal is fantastic for medium and large sized organizations or anyone who has complex workflows, products, and/or a need to integrate with other platforms. That’s a pretty general summary, but if you’re considering either of these platforms, first know what your requirements of the platform are and then start talking to the experts for each.

Acro Media is an ecommerce consultation and development agency who can help you in this regard. We specialize in open source ecommerce and a large part of our work is based around Drupal. Drupal typically works better for our clients but we know WordPress, too. If you’re researching your requirements or evaluating your options, hit us up for a quick chat, we would love to help. Otherwise, check out some of these related resources.

Contact Acro Media Today!

Related resources

Jan 07 2020
Jan 07

Happy New Year!!! Our normally scheduled call to chat about all things Drupal and nonprofits will happen Thursday, January 16, at 1pm ET / 10am PT. (Convert to your local time zone.)

This month, in addition to our usual free-for-all, we'll be talking about Drupal and CiviCRM.  Have you got it up and working your Drupal 8 site? For those of us still working in Drupal 7, what can or should we doing to prepare for the inevitable upgrade? What are your favorite resources for working with these two systems?  Come share your experiences!

Feel free to share your thoughts and discussion points ahead of time in our collaborative Google doc: https://nten.org/drupal/notes

We have an hour to chat so bring your best Drupal topics and let's do this thing!

This free call is sponsored by NTEN.org but open to everyone.

REMINDER: New call-in information -- we're on Zoom now!

  • Join the call: https://zoom.us/j/308614035
    • Meeting ID: 308 614 035
    • One tap mobile
      • +16699006833,,308614035# US (San Jose)
      • +16465588656,,308614035# US (New York)
    • Dial by your location
      • +1 669 900 6833 US (San Jose)
      • +1 646 558 8656 US (New York)
  • Follow along on Google Docs: https://nten.org/drupal/notes
  • Follow along on Twitter: #npdrupal

View notes of previous months' calls.

Jan 03 2020
Jan 03

That’s nice, now why are you telling me this?

In you role as a project- or site owner you might not be aware of the implications the “End of Life” announcement has if your site is running on Drupal 7 right now. There are two things you should be aware of:

1. Active development of Drupal 7 stops on the EOL date.

This does certainly not mean that your site will come to a grinding halt on that day, but it does mean that Drupal’s strong points will start to fade going forward. The Drupal Association will no longer provide security releases for Drupal 7, no further development on the core framework will be done and development on the Drupal 7 version of most contributed modules will stop.

Security, flexibility and scalability are often reasons why Drupal was chosen for a project and this clearly has an impact. I knowingly say ”impact” because the robustness of the Drupal project prevents a full stop of support even after the EOL date. A number of partners will be selected to provide paid security support for several years and there will always be members of the community who are prepared to do some work on unsupported contributed modules.

2. Upgrading means migrating.

Upgrading your site from Drupal 7 to Drupal 8 means that you have to also migrate all content that is present in your site. The theme that is used to display the content on the site will also have to be re-developed. This only holds true for this specific upgrade and not for later upgrades from Drupal 8 to Drupal 9 for instance, more on that later... The massive structural changes of the inner workings of Drupal are the cause of this, highly inconvenient but certainly necessary to keep Drupal the modern framework we all need it to be.

Performing a migration and re-developing the theme mean that this needs to be discussed and planned well in advance. Depending on the size of your site the time needed may vary, but to wait until the EOL date arrives is obviously not a good idea.

I see, so what should I do?

The sensible thing to do is to start thinking about what steps are necessary to perform an upgrade to Drupal 8. Drupal 8 was released in November 2015, so it has been in production use for over 4 years now. It is a very stable and mature piece of software with a wide adoption worldwide.

As mentioned earlier, “under-the-hood” Drupal 8 changed significantly compared to Drupal 7. Upgrading therefore provides a chance to perform structural and visual changes to your site that you have in mind anyway. It doesn’t make sense to make big changes to your Drupal 7 site when you know that it’s official life will come to an end in 2021. If you now start to plan for incorporating these changes into the Drupal 8 version of the site, you still have plenty of time to thoroughly discuss these changes and efficiently spend your budget when the time comes to actually perform the upgrade.

The same goes for migrating your content. The upgrade provides an opportunity to think about what content you want to keep and how you can put it to it’s best use!

Drupal 9 will be released in 2020, do I have to do all this again? Should I postpone?

Drupal 9 will be released on June 3rd 2020. Since that is less than half a year away, it might seem better to wait a bit and move from Drupal 7 to Drupal 9 directly. That’s where the big “under-the-hood” structural changes in Drupal 8 come in, upgrading from Drupal 8 to later versions will be extremely easy and not require a full migration! This makes the move from Drupal 7 to 8 an exception, once you are on Drupal 8 upgrading can more or less be done with the click of a button!

So migrating to Drupal 8 first makes a lot of sense because you can start incorporating changes into your site directly, without having to wait for a move away from Drupal 7. This way you benefit from being on the new version of Drupal right away and are future proof from that moment on.

Ok let’s do this, how do we perform the migration?

There are 3 parts relevant to the migration from Drupal 7 to Drupal 8: upgrading code, rebuilding the theme and migrating content. To perform a successful migration we first need to understand where you want to go, so we first discuss what the Drupal 8 site will look like before we do anything else. We have extensive project management experience in house that will lead to a clearly defined product to deliver.

Once we know where we are going, it is time to look at the Drupal 7 site we are coming from. For projects we have not built ourselves this usually means we perform an assessment that tells us how the site is built and what we can expect from its content. The assessment’s outcome tells us how much work the migration will entail and forms the basis for an estimated budget and time needed to complete the project.

Do you want us to help you migrate your Drupal website? Contact us for an introductory meeting and get started right away!

Dec 23 2019
Dec 23

Making multilingual sites is hard. I’ve been using Drupal since version 5 and I can say a few things about the evolution of Drupal multilingual capabilities:

  • First, Drupal 8 is – in my opinion – the first version of Drupal where someone could say that multilingual works, pretty much out of the box.
  • Second, the documentation about how to deal with different scenarios is quite good.
  • And third, from a user experience perspective, translating the user interface of a site is really hard.

In this post we will talk about the third point and what we did to manage that complexity.

Our Current Scenario

We are building a really complex site, and the main challenges we faced regarding multilingual are:

  • The site is a multisite architecture, one database using Organic Groups.
  • Each group represents a country, and each country needs its site in one or more languages.
  • We have several variations of the same language depending on the region this language is spoken in.
  • We don’t want to let content editors translate the site directly from the UI.
  • We don’t speak all the languages the site is in.

The last item is quite relevant, when you don’t speak a language, you cannot even be sure if the string you are copying into a textbox says what it should.

The First Attempt

We started with a translation matrix to store all the translations. A simple Google drive spreadsheet to track each string translation in each language.

Each column uses the language code as a header.

Using a tool to convert Spreadsheets into po files we get each translation file fr.po, es.po, pt.po.

We used wichert/po-xls to achieve this with good results.

Not So Fast

This initial, somewhat naive, approach had a few problems.

  • Drupal string translations are case sensitive. This means that if you made a typo and wrote Photo instead of photo the translation will fail.
  • Some strings are the result of a calculation. For example. Downloads: 3 is actually managed by Drupal as Downloads: @count.

But the more complex item is that Drupal 8 has two ways to translate strings. The first one is inherited from Drupal 7. The one that makes use of the well known t function for example t('Contact us.').

The other one is a new way that allows site builders to translate configuration entities.

The two scenarios that allow translation of a Drupal site.

Translating Configuration Entities is Really Hard

To translate configuration entities, you need to identify which configuration needs translation, and find the exact part relevant to you. For complex configuration entities like views, this could be quite hard to understand.

Even for an experienced site admin this can be hard to understand.

Another problem that we had to solve was the vast amount of configuration alternatives you have when dealing with a medium-size Drupal site.

Each category has a lot of items to translate.

It was clear to us that in order to translate all those items we needed to find another way.

More problems&mldr; Identifying Which Strings to Translate is Hard

One thing to consider when dealing with Drupal translations is that it’s not easy to identify if a string is displayed somewhere in the frontend or if it is only a backend string.

Translating the entire codebase may not be a viable option if you want to keep a short list of translations reviewed by a group of people. In our case, it was important to make sure that translations are accurate, and that translators do not feel overwhelmed.

We don’t have a great solution to this problem yet. One of the strategies we used was to search for all the strings in twig templates and custom modules code using a grep search.

egrep -hro "[\>, ]t\('.*'\)" . | cut -c 5-   # Get strings inside ->t(...) and t(...)
egrep -hro "{{ '.*'\|\t" .                   # Get twig strings '....'|t
egrep -hro " trans .*" .                     # Get twig strings inside trans

However, as we figured out later by reading the documentation, twig strings cannot be used as a source for translations. Internally, Drupal maps those strings back to the regular use of t('strings').

This means that strings like:

{% trans >}}Copyright {{ year }}{% endtrans >}}

Are actually converted to

t('Copyright @year')

And that last string is the one you should use as source of the translation.

At the end, we cleaned up the spreadsheet list using visual inspect, and so far it has been working fine.

How We Solved the Problems?

To recap the problems we had:

  • We did not want to translate all the available strings.
  • We did not know all the languages, therefore copy and pasting was a risk.
  • Translators were expecting to have a reduced number of strings to translate.
  • Configuration translations are quite complex to track.

As we mentioned before using the xls-to-po tool, we were able to obtain the PO files to translate one part of the strings that we needed to translate.

We also used drush_language to automate the process.

drush language-import --langcode=fr path/to/po_files/fr.po

This little snippet iterates over all of the po files in the po_files directory and imports the language using the drush command mentioned above.

find po_files -type f -name *.po | xargs basename --suffix=.po | \
xargs [email protected] drush language-import --langcode=@ @.po

The xls spreadsheet has in the first column the Message Id, and the language codes of the system

By using conditional cell colors, we can quickly identify which translations are pending.

Solving the Configuration Translation Problem

The second part of our problem was a bit more tricky to fix.

We used a custom script to get all the config entity strings that were relevant to us.

Here is a simplified version of the script.

$prefix = 'views.view.custom_view';
$key = 'display.default.display_options.exposed_form.options.reset_button_label';

$configFactory = \Drupal::service('config.factory');
$list = $configFactory->listAll($prefix);

$rows = [];

foreach ($list as $config_name) {
  $columns = [];
  // Add the unique identifier for this field.
  $columns[] = $config_name . ':' . $key;

  // Get the untranslated value from the config.
  $base_config = $configFactory->getEditable($name);
  $columns[] = $base_config->get($key);

  $rows[] = $columns;
}

If you wonder how to get the $prefix and $key, they are obtained by inspecting the name of the field we want to translate in the Configuration Translation UI.

You need to inspect the HTML of the page, see the name attribute.

We print the result of the script to obtain a new CSV file that looks like this

The first column is a unique id that combines the prefix and the key.

Then, we copy and paste this CSV file as a new tab in the general translation matrix, and complete the header with the rest of the languages translations.

Finally we use a spreadsheet formula to find the translation we want for the languages we are interested in.

=IFERROR(VLOOKUP($B2,$Strings!$A$2:Y299,COLUMN()-1,0);"")

This will search for a match in the Strings matrix, and provide a translation.

Spreadsheet magic.

Final step: Importing the Configuration Strings Translation Back to Drupal

Once we have all the translations we need. We export the CSV file again and use this other script (simplified version) to do the inverse process:

use Symfony\Component\Serializer\Serializer;
use Symfony\Component\Serializer\Encoder\CsvEncoder;
use Symfony\Component\Serializer\Normalizer\ObjectNormalizer;

$filename = 'path/to/config_translations.csv';

$serializer = new Serializer([new ObjectNormalizer()], [new CsvEncoder()]);
$configFactory = \Drupal::service('config.factory');
$languageManager = \Drupal::service('language_manager');

$serializer->encode($data, 'csv');
$data = $serializer->decode(file_get_contents($filename), 'csv');

foreach ($data as $row) {
  $name_key = array_values($row)[0];
  list($name, $key) = explode(':', $name_key);

  // The languages we care start after the second column.
  $languages = array_filter(array_slice($row, 2));

  foreach ($languages as $langcode => $translation) {
    $config_translation = $languageManager
                            ->getLanguageConfigOverride($langcode, $name);
    $saved_config = $config_translation->get();
    $config_translation->set($key, $translation);
    $config_translation->save();
  }
}

Some Other Interesting Problems We Had

Before finishing the article, we would like to share something interesting regarding translations with contexts. As you may know, context allows you to have variations of the same translation depending on, well&mldr; context.

In our case, we needed context to display different variations of a French translation. In particular, this is the string in English that we needed to translate to French:

Our organization in {Group Name}

In France, this translates into Notre organisation en France. But if you want to say the same for Canada, due to French grammatical rules you need to say Notre organisation au Canada (note the change en for au).

We decided to create a context variation for this particular string using context with twig templating.

{% trans with {'context': group_iso2_code} >}}
Our organization in { group_name }
{% endtrans >}}

This worked ok-ish, until we realized that this affected all the other languages. So we need to specify the same translation for each group even if the language was not French

This is not what we want...

After some research we found the translation_fallback module but unfortunately it was a Drupal 7 solution.

Long story short, we ended up with this solution.

{% if group_uses_language_context >}}
  {% trans with {'context': country_iso2_code} >}}
    Our organization in { group_name }
  {% endtrans >}}
{% else >}}
  {% trans >}}Our organization in { group_name }{% endtrans >}}
{% endif >}}

Which basically provides two versions of the same string. But if the group needs some special treatment, we have the change to override it. Lucky for us, xls-to-po has support for strings with context. This is how we structured the translations for strings that require context:

CA, in this case, is the ISO code for Canada

Conclusion

For us, this is still a work in progress. We will have to manage around 20 or more languages at some point in the project. By that point, having everything in a single spreadsheet may not be maintainable anymore. There are other tools that could help us to organize source strings. But so far a shared Google Sheet worked.

We still use configuration management to sync the strings in production. The snippets provided in this post are run against a backup database so we can translate all the entities with more confidence. Once we ran the script we use drush config:export to save all the translations to the filesystem.

Dec 18 2019
Dec 18
Project: Drupal coreVersion: 8.8.x-dev8.7.x-dev7.x-devDate: 2019-December-18Security risk: Critical 17∕25 AC:Basic/A:User/CI:All/II:All/E:Proof/TD:UncommonVulnerability: Multiple vulnerabilitiesDescription: 

The Drupal project uses the third-party library Archive_Tar, which has released a security improvement that is needed to protect some Drupal configurations.

Multiple vulnerabilities are possible if Drupal is configured to allow .tar, .tar.gz, .bz2 or .tlz file uploads and processes them.

The latest versions of Drupal update Archive_Tar to 1.4.9 to mitigate the file processing vulnerabilities.

Edited to clarify the nature of the upstream release.

Solution: 

Install the latest version:

Versions of Drupal 8 prior to 8.7.x are end-of-life and do not receive security coverage.

Additional information

All advisories released today:

Updating to the latest Drupal core release will apply the fixes for all the above advisories.

(Note that this SA is the only one in the list that applies to Drupal 7.x)

Reported By: Fixed By: 
Dec 18 2019
Dec 18
Project: Drupal coreVersion: 8.8.x-dev8.7.x-devDate: 2019-December-18Security risk: Moderately critical 10∕25 AC:Basic/A:User/CI:Some/II:None/E:Theoretical/TD:DefaultVulnerability: Access bypassDescription: 

The Media Library module has a security vulnerability whereby it doesn't sufficiently restrict access to media items in certain configurations.

Solution: 
  • If you are using Drupal 8.7.x, you should upgrade to Drupal 8.7.11.
  • If you are using Drupal 8.8.x, you should upgrade to Drupal 8.8.1.

Versions of Drupal 8 prior to 8.7.x are end-of-life and do not receive security coverage.

Alternatively, you may mitigate this vulnerability by unchecking the "Enable advanced UI" checkbox on /admin/config/media/media-library. (This mitigation is not available in 8.7.x.)

Additional information

All advisories released today:

Updating to the latest Drupal core release will apply the fixes for all the above advisories.

Reported By: Fixed By: 
Dec 18 2019
Dec 18
Project: Drupal coreVersion: 8.8.x-dev8.7.x-devDate: 2019-December-18Security risk: Moderately critical 14∕25 AC:Basic/A:Admin/CI:Some/II:All/E:Theoretical/TD:DefaultVulnerability: Multiple vulnerabilitiesDescription: 

Drupal 8 core's file_save_upload() function does not strip the leading and trailing dot ('.') from filenames, like Drupal 7 did.

Users with the ability to upload files with any extension in conjunction with contributed modules may be able to use this to upload system files such as .htaccess in order to bypass protections afforded by Drupal's default .htaccess file.

After this fix, file_save_upload() now trims leading and trailing dots from filenames.

Solution: 

Install the latest version:

  • If you use Drupal core 8.7.x: 8.7.11
  • If you use Drupal core 8.8.x: 8.8.1

Versions of Drupal 8 prior to 8.7.x are end-of-life and do not receive security coverage.

Additional information

All advisories released today:

Updating to the latest Drupal core release will apply the fixes for all the above advisories.

Reported By: Fixed By: 
Dec 18 2019
Dec 18
Project: Drupal coreVersion: 8.8.x-dev8.7.x-devDate: 2019-December-18Security risk: Moderately critical 12∕25 AC:None/A:None/CI:None/II:None/E:Theoretical/TD:AllVulnerability: Denial of ServiceDescription: 

A visit to install.php can cause cached data to become corrupted. This could cause a site to be impaired until caches are rebuilt.

Solution: 

Install the latest version:

Versions of Drupal 8 prior to 8.7.x are end-of-life and do not receive security coverage.

To mitigate this issue in any version of Drupal 8, you can also block access to install.php if it's not required.

Additional information

All advisories released today:

Updating to the latest Drupal core release will apply the fixes for all the above advisories.

Reported By: Fixed By: 
Dec 17 2019
Dec 17

Developer portals need three kinds of great content to succeed. 

  1. API Documentation

  2. Technical Documentation

  3. Marketing Content

Content is being consumed differently now than it was in the past. Dense long-form, bespoke technical communication is going away. Clear, highly visual , easy to read content is taking the lead.  When building a developer portal, content quality and organization needs to be a high priority for your team. .   

API Documentation

Clear API Documentation is a critical component of success.  Your developers rely on this documentation during development.   It needs to be easy to read and understand, and most importantly it needs to be consistent across all your APIs; this consistency starts with good planning upfront. This is content strategy with a particular focus on technical documentation and will result in a writing guide for API docs to help foster usability and readability. Templates and writing guides provide consistency that will increase your developer community’s happiness and productivity.  

Technical Documentation

Technical Documentation is your API program’s supporting content. These include practical use case scenarios, SDK documentation, Frequently Asked Questions, and other technical topic content. Paying attention to the quality of this content is important.  Rambling, bespoke technical documentation will not be consumed by your developer community and will slow the growth of your API acceptance. We help companies develop content governance strategy plans that create a consistent tone, tenor and taxonomy for your technical documentation. Consistent, easy to read, well tagged technical content is a winning combination. 

Marketing Content

Marketing Content. Digital transformation is being powered by APIs; the company API developer portal is becoming the place where these initiatives are being communicated. The ‘customer’ is the developer who comes to your site and consumes your API’s in order to build out new products, services and transactions. Growing adoption of API programs along these channels requires solid marketing material. This content communicates the business value of using your API products and should include all stakeholders in the process as you gather input from across the organization. Work with writers who will create great copy and content to sell your API program. 

The Apigee developer portal is a powerful content management system built using Drupal 8. It is the perfect platform to manage these three types of content.   

Chapter Three is a digital agency that helps organizations develop amazing Apigee developer portal experiences by providing API program strategic planning, content strategy, technical writing, development, training and support.

We look forward to partnering with you. 

Dec 15 2019
Dec 15

I have t' say, I were bein' skeptical about dark mode in our current operatin' systems, but since wirin' it up t' switch t' it automatically after sunset, I’m a believer. I know some scallywags always operate their in dark mode, an' that's not fer me. I prefer th' light on me screen t' match th' light o' th' day. It's especially nice t' have me iPhone in dark mode at concerts, so I can avoid bein' "that lubber" who blinds th' person behind me,

Websites now respect th' system settin' o' dark mode, an' e'er since Jeff Geerling updated his site's theme to support dark mode, I had on me list t' do th' same.

It turns out that the Responsive Blog Drupal theme, a very nice theme that does what it says on th' tin, has a switch fer turnin' on th' dark mode version o' it. I'm glad I realized that most o' th' work had been done fer me, an' I've submitted a patch to the project for review.

The last frontier o' dark mode based on system settin' is third-party JavaScript widgets. None o' th' 3 widgets on me blog, t' me knowledge, have th' ability t' switch automatically.

Dec 13 2019
Dec 13

More user-friendly, more intuitive, more accessible — this is what modern websites should be. One of the key aspects of improving website accessibility is enabling keyboard navigation.

The newly released Drupal 8.8 is great in this arena — it introduces keyboard accessibility for quickly adding media from Media Library to CKEditor’s content with no mouse.

Let’s see this in action — video included! And if you want to see this (and many other cool new features) right on your website, schedule an update to Drupal 8.8 with our Drupal experts.

Why keyboard accessibility is important

Undoubtedly, website accessibility is vital for business reputation, your website's traffic, audience, SEO, and overall user-friendliness. And website accessibility would be incomplete without keyboard accessibility — see why.

Many users prefer keyboard navigation to mouse navigation because they find it more efficient. However, for users with particular disabilities, it’s not a matter of preference — they simply have no choice, so keyboard accessibility is essential. These cases include:

  • motor impairments, tremors, loss of muscle control (users cannot hold a mouse properly)
  • visual impairments (users rely on screen readers and cannot see where to click the mouse)

That’s why respectful brands include keyboard accessibility in the requirements to their websites. And it’s now easy with D8.8!

The particular feature we are discussing today is about keyboard accessibility in creating content and adding multimedia. In addition to admins and content editors, it will be helpful to all users on a wide variety of websites that allows content creation. Let’s go.

Keyboard accessibility as final touch in Drupal’s media ecosystem

It looks like keyboard accessibility is the final stroke in Drupal 8’s perfect media handling ecosystem. Up until the D8.8 release, users and editors have been enjoying other new features in this sphere:

  • With D8.6, came easy media handling with saving and reusing it in Media Library and embedding it into the content. The oEmbed feature allowed everyone to easily add YouTube or Vimeo videos through links.
  • D8.7 gave us the new attractive and user-friendly Media Library interface with bulk uploads and other useful features.

Finally, Drupal 8.8 has introduced Media Library and WYSIWYG integration to add media with a simple icon in the content editor. It has also made the Library stable so it is absolutely ready for live sites. And keyboard accessibility has finally brought the beauty and interactivity of multimedia close to everyone — no need for a mouse!

Tweet about keyboard accessibility in Drupal 8 Media Library

How it works: Drupal 8's keyboard navigation in adding media to content

To embed some items from Media Library using keyboard accessibility opportunities, users can:

  • move to the CKEditor toolbar (“Alt” + “F10” on the keyboard)
  • find the Media Library icon (“Tab” + “arrow keys” on the keyboard)
  • open the Library (“Space” or “Enter” on the keyboard)
  • move around the Library interface to select items (“Tab” + “arrow keys” on the keyboard)
  • select the desired item (“Space” on the keyboard)
  • edit the item’s ALT tag, position, and caption (“Enter” on the keyboard)
Selecting media to embed in Drupal 8.8 CKeditor from Media Library
  • move to the “Insert selected” button (Tab + arrow keys on the keyboard)
  • embed the item into the content (Enter)
Embedded media into Drupal 8.8 CKeditor from Media Library

Note: please keep in mind that the correct key commands may depend on the version of the OS.

A video is worth a hundred words, so see how keyboard accessibility works for media embedding in Drupal 8.8.

[embedded content]

To get the Library icon on the CKEditor dashboard, it’s necessary to first add it to the active toolbar by dragging.

Adding Media Library icon to active toolbar in Drupal 8.8 CKEditor

Drupal will also ask you to enable the “Embed Media” filter below.

Enabling the Embed Media filter in Drupal 8.8 CKEditor

Of course, the Media and Media Library modules should also be enabled. It is also possible to add multiple media fields as part of your content type structure, which is covered in the blog post on media handling by our colleagues from Drudesk. For example, every your blog post could have 3 videos, 5 photos, and so on, built into its structure.

Let your website have the latest features!

Indeed, keyboard accessibility in Drupal 8 looks great. We can help you with its setup on your website. Entrust our web development agency with smoothly updating your website to Drupal 8.8 — and let your website follow the best digital trends in keyboard accessibility and much more!

Dec 09 2019
Dec 09

With Drupal 9 set to be released later next year, upgrading to Drupal 8 may seem like a lost cause. However, beyond the fact that Drupal 8 is superior to its predecessors, it will also make the inevitable upgrade to Drupal 9, and future releases, much easier. 

Acquia puts it best in this eBook, where they cover common hangups that may prevent migration to Drupal 8 and the numerous reasons to push past them.

The Benefits of Drupal 8

To put it plainly, Drupal 8 is better. Upon its release, the upgrade shifted the way Drupal operates and has only improved through subsequent patches and iterations, most recently with the release of Drupal 8.8.0

Some new features of Drupal 8 that surpass those of Drupal 7 include improved page building tools and content authoring, multilingual support, and the inclusion of JSON:API as part of Drupal core. We discussed some of these additions in a previous blog post

Remaining on Drupal 7 means hanging on to a less capable CMS. Drupal 8 is simply more secure with better features.

What Does Any of This Have to Do With Drupal 9?

With an anticipated release date of June 3, 2020, Drupal 9 will see the CMS pivot to an iterative release model, moving away from the incremental releases that have made upgrading necessary in the past. That means that migrating to Drupal 8 is the last major migration Drupal sites will have to undertake. As Acquia points out, one might think “Why can’t I just wait to upgrade to Drupal 9?” 

While migration from Drupal 7 or Drupal 8 to Drupal 9 would be essentially the same process, Drupal 7 goes out of support in November 2021. As that deadline approaches, upgrading will only become an increasingly pressing necessity. By migrating to Drupal 8 now, you avoid the complications that come with a hurried migration and can take on the process incrementally. 

So why wait? 

To get started with Drupal migration, be sure to check out our Drupal Development Services, and come back to our blog for more updates and other business insights. 
 

Dec 04 2019
Dec 04
Start:  2019-12-04 (All day) UTC Organizers:  mcdruid Fabianx Event type:  Online meeting (eg. IRC meeting)

Per the D7 release schedule we aim to release Drupal 7.68 on 2019-12-04.

Details of what will be in the release can be seen here:

https://www.drupal.org/project/drupal/issues/3097342

The final patches for 7.68 have been committed and the code is frozen (excluding documentation fixes and fixes for any regressions).

Relevant Change Record(s) for the release (this is not the full list of changes, rather only a list of notable API additions and other changes that might affect a number of other modules, so it's a good place to start looking for any problems):

If you do find any regressions, please report them in the issue queue. Thanks!

Dec 02 2019
Dec 02
A Step-by-step guide to integrating your BigCommerce store with the Drupal CMS


The BigCommerce for Drupal module, created by Acro Media in partnership with BigCommerce, was released early this year and brings together two different platforms – BigCommerce, the open SaaS ecommerce platform, and Drupal, the open source content management system. The result provides a wonderful new way for retailers to implement an innovative and content rich headless ecommerce strategy. If you use one and would like to have the capabilities of the other, the BigCommerce for Drupal module is the bridge you need. With this module, you can use Drupal as the powerful front-end CMS with BigCommerce as the easy-to-use and scalable ecommerce backend.

This post is a step-by-step guide for people who want to know how to install the BigCommerce for Drupal module and get started with both platforms. If you just want to know more about the BigCommerce and Drupal together as ecommerce solution, check out this post instead.

How this module works

Here’s a quick overview of how this all works. The BigCommerce for Drupal module integrates BigCommerce and Drupal together, but each platform is still used for different tasks.

In BigCommerce, you configure products, categories, shipping, taxes and everything else for the ecommerce side of your site. BigCommerce is also where you go to manage orders as they come in.

Drupal is then used for the website frontend and theming. Product and category information from BigCommerce are synced to Drupal, importing them as Drupal Commerce products so that they can be displayed and used like any other Drupal-based content. Any non-commerce content is also managed within Drupal. When a customer goes to checkout, a BigCommerce checkout pane is embedded in the Drupal site to securely process payment and save customer and order information.

Setup BigCommerce and Drupal

On to the guide! Follow these steps and you’ll have your BigCommerce and Drupal store configured in no time!

Prerequisites

This guide already assumes that you have the following ready.

  1. A BigCommerce account and store created
    You will need to create a BigCommerce account with at least one product, shipping method and payment method configured in your BigCommerce store. Do this here, not in Drupal.

    NOTE: BigCommerce currently offers a 14-day trial period, so any one can go and create and configure a store easily for free. For this demo, I signed up for that and created some random products to use for testing.

  2. A working Drupal 8 site
    You should have a Drupal 8 site with the Commerce module enabled and a default store added (via Commerce > Configuration > Store > Stores). You don’t need to do any other setup here yet or enable any of the other Commerce modules like checkout or payment. BigCommerce is going to handle all of this for you.
  3. An SSL certificate for your Drupal site
    Your Drupal website needs to have an SSL certificate active for the BigCommerce checkout form to render. This is required because it ensures security for your customers at checkout, so make sure you install one.

BigCommerce for Drupal setup guide

With the prerequisites done, here’s what you need to do to the the BigCommerce for Drupal connection made.

Step 1: Create a BigCommerce API account

  1. Go to your BigCommerce store admin page and navigate to Advanced Settings > API Accounts.
  2. Click on “Create API Account” button and select “Create V3/V2 API Token”.

    BigCommerce Store API Accounts page
    Fig: BigCommerce Store API Accounts page

  3. Provide a name (i.e. Product Sync) and select the scope for each features (i.e. if you don’t want the ability for the Drupal admin to modify product information, you can set the scope for “Products” as “read-only”).

    API configuration in BigCommerce
    Fig: API configuration in BigCommerce

  4. Click “Save” to save your changes. Once saved, you will see a summary and a prompt to download a file. Download it and keep it safe. Once you create an API account, you can’t modify the keys (but you can always make a new one).

    BigCommerce API Credentials dialog box
    Fig: BigCommerce API Credentials dialog box

Step 2: Download and configure the BigCommerce for Drupal module

  1. Get and install the BigCommerce for Drupal module.TIP: This module requires a bunch of other modules to work. To get the BigCommerce for Drupal module and all of its dependencies at the same time it’s recommended to use Composer instead of manually downloading it. Running the following command within your Composer based Drupal project will get everything you need.
    composer require drupal/bigcommerce
    
  2. In Drupal, navigate to module configuration page at Commerce > Configuration > BigCommerce > BigCommerce Settings.
    1. Fill in the API Path, Client ID, Secret Key, and Access Token that you received when creating the BigCommerce API.
    2. Hit “Save”. If everything is correct, you will see a message saying “Connected Successfully”.

      BigCommerce Configuration page in Drupal
      Fig: BigCommerce Configuration page in Drupal site

  3. Next we configure the Channel Settings. This will create a storefront url for you in BigCommerce which will match the one that is generated on the Drupal side.
    1. Select “Add new channel” from the select channel list.
    2. Provide a channel name.
    3. Click the “Create new BigCommerce channel” button. You will then see a Site ID and Site URL on the setting page.

      BigCommerce configuration page in Drupal - Channel settings
      Fig: BigCommerce configuration page in Drupal

  4. Now in the same Channel Settings area, click on the “Update BigCommerce Site URL” button. This lets you confirm that the url generated is actually sent to the BigCommerce, otherwise the checkout form will not be loaded on your Drupal site.

    You can also confirm the channel connection in from within the BigCommerce admin dashboard by visiting the Channel Manager admin page.

    Channel Manager storefront confirmation in BigCommerce
    Fig: Channel Manager storefront confirmation in BigCommerce

Step 3 : Sync products, variations and taxonomies from BigCommerce

  1. In Drupal, navigate to the product synchronization page at at Commerce > Configuration > BigCommerce > BigCommerce Product Synchronization.
  2. Click the “Sync Products from BigCommerce” button and ta-da, all the products, variations, and categories will be synced to your Drupal site in an instant.

    Alternately, you can also synchronize via the following Drush command. Advanced Drupal users can use this command on cron to do automatic syncing.

    drush migrate:import --group bigcommerce
    
    Product Synchronization page
    Fig: Product Synchronization page

    BC4D-Setup_Syncing-from-BigCommerce-in-progress-1
    Fig: Syncing from BigCommerce in progress

    NOTE: If you run into errors when syncing products, it probably because you don’t have a store added in the Drupal Commerce module yet. Add one at Commerce > Configuration > Store > Stores.

    TIP: Any time you make changes to the products in BigCommerce, visit this page or use the Drush command to synchronize the changes. Before syncing, you’ll also see a message telling you that updates are available.

  3. Confirm the products have synced by visiting the Product page for Drupal Commerce at Commerce > Products. A list of all of the products brought in from BigCommerce will appear here.

Step 4 : See the BigCommerce checkout in action

  1. Now that everything is set up, go to a product page, and it to your cart and proceed to checkout.

    If everything was done correctly, you will be able to see the BigCommerce checkout form embedded in to your Drupal site! Hurray! All of the shipping methods, payment methods, tax calculations, and other BigCommerce store configurations will be seen in the embedded form here.

    If you don’t see the checkout form make sure that your channels settings are correct and that you have an SSL certificate installed.

    Drupal’s checkout page with embedded BigCommerce checkout form
    Fig: Drupal’s checkout page with embedded BigCommerce checkout form

    Drupal’s checkout page after order complete
    Fig: Drupal’s checkout page after order complete

  2. Once an order has been placed, the order information will be stored in Drupal (at Commerce > Orders) and will also be sent to BigCommerce (at Orders > View).

    BigCommerce backend View Orders page
    Fig: BigCommerce backend View Orders page

Additional notes

The BigCommerce for Drupal module is ready for production and available for all to use. When writing this guide, there were some additional notes that I wanted to share.

  • At this time, product management should always be handled within BigCommerce and then synced to Drupal. Currently there is no option to bring back a product if you delete it in the Drupal side, so be careful.
  • A development roadmap for the module can be found here. It outlines future features and plans.
  • If you use the module and find any bugs or want specific features, please add them to the module issue queue here.

Acro Media is a BigCommerce Elite Partner

Acro Media is the development team partnered with BigCommerce that made the BigCommerce for Drupal module a reality. We have many, many years of ecommerce consulting and development experience available to support your team too. If you’re interested in exploring Drupal, BigCommerce or both for your online store, we’d love to talk.

View our BigCommerce for Drupal services

Nov 21 2019
Nov 21

Enjoy a random 404 video.

Or explore more of what we do.

We offer strategy, design and development services across industries and using a wide array of tech.

Read more about each below.

  • Business
  • Branding
  • User Research
  • Content Strategy
  • SEO
  • Accessibility
  • Responsive
  • Experience
  • Styleguides
  • Performance
  • Security
  • Migrations
  • Support
  • Training

Industry.

  • Finance
  • Healthcare
  • Higher Ed
  • Nonprofit
  • Tech

Technology.

  • PHP
  • Drupal
  • WordPress
  • Laravel
  • Javascript
  • Node
  • Vue
  • Nuxt
  • Electron
  • DevOps
  • Docker
  • Lando

Other.

  • Magic
  • Localdev
  • Testing
  • Events
  • Webinars

Drupal themes and component libraries

Nov 17 2019
Nov 17
Nov 15 2019
Nov 15

Our normally scheduled call to chat about all things Drupal and nonprofits will happen Thursday, November 21, at 1pm ET / 10am PT. (Convert to your local time zone.)

Feel free to share your thoughts and discussion points ahead of time in our collaborative Google doc: https://nten.org/drupal/notes

We have an hour to chat so bring your best Drupal topics and let's do this thing!

Some examples to get your mind firing: how do I recreate [feature] on my Drupal 7 site in Drupal 8? I need to explain [complicated thing] to a non-technical stakeholder -- any advice? How can I get Drupal and my CRM to play nicely?

This free call is sponsored by NTEN.org but open to everyone.

ATTENTION: New call-in information this month. We're moving to Zoom, y'all!

  • Join the call: https://zoom.us/j/308614035
    • Meeting ID: 308 614 035
    • One tap mobile
      • +16699006833,,308614035# US (San Jose)
      • +16465588656,,308614035# US (New York)
    • Dial by your location
      • +1 669 900 6833 US (San Jose)
      • +1 646 558 8656 US (New York)
  • Follow along on Google Docs: https://nten.org/drupal/notes
  • Follow along on Twitter: #npdrupal

View notes of previous months' calls.

Nov 11 2019
Nov 11

Enjoy a random 404 video.

Or explore more of what we do.

We offer strategy, design and development services across industries and using a wide array of tech.

Read more about each below.

  • Business
  • Branding
  • User Research
  • Content Strategy
  • SEO
  • Accessibility
  • Responsive
  • Experience
  • Styleguides
  • Performance
  • Security
  • Migrations
  • Support
  • Training

Industry.

  • Finance
  • Healthcare
  • Higher Ed
  • Nonprofit
  • Tech

Technology.

  • PHP
  • Drupal
  • WordPress
  • Laravel
  • Javascript
  • Node
  • Vue
  • Nuxt
  • Electron
  • DevOps
  • Docker
  • Lando

Other.

  • Magic
  • Localdev
  • Testing
  • Events
  • Webinars
Nov 05 2019
Nov 05

Shawn McCabe, Acro Media’s CTO, recently made waves when he proclaimed through our blog that Ubercart is dead. We received both praise and criticism from the Drupal community for saying it, but the truth of the matter is that Ubercart, once the primary module businesses relied on for adding ecommerce functionality into the Drupal CMS, has yet to have a stable Drupal 8 release (even though Drupal 8 was released 4 years ago in November, 2015). It’s currently stuck in “alpha” and overall usage has been steadily declining for years. Read the initial post for more information.

We put out that post as an attempt to inform businesses that are currently using Ubercart that they should be planning their migration to something else ASAP, before Drupal 7 reaches end-of-life. Our suggestion for these businesses is to move to the Drupal Commerce module for Drupal 8. Drupal Commerce is the successor to Ubercart and was founded by one of the Ubercart creators. It’s the natural choice for these businesses and overall it’s a much better platform in every way.

Of course, when you tell a business that they need to replatform because their ecommerce software is “dying,” that’s not an easy thing for business owners to hear. Many flat-out ignore it to be honest, but those who understand the warning want to know more about how it will affect their business. From the reaction we received to the initial post, we understood that more needed to be said. Businesses using Ubercart now have questions that need to be answered. Because of this, we held an “Ubercart is Dead Roundtable” webinar-style discussion where we put Shawn in the spotlight to answer the questions that have come in. The goal of this discussion was to be both informative and demystifying, a general discussion instead of a sales pitch.

So without further ado, here is the roundtable recap video. A list of timestamped discussion topics are shown below the video. If you have any other questions not mentioned here, send us a message. We would be happy to answer any questions you may have.

Watch the roundtable

Host: Jace Anderson
Specialist: Shawn McCabe, CTO

00:00 - Introduction
00:45 - Who is Shawn McCabe
01:55 - Why do you [Shawn] think Ubercart is Dead?
03:07 - Why is Drupal Commerce the next platform of choice?
04:02 - Why should I move off of Ubercart when our business is currently operating fine?
05:58 - Is there a performance difference between Ubercart and Drupal Commerce?
08:06 - Is it possible to move off of Ubercart but stay on Drupal 7?
09:29 - How do we know Drupal Commerce won’t see the same fate as Ubercart?
11:00 - Is there a big difference in the features from Ubercart to Drupal Commerce? Is Drupal Commerce more robust?
13:35 - Is there a big learning curve for the backend administrators when using Drupal Commerce?
15:21 - How big of an undertaking is the migration from Ubercart to Drupal Commerce? Can an IT team of 5 complete it?
16:44 - What website components add to the complexity of a migration?
18:00 - Would a migration interrupt my business? Will it affect the customer experience?
18:54 - How would a migration impact my internal operations?
20:25 - How do we know Drupal Commerce won’t see the same fate as Ubercart (second part)?
21:26 - Currently we use multi-currency. Does Drupal commerce support this too?
22:41 - We use MailChimp for abandoned cart recovery. Can it still be used with Drupal Commerce?
23:10 - Are there other alternatives to Drupal Commerce? Is it the only option to continue using Drupal?
24:04 - How does Drupal Commerce perform on mobile?
25:02 - From your blog post, there looks to be companies using Ubercart on Drupal 8. What would prompt this?
25:57 - Can Drupal Commerce be used for custom customer experiences?
27:20 - Based on my research, Drupal Commerce is defined as having a difficult user interface. How can we ensure our team will be able to manage the backend?
28:28 - Can I manage my orders from my mobile device?
29:19 - What does Drupal Commerce offer for legacy software integration?
30:51 - What are the key specifications in a migration that attribute to an increased cost when doing a migration?
32:31 - Is my data migrated automatically? Can I also move order history, receipts and customer data?
33:40 - For a migration, where does one find support?
34:52 - What process is involved in managing coupons and promotions?
37:01 - How does bundling differ from Ubercart to Drupal Commerce?
38:00 - Does Drupal Commerce have subscription payment functionality?
40:05 - Is Drupal Commerce catalog taxonomy based?
41:10 - Shawn’s final words to those still on Ubercart who are not planning their move away from it yet.

Click to contact one of our ecommerce consultants

Nov 05 2019
Nov 05

The Drupal Pitch deck has been created, as part of the Promote Drupal initiative, to support and strengthen the position of those in sales roles who present Drupal to decision makers and buyers. We want to help elevate Drupal via agencies, co-ops, and independents. It is an initiative I have led, in close partnership with Suzanne Dergacheva and Ricardo Amaro and involving over 100 contributors.

The Drupal Pitch Deck slides

Born out of a meeting of European Drupal leaders in Darmstadt. In just 12 months ago The Drupal Pitch Deck has come a long way. Version 2.0 of the deck is available now, contains 108 slides in all, and 73 case studies representing the best Drupal projects from agencies across the globe

It was fantastic to see the project featured during introductions ahead of the DriesNote and Suzanne Dergacheva present The story of how the pitch deck came to be at the Drupal Initiatives Keynote at DrupalCon Amsterdam. Seeing non code contributions from so many people being celebrated on this global stage was a real highpoint of the conference for me.

Call for content remains open, you can Add Your Slide Here. With the latest and greatest Drupal projects celebrated at the International Splash Awards we are calling all agencies to submit their incredible new case studies.

In preparation for DrupalCon the team at CTI Digital worked to deliver a solution which allowed all deck content to be transferred into Drupal 8. Integrated to Lingotek at translation management system which enables us to start the internationalisation of the pitch deck. Special thanks must go to Richard Roberts at Lingotek who worked tirelessly over the week of DrupalCon on boarding community translators.

Now that we have systems in place we are actively inviting people to volunteer to translate slides into their language here.

Stages of development

Call for front end developers

All but stage 7 is complete now. We are keen to attract front end developers to join the effort to produce the presentation layer, a Drupal theme. What we have in mind is detailed here

Promote Drupal Pitch Deck Version 2.0 released

During the Birds of a Feather “Bof” meeting we released Version 2.0 of the Pitch Deck which you can download now.

Pitch Deck BoF

Photo: Alex Moreno

Contribution day

Non code contributions to Drupal is a theme close to my heart. So I was delighted to see 2 tables full of people translating and creating new content at the Contribution Day.

Contribution day table
 

Not only this, some of the team were first time contributions and only registered on Drupal.org for 3 weeks. For me this is what success looks like.

Issue queue recognising non code contributions

In addition to translation we saw several subject experts drafting new slides providing supporting evidence as to why Drupal is a prime choice in Higher Education and for Government.

New slides

We still need volunteers in far greater numbers to achieve the translation into 16 languages which is underway. Right now we are calling for people speaking English and the following languages to volunteer.

  • Arabic
  • Bulgarian
  • Catalan
  • Dutch
  • English
  • Farsi (Persian)
  • French
  • French
  • German
  • Hebrew
  • Hindi
  • Hungarian
  • Italian
  • Japanese
  • Polish
  • Portuguese
  • Slovak
  • Spanish
  • Thai
  • Turkish

In conclusion the Pitch Deck Initiative has achieved far more than we could ever have imagined on that day in Darmstadt last year. With the right support from community members we will soon deliver decks in 19 languages. It really is down to you! It’s an ideal opportunity to contribute your skills in bite size chunks. As you’ve already seen there are plenty of ways to join our movement.

On behalf of Ricardo, Suzanne and myself many thanks to all who have participated. We look forward to meeting you too, everyone is welcome!

Nov 04 2019
Nov 04
A proactive approach for cleaner Drupal coding


So you are stuck in the cruft, struggling to create some semblance of sanity within a sea of code-rot. Code standards sound like a great idea for your project, but perhaps automated enforcement tools look like more of a pain than they're worth. This post is intended for Drupal developers using PhpStorm who need fast, flexible, standards enforcement tools.

Maintaining a stringent standard for your codebase is a battle. On one hand, your code is cleaner, more unified, and easier to maintain. On the other hand, these little formatting rules cause frustration and time loss - especially if a tiny slip causes you to waste a full pipeline cycle just to pass an automated standards check. As they say, the best defence is a strong offence, and the tools proposed here will help you find and fix standards violations before they reach a pipeline.

Drupal recommends a tool called PHP Code Sniffer, aka phpcs, to scan your files for Drupal Code Standards violations. Thankfully, it also comes with a companion tool called PHP Code Beautifier and Fixer, aka phpcbf, which fixes the small, tedious violations for you.

The goal of this post is to get phpcs and phpcbf under your fingertips and into your habits. Only once you have hotkeys set-up to run these tools while coding will they become useful — instead of just annoying.

The steps are as follows:

  1. Install and set-up phpcs
  2. Create a custom combination of rulesets
  3. Integrate with PhpStorm for hotkeys and syntax highlighting

1. Install and set-up phpcs

It may seem straightforward to install phpcs globally via Composer or apt, or to simply require it in your current composer project. However, a global install is not easy to customize and share. Instead, I recommend using a standalone repo that is specifically for your code standards tools. When your standards stand alone, they are easier to edit, share with teammates, and transfer to new work environments.

Here’s a simple repo to get you started:
https://github.com/nilswloewen/drupal_code_standards

  1. If you currently have phpcs or phpcbf installed globally, uninstall them before proceeding.
  2. Quick install with example repo:
    git clone [email protected]:nilswloewen/drupal_code_standards.git
    cd drupal_code_standards
    composer install
  3. Once composer has installed phpcs for you, add it to your global path with:

    export PATH=$PATH:~/PATH/TO/drupal_code_standards/vendor/bin
    NOTE: Adjust accordingly for your shell and OS of choice.
  4. Next, you must tell phpcs which rulesets you have installed use.

    The optional tool phpcodesniffer-composer-installer will automatically detect rulesets in your composer package and set your phpcs & phpcbf installed_paths for you. This is part of the example repo and the next step should have been done for you during "composer install".

    However, to set installed paths to rulesets manually run:

    phpcs --config-set installed_paths vendor/drupal/coder/coder_sniffer,vendor/phpcompatibility/php-compatibility/PHPCompatibility
    

    Then confirm that phpcs knows about the rulesets within the installed paths with:

    phpcs -i

    You should see this list that confirms your rulesets:

    The installed coding standards are ... PHPCompatibility, Drupal and DrupalPractice
    

    You may need to set installed paths for phpcbf as well using the same process.

2. Create a custom combination of rulesets

Out of the box, phpcs can only run one standard at a time. This is a problem when working with Drupal because we have 2 standards to follow. For this post I have added a third standard, PHPCompatibility, which is helpful when upgrading php versions on legacy projects.

  1. To combine standards we first create a custom ruleset that references multiple rulesets. Note that this is already included in the example repo as phpcs-custom-standards.xml.
    <?xml version="1.0"?>
    <ruleset name="Custom code standards">
    <rule ref="Drupal"/>
    <rule ref="DrupalPractice"/>
    <rule ref="PHPCompatibility"/>
    </ruleset>
  2. Then set this standard as your default. Use an absolute path to ensure your standard will be found no matter what context phpcs is called from.
    phpcs --config-set default_standard ~/PATH/TO/drupal_code_standards/phpcs-custom-standard.xml
    
    See the example standard for a few other helpful settings.

3. Integrate with PhpStorm for hotkeys and syntax highlighting

There are two levels of integration with PhpStorm: Passive and Active.

Passive

Passive code analysis with PhpStorm Inspections will give you syntax highlighting and hover-over explanations of the file you are currently working on.

PhpStorm passive integration

This is quite helpful when dealing with one file at a time, but when you need to get an entire directory to pass standards, you need a way to hunt for violations.

Active

Active analysis when you use phpcs to scan many files at once. You can do this through the terminal with a command like:

phpcs ~/module # Scans all applicable files in dir.
phpcs ~/module/example.php # Scans only a specific file.

However, it’s a pain to open a terminal window, navigate to the file you are working on, and then type a command. You’ll probably forget or neglect to check your work because of these extra steps involved. A better way to run phpcs is to set-up hotkeys within PhpStorm to scan your files instantly.

Configure PhpStorm inspections

  1. Register phpcs and phpcbf as PHP Quality Tools.

    Settings | Languages and Frameworks | PHP | Quality Tools | Code Sniffer

    PhpStorm PHP Quality Tools settings
  2. Enable the inspection.

    Settings | Editor | Inspection | PHP | Quality Tools

    PhpStorm PHP Inspections settings

  • Set the extension list to match what Drupal standard sets: source
    php,module,inc,install,test,profile,theme,css,info,txt,md,yml
    
  • DO NOT set the "Installed standard paths", as this overrides what you have previously set in the command line.
  • The refresh list button on "Coding Standard" should mimic what "phpcs -i" shows. Choose "Custom" Coding Standard and then click the ellipses to choose the path to your custom standards file (i.e. phpcs-custom-standards.xml).
  • Click OK and your inspections should be working!

Configure hotkeys

  1. Register phpcs and phpcbf as external tools.

    Settings | Tools | External Tools

    PhpStorm External Tools settings

    The "$FilePath" argument runs the tool against the file you are currently working on, or against a selected folder when in project view.
  2. Double check that this step works by running the tool from the main menu.

    Tools | External Tools | phpcs

    Running phpcs external tool

  3. This is the special sauce. Configure a keyboard shortcut for your new tools.

    Settings | Keymap | External Tools

    PhpStorm Keymap settings

  4. Right click on the external tool you just registered and add a keyboard shortcut. "Ctrl+Alt+Shift+Comma" was simply a combination that was not used anywhere else in my setup.

Bringing it all together

Now you can actively use phpcs and phpcbf while you code! I frequently use the phpcbf hotkey while writing new code to do the tedious stuff for me, such as creating doc blocks and pushing whitespace around. Here's an example:

Use phpcbf in PhpStorm with a hotkey

With phpcs and phpcbf now under your fingertips you are set to be much more assertive in your application of code standards!

Taking it to the next level

If you are using Gitlab for CI/CD, which I hope you are, another great strategy for enforcing standards is to create a pre-deployment job that scans your custom code for violations. This will keep your team (and you) in check by stopping standards violations from being auto-deployed.

After a few super annoying pipeline failures for minor syntax errors, you will want this next level of enforcement — git pre-commit hooks. I highly recommend using grumphp to manage this for you.

Best of luck keeping your code readable and up to snuff!

End-to-end Drupal services

As a full service Drupal agency, Acro Media has significant expertise in digital commerce architecture, ecommerce design, customer experience, software development and hosting architecture. If you’re looking for a Drupal agency dedicated to code and project quality, check us out. We would love the opportunity to talk.

View Our Drupal Commerce Services

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