Upgrade Your Drupal Skills

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

See Advanced Courses NAH, I know Enough
Mar 03 2021
Mar 03

This post is an updated part of our Marketer's Guide to Drupal series. This guide will walk you through considerations for choosing an open source CMS, plus case studies and CMO advice to bring your site to the next level.

Supercharge SEO with Drupal

“Over the last 20 years, Drupal has grown into one of the largest enterprise content management systems in the world.” - Drupal Founder Dries Buytaert

Along with the growth of Drupal, the marketing landscape is vastly different now than it was 20 years ago. The same techniques once used to make the top of the search engine no longer work, so marketers need to understand the powerful role a CMS like Drupal can play in building a successful SEO strategy. 

The release of Drupal 8 marked a significant stride in giving content authors more control. That focus continues to evolve with Drupal 9. Notable editor-focused features include a templating engine called Twig for component variety, an API-first foundation to “write once, publish everywhere”, and an editor-friendly content block authoring experience. Layout Builder additionally provides a "drag and drop" module that lets editors add components to pages and add pages to the site with no code. Now, Drupal 9 has even more upgrades for marketers, tech-savvy or not.

This shift places the marketing team in the driver’s seat more often and allows them to get involved in the CMS decision. In this post, we’ll outline some ways you can up your SEO game with Drupal.

Traditional SEO is Dead

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

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

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

Mobile-First Mentality

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

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

The Need for Speed

Another big factor that could affect your rankings is speed on both desktop and mobile. Google places such high importance that they provide a PageSpeed Insights test to show where and how your website is slowing visitors down. Drupal 9 is “smart” in that it caches all entities and doesn’t load JavaScript unless it has to. This means the same content won’t be reloaded over and over and instead can be loaded quickly from the cache. It also uses a feature called velocity, which makes creating and publishing new dynamic content experiences is significantly faster than in Drupal 7 and older Drupal versions.

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

Accessibility = Key for Search

Drupal 8 spurred an overall commitment to accessibility from the community, and with the release of Drupal 9 came another big push toward improving web accessibility, including: 

This is important because, as we know, the relationship between web accessibility and SEO is closely intertwined. Although accessibility is not actually a Google ranking factor (yet), improving accessibility on your website has a high chance of improving your SEO rank.

SEO Friendly Modules for Drupal 9

There are thousands of modules available for Drupal 9, many of which are perfect for marketers. Whether you’re looking to try out something new or to find something that fits what you already know, you have your pick. Here are our favorite SEO modules to use when optimizing your site:

  1. Metatag - allows you to automatically provide metadata, aka "meta tags", that help search engines understand your content. This must-have module offers over 300 different meta tags for different purposes, so take a look and find the right ones for your site.
  2. Two Metatag submodules that we highly recommend are Twitter Cards and Open Graph. Connect your site to Facebook, LinkedIn, Slack, Twitter, and other social platforms and control how links will look when shared on them.
  3. Schema.org Metatag - provides a way of adding some of the hundreds of standardized metadata structures from the international schema.org project on a site, making it easier to clearly define metadata that Google et al can use to more accurately understand your site’s unique information.
  4. Pathauto - helps save you time from manually having to create URL path/aliases as new content is created.
  5. Sitemap - provides a site map that gives visitors an overview of your site. It can also display the RSS feeds for all blogs and categories.
  6. Redirect - Almost every new site needs to incorporate 301 redirects for old page URLs. This gives site admins an easy interface for creating those redirects in Drupal.
  7. Google Analytics - this simple module allows site admins the ability to easily configure Google Analytics in Drupal.
  8. Easy Breadcrumbs - uses the current URL (path alias) and the current page's title to automatically extract the breadcrumb's segments and its respective links.

Thankfully, because Drupal is open source, you’re not out of luck in the instance that you can’t find a module that works for you. There are many options available for making a new one that works, from building it yourself to enlisting help from a Drupal team like Mediacurrent.

Visualize SEO Success with Siteimprove

In addition to Drupal's SEO-friendly modules, an SEO optimization tool like Siteimprove can…

  • Give content editors information about their technical SEO to make more informed decisions
  • Gain an understanding of how SEO and content intersect for your overall strategy
  • Flag potential issues before your content is published
  • Provide insights about the SEO impact on unpublishing a page

The Siteimprove module works directly in Drupal, giving editors access to these insights while they’re adding content. This means no more waiting to fix it post-publish. It is important to correctly set up Siteimprove in order to get the most out of it and effectively transform your strategy into a workable roadmap for your site.

SEO and Beyond

Drupal’s content management system is perfectly structured for search optimization and its core features support many of the critical SEO elements. But features only take you so far on their own. To manage and continuously improve your SEO, consider a dashboard like Siteimprove that you can customize to show you just how the data is processed and how it impacts your business's goals.

Setting those custom data points and interpreting the data that comes in can be time-consuming and difficult, so if you need any help, our team of Siteimprove certified experts can apply our knowledge to configuring your dashboards and making sense of the data. Get started with a Siteimprove tune up.

Mar 02 2021
Mar 02
[embedded content]

Don’t forget to subscribe to our YouTube channel to stay up-to-date.

The “Long text and summary” field has a formatter called “Summary or trimmed”. This formatter allows you to trim text to a specified set length which is important if you’re displaying a list of articles. The last thing you want is to have an article display 1000 words on the homepage.

However, this default “Summary or trimmed” formatter cannot trim the summary. If the author enters in lots of text into the summary it’ll display everything.

The Smart Trim module offers a field formatter for trimming text fields. Additional settings are available more than the default “Summary or trimmed” option – an improvement over the default formatter.

Smart Trim can also apply to Text (Plain) and Text (Plain, Long) fields which, by default, do not have the “Trimmed” option available.

Table of Contents

Getting Started

Before we can begin, go download the Smart Trim module.

Using Composer:

Composer require drupal/smart_trim

Once downloaded go and install the module.

How to Use Smart Trimmed Formatter

1. Go to Structure > “Content types” and click on the “Manage display” on a content type row.

2. Under the “Format” of text fields, an option of “Smart trimmed” will be available.  Select this option.

3. After the “Smart trimmed” option is selected, click on the cogwheel on the right.  More configuration settings are available. (The Summary option is not available for text fields without summary.)

4. Configure the settings accordingly, then click Update and save.

Format Settings

Trim units

Trimming of text can be applied to characters or words. This takes care of word-boundary issues on trimming.

Suffix

Suffix can be appended to the trimmed text, such as “…”.

Display more link?

When enabled, a link of “More” will be added to the bottom of the page. This will allow the user an option to view the entire page.

Summary

This option is only available when using the “Text (formatted, long, with summary)” field. Three options are available:

  • Use summary if present, and do not trim
  • Use summary if present, and honor trim settings
  • Do not use summary

These options allow overriding of the summary.

Strip HTML

This option will Strip out any HTML when displayed. This is important if you’re truncating text because you could display an opening HTML tag but not close which could break the site styling.

Summary

The Smart Trim module provides a more powerful trimming formatter than what is offered out-of-the-box. Best of all, it can be used on any type of text field.

FAQ

Q:  Can I use this module for all text fields?

Yes, it can be applied to all default text fields, plain or formatted, short or long.

Editorial Team

About Editorial Team

Web development experts producing the best tutorials on the web. Want to join our team? Get paid to write tutorials.

Feb 27 2021
Feb 27

Part of contributing to any open source project, or even really being a contributing member of any community, is sharing what you know. That can come in many forms. While many projects over emphasis code, and most of us understand the value of conference talks, good how-to articles are some of the most critical contributions for any software platform. There isn’t much point to a tool if people cannot figure out how to use it.

Why do I write how-to articles

I’ve contributed code to Drupal, some of it even good and useful to others. But usually when I hear someone noticed something I created it’s blog posts about how to solve a problem.

When I struggled to find the answer to a question I expect it is a candidate for a how-to post. I am not so creative that I am often solving a problem no one has, or will want to, solve for another project. And I am good enough at what I do to know that if I struggled to find an answer it was probably harder to find than it could been.

That helps me find topics for articles that are helpful to the community and benefit me.

How-to articles help others in the community use tools better

The goal of a good tutorial is to help accelerate another person’s learning process. The solution does not have to be perfect, and I know most people will have to adapt the answer to their project. I write them when I struggled to find a complete answer in one place, and so I’m hoping to provide one place that gives the reader enough to succeed.

Usually I combine practical experience earned after digging through several references at various levels of technical detail – including things like other people’s blog posts, API documentation, and even slogging through other people’s code. I then write one, hopefully coherent, reference to save others that digging extra reading.

The less time people spend researching how to do something, the more time they have to do interesting work. Better yet, it can mean more time using the tools for their actual purpose.

How-to articles serve as documentation for me, colleagues, and even clients

The best articles serve as high level documentation I can refer back to later to help me repeat a solution instead of recreating it from scratch. When I first wrote how-to articles I was solidifying my own learning, and leaving a trail for later.

They also came to serve as documentation for colleagues. When I don’t have time to sit with them to talk through a solution, or know the person prefers reading, I can provide the link to get them off and running. Colleagues have given me feedback about clarity, typos, and errors to help me improve the writing.

I have even sent posts to clients to help explain how some part of their solution was, or will be, implemented. That additional documentation of their project can help them extend and maintain their own projects.

How-To articles give me practice explaining things

One of the reasons I started blogging in the first place was to keep my writing skills sharpened. How-to articles in-particular tend to be good at helping me refine my process in specific areas. The mere act of writing them gives me practice at explaining technology and that practice pays off in trainings and future articles. If you compare my work on Drupal, Salesforce, and Electron you can see the clarity improve with experience.

How-To articles give me work samples to share

When I’ve been in job applicant mode those articles give me material to share with prospective employers. In addition to Github and Drupal.org, the how-to articles can help a hiring manager understand how I work. They show how explain things to others, how I engage in the community, and serve as samples of my writing.

How-To articles help me control my public reputation

I maintain a blog, in part, to help make sure that I have control over my public reputation. To do that I need inbound links the help maintain page rank and other similar basic SEO games.

From traffic statistics I know the most popular pages on this site are technical how-to articles. From personal anecdotes I know a few of my articles have become canonical descriptions of how to solve the problems.

When I first started my current job we had a client ask if I could implement a specific feature that he’d read about in a post on Planet Drupal. It turned out to be mine. Not only was I happy to agree to his request, it helped him trust our advice. My new colleagues better understood what this Drupal guy brought to the Salesforce team. Besides let’s be honest it’s fun when people cite your own work back at you.

Writing your own

You don’t have to maintain a whole blog to write useful how-to articles. Drupal, like most large open source projects, maintains public wiki-style documentation. Github pages allow anyone to freely publish simple articles and there are many examples of single-page articles out there. And of course there is no shortage of dedicated how-to sites that will also accept content.

The actual writing process isn’t that hard, but often people leave out steps, so I’ll share my process. This is similar to my general advice for writing instructions.

Pick your audience

It’ll be used more widely than whoever you think of, but have an audience in mind. Use that to help target a skill set. I often like to think of myself before I started whatever project inspired the article. The higher your skill set the more you should adjust down, but it’s hard to adjust too far, so be careful is aiming for people with far less experience than you have – make sure you have a reviewer with less experience check your work. Me − 1 is fine, Me − 5 is really hard to do well.

Start from the beginning and go carefully step by step

Start with no code, no setup, nothing. Then walk forward through the project one step at a time writing out each step. If you gloss over a detail because you assume your audience knows about it add reference links. You can have a copy of a reference project open but do not use it directly; it’s there to prevent you from having to re-research everything.

List your assumptions as you go

Anything that you need to have in place but don’t want to describe (like installing Drupal into a local environment, creating a basic module, installing Node, etc) state as an explicit assumption so your reader starts in the same place as you do. Provide links for any assumptions which are likely hard for your expected audience to complete. This is your first check point – if there are no good references to share, start from where that article you cannot find should start (or consider writing that article too). 

Provide detailed examples

Insert code samples, screenshots, or short videos as you progress. Depending on what you are doing in your article the exact details of what works best will vary. Copy and paste as little reference code as possible. This helps you avoid accidentally copying details that may be revealing of a specific project’s details.

If you look at mine you’ll see a lot of places where I include comments in sample code that say things like “Do useful stuff”. That is usually a hint that whoever inspired the article had interesting, and perhaps proprietary, ideas in that section of code (or at least I worried they would think it was interesting). I also try to add quick little asides in the code samples to help people pay attention.

Test as you go

Make sure your directions work without that reference project you’re not sharing. This is both so your directions work properly and further insulation against accidentally sharing information you ought not share.

End with a full example

If you end up with a bunch of code that you’ve introduced piecemeal, provide a complete project repo or gist at the end. You’ll see some of my articles end in all the code being displayed from a gist, and others link to a full repository. Far too many people simply copy and paste code from samples and then either use it blindly or get stuck. Moving it to the end helps get people to at least scan the actual directions along the way.

Give credit where credit is due

If you found partial answers in several places during your initial work, thank those people with links to their articles. Everyone who publishes online likes a little link-love and if the article was helpful to you it may be helpful to others. Give them a slight boost.

Feb 22 2021
Feb 22
[embedded content]

Don’t forget to subscribe to our YouTube channel to stay up-to-date.

This tutorial will demonstrate how to use the Custom Permissions module.

By default in Drupal, user permissions in the Drupal backend are not very granular.

For example, if you want to give a role the ability to edit only the “Basic site settings” in the Drupal admin UI. In Drupal, this can be achieved by giving the access permissions “administer site configuration”. However, with this permission enabled, the role will also have the ability to edit other site settings which you may not want a user to have access to.

Enter the Custom Permissions module.

With this module, you could solve the above problem by creating an extra custom permission to edit only the “Basic site settings” page without assigning the “administer site configuration”.

This light-weight module will allow you to specify the exact admin route (or path) that you want to give permissions to without giving the role access to everything in the administration section.

In this tutorial, you’ll learn how to create a custom permission which will only have access to the “Basic site settings” page. We’ll be using the 8.x-2.x version of the module.

Table of Contents

Difference between 1.x and 2.x?

Both versions accomplish the same functionality, but the difference is that when specifying the page you want to give access to, version 8.x-2.x uses routes and version 8.x-1.x uses paths.

Diagram 1 – Version 8.x-1.x using paths Diagram 2 – Version 8.x-2.x using routes

How to Find out the Route Name

A route in Drupal is a path which is defined for Drupal to return some sort of content on. Routes are defined in a module’s MODULE_NAME.routing.yml file. There can be routes defined in contributed, custom or Drupal core modules.

For Drupal core routes (paths in the Drupal core admin UI), you would want to text-search for the path in: web/core/modules/system/system.routing.yml

For contributed or custom routes, search in the relevant modules’s “.routing.yml” file.

In our example, the block of code in system.routing.yml for our path “admin/config/system/site-information” is:

system.site_information_settings:
   path: '/admin/config/system/site-information'
   defaults:
     _form: '\Drupal\system\Form\SiteInformationForm'
     _title: 'Basic site settings'
   requirements:
     _permission: 'administer site configuration'

The route name is bolded above to show you what the route name will be. The exact route name is: system.site_information_settings.

Using Devel

If you prefer not to search through code to find the route name, look at using the Devel module. Devel comes with a Routes Info page which lists all the active routes and its paths, and you can filter the page. This makes it easy to find the correct route.

Once the module is installed click on the Devel link in the toolbar then “Routes Info”.

On the “Routes Info” page you’ll see a long list of routes and its paths.

Getting Started

This module requires no additional libraries and can simply be downloaded with Composer.

Using Composer:

composer require drupal/config_perms

Installing the module with above composer command will install version 8.x-2.x of the module.

Once downloaded go and install the module.

How to create a Custom Permission

In this tutorial, we are going to create a custom permission to allow a role to access and update only the “Basic site settings” page in the Drupal admin UI.

1. Once the module is installed, go to People > Custom permissions.

You’ll notice that the module comes with four default custom permissions.

2. Click on the “Add permission” button, and you will get an additional row to add a new permission.

3. Give your new permission an admin human-readable name and click on “Save”. Note that this name is only visible to the site admin. The route that we want to use for the “Basic site settings” is “system.site_information_settings”.

4. Go to People > Roles and edit the permissions of the role that you want to assign this new custom permission too. We will use the “Authenticated user” role in this example.

5. Scroll to “Custom Permissions” and you will see the new custom permission human-readable name you created in Step 3. Enable it.

6. For the new role to access the administration pages in Drupal, you also have to enable “Use the administration pages and help”. You can also enable “Use the toolbar” so the user can see the enabled permission in the admin toolbar although this is just for convenience and not a requirement for this tutorial.

7. Now, the user with the role “Authenticated user” will have access to the following permission as shown below:

Summary

Drupal, by default, may not always define granular permissions to certain administrative pages. Typically, a role can be given all or no access to administrative pages.

Using the contributed module Custom Permissions (version 8.x-2.x) you can define custom permissions for specific Drupal admin pages. This module provides finer granular permissions for specific Drupal routes/paths.

Editorial Team

About Editorial Team

Web development experts producing the best tutorials on the web. Want to join our team? Get paid to write tutorials.

Feb 17 2021
Feb 17

As the owner of a web project, you may want to directly access your production site to run developer tools. Historically, many of us would access a live site using SSH for direct shell access on a single static server for traditional hosting. Some hosting providers give limited access to run single commands from a local command line, or start a remote shell session with more complicated commands, but there are delays and it can be a bit like fiddling around in the dark. Add some Kubernetes-based, containerized hosting into the mix and it can feel really intimidating and complicated.

With the release of DDEV-Live CLI version 0.9.2 and API v 0.7.1 you now have the option of initiating an interactive session with a site on our Kubernetes-based hosting platform. We handled the complicated parts so you don’t need to understand the container architecture that holds your project— just connect, navigate around inside the project, and use your command line tools as usual. 

How do I run commands on a remote host?

Previously, in order to run command line tools on a project in a DDEV-Live environment such as production or Preview, you could run a single command using ddev-live exec. (For those of you familiar with the DDEV-Local ddev exec command, this is similar behavior that allows you access inside the web container.) Each command was run individually, and it was difficult to observe the results of the command. Commands could take an unknown period of time to execute, resulting in a loss of momentum, productivity, and even causing a little frustration.

These direct commands are still available and have plenty uses, for example if you just want to set configuration or trigger a single command such as:

ddev-live exec mysite -- drush cr

Until now, running these commands could take several minutes, and the DDEV-Live CLI gave minimal feedback. This is because any command sent using ddev-live exec created what’s called a “job” in the backend on our platform, which would enter a scheduling queue and eventually would be executed. Once the job was actually triggered, the command would run in the expected amount of time, so the delay was just in how the command passed from the user to the project. Good news! We’ve found a better way.

Interactive exec for production containers

Now, the ddev-live exec command consumes our API, which gives everyone more options and flexibility. The exec command itself is faster as a single command and it offers an exciting new interactive mode! Check it out: start a session with ddev-live exec mysite --i [command] and the CLI will start a bidirectional stream of command output between your terminal and the Kubernetes pod where your project lives. The flag --i runs the exec command as an interactive session. Omit it to run a single command as non-interactive.

Instead of waiting for a scheduled “job” to run somewhere in Kubernetes, commands execute right away in both interactive and non-interactive modes. Thanks to the API, you will not connect directly to the pod in Kubernetes, you connect to an API server which brokers everything you type to Kubernetes:

Client <====> API Server <===> Kubernetes

“That was a bunch of words!” you say. Here’s a more specific, super simple, example: run ddev-live exec mysite --i bash. Now you have a shell session open, you’re in the docroot for your project, and you can list files to prove it: 

Screenshot of command line when running `ddev-live exec test-wp --i bash`. A prompt for the remote container appears, and we show listing the files in that directory.

While you’re here, you can start to do all kinds of fun stuff and quickly interact directly with your tools and files. For WordPress users, WP-CLI is available in the container:

[email protected]:~/html$ wp cli version
WP-CLI 2.4.0

Other developer tools and tasks in interactive exec mode: 

  • Inspect sites/default/files. 
  • Inspect code. 
  • See what CMS version is live. 
  • Inspect PHP configuration in /etc/php/. 
  • Confirm PHP major and minor version with php --version
  • Remove files in sites/default/files that shouldn’t be there.
  • Observe a deployment and check whether Composer downloaded the right files to the right places.
  • Explore (and alter) the database with drush sql-cli.
  • Check what code commit is deployed with git log.
  • Top Drush commands like drush cr and drush uli.

With DDEV-Live, you can now initiate an interactive session with your project on production and interact with developer tools in a natural command-line context. You can go ahead and run the commands you need to maintain and administer your project without delays or needing to pull and push entire site updates in order to accomplish simple interactive tasks.

Run commands on production websites

DDEV solves the difficulty of using developer tools on projects in hosted containers and the delay of waiting for individual commands to execute by offering an interactive command line connection to the production server that gives the end user the ability to work directly on their own live projects. That leads to saved time, increased velocity, and the flexibility to work with your projects the way you need to. 

tl;dr – Sign up for a free trial with a DDEV-Live personal account, set up your workspace, spin up a site from a repository on your GitHub account, and try running ddev-live exec newSiteName --i bash. Please let us know how it goes and what else you need! 

Share this post:

Feb 17 2021
Feb 17

TL&DR: Use drupal.org's issue forks to make Drupal 9 compatibility fixes work with Composer.

While most software developers are in agreement on the two hardest things in software development – cache invalidation, naming things, and off-by-one errors – not everyone is in agreement on how to rank the rest of the top ten challenges. One that must surely rank high is dependency management algorithms and dependency management tools. These make sure that different libraries and additions to a codebase are kept up to date and APIs are kept compatible. For example, supposing a codebase has SquareWidget v2 and CircleWidget v2; if SquareWidget v3 comes out but is incompatible with CircleWidget v2, the codebase's dependency management tool would prevent updating to SquareWidget v3 until a compatible version of CircleWidget was available.

In the Drupal world, we've historically avoided formal dependency management as we could just download a package from drupal.org and get running, occasionally realizing "Oh I needed CTools too" and grabbing it. Along the way, some folks built the Drush tool which, amongst other things, could download these dependencies automatically. It wasn't until Drupal 8 came along that more formal dependency management became a thing because of its heavy use of 3rd party libraries, in large part thanks to the use of the Composer system. This tool came out of the wider PHP community's need for a generic, reliable dependency management system, and in the Drupal maintainers' drive to adopt more 3rd party libraries and tools it was the obvious choice. After an initial bumpy learning phase, almost all contemporary Drupal 8 and 9 website projects today are managed using Composer.

The drupal.org infrastructure provides a custom wrapper around Drupal core, module, and theme metadata so that it can be loaded using Composer using its metadata platform Packagist. Modules and themes which already include a composer.json file will have that made available as-is. However, a large portion of Drupal 8 and 9 contrib projects don't have this, so the drupal.org infrastructure maps the info.yml files into a format Composer can understand. This way a module that was initially ported to Drupal 8 a few years ago can still be added to a contemporary D8 project managed with Composer, even if the module hasn't been touched in years. It's awesome.

The World of Drupal 9 Updates

Back in October 2019, a new feature was added to core 8.7.8 which allowed modules to specify the versions they were compatible with by using a new line in their info files. This new line became a requirement on Drupal 9 as there needed to be an indication in modules & themes to indicate what APIs they were compatible with. For most projects the new line makes the info file look like this – note how the old "core" value is now replaced with a "core_version_requirement" value:

name: Commerce Migrate
type: module
description: Provides various Commerce-specific Migrate handlers.
core_version_requirement: ^8.8 || ^9
package: Commerce (contrib)
dependencies:
 - drupal:migrate
 - drupal:telephone
 - migrate_plus:migrate_plus

A module (or theme) could use the new line to indicate they were compatible with both Drupal 8 and 9 simultaneously, and the majority of the most popular modules have made the necessary changes.

Drupal 9 presented the first major release of Drupal core that was such a low impact update it was possible to run many websites on either 8.9 or 9.0 just by swapping the core files out (and updating the dependencies). Gone are the days of having to rebuild a site from scratch for each major upgrade, instead we just have to keep our codebases fully up to date and swap to the new core release pretty quickly.

Except for that one line.

That one new line has to be in each info.yml file in the codebase (except for test files, but that's a different matter), so any under-maintained or unmaintained module or theme will need to be updated. Thanks to the wonders of modern development tools, it was estimated that almost a quarter of all Drupal 8 modules & themes could be upgraded to be compatible with Drupal 9 by just changing their info file! Over the course of 2020, thanks to contributions and collaborations from folks all over the world, a huge number of modules and themes were updated to be fully compatible with Drupal 9, and a large portion of those that don't have releases have patches available.

The Catch-22

The fact that there are patches to make Drupal 8 modules & themes compatible with Drupal 9 is great for maintainers or would-be maintainers - they don't need to go through the efforts of making all of the changes themselves, they can just review what has been provided and, hopefully, commit it. Normally patches are great for end-users too, because again they don't have to take the time to make the change themselves, someone has made it available for them.

Here is what happens when you apply a patch using Composer:

  1. Composer downloads the project's listing from Drupal's custom Packagist system (see above).
  2. It compares the dependencies from the listing against what's currently in the codebase.
  3. It deletes the existing copy of the underlying module or theme, if present.
  4. It downloads a fresh copy of the module/theme that matches the dependencies.
  5. It applies the patch.

Normally this patch process works great - you find a patch, add to your codebase, and away you go, remembering to leave a comment to the patch creators how well it works for you. However, there's a major limitation here - even if the patch contains changes to the composer.json dependencies, it's applied after Composer has decided whether or not to install it.

In short, you can't use a patch to tell Composer that a Drupal 8 module is compatible with Drupal 9.

Improved Code Collaboration Workflows

Drupal originally used CVS to manage the codebase. This was very limited by today's standards, but it was reasonable back in the early 2000s and provided a means to centrally manage the large codebases of both core and the ever expanding array of contributed modules & themes. Proposed changes to these codebases were handled using patch files, which are simply text files which indicate a file to be modified, which lines are to be removed and which are to be added. It worked well enough, but there was a large learning curve for beginners to get past.

Over the years more flexible & functional replacements for CVS became common, including centralized systems like Subversion and decentralized systems like Mercurial, Perforce or git. Rather than take the short jump to another centralized system, the effort was taken to build out a replacement code management platform using git, under the umbrella project name of "The Great Git Migration". Completed in 2011, the effort was lead by Sam Boyer, and the community has been all the better for it.

However, after the git migration was completed the community was still stuck with patch files. While github had its pull request workflow, the Drupal community was screaming at the need for somewhat archaic collaboration workflows.

Skip ahead nine years and an awful lot of discussion and research, in 2020 the community finally had a replacement code collaboration workflow in the form of merge requests via the Gitlab system. This new workflow allows anyone to create a fork of a project, make changes, and then create a gihub-pull-request -like change request, dubbed a "merge request", for others to review. Unlike github's pull request system, it's also really easy for anyone to collaborate on the same merge request, which lends itself really nicely to collaboration with others rather than solo development. After some opt-in beta testing, the new system was launched community-wide for every single code project on drupal.org to use.

The new issue fork and merge request system is based upon the simple concept that each individual issue on drupal.org can have its own copy of that project's codebase, an issue fork, and that codebase can be downloaded individually using git. With an issue fork anyone can make whatever changes they need directly with git and others can then download those changes directly using git - no additional tools needed, no patch files flowing around.

This also means that it's possible to tell Composer to download the codebase from an issue fork instead of from the main repository.

This means that an issue fork can be used to get around Composer's patch-vs-dependencies catch-22!

Putting it All Together

First off, it should be noted that issue forks are, to all intents and purposes, a separate physical repository than the parent project they fork from. This means that you cannot just download the issue fork by telling Composer to use a specific branch of the main project, Composer has to be told to use a completely different repository.

It's also worth bearing in mind that, for a given Drupal project (module or theme), only one issue fork can be used at a time. Because an issue fork is a separate repository, it isn't possible to download two different versions of the same module/theme and magically have them squish together. Therefore, if multiple merge requests / issue forks are needed for a given project then the others have to be applied as patches; alternatively, a separate "meta" issue could be created that combines multiple changes into one merge request, but at that point it might be easier to just become a maintainer and commit the changes.

In this example, I'm going to use the merge request created for the Drupal 9 compatibility issue for the Commerce Migrate module.

  • First off, find the issue fork portion of the d.o issue, which should be right underneath the list of attachments & patches, which is underneath the issue summary.
    Issue fork options
  • Click the "Show commands" button to expand out the example git commands.
    Show commands
  • In both the "Add & fetch" sections there will be a "git remote add" line. Included in this is a URL that's needed to download the codebase from the issue fork - one starts with "[email protected]" while the other starts with "https://git.drupalcode.org". Because of how these things work, the "https" one is the most reliable option to use, especially when using some sort of a build system for managing the site. Copy the full line (click the "copy" icon to copy it to the clipboard) and extract the URL, e.g. "https://git.drupalcode.org:issue/commerce_migrate-3150733.git".
  • Click the "commands" button again to hide them, and then get the branch name, which in the example above is "3150733-drupal-9-compatibility".
  • In the site's composer.json file, in the "repositories" section add a new item with two values: {"type": "git", "url": "URLFROMABOVE"} e.g.:
           {
               "type": "git",
               "url": "https://git.drupalcode.org/issue/commerce_migrate-3150733.git"
           }
  • Look for the item in the "repositories" section that has "type" set to "composer" that has the "url" value "https://packages.drupal.org/8". If it doesn't exist already, add an item to that definition called "exclude" and make it a list. Add the Composer name of the module/theme you want to use, e.g. "drupal/commerce_migrate", so that it looks like this:
           {
               "type": "composer",
               "url": "https://packages.drupal.org/8",
               "exclude": ["drupal/commerce_migrate"]
           },
  • Change the listing for the project in the "require" (or "require-dev") section to point to the branch name identified above, e.g. "drupal/commerce_migrate": "dev-3150733-drupal-9-compatibility",
  • Save the changes to the file.
  • Update the project in composer, e.g. composer update drupal/commerce_migrate.

The last command will now download that project from the issue fork instead of the main codebase.

Note: these should only be used as a short term solution, the goal should always be to collaborate to get changes committed so that these steps aren't needed.

For clarification it should be mentioned that the "exclude" change can be skipped by listing the new repository above the existing D8 one, however I prefer to use "exclude" as it's more verbose and depends on less Composer magic in order to work.

But it Didn't Work?

One problem that can arise is that Composer can't process the project, which it will tell you with this error message:

  [Composer\Repository\InvalidRepositoryException]
  No valid composer.json was found in any branch or tag of [email protected]:issue/commerce_migrate-3150733.git, could not load a package from it.

This simply means that the project doesn't have a "composer.json" file in it, so you can fix that by adding a composer.json file to the repository. Once that is created (make sure to run "composer validate" before saving it!) and uploaded to the issue fork, it'll be possible to download it to a site's codebase again.

Put That Thing Back Where it Came From or So Help Me

Because they don't keep current with upstream changes and can fall out of date quickly, issue forks should be used sparingly in website projects. As it happens, the patch for Commerce Migrate I wrote this blog post around was committed between the time I started the blog post and it was published – "The Drop Is Always Moving", as they say.

When the day arrives and the project has its Drupal 9 fixes committed, there are a few steps to remove the issue hackery and make the website's codebase happy again.

  1. Remove the extra "repositories" item.
  2. Remove the "exclude" line from the "type":"composer" repository; if there aren't any remaining items in the "exclude" section it can be removed entirely.
  3. Change the "require" line (or "require-dev" line) back to point to the appropriate release that includes the Drupal 9 fixes.
  4. Run "composer validate" to make sure the composer.json file is correct.
  5. Run "composer update drupal/PROJECTNAME" to get the new, cleaner version of the project.
  6. Commit the changes.
  7. Celebrate.

That Was a Lot of Words, Do You Have a Picture?

This topic was covered in a recent Contrib Half Hour. Because I forgot to record that meeting (I'm a professional, honest) I repeated the steps the following week, so now there's a recording of me stepping through the process to create an issue fork to make a Drupal 9 fix for a Drupal 8 module work in Composer:

[embedded content]

Feb 11 2021
Feb 11

Last week one of our clients was asking me about how they should think about the myriad of options for website hosting, and it inspired me to share a few thoughts. 

The different kinds of hosting

I think about hosting for WordPress and Drupal websites as falling into one of three groups. We’re going to compare the options using an example of a fairly common size of website — one with traffic (as reported by Google Analytics) in the range of 50,000–100,000 visitors per month. Adjust accordingly for your situation. 

  • “Low cost/low frills” hosting — Inexpensive website hosting would cost in the range of $50–$1,000/yr for a site with our example amount of traffic. Examples of lower cost hosts include GoDaddy, Bluehost, etc.  Though inexpensive, these kinds of hosts have none of the infrastructure that’s needed to do ongoing web development in a safe/controlled way such as the ability to spin up a copy of the website at the click of a button, make a change, get approval from stakeholders, then deploy to the live site. Also, if you get a traffic spike, you will likely see much slower page loads. 
  • “Unmanaged”, “Bare metal”, or “DIY” hosting — Our example website will likely cost in the range of $500–$2,500/yr. Examples of this type of hosting include: AWS, Rackspace, Linode, etc. or just a computer in your closet. Here you get a server, but that’s it. You have to set up all the software, put security measures in place, and set up the workflow so that you can get stuff done. Then it’s your responsibility to keep that all maintained year over year, perhaps even to install and maintain firewalls for security purposes. 
  • “Serverless” hosting¹ It’s not that there aren’t servers, they’re just transparent to you. Our example website would likely cost in the range of $2500–5000/yr. Examples of this kind of hosting: Pantheon, WP Engine, Acquia, Platform.sh. These hosts are very specialized for WordPress and/or Drupal websites. You just plug in your code and database, and you’re off. Because they’re highly specialized, they have all the security/performance/workflow/operations in place that 90% of Drupal/WordPress websites need.

How to decide?

I recommend two guiding principles when it comes to these kinds of decisions:

  1. The cost of services (like hosting) are much cheaper than the cost of people. Whether that’s the time that your staff is spending maintaining a server, or if you’re working with an agency like Advomatic, then your monthly subscription with us. Maybe even 10x.  So saving $1,000/yr on hosting is only worth it if it costs less than a handful of hours per year of someone’s time. 
  2. Prioritize putting as much of your budget towards advancing your organization’s mission as possible. If two options have a similar cost, we should go with the option that will burn fewer brain cells doing “maintenance” and other manual tasks, and instead choose the option where we can spend more of our time thinking strategically and advancing the mission.

This means that you should probably disregard the “unmanaged/bare/DIY” group. Whoever manages the site will spend too much time running security updates, and doing other maintenance and monitoring tasks. 

We also encourage you to disregard the “low cost” group. Your team will waste too much time tripping over the limitations, and cleaning up mistakes that could be prevented on a more robust platform.

So that leaves the “serverless” group. With these, you’ll get the tools that will help streamline every change made to your website. Many of the rote tasks are also taken care of as part of the package. 

Doing vs. Thinking

It’s easy to get caught up in doing stuff. And it’s easy to make little decisions over time that mean you spend all your days just trying to keep up with the doing. The decision that you make about hosting is one way that you can get things back on track to be more focused on the strategy of how to make your website better. 

¹ The more technical members of the audience will know that “serverless” is technically a bit different.  You’d instead call this “platform-as-a-service” or “infrastructure-as-a-service”. But we said we’d avoid buzzwords.

Feb 11 2021
Feb 11

In our recent webinar, we set out to help higher ed marketing teams rethink their digital focus for the year ahead. 

We tapped a group of experts with years of experience helping some of the best-known colleges and universities deliver engaging digital experiences to discuss key web strategy takeaways. Members of the expert panel included:

  • Muzel Chen - Senior Digital Strategist, Mediacurrent 
  • Diane Kulseth - Senior SEO Consultant, Siteimprove 
  • Steve Persch - Technical Product Marketing Manager, Pantheon

If you missed our webinar or want to watch it again, check out the full recording: 

[embedded content]

The live audience came ready with their most pressing questions on topics from personalization and SEO best practices to harnessing analytics and breaking down the communication barriers between Marketing and Admission departments. Below is a summary of what was discussed on the webinar. 

Personalization 

Is personalization dead?

Diane Kulseth: I've seen some higher education institutions using personalization effectively by auto-populating forms. That can be really helpful to keep things seamless for the experience for the student. At the same time, we're talking to a generation that's getting more and more skeptical of the internet. 

There's a misconception that adopting new technology will automatically save you time. Technology, like personalization, can save you a lot of time but it will also take time to implement correctly.

Steve Persch: Technology buying decisions are often made on the assumption that by buying a tool, you will get to spend less time doing a certain task. I think a similar motivation leads a lot of people to buy personalization. They think getting a more powerful measuring tool will fix their problem, but it actually gives you more to measure and requires more of your time.

Muzel Chen: There’s also the issue of how do we use personalization effectively? Students want to get information right away and personalization can reduce these obstacles in navigation and process.

Personalization can mean many things, but in the context of higher ed, we can personalize content for an audience based on their common demographics and behaviors. But it also depends on your medium: are you trying to personalize in social media? Website? Email? Text message? Audiences have different expectations from each marketing channel, which is predicated by the amount of PII (Personally Identifiable Information) they have disclosed to those channels. 

Depending on the context and level of personalization, they can range from convenient to creepy, and striking that right balance can be tricky. But when it works, visitors experience a higher level of engagement because of the convenience and they feel the institution cares about them.

SEO Best Practices for Subsites and Domains 

When thinking about a redesign, I know websites should have ONE main goal, but how do you handle a few different audiences without creating microsites? For example, prospective vs. current students?

Muzel Chen: Some of these issues are mitigated by dedicating an area in your architecture for those specific audiences. But there are situations where it feels the content is servicing all audiences or only one exclusively. These situations typically result in microsites which can be difficult to manage. 

An easy way to address those needs is to start with an audience-neutral page, have the audience self-identify, and place those audience-specific pages at a deeper level. For example, common pages where this occurs are: campus living, parking permits, and health services. These top-level pages will have content that speaks to all audiences and grows in detail as the visitor goes deeper into your site. The details can then begin to diverge by audience type. 

Do you see any trend of separate sites vs. subsites for academic departments (or other smaller units) within a university or college?

Muzel Chen: Over the last decade, it's been very common for higher ed to have subdomains (separate sites) for each individual department or school. But, these sites grow out of hand and become difficult to manage especially when there's not any established governance for tracking content updates across all of the subdomains. 

More institutions are starting to transition to the subfolder (or subsite) practice. It’s easier to see the big picture of all your sites and manage them all within their content management system. 

How can one build a culture of importance for SEO across a decentralized organization (i.e., schools, departments, and offices, like Admissions, all run their own websites)?

Diane Kulseth: I think the biggest part is tying it back to what it all means. Whether it's donor relations, increased revenue for the university, or admissions, tie it back to their goals. That's first and foremost and all of that helps the website and it helps your students. It helps your donors. It helps your prospective parents of students to be able to better navigate the website. 

SEO is great for SEO's sake and building great traffic, but it's also really helpful for all your other marketing initiatives to make sure that people are able to get where they want to go on a seamless web experience that loads properly and is easy to navigate with strong information architecture. 

Marketing Strategy and Analytics 

What are some of the challenges you've seen higher ed leaders face when implementing marketing technology?

Muzel Chen: Reporting. I often see data collection tools being misconfigured. Or collecting lots of data without really defining its purpose. Everybody wants to get access to analytics data, and once that's provided, they use it once and never touch it again. Suddenly, you have 100 users and nobody is providing insights. Without data, all planning comes down to guesswork.

Steve Persch: You almost need Google Analytics for your Google Analytics to track who's using it.

Which analytics data seems to be the most valuable to higher ed? I realize this is likely very organization or campaign dependent, but anything generally useful that may not be obvious?

Diane Kulseth: First and foremost, you want to have your reports on RFIs or requests for information and your applications, and then connect that to enrolled students within your CRM or admissions platform. 

Beyond that, once you start digging deeper, it's really important to start looking at insights like when people are coming to this page from an advertising campaign, are they actually engaging with the page for a substantial amount of time? Are they going elsewhere? How are they responding to your marketing messages? Can you get even more granular and start looking at the demographics behind them? Are these men, women, what are their age ranges? What other insights can you glean from your different tools? I think all of that can be really helpful, but again, start with your basics: RFIs, enrollments, and applications.

Overcoming Department Silos 

Do you have any tips for how Admissions and Marketing can work together?

Steve Persch: Shifting to an iterative or agile mindset for your website is especially difficult when so much of a university operates on a semester or year-long calendar. There's an expectation that you need the web plan for the next year or 10. Saying we're going to do small experiments and get feedback week by week is challenging to accomplish in the higher ed ecosystem. However, I think that you need to find a way to do it with strong cross-departmental relationships across those silos. 

Muzel Chen: We talked about analytics access as one of the technology challenges, but as far as a people challenge, what I see most often is communication. A lot of departments are still siloed — especially marketing and admissions.

A good starting point here is setting up a meeting cadence where you can share common challenges to solve and opportunities to pursue. For example, an ideal project is to link marketing and admissions data, which tracks the visitor as they leave the main site and enters the application process. Marketing could validate their campaigns by reviewing the application data, whereas admissions could personalize the student experience by using marketing’s data. 

Optimize Your Higher Ed Site 

Explore how RainU CMS can help your school launch on Drupal in 30 days or less with a Pantheon-powered hosting solution. Together with Siteimprove, Mediacurrent’s digital strategists can help you optimize your website for SEO, accessibility, and overall performance. 

Feb 09 2021
Feb 09

[embedded content]

It is not uncommon for links to be styled like buttons when building websites.  Although this is not frowned upon, it is important to understand what HTML element to use depending on the purpose of that element.  For example, a element is frequently used to perform an action such as submit a form, or interact with an element to change its behavior., whereas s element is often used to direct the user to another page, site, or section of a page.  Visually it may not make much difference how links or buttons are styled, but choosing the right element matters from a semantic and even accessibility perspective.  Let’s go over how to dynamically render the right HTML element depending on the element’s purpose using Twig on a Drupal website.

Before we get into the details of the code, let’s understand how the two elements differentiate from each other which will help us qualify the right element to use.  Probably the easiest way that makes the

and different from each other is that a contains a href attribute and the does not.  This alone can help us determine whether we should use a or element on our site.  The href attribute will always be present when using an anchor element.  So let’s use the href attribute to our advantage.
  1. Let's start by defining some key data elements we usually have at our disposal when building a button or anchor element in Twig or React:  url, text, class
  2. It’s possible we won’t always have url or class, but text will most likely be available so we can label the element (i.e. Read more, Submit, etc.)
  3. We know that a will always need a url.  We also know a
will never have a url value</li></ol>

Using the logic above, we could start writing some code.  Let’s start with Twig and then we will repeat the process with JavaScript if you are working on a React or Gatsby project.

{% if url %}

  

    {{ text }}

  

{% else %}

  
    {{ text }}    {% endif %}

JavaScript and/or Gatsby

The logic to follow in any other language will be the same. The syntax may vary but ultimately we are checking for a URL and if so, let’s print a element, otherwise, let’s print a element.  However, in Gatsby there is one more scenario to consider; is the URL internal or going to an external page/site?  One of Gatsby’s powerful core components or features is .  This is used to prefetch pages in a gatsby site which results in incredible performance improvements.  So our logic just got a little more complex because not only do we need to check for whether there is a URL, we also need to determine if the URL is internal or external.  If it is internal, we will use a component, otherwise, we will use a traditional element.  Let’s see how we can make this work.  In an effort to keep this example short and to the point, I am excluding some pieces you normally would see in a real gatsby component.  This would typically be done in a button.js file.

import React from 'react';
import { Link } from 'gatsby';

const Button = ({
  children,
  to,
  href,
  ...props
}) => {

  // If the `to` prop exists, return a link.
  if (to) {
    return (
      
        {children}
      </Link>
    );
  }

  // if the `to` prop does not exist but `href` does, return a  element.
  if (href) {
    return (
      
        {children}
      
    );
  }

  // If the `to` or `href` props do not exist, return a 
element. return ( {children} ); }; export default Button;

If a to prop is identified, we return a Gatsby component. As we can see this is a more complex piece of code but ultimately does the same thing as when we wrote it in Twig.  The difference here is that we are detecting three scenarios to determine which element to return:

  • If href prop is detected instead of to, we return a traditional element with target="blank" and rel="noopener noreferrer", According to Gatsby docs, routing to target="_blank" is the equivalent of an external page and Gatsby cannot be used. Docs here: https://www.gatsbyjs.com/docs/linking-between-pages/#using-a-for-external-links
  • Finally, if neither to nor href are detected, we return a element.

In Closing

Some may not see the need to go to this extreme to simply decide whether we need a button or anchor element.  However, there are many reasons why this is something you should consider as this could impact accessibility, UX, and in the case of Gatsby, even your site performance.

Feb 09 2021
Feb 09

Now on Drupal 9, the community isn’t slowing down. This month, we continue our interview with Angie Byron, a.k.a Webchick, a Drupal Core committer and product manager, Drupal Association Board Member, author, speaker, mentor, and Mom, and so much more. Currently, she works at Aquia for the Drupal acceleration team, where her primary role is […]

The post Community Corner: Interview with Angie Byron, Part Two appeared first on php[architect].

Jan 28 2021
Jan 28

Photo of Hilmar Hallbjörnsson at DrupalCon Amsterdam trivia night 2019 by Illek Petr.

10 minute read

How often do you get to chat with a viking about web development? After DrupalCon Europe last December a few folks got together on Zoom to emulate our usual “hallway track” coffee hour chats, and I learned that a couple friends have been leveraging DDEV-Local to teach web development to newcomers. This is the second blog in the series, please read more about Mauricio Dinarte giving students a quick path to success here.

Hilmar Hallbjörnsson has been a friendly face at Drupal events around the world for so many years we’re not sure where or when exactly we first met. Drupal GovCon? Drupal Europe? In a community fond of headwear, Hilmar, aka drupalviking, stands out in various horned helmets at events. He is currently living and teaching in Iceland and recently taught a web development course at Reykjavík University.

How long have you been working with Drupal?

I’ve been a Drupal developer for nine years now, starting back in 2011. Before that I had written three or four CMSs on my own. After I got to know Drupal, I started crying because I realized that I would never-ever-ever have to write authentication methods again. So it was love at first sight, definitely. In the nine years since it’s just kept growing and maturing in many ways.

Actually, admitting being a PHP developer in Iceland is difficult,  it would be easier to admit that you belong to a goat sacrificing cult! People talk about how PHP was back in the day when we were running PHP 4.7 but all my servers are now on PHP 7.4, so things have changed just a bit.

What topics do you teach new web development students?

I teach a course called “Developing open sourced web software” at Reykjavík University. Because of COVID, they called me in the middle of October, and asked me if I could deliver a course in the last week of November. My colleague, Reynir, and I looked at each other and said “Þetta reddast,” which is a common saying in Iceland: “We will figure it out somehow.” And we did! After this year, we might try to set that up so I could teach it in multiple schools as an online course.

The course begins with exploring: what is open software? What are the types of open software? What are the licenses? What does “free” and open source really mean? Then we got into how  web software is delivered, with mostly open source AMP (Apache, MySQL, PHP) stacks. Then we kept on going with how to contribute to open software.

We started with Drupal, had two projects, essays, a verbal exam, and students had to keep a diary to log what they did. Part of that was to train them to write good commit messages later and be able to verbalize what they were doing and why. They got to know Drupal as a site builder, creating a simple music or board game collection on the site, using views, user permissions, image styles and so on. We had to scale down the second project in the course from bug hunting to writing a little API that could look up a song or a board game, and then add it to a collection via services. That was a sufficient challenge for a three week course.

What tools, software, guides do you offer web development students?

For local development, I used DDEV exclusively. Connecting and setting up everything with DDEV — that was the second time I literally cried. I used to have problems down the ying-yang; I had written five or six huge blog posts just for my own reference on setting up my work computer, to get Apache running, MySQL running, trying to configure SSL (which never worked right), trying to get the debugger running. It was a headache and a half. Then maybe a year or two years later, when I had to do it all again, everything was outdated. 

Almost the whole time that I’ve been working I’ve been a one man team. When you are in a bigger company you would have the DevOps expert who understands everything about Docker, and everything about what’s happening under the hood. I was always trying to understand what exactly Docker was doing at the same time as I needed to be building the site, managing clients, and umpteen other task. 

Then I got DDEV, and being able to say `brew install ddev`, then just the `ddev config`, enter, enter, enter, then `ddev start`. My site is up and running! Oh, I need more memory for Maria DB? Okay, no problem, tikatikatak, `ddev restart`, up and running. So being able to both use it professionally and to start students on a project was great. 

I did record a few lectures because we had a very short timeframe of three weeks so there wasn’t time to send them off to research on their own as much. I also refer students to Drupalize.me as supplementary material to the lectures.

But, again, having a tool like DDEV helped me out a lot. DDEV have done the hard work, you are the experts in Docker. I was able to explain how open source software works in general, then point them to DDEV and have them follow the documentation to install Drupal. It’s important to understand what’s under the hood, but just as with a car, you know there is an engine in the front, and you know the shape of it. But probably you, like me, open the hood, and say nope! let’s call a mechanic.

What are some pros and cons to using DDEV for local web development?

As a convert from Windows, I’ve been very happy with how quick and easy getting started with a local development environment on a Mac is. All my students that had Mac were up and running within 30 minutes. But we hit some snafus with Windows. Some of them were because they had some other web servers or port problems. Any previously configured machine from a student who installed a lot of programs for some of their courses was a headache, but we were able to get everybody up and running. My colleague Reynir runs Windows himself, so he took care of all the Windows people. On his personal machine it was smooth once we figured out that WSL was the way to go.

There is a little bit of DDEV documentation that could improve. I was trying to use Drupal Console but I couldn’t find how to initiate the Drupal Console with the command line as you would with Drush, eg `ddev drush`. ed note: There’s now an answer for this on StackOverflow, and any custom command can be added to DDEV.

I also noticed if I was trying to debug with drush commands, xdebug, and phpstorm, I had to ssh into the web container and then run the commands, going into the vendor directory. It was just an unfamiliar sequence of things I had to do in order to get to the right place and run the right commands. 

In general, the documentation is good, but it’s very technical. It would be nice to have more visual guides rather than just text. I experience that a lot in my hobby, board games, reading and editing a lot of rule books, so I know that a user often wants a more visual explanation. It’s easy to skip over a line of text and miss something very essential. For a lot of people who are a bit less used to technical documentation it can be a hurdle to get started.

DDEV-Live hosting would also benefit from a really clear guide: this is what you do to get up and running, and you’re done. ed note: Once you sign up for an account on DDEV-Live there’s now a visual stepper to get started. More soon! please give it a try and let us know what you think.

Hilmar in a wig with two large braids and a helmet with goat-like horns.@drupalviking photo by Michael Cannon

Have you worked with other open source CMSs much?

I actually wrote my first WordPress plugin two weeks ago, because I had to create a API endpoint and fetch some data. After that experience, I am more confident that I made the right decision back in 2011 with Drupal! I tried Joomla and Magento back in the day but they’ve changed so much since then.

I’ve also done some custom CMSs with very strange customer requests. Probably the most fun that I’ve had was to make a website where you rented sheep. You would rent a sheep for a year, it lived on the farm, and you got the lamb in spring, then the mutton, wool and whatever in the fall. You could go visit “your” sheep of course, and there was a social aspect on the site with photos and such. But a disconnect with the salesperson resulted in overpromising and under delivering and it didn’t work out. It actually would be very, very exciting to try to implement that again, and use Drupal to do that. It was that kind of project that is so absurd that you really want to see it through.

How did you become interested in teaching web development?

Before I graduated back in 2012, I was a teacher’s assistant. For my last year, I was the TA for people not living close to Reykjavík who had online meetings instead of in person, so virtual learning is not new to me. My professor was always saying we needed to teach more PHP, all these CMSs are based on it, and that idea just got more focused on Drupal over time.

At Reykjavík University, we have a special project to culminate our studies where students work on something outside of the school, in the “real world,” instead of writing a thesis. I was working as a project manager for the Music Association of Iceland which had a very old system that needed new software, database migration, everything. I approached Reykjavík University with that project, and we were lucky enough to get a great great team of five people, four of whom were women. So, when the school project was finished we were about 85% ready to actually deploy, and that code has actually been up and running since. Very proud of that. 

Then this past fall I pitched a Drupal migration as a project for students and had three students the whole semester doing a Drupal 7 to Drupal 9 transformation of a site. So I was already teaching Drupal when they asked me, can you do this intensive course? Then we just gathered a bit more material and carried on. And now we are proud to say that two of the students are now employees of our company, Um að gera. Even prouder that we were able to hire women in both positions.

Everyone learns in different ways for sure. For me, I learn visually, and I learn by example — I am not the greatest investigator. A colleague and best friend of mine works very differently from me, but as a pair we work so great together. He gets bored very, very quickly so he is constantly trying out new things. That’s not what I like to do. He can go and say, okay, I boiled it down, I checked seven different things this is how you do it. He explains that to me in maybe 30 minutes, 60 minutes, because we know each other’s lingo. Then I implement that, and I take it further. And that just works well together. So, strengthening people’s individual skills and tendencies and helping them find where they fit in a team is also an important part of teaching.

What do you see in the future for teaching, web development, and open source?

I think we just have to do more. What I want to see is: can we streamline and standardise how we teach Drupal? As I said, everyone learns differently, but there are so many approaches, methods, materials it’s overwhelming. Drupalize.me is quite a good website, but the structure going from A to B to C is sometimes a little bit convoluted. I struggled a lot when I was doing the transition from how to site build into teaching people how to really program. Then I found this book — called Drupal Nine Module Development, by Daniel Sipos, that was very helpful and very up to date.

At the same time, I was transitioning from functional programming to object oriented programming. Teaching this course also revealed how hard it is to teach object oriented programming. It’s much easier to explain object oriented programming when you have some concrete things to implement, like when I have my students implement custom entities. Just by explaining how the interfaces connect, and I am implementing this interface, and I am extending a base abstract class… The learning curve is such a steep one. You’re not only teaching PHP, and Drupal, you’re also teaching object oriented programming to people who haven’t encountered anything like it before.

How do you think we could unify efforts and standardize teaching Drupal? Is there an initiative for that already?

If there is an initiative, I would definitely want to be a part of that. We need to have a unified process so there are various tracks to get into Drupal. Where are your skills? Every skillset is important. When we started giving people contribution credit for documentation and contributing in other ways, not just code, that made our community much, much better. We were almost deteriorating the community by putting coders on a pedestal, and everybody else was not recognized. Having people who are specialists in QA, or who are great with writing or marketing is equally as important as writing the code itself. 

We need an initiative to address how we are teaching Drupal to the world so that any person can come in and understand how things work and how they fit in. That’s why I’m very interested in doing this, to create a solid toolbox for teachers, and to share ideas on how to teach and how to build using realistic example projects. Something you can go through from installation to completion, from a variety of angles. If you’re a site builder start here, do this. If you’re a designer, download this, follow this guide. We are drowning in work in the Drupal world, we need all the help we can get, so how about we have a great way to teach newcomers?

Where to find Hilmar

Hilmar’s company, for which he is backend Drupal dev, DevOps expert, CEO and CTO is Um að gera, and his personal blog is DrupalViking.com. Look forward to a blog post about updating that site from Drupal 8 to Drupal 9 this February!

Do you have expertise in teaching web development? Would you be interested in joining an initiative? Drupal Core Mentoring is also working to streamline on-boarding for new contributors, especially at DrupalCon events. Continue the conversation with us this spring at DrupalCon North America! In the meantime:

*/

Share this post:

Jan 27 2021
Jan 27

RainU logo

On the heels of our recent Drupal 9 release of Rain CMS, we are excited to officially announce the beta release of our Rain University platform, RainU. RainU CMS is a Drupal-based development platform made just for higher education. Colleges and universities can now launch new sites faster with full, flexible control over content.

The RainU CMS Theme

RainU for Drupal homepage with hero image shows a group of students in graduation caps

New RainU CMS theme homepage

The RainU theme is based on the main Rain base theme but adds additional features that are relevant for university websites. The navigation and content have been staged to help content authors get started quickly. Some of the new features added to RainU are the event and quote carousels, as well as more components for highlighting content.

Building pages

RainU CMS content field for frequently asked questions

Rain CMS admin content edit page

RainU content authoring

Paragraph browser dialog

With Rain University, we give content authors the freedom and flexibility to build robust pages using a library of pre-stocked components (called “paragraphs” in Drupal). The Rain Admin UX offers many improvements over the stock Drupal admin which makes the overall experience more intuitive for editors.

Find out more

Currently, Mediacurrent’s Rain University CMS is available to new and existing clients. Our team of strategists, designers and developers can work with your organization to migrate your website from a legacy CMS onto an enterprise, open source platform.

For more information on the benefits of Rain University CMS and to schedule a free demo, please visit the RainU page or chat with us right now (see bottom right corner of the page). We would be happy to talk more about your project or schedule a demonstration.

Jan 27 2021
Jan 27

I recently recorded a video series tutorial about progressive Drupal decoupling. In this series I take two of the official React app examples and turn them into widgets. Your Drupal editorial team can then embed those React applications (a calculator, and an emoji selector) as blocks in a page, as a field in a content type, as an embedded entity in the body field using the WYSIWYG, …

#1 Embed Any JavaScript Application

In this first video in the series we will take one of the offical examples from react and we will turn it into a widget ready to be embedded in Drupal (or anywhere else).

Steps

  1. Create new repository from template.
  2. Migrate source to new repo.
    • Copy new source files.
    • Adapt index.js (including render function).
    • Combine package.json.
    • Find & replace «widget-example».
    • Remove / add specific features.
  3. Reformat and execute tests.
  4. Execute locally.
  5. Deploy application.

#2 The Registry & the App Catalog

The widget registry is the place where you aggregate your widgets (and other people’s widgets you want to use) to make them discoverable to Drupal and other CMS integrations.

This piece plays a fundamental role in the governance of your project(s). You can choose to have a single registry for all your Drupal installations, or one registry per project. You can use the pull requests to gatekeep what versions are added to the registry and who can publish them. The idea is that the owner of the widget-registry project has the authority of accepting PRs to add/update widgets so they are available in the registry (and therefore in Drupal).

#3 Set up Progressive Decoupled Drupal

In this video we will learn how to connect Drupal and the widget registry to let editors embed JS applications all over Drupal (that includes support for i18n!).

You can, for instance, embed JS applications as blocks, as a field for a content type, in the body field as an entity embed, …

Photo by Shifaaz shamoon on Unsplash

Jan 26 2021
Jan 26

As we look ahead to the end of the future academic year and what the future looks like, we see uncertainty clouding what is a typical admissions season for teams in higher education. 

Recently, we asked our partners in higher education to share their digital challenges. We heard that admissions personnel, as well as marketing teams at the college and university level, are feeling the pressure. They need to make sure the expectations of stakeholders are met or exceeded despite the unpredictable path ahead. 

Even though teams may face challenges ahead, one thing is certain: rethinking digital strategy to set your path forward will set your team up for success and your institution apart from others. 

The website is the heart of your digital strategy, and both should be built to adapt. That’s why many higher education institutions choose Drupal for their organization’s CMS. 

Below are five areas to focus your digital strategy, with some of our favorite tips and tools to improve campaigns moving forward.

Reevaluate Your Content Strategy

Universities used to enjoy a steady flow of students enrolling in programs. However, the future is now uncertain because of the COVID-19 pandemic leading many students to forego education or to choose online courses over taking classes in a traditional, physical environment. 

The uncertainty affected not just marketing teams at universities, but students as well. When the McKinsey higher education survey was conducted in April 2020, 37% of responding students were confident that things would return to normal by the end of summer. However, the 2020-2021 school year has thus far reflected much of what the previous school year 

Findings from our own client survey showed that uncertainty in the 2020 recruitment season led to several shifts in strategy to further help the user journey in the decision making process of choosing programs such as the following: 

  • Virtual tours rather than in-person tours
  • Live video conferences rather than in-person sessions
  • Website content to supplement brochures and physical marketing materials

Changes in academia lead to a shift in messaging, so teams need to evaluate if their content strategy is still working or if more needs to be done to cater to today’s student and their new priorities. 

Some ways in which evaluating content strategy can be done include: 

Persona research

 Although you may have a general idea of who your target audience is, more thorough research that includes user surveys can help create a better understanding of who your content should speak to. For instance, you may learn from user surveys that students and parents are uncertain about returning to in-person learning because they want to know more about what is being done to keep people safe in the classroom. With this information in mind, you might develop more content about COVID-19 cleaning protocols to give them peace of mind.

Content audit

Is your content resulting in growth, and does it cater to your users? If you are not getting the most out of it, an audit can help address gaps and find opportunities. 

Dashboard creation

Making sense of data is an important responsibility of a university’s marketing team. User-friendly dashboards can simplify the process of reviewing data and making decisions based on findings. Working with a digital strategy team with experience in higher education to improve your approach can yield results that allow your content to better serve student needs.

Give Your Marketing Team The Tools to Succeed

Giving the university marketing team agency in creating content quickly and efficiently is a top priority of many agencies that work directly with these teams. However, finding a CMS that provides the flexibility they want and a user-friendly editorial experience they need can be a challenge.  

RainU CMS can improve the editorial experience for content editors looking for a solution that allows for easier workflows that match with your existing design standards. With the ability to launch sites in 30 days or less, Rain helps both content editors and developers create flexible websites fast.

If your site is on Drupal, creating a decoupled solution with Gatsby may be just what you need. The business case for decoupled Drupal with Gatsby can help you determine if the cost and benefits are right for your university. Our developers are well adept at providing guidance in setting up GatsbyJS.

Using Drupal with Gatsby is a great way to get an enterprise-quality CMS for free, paired with a great modern development experience and all the benefits of the JAMstack, like performance, scalability, and security.

Gatsbyjs.org

Make Smarter Use of Resources  

Unprecedented changes in higher education likely result in unexpected changes to budgets and priorities. Streamline the routine maintenance of your Drupal site to shift more budget toward new features. Here’s how Mediacurrent’s development solutions like Automated Updates and Multisite+ can help:

With Automated Updates, you can save hours of manual development work. Our automation services initiate pull requests, create JIRA issues, and stage updates within Pantheon’s multidev environment. Your team of project managers and developers can focus on productive work rather than administrative tasks when using Automated Updates for your project. 

Need to create multiple sites? Spin up new instances with Multisite+! With a shared codebase, your sites can go from concept to creation quickly and efficiently, and each has its own database, configuration, files, and base domain or URL to help with organizing your content. 

We have a wide variety of development services to meet your university marketing needs. 

Enhance Web Accessibility 

Universities cater to individuals of all abilities, so it’s important to make sure the digital experience is accessible to all. Using a tool like Siteimprove can help university marketing teams better understand how their site’s accessibility matches up to Web Content Accessibility Guidelines (WCAG) standards. 

SiteImprove dashboard with circular progress charts for QA, accessibility, SEO

SiteImprove's automated reports provide an easy way to measure and document progress toward accessibility goals

Failing to keep on top of website accessibility could lead universities to face warnings from the Department of Education as well as lawsuits. Mitigation measures such as using Siteimprove or working with a skilled accessibility team to audit and remediate your site allows your team to take steps that minimize the possibility of lawsuits as a result of your site’s digital experience. 

Launch New Campaigns Faster 

Colleges and departments within universities often need to launch campaigns quickly, and depending on the technology involved, expediency is integral. Teams must have a workable solution to accomplish the goals of an individual college or department.

Marketing teams can take advantage of RainU CMS to launch to market in 30 days or less. 

RainU CMS for Drupal homepage

Gain more control over your site with RainU CMS such as:  

  • Robust Security - Mitigate attacks from hackers - RainU CMS has several built-in security hardening features to help.
  • Flexible Content Feature-Packed - Build pages with a flexible, easy to use interface in RainU CMS for rapid development.
  • Component-Based Theme - Like with other Drupal sites, RainU CMS has reusable components and a built-in style guide which reduces design time.

Demo RainU CMS 

Ready to take your higher ed site and marketing campaigns to the next level? Explore how RainU CMS can get you there and check out the demo below. 

[embedded content]

Jan 25 2021
Jan 25

Newly engineered opportunities have opened the doors for Higher Education institutions to pioneer student, researcher, and funding recruitment. From deeper data applications to mass-scale live debates, the Higher Education sector is going through a digital transformation, with varying rates and approaches.

New data and accessibility regulations, as well as pressure on student recruitment from COVID-19, have required Higher Education institutions to accelerate these 'digital transformation roadmaps'.

Entire organisations have had to react and re-evaluate everything across technology implementation, face-to-face education, student recruitment, and community satisfaction.

The forces of change are drawing in at an unprecedented rate. But are universities equipped to make the quality, long-term adjustments needed?

Senior stakeholders from the University of West London, Manchester Metropolitan University, and Oxford Saïd Business School sat down with Paul Johnson, our Drupal and HE Specialist at CTI Digital to discuss their digital challenges and opportunities during a panel at DrupalCon Europe. We received a unique perspective on various UK organisations' challenges with differing cohorts, scale and complexity, age and legacy systems.

Watch the full panel here, and use the time stamps below to navigate:

[embedded content]

00:00 - Introduction with:

  • Chair and top left: Paul Johnson, HE Specialist at CTI Digital
  • Bottom left: Adrian Ellison, Associate Pro-Vice-Chancellor & Chief Information Officer at the University of West London.
  • Top right: Nick Holland, Head of Digital at Manchester Metropolitan University.
  • Bottom right: Iain Harper, Head Of Digital Marketing, Saïd Business School, University of Oxford.

05:29 - Why The University of West London chose to upgrade and continue using Drupal.

09:50 - How Manchester Metropolitan University built the business case to move to Drupal.

13:29 - Oxford Saïd Business School's experience of using Drupal 8 for multiple years.

19:30 - Managing "HiPPO" (Highest Paid Person's Opinion) and different stakeholders' opinions.

22:20 - Data-driven decision making to changes of an existing platform at Oxford.

24:58 - Managing governance for an entire platform change at MMU.

26:58 - Managing change to projects and their teams over multi-year projects.

33:54 - Lockdown and adapting working with staff and students remotely.

37:04 - Content governance and consistency.

38:54 - Designing and building a website for diverse audiences.

41:22 - What features or capabilities for Drupal should Drupal develop for HE's future?

If you're looking for a digital partner to support your digital transformation. We're the team you're looking for. Our full-service team can take your through discovery and user research to plan and define the underlining requirements that meet your business goals. Our content strategy and development team will then be available to make your digital roadmap become a reality—all under one roof, with years of precedented success.

Get in Touch

Jan 21 2021
Jan 21

Photo of Mauricio Dinarte at DrupalCon Seattle contribution day in 2019 by Josef Kruckenberg @dasjo

9 minute read

It’s always a joy when the planets align and connections are made! After the virtual DrupalCon Europe in December a few folks caught up on social Zoom, where I learned that a couple of my longtime friends in the Drupal community are using DDEV-Local to teach web development to newcomers. 

Mauricio Dinarte was one of my first mentors when I started learning Drupal in 2013, so it was an honor to interview him for this blog. Mauricio, aka dinarcon, has been doing Drupal for a decade now and teaching Drupal for half that time locally in Nicaragua as well as at Drupal Camps and Cons worldwide. This is the first blog in a set, please read more about teaching Drupal in Iceland from Hilmar Hallbjörnsson.

What do you teach attendees about Drupal and React and what are some of the challenges in getting them started?

I teach Drupal site building, Drupal migrations, Drupal upgrades, and ReactJS basics. I present sessions at events, which are a lecture style, and workshops going over specific examples and hands-on exercises. That has been quite different when they used to be in person versus now that they are online. Before, you were able to see someone had an issue, sit next to them and try to work together out of the problem. But now it’s mostly online and depending on the size of the class, it’s not possible to let the attendees screen share. So that is a challenge. 

Sometimes the setup is as simple as sending over links to repositories and lessons. Sometimes it’s using the quick start command in Drupal or something like DrupalVM or DDEV for more advanced classes. In all scenarios, no matter what the topic is, I strive for keeping it very, very simple in terms of the local development environment. It is not always possible, but that’s something that I really look for: some way in which there is the least amount of effort from getting started to having a functional site and, depending on the course, writing the first line of code.

How are you supporting students and adjusting to fit a more virtual, online format?

About two weeks ago, I gave a presentation on layout builder to a small group. We were using MAMP and Pantheon environments to deploy, because it was not about explaining everything but just the essence of the tool. With some set up in advance I was able to start the training, so that was right for this instance. But in general, with online trainings, there have been a lot of challenges. Funny enough, most of the challenges go back to what I was describing – the local development environment. 

For example, along with my colleagues at Agaric, in 2020 we presented three or four different online workshops. We would spend hours, and hours, and hours giving people support ahead of the training to get their local environments ready. We have seen so many different setups, every computer is different. It can get complicated. That is why we offer office hours before the trainings to help people get ready. We also offer training recordings so everyone can practice later. Again, the key is having a simple set up with a local environment to begin with.

That goal of having quick wins when getting started coding sounds similar to our work with Drupal contribution mentoring

Yeah, requiring the least amount of effort to get started is ideal — because in the context of mentoring, people want to contribute to Drupal as an open source project, and in the context of a training they want to learn a new skill. They don’t necessarily want to learn Docker, Composer, LAMP stacks, or virtual machines to be able to contribute. That’s why, depending on the topic and issue I choose the development tools that meet the minimum requirements to get them started.

How do you determine which development tools are best for Drupal migrations or getting started or… ?

These have changed over the years. When I started presenting the Drupal workshop back in the day as part of the global training days program, I used simplytest.me, an online tool for installing Drupal. Back then the installation would only be available for two or three hours. I remember talking with Patrick Drotleff, the creator of the tool, when he was extending the lifespan of temporary sites to about 24 hours. This allowed us to give a full day training using simplytest.me alone. 

Before that, we would spend two of the three hours just trying to get an *AMP stack on each person’s computer. It was inefficient and frustrating. That’s the friction that we wanted to avoid – people want to learn something new and then they discover that they need to learn twenty other things to be able to start being productive.

Later, I started using Pantheon for the Drupal site building courses, because they have the free tier with no time limits. Pantheon also has a program called Pantheon for Educators where trainers like me can create environments on behalf of their students in advance. On the day of the training, we jump directly into the content, we don’t need to worry about “Do you have LAMP stack on your computer?”

For Drupal Migrations it’s a little bit different because we know we need more setup than just an out-of-the-box Drupal installation on Pantheon. Some modules need to be installed via composer. Depending on how the Pantheon site is set up, this might require configuring SSH keys . To keep things simple, I default to the Drupal quick start command. That uses the built-in PHP Web Server, SQL lite, and PHP itself. With that you can get a Drupal installation in five to 10 minutes. That does require a little bit of technical knowledge and having PHP and Composer installed on your computer.

As a part of UnderstandDrupal.com I recently released a Drupal Migration training. In the lecture on debugging migrations I use DDEV because it’s very simple to install DDEV and to configure Xdebug, so that was kind of the selling point. It was literally just issuing a command, setting a breakpoint, and allowing the IDE to listen for connections. And that was it.

Before DDEV I was using DrupalVM for many years. It works great if you have VirtualBox, Vagrant, and Ansible installed in your machine. But getting them properly configured in the first place can be challenging in some environments. So, you need to make a decision: to install VirtualBox or Docker. Attendees might come to a training with Windows, Linux, Mac. Sometimes they do not have admin privileges on that machine. I have fought many of those battles. And I don’t consider myself a sysadmin! So the simpler the tool, the better for me. That’s basically why I chose DDEV. 

Tell me a little more about your experience using DDEV for local development? What was especially useful or lacking?

Definitely useful how easy it is to configure Xdebug. Coming from DrupalVM I was really looking forward to how to debug, which works out of the box. But the highlight of DDEV is Randy Fay! I post a question in the #ddev Slack channel and he answers within minutes! Sometimes I just lurk in the channel to learn from others. Randy is so good at offering support, not only on a technical level. He also takes the time to explain how things work. That is a big asset for DDEV, you know, having someone who is able to offer support in a timely, kind, and humane way.

The only thing, which isn’t specific to DDEV, is that in order to get the local environment working you need Docker installed. That might be a challenge in itself. For example, two days ago, I was working with a client who was having problems with the DDEV installation. And the reason was because they had just updated Docker desktop and that broke things. Of course the system requirements are in the docs, but sometimes people update their tools as soon as new releases are available without checking compatibility.

What are the needs and goals of the students who sign up for Drupal web development trainings? Who are they?

Recently in my local community we noticed when we promoted the training as “Get started with Drupal” people didn’t know what Drupal was. So we switched the name to “How to build a website in a day” and got much more interest. We’re often teaching small business owners how to build a simple website for their business. While covering ecommerce integration is not feasible, we teach them how to build a product catalog in a day. 

We have also given many sessions and trainings to university students majoring in computer science and design. The course is always tailored to the audience. So we talk about theming, reusable components, and modules to highlight Drupal’s flexibility and provide foundational knowledge. Sometimes we have attendees in leadership roles, or project managers, who come to a training to understand the bigger picture. They want a sense of the tools, what is possible, what is recommended so they can be a bridge between developers and stakeholders. 

For the Drupal migrations trainings, that audience is varied. Sometimes they’re the one technical person in the organization who has been tasked with doing the update. The introductory course is friendly to just about anyone since it only requires understanding of site building concepts like nodes and users. Intermediate and advanced migration courses require some programming knowledge, but provide detailed instructions and examples as necessary. They may also obtain Drupal upgrade training which does require more PHP knowledge and a more complex local environment setup. Getting the two versions of Drupal talking to each other is when people start to lean on our support and office hours. Sometimes attendees just need to solve a specific problem, and that is again when we need to get them started with as little friction as possible.

Some audiences benefit more significantly from migration trainings. For example, universities or governments who have hundreds of sites: They learn once and apply the knowledge multiple times.

What are your teaching goals for 2021?

I want to expand UnderstandDrupal.com to a teaching platform with more resources in text and video format. Different people learn in different ways to it makes sense to offer both options. Additionally, a goald I really hope I can accomplish in 2021 is to translate the material to other languages. One of the primary goals of UnderstandDrupal.com is to make the content accessible to as many people as possible. As someone who is not a native English speaker, I know the language barrier can be very high. I started translating to Spanish and French myself. I couldn’t keep up with that, but I will try again this year. 

I love what you said about the scaling and cascading effect of an impactful training for the right attendees. Why did you get into teaching?

Going back to study groups in school, I liked that experience of learning together. It made us more efficient, made the process accountable. Now, in my day-to-day professional experience, teaching has made me a better developer, and has allowed me to learn a lot more about the subjects I teach. If I weren’t a developer, I would probably be a teacher.

For example, in 2019, I wrote a series of articles about Drupal migrations for UnderstandDrupal.com which I  consider the pinnacle of my Drupal contributions to date. It was 31 days straight trying to write a technical article every day. It seemed so reasonable at the beginning, but I was proven wrong early on. It could take up to eight hours to write an article. One of them took me 20 hours because I had to do a lot of  research, debugging, and testing. So producing the series exaggerated all the benefits and all the difficulties in teaching and producing content. 

I learned so much. Before I started writing that series, I had been doing migrations maybe for three years. I thought I knew enough to be brave and make that public commitment. By writing articles I think that my knowledge doubled or tripled in just that month, because I was so heads down into the topic., I would spend hours in the debugger stepping through the migrate API code, understanding, or trying to understand, how it worked. 

I teach because I enjoy it, I like sharing my knowledge. When I started my journey, I didn’t know of the Drupal community. For me, Drupal was a tool that allowed me to build a website without knowing a lot of HTML or CSS. It was probably six months later that I encountered my local community at a meetup. In five minutes, someone would answer what had taken me weeks, or months to investigate. So that’s why I teach, to be able to help others, save them time, and hopefully save them frustration.

Where to find Mauricio

The Drupal Nicaragua community can be found in many places, including groups.drupal.org, Facebook and Twitter.

UnderstandDrupal.com is Mauricio’s own site and project with pre-recorded courses on Drupal Migrations and ReactJS. Much of the material is free and open source. When you sign up for a virtual training you get the additional benefit of live explanations, lectures, and hands-on help with set up and questions. Please support Mauricio via one of the sponsorship links on the site!

*/

Share this post:

Jan 21 2021
Jan 21

Problem: The Power (and Pitfall) of Paragraphs

With great content modeling powers comes great responsibility for Drupal developers. 

While building a website, you may face the challenge of creating multiple paragraphs without much reuse. This can contribute to a poor content architecture that will burden you for the lifetime of your application. This issue can come about when a developer is building out paragraphs and decides to generate multiple paragraphs with similar fields or new fields that perform the same functionality as other fields. 

For example, let’s say a developer is tasked with building a normal Text Paragraph which is just one textarea field, which is simple enough. Now, let’s say a client comes to that developer and ask if the Text Paragraph could have a header field, and a subheader field. Usually, a developer might decide to just create a new paragraph, maybe call it a Card Paragraph, that has a new header field, subheader field, and a new body field. Well, what if you could just reuse the body field from the Text Paragraph? There is a way to do that by using Form Displays and the default Paragraphs reference field widget. Of course, the example above is simple, but there might be better cases which will be explained below.

Solution: Reuse Paragraphs and Form Displays

Mediacurrent’s Rain CMS  is an open source project that comes bundled with ready-to-use content types and paragraphs. One of those is the Card paragraph. The Card paragraph by itself might just have a title, media, body, and layout field. This is pretty useful as its own componentized item that can be reused on other components. Now let’s say you have another paragraph that is called a Breaker, which essentially is almost like a Card Paragraph but might have some variation. This Breaker paragraph might reuse the same title, body, but also has an extra field called right body for any text that might need to be put on the right column.

The way one can keep reusing the Card paragraphs, with other paragraphs that get created in the future is to add more fields onto the Card paragraph itself.

Drupal manage fields tab

As displayed above we have a ton of fields added on to the Card Paragraph. One might say that why are you doing this, wouldn’t all these fields get displayed on the frontend. Technically yes at first, but there is a way to limit what fields get displayed on the Card paragraph itself and then a step on getting the Breaker paragraph to utilize the same fields coming from the Card paragraph.

This method is using what’s called view modes in the Form Display configuration. What you want to do is go into Managed Form Display in the CMS for the Card paragraph that you just created and take a look at what displays are available.

Drupal backend - manage form display

As you can see above we already have some displays created in the Rain distribution we are using. We have the Default, Breaker, Carousel, Column, Card Compound, and Overlay Breaker. These are all Form Display’s which are used for other Paragraph variations. 

custom form display

Creating a new display is easy; you want to go to the bottom under the Default view mode and hit Custom Display Settings, which should drop down the above selection. As displayed in the screenshot there are some that are enabled and disabled. You can create a new one by clicking Managed form modes.

Now that we sidetracked a bit and explained how view modes work and how they are created, let's dive back in and talk about how you can now create this Card variation paragraph which is called the Breaker. Since we have a display already enabled for the Breaker what you want to do is click on the Breaker and see what fields are enabled by default.

Drupal manage form display

Shown above this has the title, body, and the new body right field which is technically still part of the Card Paragraph, but just using a different form display. If you compare this display with the default display you can see that different fields are enabled and disabled, which allows for flexibility for reusability. Now that we see that the fields needed for the Breaker have been created or enabled, let’s go create the Breaker paragraph.

create breaker paragraph

We then add a description and say that this is a breaker that will have content with two columns. If you remember above we have a body field and a body right, this is used to create these two columns.

When creating your Breaker paragraph make sure to add all the fields that are unique to this breaker like Line Break, and Show Two Columns which have specific functionality for the Breaker, but you also want to create a Paragraph reference field called Card which will allow you to reference a Card.

So how do you get it so this Card field shows the fields that you want from the Card Paragraph? Well, that’s why we worked on using the view mode on the Form Display for the Card Paragraph. What you want to do is the following.

Drupal manage form display card

Under the Breaker paragraph go to the Managed Form Display. Then under the Card field, you can use any widget that has the Form Display mode available. This will allow you to use the Form Display mode option in the widget to target the right display mode you want to use from the Card. Select the Breaker display mode.

select breaker display mode

Once this is done, hit save.  Now what you should expect is that whenever you go to create a breaker and you use the card field it should show the fields that are specified on the Card Breaker view mode.

card breaker

Building Paragraphs the Smart Way 

Now whenever you as a developer get tasked with building out a paragraph, make sure to ask yourself: What can I do to reuse fields and displays as much as possible? I hope this guide will help you to make smart decisions for a better content architecture going forward.

Jan 13 2021
Jan 13
If it is the top level menu, we print a
    and we pass Drupal’s attributes in addition to our custom classes.</li>
  • If menu is not top level (submenus), then we simply print a
      with its corresponding class.</li>

Learn more about Macros in Twig Templates.

Looping Through the Menu Tree

Looping through the items array allows us to intersect each item and apply classes or attributes.

  • First, we loop through the items array (for item in items), and for each item, we print a
  • to which we pass an array of CSS classes using attributes.addClass() method.  However we do this only if we have access to Drupal's attributes ({% if attributes %}).  If not, we manually print the same classes on the list item. 
  • For each item and link, we pass a series of things such as:
    • The link title
    • The link url
    • Is the link in the active trail,
    • ... and others.
  • Inside the list item, we check to see if that particular item has other items or submenus({% if item.below %})
  • When submenus exist, we make use of the macro again to repeat the process of printing the menu. This is where the macro saves us from writing duplicate code.
  • For each level of submenus we are increasing the menu_level by 1 and printing it as part of the submenu class. This is handy if we want to target a specific submenu in the tree.
  • Finally, we close all previously open actions/tags (i.e. for loops, if statements, lists, and macro).

RESOURCE: I recently ran into a blog post by Tamas Hajas where he has a great way to address classes and states on a menu. Check it out: Drupal 8 Twig: add custom CSS classes to menus

Looking at the Rendered Menu after Macro Improvements

Now that we have a better understanding on how the macro works, and after making the improvements discussed above, the markup for the menu would look something like this:
Example of menu with good markup.

These styles are as bare as possible. They are simply to make the menu look presentable and could use a lot of improvements. This is what the multi-level menu looks like:

Example of an expanded menu

Create a Twig Template Suggestion for the Main Menu

Our ultimate goal is to update Drupal’s menu system to render using the navigation component. 

Follow these steps to enable Twig Debugging in your theme. Then, you can inspect your site, which will allow you to see the various template suggestions that Drupal uses to render the page; including your navigation menu. The debug information looks like this:

Example of twig debugging code.

Under File Name Suggestions notice two template names: menu.html.twig & menu--main.html.twig. The X next to menu.html.twig indicates Drupal is using this file to render the Main Menu. The second file, menu--main.html.twig, is what Drupal is suggesting we create if we only want to alter the Main navigation and not other menus.  The word "main" in the file name represents the Drupal machine name for that menu.

Under Begin Output notice the path where menu.html.twig can be found, the example above is pointing to Drupal’s stable theme.

To ensure we only affect the main menu and not other menus on our site, we are going to make a copy of Drupal’s menu.html.twig in our theme and then override it. This is recommended rather than modifying Drupal core’s template. Let’s start:

  1. Copy the menu.html.twig template from core/themes/stable/templates/navigation/ into [site_root]/themes/custom//templates/navigation/menu.html.twig (if these folders do not exist yet in your theme go ahead and create them).
  2. Following the golden rule “Never hack core”, we want to make a copy of Drupal’s menu template in our own theme. Replace the core theme’s name with your core base theme if you are not using stable.
  3. Next, In your theme rename the newly copied template to menu--main.html.twig.
    Copying menu.html.twig into our theme will affect other menus. This is why we are renaming the template so it only affects the main menu (menu--main.html.twig). Replace ‘main’ with whatever your menu’s machine name is if you are not using Drupal’s Main Menu. This can be found in Drupal’s Menus page (admin/structure/menus).,>
  4. After clearing Drupal’s cache, inspect the menu again and you should see the X next to menu--main.html.twig which means Drupal is now using our custom twig template suggestion to render the menu.

Create a Multi-level Menu in Drupal

  • Let’s make sure we have a menu we can see in Drupal. Let’s create a multi-level menu using the Main Navigation menu (Structure | Menus | Main Navigation).
  • Add as many links as you wish. Be sure to add nested items so we end up with a multi-level menu.
  • In addition, ensure each of the submenu’s parent links are set to “show expanded”. You will see the option on the Add/Edit Link page.
  • Finally, go to Structure | Block Layout and click Configure next to Main Navigation
    • Change Number of levels to display to Unlimited. This will ensure dropdowns are rendered and display in your navigation.

Integrate the Main Menu component with Drupal’s Menu

The last part of the process is to integrate all the work we’ve done with Drupal, so our Navigation is rendered with the markup, styles, and behavior we implemented when we built the component.  

  1. In your editor, open [site_root]/themes/custom//templates/navigation/menu--main.html.twig
  2. Delete all the content in the twig template except for the comments, and then paste the code below into it
{% include '@your-namespace-here/navigation/navigation.twig' %}
  1. Clear Drupal’s cache
  2. Reload Drupal’s page

Since we moved the macro to the component’s location, all we need to do in the menu--main.html.twig template is to call our Navigation component by using a Twig include statement. 

If we did our job right, Drupal’s menu should now look and behave the same way as our component. In addition, if you inspect the Drupal page, the menu should reflect the same markup as the main-menu component.

Drupal Libraries

As a best practice, we should create a drupal library to attach any styles and javascript to our component. See this article for adding CSS and JS to a page or component.

If your navigation is displaying unstyled that's because a Drupal library does not exist.  Create one as follows:

navigation:
  css:
    component:
      dist/css/navigation.css: {}

Your compiled css path may be different.

This library has already been attached above inside navigation.twig

By doing this any styles we wrote for the component will apply to the main navigation when it’s rendered in Drupal. Drupal libraries have no effect in Pattern Lab.

After completing the steps above, clear your Drupal’s cache and reload your Drupal site. You should see your Drupal menu being rendered with all the styles and markup we wrote throughout this post,

What about Accessibility?

You should always ensure your menus and navigations are accessible. It is the right thing to do. However, don't yell at me for not following my own advice. In an effort to keeping this tutorial simple, I opted to omit anything related to accessibility. Perhaps part two can focus on that ;-)

Video Tutorials

[embedded content]

[embedded content]

In Closing

I’d like to admit that I went about the long way to get the main menu working on both, Pattern Lab and Drupal. There are other ways to accomplish this by using contrib modules such as Simplify Menu (full disclosure, I am a co-maintainer of the module), and perhaps Twig Tweak among several others, however, the approach I took here gives you the most control and that can make all the difference if you are dealing with a pretty advanced or complicated menu.

Jan 13 2021
Jan 13

namespace Drupal\mymodule;

use Drupal\Core\Config\ConfigFactoryInterface;
use Drupal\Core\Entity\EntityInterface;
use Drupal\Core\Entity\EntityTypeManagerInterface;
use Drupal\Core\PathProcessor\InboundPathProcessorInterface;
use Drupal\Core\PathProcessor\OutboundPathProcessorInterface;
use Drupal\Core\Render\BubbleableMetadata;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpKernel\Event\GetResponseEvent;
use Symfony\Component\HttpKernel\KernelEvents;

/**
* Get the active subsite from the request based on URL.
*/
class SubsiteManager implements EventSubscriberInterface, OutboundPathProcessorInterface, InboundPathProcessorInterface {

const SUBSITE_ENTITY_TYPE = 'node';

const SUBSITE_PATH_FIELD = 'field_path';

/**
* The entity type manager.
*
* @var \Drupal\Core\Entity\EntityTypeManagerInterface
*/
protected $entityTypeManager;

/**
* The configuration factory.
*
* @var \Drupal\Core\Config\ConfigFactoryInterface
*/
protected $configFactory;

/**
* The active subsite.
*
* @var \Drupal\Core\Entity\EntityInterface
*/
protected $subsite;

/**
* Contruct the SubsiteManager.
*
* @param \Drupal\Core\Entity\EntityTypeManagerInterface $entityTypeManager
* The entity type manager.
* @param \Drupal\Core\Config\ConfigFactoryInterface $configFactory
* The configuration factory.
*/
public function __construct(EntityTypeManagerInterface $entityTypeManager, ConfigFactoryInterface $configFactory) {
$this->entityTypeManager = $entityTypeManager;
$this->configFactory = $configFactory;
}

/**
* {@inheritdoc}
*/
public static function getSubscribedEvents() {
return [
// Runs as soon as possible in the request but after
// LanguageRequestSubscriber (priority 255) because we want the language
// prefix to come before the subsite prefix.
KernelEvents::REQUEST => ['onKernelRequestSetSubsite', 254],
];
}

/**
* Get the active subsite from the request.
*
* @param \Symfony\Component\HttpKernel\Event\GetResponseEvent $event
* The event to process.
*/
public function onKernelRequestSetSubsite(GetResponseEvent $event) {
// Set the default subsite as fallback.
if ($default_subsite = $this->getDefaultSubsite()) {
$this->setCurrentSubsite($default_subsite);
}

$request = $event->getRequest();
$request_path = urldecode(trim($request->getPathInfo(), '/'));

// First strip the language when it's processor is available. This is only
// the case when more than 1 language is installed.
if (\Drupal::hasService('path_processor_language')) {
$request_path = \Drupal::service('path_processor_language')->processInbound($request_path, $request);
}

// Get the first part of the path to check if it matches to a subsite page.
$path_args = array_filter(explode('/', $request_path));
$prefix = array_shift($path_args);

if (!$prefix) {
return;
}

// If the prefix matches to a subsite page, set it in the property.
$subsites = $this->entityTypeManager->getStorage(static::SUBSITE_ENTITY_TYPE)->loadByProperties([
'type' => 'subsite',
static::SUBSITE_PATH_FIELD => $prefix,
]);
$subsite = reset($subsites);
if ($subsite) {
$this->setCurrentSubsite($subsite);
}
}

/**
* {@inheritdoc}
*/
public function processInbound($path, Request $request) {
// Get the first part of the path to check if it matches to a subsite page.
$path_args = explode('/', trim($path, '/'));
$prefix = array_shift($path_args);

// If we don't have a prefix, or if the prefix is the only thing in the path,
// keep the current path as it is. This is a subsite homepage.
if (!$prefix || $path === '/' . $prefix) {
return $path;
}

// Only when dealing with a subsite page, change the request.
$subsites = $this->entityTypeManager->getStorage(static::SUBSITE_ENTITY_TYPE)->loadByProperties([
'type' => 'subsite',
static::SUBSITE_PATH_FIELD => $prefix,
]);
$subsite = reset($subsites);
if (!$subsite) {
return $path;
}

return '/' . implode('/', $path_args);
}

/**
* {@inheritdoc}
*/
public function processOutbound($path, &$options = [], Request $request = NULL, BubbleableMetadata $bubbleable_metadata = NULL) {
if (!empty($options['subsite'])) {
$subsite = $this->entityTypeManager->getStorage(static::SUBSITE_ENTITY_TYPE)->load($options['subsite']);
$options['prefix'] = $this->addPrefix($options['prefix'], $subsite->get(static::SUBSITE_PATH_FIELD)->value);
}
$subsite = $this->getCurrentSubsite();
if ($subsite && empty($options['subsite']) && !$this->isDefaultSubsite() && $path !== '/' . $subsite->get(static::SUBSITE_PATH_FIELD)->value) {
$options['subsite'] = $subsite->id();
$options['prefix'] = $this->addPrefix($options['prefix'], $subsite->get(static::SUBSITE_PATH_FIELD)->value);
}
return $path;
}

/**
* Create the updated path prefix.
*
* @param string $existing_prefix
* The existing path prefix.
* @param string $subsite_prefix
* The Subsite path prefix.
*
* @return string
* The combined path prefix.
*/
protected function addPrefix($existing_prefix, $subsite_prefix) {
$existing_prefix = trim($existing_prefix, '/');
$subsite_prefix = trim($subsite_prefix, '/');
$combined_prefixes = array_filter([$existing_prefix, $subsite_prefix]);
$prefix = implode('/', $combined_prefixes) . '/';
return $prefix !== '/' ? $prefix : '';
}

/**
* Set the current subsite.
*
* @param \Drupal\Core\Entity\EntityInterface $subsite
* The current subsite.
*/
public function setCurrentSubsite(EntityInterface $subsite) {
$this->subsite = $subsite;
}

/**
* Get the current subsite.
*
* @return \Drupal\Core\Entity\EntityInterface
* The current subsite.
*/
public function getCurrentSubsite() {
return $this->subsite;
}

/**
* Get the default subsite.
*/
public function getDefaultSubsite() {
// Fetch a default subsite based on a config page.
$default_subsite_id = $this->configFactory->get('mymodule.settings')->get('default');
return $default_subsite_id ? $this->entityTypeManager->getStorage(static::SUBSITE_ENTITY_TYPE)->load($default_subsite_id) : NULL;
}

/**
* Check if the current subsite is the default subsite.
*/
public function isDefaultSubsite() {
return $this->subsite && $this->getDefaultSubsite()->id() === $this->subsite->id();
}

}</span>

Jan 13 2021
Jan 13
[embedded content]

Don’t forget to subscribe to our YouTube channel to stay up-to-date.

The roles and permissions system in Drupal is powerful, but it can be tricky to configure correctly. Some permissions give a role too much privileged access where others aren’t granular enough.

An excellent example of this is if you need to create a role to manage user accounts.

Drupal comes with the permission “Administer users” which lets you create user accounts, only give this permission to trusted users.

The above mention permission allows you to create user accounts but you can’t assign them roles without “Administer roles and permissions”. But this permission (“Administer roles and permissions”), will enable you to assign any roles, including the default Administrator role.

From this:

To this:

In some circumstances, you don’t want users who can create user accounts to have the ability to assign any roles, especially the Administrator role.

What if you want to control exactly which roles can be assigned? This is where Role Delegation can help.

Table of Contents

Getting Started

To get started, download and install Role Delegation.

composer require drupal/role_delegation

Using Role Delegation

All the module does is offer granular permissions for assigning roles.

Once the module is installed, go to People > Permissions and search for the Role Delegation section.

You’ll notice that you get a specific permission for each role, and you also get the “Assign all roles” for absolute power.

All you need to do is give one of the “Assign {role} role” permission and they’ll be able to assign users into that role.

Assign Role

Once a role has been assigned a few “Role Delegation” permissions, they can assign roles in two ways.

First, if you edit an account you should see the Roles checkbox below Status.

The module adds a new tab on user accounts called Roles. This page has all the allowed roles as checkboxes.

Select a role and click on Save to assign them.

Summary

The functionality that Role Delegation offers should be in Drupal core in my opinion. If you need to control which roles can be assigned then it’s a useful module to add to your Drupal site building toolbox.

FAQ

Q: I can’t see the “Administer roles and permissions” permission on my site?

It was changed from “Administer permissions” to “Administer roles and permissions” in Drupal 9.1.

Ivan Zugec

About Ivan Zugec

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

Jan 08 2021
Jan 08

Now on Drupal 9, the community isn’t slowing down. This month, we sit down and talk with Angie Byron, a.k.a Webchick, a Drupal Core committer and product manager, Drupal Association Board Member, author, speaker, mentor, and Mom, and so much more. Currently, she works at Aquia for the Drupal acceleration team, where her primary role […]

The post Community Corner: Interview with Angie Byron, Part One appeared first on php[architect].

Jan 07 2021
Jan 07

student in cap and gown attending a virtual college graduation ceremony

Customer Stories on The Pivot to Digital 

In a year like no other, Mediacurrent’s higher education partners were challenged to shift strategies. We recently welcomed a customer panel of seven marketing strategists to share their stories at our company retreat. With voices ranging from two Ivy League universities to an online college, the panel reflected on how the pivot to virtual tours was an ambitious undertaking. So too was the need to rethink student communications and reassess the metrics that matter most.

The following is a transcript of a virtual roundtable by Michael Silverman of Mediacurrent with a panel of seven digital leaders in higher education. It was conducted in December 2020 at the Mediacurrent company retreat. Some of the questions have been edited for brevity and clarity.

How has your recruitment strategy changed with COVID-19? What works now for student enrollment marketing?

For this digital director at a private catholic university, COVID-19 drove his team to imagine creative alternatives for events and approach their marketing funnel in a new way: 

There's been the need to be more creative to reach our target audience. We had to find different ways to engage prospective students. One thing we did was to host a socially distanced drive-in event where prospective students came to the college and watched all about our college. We’ve also moved to more virtual events (I can tell you because I entered over 300 events on our Drupal site!) for new and returning students. We look for different ways to connect with them, to make sure that they stay engaged with the university.

We had a habit of focusing on top of the funnel brand awareness and it was harder to get prospects into the funnel. So we had to make a more concerted effort to reach the students that were already in the funnel, getting them to apply and then put their deposit down. We were working with a smaller pipeline and we had to be more efficient in speaking to it. 

According to this director-level digital strategist for a major state university in the northeast, highlighting the value of a local education was a successful tactic:

When we were being able to get people onto the campus, 70% of people who came to visit ended up applying. Because we were missing out on that, moving to virtual visits, we had to change our messaging quite a bit. 

We found that people were more likely to want to stay at home or stay local. Because our biggest audiences are in-state, and we have 19 campuses across the state, that's been a big point for our message. We really focus on the campus and that local education rather than that “big brand” messaging. 

On a campus of 2,000 students in the Great Plains region, this marketing expert saw how small group tours are more personalized than before:

After shutting our campus down for the spring and summer, we were able to get back to a model that allows for individual family tours. That personal touch has helped us a lot. In October, we hosted more individual tours than any group tour of previous years. Our admissions counselors really take pride in fostering relationships with prospective students through personal interactions like texting, calling, or writing letters.

Aside from campus visits, what were some other leading indicators for applications? 

Prospective students had a high need for information about how the school was reacting to the pandemic. This state university (the same referenced above) saw the opportunity for retargeting campaigns:  

We’ve started to focus more on people coming to the admissions website and just reading through some of our COVID information. Our focus groups found that given the uncertainty, people wanted us to be able to proactively communicate what was going on and what we were planning to do with student enrollment moving forward. So we drove a lot of people to that information. If we saw that people were reading that and clicking over to one of our conversion actions, we would set up retargeting campaigns towards them and get them further down. This was a new strategy because we had never really used any of our PR materials within our enrollment advertising. 

We had never really done retargeting before for trying to get people to accept their offer of admission. We've started to build up some scores in our Slate CRM for the probability of enrollment. We've been able to figure out the people that are most likely to enroll and are able to retarget them at the beginning of the funnel with lookalike audiences and Facebook. Then we’re also retargeting accepted students who are still in the funnel. 

Where do you see the biggest change in measurable goals for your organization due to the changes brought on by COVID-19?

This CMO of an online college for holistic health was able to boost enrollment even as the competition for distance education was skyrocketing:  

We didn't see an enrollment drop-off at all. In fact, we've seen an increase in enrollment. Back in February, I pulled all of our pay-per-click marketing. I had a feeling that if this hit, every single on-campus entity would need to go online and we wouldn’t be able to compete. That strategy saved us. 

We stopped focusing on trying to attract people to enroll. We knew that everyone else was trying to attract them as a consumer. We started doing educational wellness webinars to help people to grow their skills, inviting them to engage with us on an entirely different platform. 

Has your institution been forced to cut costs or reallocate resources? If so, how has that affected your group?

This web strategist for a small university in the midwest weighed in that she faces uncertainties in the upcoming admissions cycle. Looking ahead, her department budget will be geared toward third-party community platforms:

We’re a small school and we were able to pivot pretty well...until now. Our students come because they get to co-op the entire time they're here as a part of the degree requirement. So we're now starting to see it going into this admissions cycle, but we're being very creative because obviously, you're not having your large scale visit events on campus.

For my role, which is running the main site, there probably will be some dollars pulled from me in order to focus on some third-party platforms that are focused on building a community with potential students. Not necessarily budget cuts, but I’ve seen the shifting of money to focus on some of these ongoing virtual things that will continue. 

Without the in-house IT resources to launch a new website, this project director at an Ivy League school relied on Mediacurrent for support:

We hired Mediacurrent prior to the onset of the pandemic to create an online platform that would be useful in the event of a future financial crisis. Two months later, we found ourselves potentially in the midst of that financial crisis.

Our IT department needed to focus on making it so that our students could all attend class online from all over the world. All of a sudden I was in the middle of a Drupal website project, and frankly, I'd never heard of Drupal before this. 

What are the biggest pain points from day to day related to the technology and management of your website?

The crisis forced us to go digital in many ways. It's incredibly important for our websites to stay accessible. Mediacurrent has done a good job of understanding what matters to our stakeholders and helping us navigate accessibility. That’s a huge priority.

This is where working at a school that has a lot of name recognition can bite you. We may not have had to do as much outreach or aggressive marketing as some other schools. So we were extremely behind the curve when we changed to virtual info sessions. We were able to get our information sessions up and running in a way that's decentralized so I didn't have to manage all of that. We could train other staff to get them up and running and host them on their own, which we do through Slate. 

Having virtual information sessions and other digital channels is something that definitely will continue going forward because it allows us to get our message to a broader audience. We're able to share what the school community is like, and what our financial aid can offer.

Marketers from a state school and a small private school both shared how Drupal empowered them to quickly adapt the digital experience: 

On our current site, the back end user experience is really difficult. We have no flexibility to change things when our strategy changes. It's a mess. So what we're building now in Drupal 8, we are very, very excited about. We've been working very closely with the team at Mediacurrent to improve the user experience for our authors and also being able to adapt to changes quickly. 

This year is nothing but pivot. I’m constantly making changes to the website. On our previous Drupal 7 site, I had a hard time adding blocks of content. Now, with Drupal 8 and Layout Builder, I’ve got everything that I need in my tool kit. I can go in on the pages to move around what I need to move around. I’m able to change the content up on a dime. 

What has been your experience working with Mediacurrent? 

All of our panelists agreed that finding the resources to launch new digital campaigns was a steep challenge. This Ivy League marketer summed it up best:

Staff in higher ed are stretched very, very thin. And at this moment, I'm finding that it's harder for us to be forward-looking. The availability and transparency with the Mediacurrent team have been wonderful. We’ve had many Mediacurrent developers working on our team over the past couple of years and as well as user experience and project managers. They’ve not only helped to find ways to improve our site and make the experience better for prospective students and current students but also to keep up with the necessary bugs and Drupal security features. 

The panelists also thanked the Mediacurrent team for being a reliable partner in uncertain times:

It was an enormous blessing not to worry about the development of our platform given everything else that was going for our school in response to the pandemic. I had complete trust in the Mediacurrent team and you didn't let us down.

I’ve needed things more quickly to adapt our strategy this year. As a digital agency partner, Mediacurrent did that. It’s made the difference between sinking and swimming.

What areas of your digital strategy do you see remaining post-pandemic?

An Ivy League project director reflected on how lessons learned from virtual learning may carry over to the classroom:

The particular program that I'm involved in is a specialized master's program targeted specifically overseas. In addition to all of the other travel-related concerns associated with the pandemic, there are also visa issues, et cetera. By necessity, we've been in this mode of, rather than bringing students to campus to sort of convince them to ultimately enroll, needing to do that in a virtual way. As with the classroom experience, we're hoping ultimately to get back to a non-virtual experience. But there are pieces of the virtual experience that we would think about trying to preserve, even in a nonvirtual world. 

We're anxious to get back into the classroom but there are pieces of the online experience that we've enjoyed and have started to think about how we can bring some of those elements into a physical classroom. Something as simple as the ability to interact with students via the chat function in Zoom. How do you think about taking that functionality and applying it in a physical classroom? And I don't know that we have any great answers yet. But it's very much something that we're thinking about.

This private catholic college sees a data-driven website in its future: 

Partly because of COVID, my marketing department was moved into admissions. It's been great because we've had access to more data, so it's allowed us to be more targeted and granular in our advertising. Now I know down to zip codes where my most likely students are to come from. 

So it's been a real benefit in a time where we've had to be more efficient with what we're doing, what we're spending, what we're advertising. And it's kind of also the direction for where I want to go with the website. And that's making sure that all of my analytics, all of my CRM pieces, everything is hooked into Drupal and doing what it needs to do so that we can be efficient even after COVID.

Now What? Rethink Your Digital Focus 

Whether the goal is to boost enrollment, improve student retention, inspire, educate, or engage learners, your website plays a critical role. See how other institutions adapting their digital experience in our upcoming webinar. Join experts from Mediacurrent, Siteimprove, and Pantheon who have helped some of the best-known colleges and universities deliver engaging digital experiences. We hope to see you there! 

higher ed webinar banner

Save a spot for the webinar: Reimagining Your Higher Ed Web Strategy

Jan 04 2021
Jan 04
Sean B

Two weeks ago I tweeted about updating a website with 123 contrib and 59 custom modules to Drupal 9. When I sent that tweet I was just starting the update and all was going pretty smooth. After using the awesome Upgrade Status module, all the contributed modules and our custom modules showed they were ready. Since our team believes waiting only makes it harder to keep up, we decided to go for Drupal 9.1.0 while we were at it.

I want to start by saying that we have quite some test coverage for our custom code, and a lot of functional tests as well. I’m not sure how much time this saved, but even with the test coverage soms issues were tricky to find. That is also the reason I’m writing this. Partially to help teams that do not have the luxury of extensive test coverage, partially as a reminder that test coverage will eventually save time!

Updating all the modules using composer was a little tricky. The site contains a little over 50 core patches. Luckily most still applied but 17 of them had to be updated or rerolled. We also had to update PHPUnit and since we are using brianium/paratest we had to update to PHPUnit 9 to make all dependencies work. After we had all the code updated, the fun started.

The first thing that needs to be done to get a running site is make sure all service dependencies are correct. The deprecated entity.manager and path.alias_manager were the ones we found most.

The Path Alias core subsystem has been moved to the “path_alias” module

https://www.drupal.org/node/3092086

\Drupal\Core\Path\AliasManagerInterface
@path.alias_manager
\Drupal\path_alias\AliasManagerInterface
@path_alias.manager

EntityManager has been split into 11 classes

https://www.drupal.org/node/2549139
We found quite a few places where we had overridden or extended core classes that still injected the old entity manager. If you find references to the old entity manager in your code, there is a good chance you need to replace it with the entity type manager. In some cases though, you need other services as well, so please pay close attention to check if the constructor has changed.

entity.managerentity_type.manager

Some of the classes we had extended/overridden and constructors we had to change were:

  • NodeController
  • CommentDefaultFormatter
  • TermSelection
  • ContentEntityNormalizer

Now that we had a running site, some of the blocks wouldn’t show up. We traced this to the following issues.

Plugins now use the ‘context_definitions’ key to define their contexts

https://www.drupal.org/node/3016699

 * context = {
* “user” = @ContextDefinition(“entity:user”, label = @Translation(“User”))
* }
* context_definitions = {
* “user” = @ContextDefinition(“entity:user”, label = @Translation(“User”))
* }

Entity contexts have dedicated classes

https://www.drupal.org/node/2976400

$context = new ContextDefinition(‘entity:’ . $entity->getEntityTypeId())$context = EntityContext::fromEntityTypeId($entity->getEntityTypeId());

Render callbacks must be a closure or implement TrustedCallbackInterface or RenderCallbackInterface

https://www.drupal.org/node/2966725
This mostly applied to #pre_render methods for our code, but we also had some custom #lazy_builder callbacks.

$build[‘#pre_render’][] = my_module_block_pre_render’;$build[‘#pre_render’][] = [MyModuleBlock::class, ‘preRender’];

Now that we had a “working” site, it was time to run the tests. The following list of deprecations/changes was harder to track down and we would probably only have found those issues after extensive user testing.

The “Symfony\Component\HttpKernel\Event\GetResponseForExceptionEvent::getException()” method is deprecated since Symfony 4.4, use “getThrowable()” instead

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

public function on404(GetResponseForExceptionEvent $event) {public function on404(ExceptionEvent $event) {

Several file uri/scheme functions deprecated and moved to \Drupal\Core\StreamWrapper\StreamWrapperManagerInterface

https://www.drupal.org/node/3035273

\Drupal::service(‘file_system’)->uriScheme($uri)StreamWrapperManager::getScheme($uri)

user.private_tempstore is deprecated use the ‘tempstore.private’ service instead

https://www.drupal.org/project/entity/issues/2951683

$container->get(‘user.private_tempstore’)$container->get(‘tempstore.private’)

ConfigurablePluginInterface is deprecated in favor of ConfigurableInterface, DependentPluginInterface.

https://www.drupal.org/node/2946161

interface MyModulePluginInterface extends ConfigurablePluginInterface, PluginFormInterface, PluginInspectionInterface {interface MyModulePluginInterface extends ConfigurableInterface, PluginFormInterface, PluginInspectionInterface {

Deprecate TermInterface::getVocabularyId()

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

$term>getVocabularyId()$term>bundle()

The ::getCurrentUserId method is deprecated

https://api.drupal.org/api/drupal/core%21modules%21node%21src%21Entity%21Node.php/function/Node%3A%3AgetCurrentUserId/8.7.x
We had references to getCurrentUserId in the config of media/node base field overrides (eg core.base_field_override.media.image.uid.yml). These should be replaced. Other entity types might have them too.

default_value_callback: ‘Drupal\media\Entity\Media::getCurrentUserId’default_value_callback: ‘Drupal\media\Entity\Media::getDefaultEntityOwner’

POSTing to EntityResource can now happen at /node, /taxonomy/term … instead of /entity/node, /entity/taxonomy_term …

https://www.drupal.org/node/2737401

 * “https://www.drupal.org/link-relations/create" = “/api/my-entity/{id}” * “create” = “/api/my-entity/{id}”

CSRF token route protection moved out of the REST module to be available to other core systems and contrib.

https://www.drupal.org/node/2772399

$response = $http_client->get(‘/rest/session/token’, [‘query’ => [‘_format’ => ‘hal_json’]]);$response = $http_client->get(‘/session/token’, [‘query’ => [‘_format’ => ‘hal_json’]]);

Forwards-compatibility shims of PHPUnit 8 functionality added for PHPUnit 6 & 7

https://www.drupal.org/node/3133050
We had to change some of our tests for compatibility with the new PHPUnit version.

$this->assertContains$this->assertStringContainsString

Overridden test methods require void return type hints

https://www.drupal.org/node/3114724

protected function onNotSuccessfulTest(\Throwable $t) {protected function onNotSuccessfulTest(\Throwable $t): void {

Even though most of these changes had change records, I was not fully aware of all these breaking changes and I’m also not sure how realistic it is to keep track of everything. In the end it took about 4 full days to get all our code updated, tests debugged and code fixed. Looking at the list, it all seems like a very manageable set of changes for a project of this size. I can imagine most sites will be a lot easier to update. I guess having a decent amount of test coverage and debugging a couple of issues is probably a good enough way to deal with the changes. I’m curious how other teams handle this, so if you have a good way to maybe prevent some debugging in the future, please let me know!

Dec 28 2020
Dec 28

If you are deciding between a standard Drupal architecture vs. a decoupled one with a GatsbyJS front end (which I’ll call “Gatsby” from here on out), certainly the latter approach offers some compelling advantages. Decoupling Drupal may be easier than you think. A Gatsby front end offers a more flexible and compelling user experience across multiple channels, as well as excellent performance, security, and scalability. 

However, in developing an independent front end and back end, one must factor in the additional costs and financial benefits of doing so vs a traditional standalone approach. As described in our introductory blog post, Building a Business Case, a business case exercise can clarify costs and benefits, both in terms of initial cost, ongoing costs, and revenues of each. 

In this blog post we’ll perform this exercise for standalone vs. decoupled Drupal with Gatsby, performing the following steps: 

  1. Determine the costs of each option
  2. Determine the benefits for each option
  3. Recommend an option based on cost and benefits

Determine the Costs of Each Option

Two different types of costs need to be considered when evaluating options, the cost of the initial implementation, and the ongoing and operating costs once the implementation is complete. The following two tables approximate these costs. Note: these costs are highly theoretical approximations, only to be used as an illustration. Actual costs can only be calculated once detailed requirements are considered. 

Implementation Costs

The following table summarizes theoretical implementation costs for each of the two options. These entail the licensing and build estimates for each option. This illustration (again, theoretical numbers) assumes a simple implementation with little to no customization. 

Cost

Standalone Drupal

Decoupled Drupal with Gatsby

Initial License

$0

$0

Build

$100K

$180K

Hosting (average)

$30K

$45K

Total

$130K

$240K

A few things stand out in this comparison:

  • Freedom from Licensing Fees: Of course, Drupal has no licensing fee, but if you use an open source front end technology like Gatsby, the licensing fee will be free for that as well.
  • Time and Effort Up Front: The initial effort for the decoupled build is greater than that for the standalone Drupal build. This is because front end technologies like Gatsby are newer, and in our experience, there are bumps in the road when working with them in an initial build.
  • The Stability of Drupal 8 and Drupal 9: Drupal 8 is stable and mature, having been release level since 2016, and Drupal 9 is architecturally similar.  With a standalone solution, there are fewer bumps in the road. 
  • Hosting: Hosting costs are greater with a decoupled solution as well. The cost of hosting services vary greatly and the figures we’re stating here are an illustration. Your actual hosting costs will certainly differ. That said, you will be paying for two hosting services with a decoupled solution, one to host the back end and another to host the front end, whereas a standalone solution requires just one.

Ongoing/Operating Costs

After implementation, each option incurs recurring costs. This is a critical consideration in evaluating options that often gets overlooked, and we recommend you always factor in these costs in your decision. For our example, the following table summarizes those costs (again, they are theoretical):

Cost

Standalone Drupal

Decoupled Drupal with Gatsby

Ongoing License

$0

$0

Maintenance and Support

$40K

$20K

Hosting

$30K

$15K

Total

$70K

$80K

As with the initial cost, the ongoing costs of the decoupled option are higher, albeit by less. In our example, they’re almost equal. While hosting costs are again higher for the decoupled option, maintenance and support costs are less. Although there are initial bumps in the road for a decoupled solution, our experience has also taught us that once those obstacles are overcome, it is a lower effort to maintain the solution because Gatsby, and the React framework it’s built upon, are simpler than that of Drupal’s front end engine. It is easier to learn, and developers skilled in it are easier to find. 

Determine the Benefits of Each Option

For investment in any of these options, a benefit is expected, particularly in expenses saved or new revenue earned. Focusing on annual revenue, the following table summarizes the theoretical benefits of each option based on an assumption that the standalone Drupal solution would generate $1000 a day in revenue, or $365K per year:

Standalone Drupal

Decoupled Drupal With Gatsby

Annual revenue

$365K

$416K

In this example, and in many real-world circumstances, a decoupled option slightly improves a site’s revenue, all other things being equal. This is because, in addition to having a more powerful and flexible user interface, a decoupled solution is more performant for the end-user. Further, a Gatsby front end typically runs as a static site on a CDN, with little to no database fetching occurring during a page load. According to sources like DomainRacer and MachMetrics, companies like Myntra, Amazon, Yahoo, Flipkart, and Mozilla experienced a boost in business by increasing the page load speed of the website with less than 2 seconds. Estimated revenue decreases conversions by 7% with a one-second delay, and a whopping 17% with a five-second delay. Further, page load time affects SEO rankings in Google, and slower websites have higher bounce rates. All of this impacts an organization’s reputation and customer loyalty.

Recommend an Option 

When we combine costs with benefits as described above, we are left with the following comparison: 

standalone vs Decoupled Drupal

A scenario for Standalone Drupal vs. Decoupled Drupal With Gatsby

In year 1, for example, the net amount earned by the standalone option is $365K - $130K, or $235K. In year 2, the cost is reduced to $70K, bringing the net amount to $295K. The above graph plots net revenue for the standalone option, in blue, and the decoupled with Gatsby option, in tan, over five years.

So, in this example scenario, we can draw the following conclusions:

  • If your organization is prioritizing short term results, the standalone option is more attractive due to the stability and maturity of the Drupal platform. There are fewer early bumps in the road. 
  • If your organization is willing to make a greater up-front investment for greater long-term benefit, consider the decoupled option with Gatsby by virtue of its low long-term maintenance costs and revenue-boosting performance improvements. 

As in our previous blog post on building your CMS business case, our example scenario is overly simplistic. In reality, detailed requirements can radically alter both the costs and benefits of any option one considers. We at Mediacurrent have performed this type of analysis for some of our clients to help them with their technology investment decisions and can do the same for you. Please contact us to learn more!

Dec 24 2020
Dec 24

Happy holidays everyone. We’ve had three sites in the last two weeks that have reported reCAPTCHA problems. A captcha is the funny little thing at the end of forms that tries to prove you’re not a robot by having you spell out letters, or pick pictures with traffic lights. They’re annoying, but without them, many “contact us” forms and user registration forms can be hit with a crippling amount of spam submissions.

Newly discovered reCAPTCHA session validation errors (TL;DR)

One of our clients even recently called in for holiday support on this bug, so we’re pretty sure there are others dealing with this situation as well. They all have the same JS error and/or symptom:

CAPTCHA validation error: unknown CAPTCHA session ID. Contact the site administrator if the problem persists.

Diagnosing the session validation error

The root of this error, at least for one of our sites using simple_reCAPTCHA, is pretty straightforward (but took us days to diagnose initially). There are two parts to the issue. A typical contact us page has 2-3 forms on the page: Search, Email Sign Up, and the contact form. The submit button for each one has the same HTML ID. That's not valid HTML; IDs have to be unique. There's code in the reCAPTCHA, captcha, and simple_reCAPTCHA modules that get tripped up because of caching.

Each part (block) on the page is cached separately, so when someone visits the homepage and that gets cached, Drupal also just pulls the search form from its cache for other pages instead of rendering it from scratch.

If rendering the whole page from scratch, Drupal uses unique IDs in every form. One's submit button has the id #edit-submit, another gets #edit-submit--2, the other #edit-submit--3. But due to the caching behaviour with reusing existing blocks, we end up with:

  1. If you visit the homepage, which just has the search form, its button gets #edit-submit.
  2. When you visit the contact page, which has 2 forms that need to be rendered, the Sign-Up and contact form, Drupal uses ids #edit-submit and #edit-submit--2. But the cached search form also ends up in the header with an id of #edit-submit too.

The simple_recaptcha module does something quirky. When you click the submit button it runs some javascript to get a token from the reCAPTCHA service, which is fine, but then it has to re-click the submit button, and it does that by looking up the button by ID again. Looking up by ID gives the first element with that ID, the search form's submit button.

Similarly, the captcha and reCAPTCHA module loads the token, but it gets stored in the cache and it causes the same or similar error that simple_recaptcha does.

Helping reCAPTCHA modules deal with Drupal caching

The real bug is challenging and not fixable within our support scope of practice. More on the accessibility concerns and other issues below.

  • The fix for the simple_captcha module is to modify the javascript as described in this bug write up.
  • If you’re using the captcha module, we recommend reviewing the discussion and various patches in #3089263.
  • For the reCAPTCHA module, perhaps consider using one of the other two modules instead.

Accessibility concerns

Even if you’re not using the reCAPTCHA module, your site may still have an adverse effect on accessibility as well as confusing any Javascript that is written. Here’s a quote from the linked accessibility issue:

“It may sound minor, but it's a major issue, as it is associating the search autocomplete functionality in the header with the views filters elements in the content. The end result is that JAWS thinks a regular select element in the views filters, is a combobox, which it is not, so it's pretty confusing to users.”

So it’s not just captcha related and is definitely going to need some real consideration from the caching experts that work on that piece of Drupal. Let us know on Twitter if you’re having the same issues and how you fixed them.

New call-to-action

Dec 22 2020
Dec 22

Have you ever decided on investing in a product or service, but require approval from executive sponsors before proceeding with your purchase? Or do you like a product or service, but are hesitant to make the investment in it because it’s costly?

If either of these scenarios describes the situation you’re in, a business case is an excellent thinking tool that can help you with your decision. A business case articulates the rationale for investing in a product or service in terms of numbers. It is often presented in a formal document, but may also be presented through more informal methods like a spreadsheet or even a single slide in a slide presentation. It further provides a way to make your case to nontechnical decision-makers without needing to provide the specific intricacies about the method or approach to your desired product or service’s implementation. 

To build a business case, perform the following steps: 

  1. Define the options to evaluate
  2. Determine the costs of each option
  3. Determine the benefits for each option
  4. Recommend an option based on cost and benefits

Let’s look at each of these steps more closely.

Defining Your Options

When evaluating a new product or service, you instantly are faced with two options: purchase the new product or service, or stay with what you have. In many cases, decision-makers start with a bias toward the status quo because there is no cost in transitioning to new technology and the business process that goes along with it. Further, if a new product or service is being considered, its competing options should be considered as well, for example, if you’re considering Drupal as a web content management platform, consider WordPress too.

Let’s illustrate with an example. Say you have a proprietary, licensed legacy content management system (CMS) that is poorly performing and difficult to maintain. You and your company are no longer happy with it and want to make a change. Your budget is limited, so an open-source solution is more attractive because it carries no licensing fees. Drupal is certainly an attractive option, but as just stated, add WordPress as an option. This brings our options to the following:

  • Drupal
  • WordPress
  • Status quo CMS

In a real-world scenario, it’s good practice to consider more options than this, including evaluating proprietary options like Sitecore and Adobe Experience Manager. For the sake of simplicity, however, let’s limit our example to the ones we’ve listed. 

Determine the Costs of Each Option

Two different types of costs need to be considered when evaluating options, the cost of the initial implementation, and the ongoing and operating costs once the implementation is complete. The following two tables approximate these costs. Note: these costs are approximations only to be used as an illustration. Actual costs can only be calculated once detailed requirements are considered. 

Implementation Costs

The following table summarizes theoretical implementation costs for each of the three options. These entail the licensing and build estimates for each option. This illustration assumes a simple implementation with little to no customization. Please note that these numbers are for illustrative purposes only. Real-world figures, driven by project requirements, will certainly differ.

Cost

Drupal

WordPress

Status Quo CMS

Initial License

$0

$0

$0 (already paid)

Build

$100,000

$50,000

$0

Total

$100,000

$50,000

$0

It comes as no surprise that the implementation cost of the status quo CMS is $0, because, after all, it has already been bought and configured. The licensing costs of all three options are $0 because Drupal and WordPress are open source offerings, and the license fee of the status quo CMS has already been paid. Had Adobe Experience Manager or Sitecore been considered, their license costs would be non-zero. In our example, we budget more for the Drupal build than that of WordPress because in our experience, with Drupal’s greater power and flexibility comes greater complexity, and that typically translates to greater investment in development hours. 

Ongoing/Operating Costs

After implementation, each option incurs recurring costs. This is a critical consideration in evaluating options that often gets overlooked, and we recommend you always factor in these costs in your decision. For our example, the following table summarizes those costs. To reiterate, these numbers are for illustrative purposes only. 

Cost/year

Drupal

WordPress

Status Quo CMS

Maintenance and Support

$20,000

$10,000

$50,000

Ongoing License

$0

$0

$10,000

Total

$20,000

$10,000

$60,000

Factoring ongoing costs makes it immediately apparent that the status quo CMS is costlier in the long term, both in maintenance hours spent and in annual licensing. As with their initial implementation costs, Drupal’s ongoing costs are greater than those of WordPress because, again, of Drupal’s greater complexity.

Determine the Benefits of Each Option

For investment in any of these options, a benefit is expected, particularly in expenses saved or new revenue earned. Focusing on annual revenue (again, just an illustration), the following table summarizes the benefits of each option. 

Benefit/year

Drupal

WordPress

Status Quo CMS

Annual revenue

$200,000

$150,000

$100,000

Finally, we see where the investment in Drupal’s complexity pays off; its greater functionality typically means a greater ability to meet ever-evolving needs. We translate this in our example to a greater annual revenue than that of WordPress, and both CMSs, being more functional than the status quo CMS, are capable of generating more revenue. 

Recommend an Option 

When we combine costs with benefits as described above, we are left with the following comparison:

Cost/benefit comparison chart for Drupal vs WordPress

The above graph makes the following assumptions:

  • In Year 1, the Drupal and WordPress options earn no revenue because they’re being built
  • Likewise the status quo CMS is earning revenue in Year 1 because it has already been built

So, in this example scenario, we can draw the following conclusions:

  • If your organization is prioritizing short term results, staying with the status quo CMS is the best option.
  • If your organization is willing to make a moderate up-front investment for moderate long-term benefit, WordPress is the best choice.
  • If your organization is willing to make a greater up-front investment for greater long-term benefit, then Drupal is the way to go.

Admittedly, our example scenario is overly simplistic. In reality, detailed requirements can radically alter both the costs and benefits of any option one considers. We at Mediacurrent have performed this type of analysis for some of our clients to help them with their technology investment decisions and can do the same for you. Please contact us to learn more!

Dec 18 2020
Dec 18

Rain logo updated

The Mediacurrent team is proud to introduce the latest version of our open source Rain CMS, now for Drupal 9. The latest version ships (currently in beta) with a brand new theme and admin experience. Make your move to Drupal 9 with speed and confidence. 

The New 'Nimbus' Theme

Homepage design for Mediacurrent's Rain CMS for Drupal 9 Nimbus theme

New Rain CMS theme homepage

The new base theme comes with a full Pattern Lab style guide to make development easier using a component-based theming approach. The new Rain CMS theme also adds color module support for in-browser color configuration. We wanted a great out-of-box experience for content authors and administrators so we pre-load the site with sample content to make it simple to get started.

Rain Admin 2.0

Rain CMS for Drupal authoring experience with jump navigation to manage page components

Rain CMS admin content edit page

With the latest version of Rain Admin, the content editing experience is more intuitive to use. A jump-navigation on the right-hand side helps authors move between different sections of the page. The UX for Paragraphs has also been improved to make it visually easier to manage components on the page.

Let’s Get Started

For developers, you can download and install Rain CMS 9 using our Drupal project template: https://bitbucket.org/mediacurrent/drupal-project/src/9.x/. Setup and installation remain the same as our previous version, with detailed instructions provided in the project README file.

For more information on the benefits of Rain CMS D9 and to schedule a free demo, please visit our contact page or chat with us right now (see bottom right corner of the page). We would be happy to talk more about your project or schedule a demonstration.

Dec 17 2020
Dec 17

argument-open-sourceargument-open-source

Recently, Drupal has been on an update rampage. The introduction of the oh-so-beautiful Drupal 9 core has spurred a chain reaction of upgrades across the Drupal platform. Just this week, we’re getting a new default theme (which is hyper-minimalist and easy-on-the-eyes), a 20% reduction in install times, and automated lazy load for images. But let’s talk about the juiciest UI/UX update that came with Drupal 9 — the standardization of Drupal’s Layout Builder.

If you’ve built a pre-Drupal-9 website over the past few years, you probably dabbled with Panels/Panelizer, WYSIWYG templates, or even custom coding to set up your UX/UI. And that works. We did it for years. But you can throw that worn-out Panelizer module in the trash. The times, they are a-changing. Drupal’s new Layout Builder module combines the core functionality of Panelizer with an out-of-the-box WYSIWYG engine.

First hinted at in 2017, Drupal Layout Builder officially left the onerous Drupal testing pipeline last year as part of Drupal’s 8.7 updates. Despite circulating for a year now, the chaos of 2020 has overshadowed this potent and flexible tool. So, let’s talk about it. Here’s what you need to know about Drupal’s Layout Builder.

What is Layout Builder?

Layout Builder is a WYSIWYG page editing engine that lets you manipulate back-end features via an easy-to-use drag-and-drop interface. It’s difficult to overstate just how valuable Layout Builder is when it comes to time-savings. You can create templates in minutes, immediately preview and create content changes, and tweak page-by-page UI/UX features to create more cohesive and on-the-fly websites and landing pages.

At its core, Layout Builder is a block-based layout builder. You can create layouts for either a single page or all content of a specific type. In addition, you can jump in and create rapid-fire landing pages based on your existing design theme. There are three “layers” that Layout Builder operates on to help you build out holistic websites.

  1. Layout templates: You can create a layout template for all content of a specific type. For example, you can make a layout template for your blog posts or a layout template for every product page. This template will be shared across all pages, so you don’t have to go in and rebuild for each content type.
  2. Customized layout templates: You can also go in and make granular changes to a specific layout template. So, if you want a certain product page to be different than the layout template, you can make granular changes to just that page.
  3. Landing pages: Finally, you can create one-off pages that aren’t tied to structured content — like landing pages.

Important: Founder of Drupal — Dries Buytaert — dropped a blog post with some use cases for each of these layers.

To be clear, Layout Builder isn’t a WYSIWYG template. It uses your existing template. Instead, it allows non-developers (and lazy-feeling developers) to quickly make per-page changes to the website without diving into code. But these aren’t just simple changes. You can create a layout template for every page type (e.g., creating a specific layout for all the shoes you sell), and you can also dive into each of these layout pages to make custom changes. So, it really lets you get granular with your editing without forcing you to completely retool and redesign pages for each type of content. This gives Layout Builder a massive advantage over WordPress’s Gutenberg — which requires you to go in and re-lay elements for every page individually.

Here’s the kicker: you get a live-preview of all changes without bouncing between the layout and the front-end. Every block and field you place and every change you make to taxonomies or content is visible the second you make the change. The entire process takes place on the front-end, and changes are instantly visible. Remember, Layout Builder is part of Drupal’s Core, so you don’t need to implement new entity types of dig into third-party elements. It’s an out-of-the-box experience.

Advantages of Layout Builder

Last year, we got a gorgeous, picture-perfect demo of how Layout Builder would work. It’s beautiful, fast, and packs a punch that other leading layout builders are indeed missing. So, to help unpack the value of Layout Builder, let’s look at some of the advantages of Layout Builder:

Customization

Beyond Layout Builder’s incredibly powerful and customizable block-based design engine, it offers customization in usage. Let’s say you want to create an amazing landing page. You can start with a blank page that’s untied to structured content, drop in some hero images, a few pieces of text, some content, and a video. Suddenly, you have a custom landing page (complete with modules, blocks, and taxonomy) that exists in a separate ecosystem from your website.

Simultaneously, you can create a template for every blog post, then dive into a specific blog post and make on-time changes to just that page while still being tied to your structured content. Remember, you can make these changes nearly instantly, without touching code. And you’ll see a live preview of every change immediately without switching between interfaces.

Accessibility

Drupal is committed to accessibility. The second principle of Drupal’s Values & Principles page reads, “build software everyone can use,” and this rings true. Layout Builder meets Drupal’s accessibility gate standards (i.e., conforms to WCAG 2.0 and ATAG 2.0, text color has sufficient contrast, JavaScript is keyboard-usable, etc.)

Ease-of-use

Like many WYSIWYG editors, Drupal Layout Builder is all about “blocks.” But these aren’t your run-of-the-mill blocks. There are inline blocks, field blocks, global blocks, and system blocks. Each of these has its own use case, and you can combine these block types to create stellar pages in minutes. For example, global blocks are used to create templates, and inline blocks are used to create page-specific changes that don’t impact the layout. The combination of these block types makes Layout Builder a hassle-free experience.

Additionally, there are plenty of ease-of-use features built into the core. Layout Builder works with the keyboard, has plenty of usability features that tie to Drupal’s value statements, and allows nit-picky setups for customized workflows.

Creating a Drupal Website is Easier Than Ever

With Layout Builder, users can generate valuable content and pages without needing to patch together various WYSIWYG tools or Panel/Panelizer. At Mobomo, we’re incredibly excited for our clients to dive into Drupal Layout Builder and make actionable and memorable changes to their templates based on their in-the-moment needs and experiences.

But Layout Builder isn’t a replacement for a well-designed and well-developed website. We can help you build your next world-class website. Once we’re done, Layout Builder gives you the freedom to make substantial changes without the headaches, back-and-forth, or unnecessary touchpoints. Are you ready to create a customer-centric, experience-driven digital space? Contact us.

Dec 17 2020
Dec 17

You started your ecommerce site with Shopify, and you obviously did it right, because you are continually seeing growth. That’s fantastic! But you are starting to see areas where you are outgrowing Shopify. What are the signs you should be looking for to make sure that your business keeps growing and not be held back by your ecommerce platform?

Seven areas to look at if you think you are outgrowing Shopify:

In this blog, we will take a look at a few things you can do if you think you are starting to outgrow Shopify.

Is it time? Has your company outgrown Shopify? We can help. Call today >Are you spending too much time every month manually inputting information into your CRM, ERP or inventory systems because there either isn’t an integration available for Shopify or it is not functional? Is there a platform that can automate some of those processes? The time you save can then be put back into important business tasks for strategic growth.

Look at all the 3rd party integrations your site needs.

Or will need to integrate with vendors to keep your ecommerce machine rolling. These integrations should enable you to more securely accept payments, provide more buying and delivery options for your customers, and more. Find an ecommerce platform that easily accepts these kinds of integrations and are securely developed so that you don’t wind up with a liability down the road.

Look at your user experience and how you want your brand to be perceived.

Does your site look and feel like the brand you want it to represent? Is there something missing that the Shopify themes are just not giving you? Does your brand stand out from the rest of the Shopify templated storefronts? Will you be able to make effective changes within the restrictions of Shopify’s templates?

Are you getting the reporting you need? Limited reporting makes it hard to develop a long-term business strategy. Better reporting means better decisions and more growth.

Look at the costs of “renting” Shopify’s platform.

Adding plugins to your base Software as a service (SAAS) platform to add customer-friendly and value-add features come with a price. The costs of those modules add up and could seriously be eating away at your bottom line every month. Consider the long-term advantage of owning your ecommerce website by creating it with an open source platform like Drupal and Drupal Commerce.

Look at your data.

Did you know that your Shopify store is generating a ton of data, but that you don’t own it? Shopify ties up your data, known as service lock-in, so that transferring your data becomes a cumbersome process, especially if you have a lot of it.

Look at the effectiveness of your CMS.

Shopify is not meant to be a content management system, so when it comes to adding videos and rich media, linking pages with products, and managing large amounts of content like a blog, your customer engagement and SEO. Shopify can make it hard at times to properly implement search engine optimization (SEO) tactics that would contribute to your growth.

For small to medium-sized businesses, Shopify is the best in class for ease of getting online, standardization and generally doing the basics in ecommerce.

As your business grows you may quickly learn that the things that made Shopify so attractive in the first place are the elements that are holding you back. If you have taken the time to really look at the above items and find that Shopify still meets your needs, then great.

If you are in a position where you feel that you may be starting to outgrow your ecommerce platform, the sooner you start looking at other options, the better. Making changes away from a standardized platform will get more complicated the more and more data, plugins and services you add to your current site.

Does all of this information leave you feeling a little overwhelmed? Don’t worry, we get it.

For something as crucial as your ecommerce platform, you want to make sure you are doing the right thing. That is where we come in. We live and breathe this stuff. Our ecommerce consultants and subject matter experts are open source commerce pros and are always happy to give as much advice as you need. Reach out today and let’s talk about what your next ecommerce platform should be after Shopify.

Don't struggle with a platform that can't adapt to your needs. Talk to the experts who help businesses facing the same problems every day  Have a no-obligation conversation today >

Dec 09 2020
Dec 09

Any web developer will have to move a site from one place to another periodically, so mastering the concepts and the details are important. The details are a little different from CMS to CMS, but the big picture stays mostly the same. Please note that many people have many opinions about all of this, and some people will disapprove of what I say, but it’s intended to teach you the basic process, not the exact procedure. It also will necessarily be incomplete, since there’s no way to cover every platform or CMS, or every permutation of deployment.

  1. Move the code for the website. If the site is just an HTML/JS site, you’re done. (Typically the code is checked via Git or some other source management situation, so it can be checked out in the new location.)
  2. Move the database, which has dynamic content in it. In many cases this is just one database, but in complex situations it could be more than one database.
  3. Move the user-generated or dynamic files. On Drupal, for example, the sites/default/files directory typically has all these user-generated or dynamic files. (There may be more than one directory of user-generated/dynamic files. In Drupal there may be private files in a directory outside the docroot.)
  4. Move the exported configuration. In Drupal 8+, for example, the config_sync_directory has this explicit exported configuration.
  5. Build the site in the new location. Although older sites didn’t have a build process for deployment, almost all the newer ones do. At the very minimum, this is typically a composer install to populate the vendor directory, which is often not checked into code. But there may be far more sophisticated requirements to the build, like an npm install or a compass compile. The basic idea is that your site may have a deployment build process which will have to be replicated in the new location.
  6. Configure database settings files. Normally the database credentials on one server will not be the same as on the other, so you’ll need to update the database settings as your CMS or platform requires.
  7. Transform URLs if necessary. Some CMSs like WordPress, Magento, and Shopware, have a tendency to bury multiple references to the site URL inside the database, so a transformation has to take place after all this is done. We wish they wouldn’t do this of course, but we have to live in the world we live in. Read about how to transform URLs. You’ll need to understand how to manage this in your particular CMS, as each does it differently. (Note that in Drupal, TYPO3, and Backdrop at least, incorporating a full self-referencing URL inside dynamic content is at least a party foul, probably worse, and it ruins standard deployments.)

Simplest deployment: Drupal through Drupal 7 – code, database, user-generated files, no build process

Up through Drupal 7, all you had to do to move a site in many cases was to check out the code, load the database from a database dump, and get the files into sites/default/files where they belong. In those days (and still on WordPress) that’s mostly what you have to do. Here is the process:

On the source server (can be DDEV-Local or anywhere else):

  1. Dump the database. If the source project is in DDEV-Local, this means just doing an ddev export-db --file=/path/to/sitename.db.sql.gz If you’re on a server or elsewhere, and assuming a single database, you can mysqldump | gzip >/path/to/sitename.db.sql.gz
  2. Tar up the user-generated files: cd /sites/default/files && tar -czf /path/to/sitename_files.tar.gz .
  3. Make sure your code has been checked in and pushed properly.

On the target server (which can be DDEV-Local or anything else):

  1. Check out or update the code from your git repo or wherever it’s stored.
  2. Copy your database dump to the server and load it into the database server using a tool like mysql, for example gzip -dc sitename.db.sql.gz | mysql (or on DDEV-Local ddev import-db --src=/path/to/sitename_db.sql.gz)
  3. Copy your user-generated files tarball to the target server and untar it in the correct directory: cd /sites/default/files && tar -zxf /path/to/sitename_files.tar.gz. (Or on DDEV-Local ddev import-files --src=/path/to/sitename_files.tar.gz)
  4. Edit your settings.php or settings.local.php (preferred) to point to the database you’ve loaded.

Drupal 8+ deployment: code, database, files, config, site build

Drupal 8+ is Drupal 7 with some extras, including copying the exported configuration and doing a composer install

On the source server:

  1. Do the steps you would have done for Drupal 7
  2. Determine what build processes are required for the site. compass? npm install?
  3. Export your configuration, for example, drush cex. The result will show you where the config was exported to. (This step is only necessary if configuration changes are to be migrated to the target server.)

On the target server:

  1. Do the steps you would have done in Drupal 7
  2. composer install (or ddev composer install if the target is a DDEV-Local project.)
  3. If there are other build steps discovered for the site, like an npm install or compass, add those processes.
  4. Copy the exported configuration to the target server if necessary and put it in the configuration directory specified in your settings.php or settings.local.php (preferred). Then drush cim to import it. Best practices include checking to make sure config hasn’t been changed in the database on the target server.

TYPO3 deployment (based on TYPO3 v10)

TYPO3 is mostly the same as Drupal 7 plus a composer build, but there are often (generated) files on the local system that need to be checked into git.

On the source server (can be DDEV-Local or anywhere else):

  1. Dump the database. If the source project is in DDEV-Local, this means just doing an ddev export-db --file=/path/to/sitename.db.sql.gz If you’re on a server or elsewhere, and assuming a single database, you can mysqldump | gzip >/path/to/sitename.db.sql.gz
  2. Tar up the user-generated files: cd public/fileadmin && tar -czf /path/to/_fileadmin.tar.gz . (Note that the user-generated files must not be checked into git.)
  3. Verify that the /config and (optionally) /var/labels directories are checked into your git repo. These are directories which may have been created by sitebuilder actions, but they’re code. (Nothing else in /var should be checked in.)
  4. Make sure your code has been checked in and pushed properly.

On the target server (which can be DDEV-Local or anything else):

  1. Check out or update the code from your git repo or wherever it’s stored.
  2. Run composer install (on DDEV-Local, ddev composer install). If there are other build activities like a yarn install, do those.
  3. Copy your database dump to the target server and load it into the database server using a tool like mysql, for example gzip -dc sitename.db.sql.gz | mysql (or on DDEV-Local, ddev import-db --src=/path/to/sitename_db.sql.gz)
  4. Copy your user-generated files tarball to the target server and untar it in the correct directory: cd sites/default/files && tar -zxf /path/to/sitename_files.tar.gz. (Or on DDEV-Local, ddev import-files --src=/path/to/sitename_files.tar.gz.)
  5. Edit your public/typo3conf/LocalConfiguration.php or public/typo3conf/AdditionalConfiguration.php (or .env file, preferred) to point to the database you’ve loaded. If the target is DDEV-Local, it will already take care of this for you.

From DDEV-Live to DDEV-Local

If your site is hosted on DDEV-Live, there’s a nice ddev pull command to get it once the connection is established. See the docs for a quickstart.

From DDEV-Local to DDEV-Live

DDEV-Local does not (yet) have a “push” command, although it will in future releases. It hasn’t been included to date because it’s a dangerous operation – you could overwrite your production with an old database or something else that doesn’t belong there. In general “pushing” a database to production is never done, except perhaps that one first time. After that other techniques are called for.

  1. Make sure you know your site name and org, and do the ddev-live auth if it hasn’t already been done. (docs)
  2. If you are creating the site for the first time, create the site and import db and files, see Drupal docs or TYPO3 docs. In either case, you’ll want your site configured to automatically do the composer install build step.
  3. Push files with cd /sites/default/files && ddev-live push files .
  4. Dump the database from DDEV-Local with ddev export-db --file=/path/to/_db.sql.gz and then push it to DDEV-Live with ddev-live push db /path/to/_db.sql.gz

From DDEV-Local to Pantheon

If you’re deploying to Pantheon.io you can use the web interface to upload the database and files under “Database / Files” → “Import”. Just use ddev export-db --file=/path/to/_db.sql.gz for the database and cd /sites/default/files && tar -czf /path/to/_files.tar.gz . to create a files tarball and upload them. Advanced users can also use the “terminus” tool, which is bundled in the web container and already authenticated if you’ve done a ddev auth pantheon with our integration. So ddev ssh and use terminus to upload.

Complexities and Alternatives

There is no standard for deployment or moving sites, and nothing will replace your team’s knowledge of the site and the build process.

  • Some teams prefer to do the build on a build machine (or in CI, or on a dev machine) and check in or push the resulting artifacts. For example, some teams will do a composer install and then check in the vendor directory and related artifacts.

Resources:

Mass juggling image by Sarah Richter from Pixabay

Share this post:

Dec 08 2020
Dec 08

[embedded content]

When you are in the groove of working on a new feature for your web project the last thing you probably want to do is spend time setting up extra tools just to see how your work looks live. Many of us have staging environments, alpha environments, dev environments, several local servers on our machines and of course various continuous integration tools. All of those require at least a couple steps to get your work in progress “live” and may also be locations that you can’t just share with collaborators. 

With this in mind, and based on the feedback of real live DDEV users, we’ve just added the first features of what we’re calling “DDEV Preview” to the platform on all tiers and as part of the personal free trial. Preview allows you to create a temporary staging site with one command directly on a pull or merge request. Let’s look at how this can be helpful!

When you need to stage and demonstrate work in progress

As a developer who does not want to break production, you likely do a lot of testing and staging before tagging and releasing new work. You may have found that despite best efforts with continuous integration, staging environments go stale and require extra attention when you go to use them. Along the way you’re losing hours on each project in getting all environments up to speed, not to mention finding clever ways (that aren’t piles of screenshots) to show clients work in progress, get approval and feedback on user experience, and more.

That’s not all, either – you’ve got a wide variety of projects, various CMSs, configurations, dependencies, and services connected to each of them. There’s not much of a one size fits all approach so each needs a series of environments for dev, test, stage, production, especially when clients each have their favorite hosting providers.

In summary, it’s complicated, and it’s a lot to manage. That’s why, at the request of DDEV users, we added the capability to create a quick, temporary preview site with the latest changes from your Git repository.

Integrated preview sites with GitHub and GitLab

With the first set of features for DDEV Preview, the author of a pull or merge request (we’ll just say PR here) can now build a site directly from that PR with a comment. The DDEV Preview Bot on GitHub or GitLab watches for PRs against branches that are deployed (but not necessarily published) on DDEV-Live and automatically comments on a PR when it is created.

The Preview site is deleted when the PR is closed, so you don’t wind up with stray sites counting against your overall account quota on DDEV-Live (assuming you keep your PRs tidy!). That means you’re automatically conserving resources in terms of platform costs, too. Preview can be used independently of DDEV hosting services. You can use Preview if you are a DDEV-Local user, or anyone with a GitHub/GitLab repo, and just want to have a Preview site but not a published production site hosted on DDEV-Live.

Using Preview in conjunction with other DDEV platform features can further smooth the process of taking a feature, bug fix, or new site from local development to live deployment. The time savings an end-to-end integrated system offers adds up and gives time back to everyone involved. Developers can focus on getting the feature right, project managers can spin up preview sites to hand over to business for client check-ins, and return on hiring and infrastructure investment is maximized across the organization.

Here’s an example of how you in the real world might use this feature. 

You have an account with DDEV-Live (in this example, we’ll use GitHub, which requires the DDEV-Live GitHub app installed on your GitHub account and the ddev-live CLI installed on your machine) and deploy a site from a branch via a command such as: 

$ ddev-live create site drupal my-drupal-site \
--github-repo my-github-org/clientsite \
--branch workingbranch \
--drupal-version 9 \
--run-composer-install

Now you have a copy of the code in your branch workingbranch available on DDEV-Live, but not published with DNS etc. You also push your database and file assets. 

This is where DDEV Preview comes in. For this example, let’s say your client wants to see the current work on their new website theme right now (watch Randy’s example with a theme change here). Commit and push your local work to your GitHub repository clientsite on the workingbranch branch, and create a PR from that commit. 

Because you have that branch deployed on DDEV-Live already, our preview bot will automatically recognize the PR against the deployed branch and will comment on the PR to ask what you would like to do next. 

Run the suggested command /ddev-live-preview-site and the bot will build a preview site using the code in your PR and the assets from the previously deployed branch to show your work in progress as it would appear “live.” The bot returns a URL you can share with your client, displaying how their site will look with the new theme and their existing blog posts and images. They can validate that you’re on the right track and you can close the PR (automatically deleting the preview site) and continue working.

Launch and learn!

What are you missing in your development workflow today? How could it be easier for you (and your team) to move small pieces of work from start to finish? 

The next set of Preview features for DDEV-Live will include updates to the dashboard user experience, support for forked PRs, and shared workspaces on the platform. Further down the road will be more fine-tuned configuration management and launching Preview sites from a wider variety of environments to truly fulfill our mission of being either one flexible component or home to your entire development workflow.

Preview is available in every plan on DDEV-Live to facilitate collaboration, testing, and client approvals without creating and syncing a separate environment. Our aim is to empower open source developers who seek the freedom that flexible and configurable tools can grant a development workflow. We hope DDEV can fill that role for you.

Contact us for a personal walkthrough or to put together a custom DDEV plan to to save you time and energy.

Share this post:

Nov 24 2020
Nov 24

Do you know the version number of the browser you’re using? What about the operating system version you’re using? Chances are, you have no idea what the current version you’re using of any major software is. And that’s the way it should be.

Tips for upgrading to Drupal 9

  • Make sure your version of Drupal is up-to-date.

  • Use Upgrade Status to see if your website is ready for upgrading

  • If you have custom code, use Drupal Rector to identify code that needs to be updated

Throughout the software industry, there is a movement to more frequent, easier, updates. The reason behind more frequent updates is that everyone tends to keep software up to date and more secure, the easier and more frequent those updates come. Soon, you may not know the major or minor version of your website software, just that it is up-to-date and secure, which is the ultimate goal of any update, upgrade or version release.

What version of Drupal am I running?

Chances are if you’re using Drupal, you are using version 7 or 8. In June 2020, version 9 of Drupal was released and the last minor version of Drupal 8 was released. Both version 8 and 9 contain the same features and code. The only difference is that Drupal 9, or D9 as it is referred to in the industry, removed deprecated code and updated third-party dependencies.

(Source: Drupal.org - How to prepare for Drupal 9)

The image above shows the timeline for Drupal 8 and its version releases since 2019. The upgrade cycle in version 8 for minor releases was established to be a single release roughly twice a year. Now that Drupal 9 has been released, there will be an end-date for support for Drupal 8, but that is not scheduled until November 2, 2021. In fact, the upgrade from 8 to 9 is so painless, version 10 will be released in 2022, likely to even less fanfare, as it will also be the same as the most recent version 9.

Time to upgrade? Let our Drupal experts help!Upgrading between all minor versions of Drupal, including the jump to version 9 is advised, but is a much simpler process than version upgrades have been in the past. See what Drupal.org has to say about it here. However, if your website was recently created or released since 2016, it’s likely that you’re on Drupal 8, and the upgrade should be extremely straightforward and relatively painless.

If you find yourself on version 7 of Drupal, you can absolutely upgrade straight to D9 and skip D8 altogether. The rebuild would likely take the form of an entirely new website, but the benefits of going right to D9 are two-fold: avoiding end of life issues for D8 in 2022 and jumping on a platform that will enable to you go headless, adopt the best media, personalization, translation, and content creation tool that open source has to offer.

Why migrate to Drupal 9?

Running end-of-life platforms come with a set of problems that over time, will end up costing your company time and money. When official support for D7 runs out in 2022 (the same time as D8), security updates, bug fixes and creation of new modules for those versions will also go away. This opens your system to being more vulnerable to cyber attacks, potential downtime and a lack of up-to-date features that your customers would expect from your web presence.

Jumping right into a new build with D9, you benefit from having the long-term official support from the Drupal community including security releases that help protect your website from various vulnerabilities. D9 also removes outdated code and uses the new version of PHP, which is important in terms of security.

Other reasons to upgrade to D9, from Drupal.org:

  • Easiest upgrade in a decade, and a commitment to easy upgrades in the future. Never replatform again.
  • Continuous innovation, cutting-edge new features, reaching new digital channels while strengthening our foundation in content management.
  • Dramatically easier tools, intuitive solutions that empower business users to take advantage of the power of Drupal.

Currently, we are on the cusp of the first minor release of Drupal 9, which is planned before the end of the year. Most large ecosystem modules in Drupal have complete support for Drupal 9, including Drupal Commerce version 2.

Tips for Upgrading to Drupal 9

  • Make sure your version of Drupal is up-to-date.
  • Use Upgrade Status to see if your website is ready for upgrading (this module will flag modules that need to be upgraded to Drupal 9).
  • If you have custom code, you can use Drupal Rector to identify code that needs to be updated and, in many cases, can be automatically upgraded.

Still not sure that the upgrade to Drupal 9 is right for your organization? Have questions about the best way to handle upgrading your Drupal site? Our team is here to help you answer those kinds of questions. Check out our Drupal and Drupal Commerce Development page for more details on our services, or contact our experts to get started on your Drupal upgrade today.

Need more information on upgrading to Drupal 9? Contact our Drupal experts today to get your project started >

Josh has been creating websites since 2000, has been a Drupal community member since 2008, and is currently the Team Lead of the Investment Division at Acro Media. He spends most of his free time playing board games and yelling at his cat with his wife.

Nov 19 2020
Nov 19

Is Drupal’s open source platform secure?

When deciding on the best CMS to meet your organization’s digital vision, security is often one of the top concerns. 

Here’s the reality. ALL software (closed source, open source, or custom-developed) has the potential for security vulnerabilities. Web security is a fast and ever-changing world. What passes today as secure code may not stay the same tomorrow when new vulnerabilities surface.

There's peace of mind in knowing not only is Drupal a proven, secure CMS but that it's also in an active state of safeguarding against attacks. 

With proper planning, maintenance, and updating, open source software, like Drupal, can meet and even exceed the security standards of closed source. 

- Mediacurrent’s Mark Shropshire, Senior Director of Development, quoted in an excerpt from Setting the Record Straight on Drupal Myths: Acquia eBook 

Security and The Drupal Community

Open source software, like Drupal, has the bonus of having thousands of experts work on a particular problem. With entire teams and methodology devoted to ensuring its steadfast reputation as a secure CMS, it's comforting to know modules and code procured from the official Drupal site are as secure as possible.

Using Drupal means you never have to face these risks alone, let alone attempt to correct the problem by yourself. There's power in numbers when it comes to both discovering and fixing potential software flaws, and the Drupal community has those numbers.

Dedicated Security Team

The Drupal project has an approximately 32-person security team with a track record of professionally handling security advisories. 

Community Code Review

One of the largest developer communities in the world, Drupal.org clocked 100,000 contributors and 1.3 million users at the time of Drupal 9’s release. Having many eyes on the source code ensures more issues are discovered and resolved. 

Rapid Response Time

Defined processes around reporting and resolving security issues accelerate the response time to fix vulnerabilities and release patches. 

Core Security

Core API tools and techniques address common security risks. Community projects such as the Guardr distribution help educate the community on best practices around Drupal security.

Guardr for Drupal logo

The Guardr distribution was created to enhance a Drupal application's security and availability to meet enterprise security requirements.

Proven High Standards 

Drupal-based organizations around the world — including enterprise-level brands, major universities, government, and large non-profits — put Drupal’s high security standards to the test every day.

Drupal Security Throughout the Website Process

The Drupal community has built-in security measures to combat threats — reassuring for sure. To proactively protect your site, the concept of security needs to be at top of mind when campaigns are being launched, systems/applications are being integrated, or when software is deployed or updated. 

Security-First 

A security-first approach means going beyond compliance to better assess risk. There are two paths to achieve this approach:

1) Culture: Adopting a security mindset culture for your organization. 

2) Automation: Taking on a continuous development plan that’s rooted in process automation.

In other words, start planning for security early and often throughout the website development process. 

phases of a web project: discovery, design, development, quality assurance, deployment, support

Don’t wait until the project is about to launch to think about security! Explore our Guide to Open Source Security eBook for tips and processes to consider when putting together a security-first maintenance plan for your website and marketing tech stack.

Developer Best Practices 

Here are three ways to safeguard your Drupal site: 

1. Choose the Right Modules

If you can dream up a feature for your site, chances are it can be found in the tens of thousands of community-contributed modules available for Drupal. With so many different options to pick from, how do you choose the most secure modules possible? Some steps to take are checking for how many sites are using the module, reviewing the issue queues, and avoiding deprecated or unsupported modules. 

Find more criteria for module decision-making in our guide to Drupal module evaluation

2. Use Drupal APIs

Look to Drupal APIs documentation to secure your contrib or custom code on a project. Drupal APIs have been nurtured by the community and have built-in protections for database security. If you do write new code, whether it’s a small amount or a completely new module, the “Writing Secure Code for Drupal” guide is a must-read reference. 

3. Monitor Drupal Security Advisories 

The Drupal security team posts weekly security advisories to Drupal.org.

To keep up with security releases, you can sign to receive email notifications through your drupal.org profile options, follow the RSS feed in your news reader (core, contrib, public service announcements), follow @drupalsecurity on Twitter, or join the Drupal Slack #security-questions

Sleep Better With a Secure Drupal Site 

For more best practices, check out the Mediacurrent presentation Sleep Better with a Secure Drupal Site: 

[embedded content]

Are you ready to build a strong foundation for Drupal security but unsure where to start? There's a lot to consider in your security plan but it doesn't have to keep you up at night. Contact the Mediacurrent Security team for support. 

Nov 18 2020
Nov 18

From the consumer perspective, there’s never been a better time to build a website. User-friendly website platforms like Squarespace allow amateur developers to bypass complex code and apply well-designed user interfaces to their digital projects. Modern site-building tools aren’t just easy to use—they’re actually fun.

For anyone who has managed a Drupal website, you know the same can’t be said for your platform of choice. While rich with possibilities, the default editorial interface for Drupal feels technical, confusing, and even restrictive to users without a developer background. Consequently, designers and developers too often build a beautiful website while overlooking its backend CMS.

Drupal’s open-ended capabilities constitute a competitive advantage when it comes to developing an elegant, customer-facing website. But a lack of attention to the needs of those who maintain your website content contributes to a perception that Drupal is a developer-focused platform. By building a backend interface just as focused on your site editors as the frontend, you create a more empowering environment for internal teams. In the process, your website performs that much better as a whole.

UX principles matter for backend design as much as the frontend

Given Drupal’s inherent flexibilities, there are as many variations of CMS interfaces as there are websites on the platform. That uniqueness is part of what makes Drupal such a powerful tool, but it also constitutes a weakness.

The editorial workflow for every website is different, which opens an inevitable training gap in translating your site’s capabilities to your editorial team. Plus, despite Drupal’s open-source strengths, you’ll likely need to reinvent the wheel when designing CMS improvements specific to your organization.

For IT managers, this is a daunting situation because the broad possibilities of Drupal are often overwhelming. If you try to make changes to your interface, you can be frustrated when a seemingly easy fix requires 50 hours of development work. Too often, Drupal users will wind up working with an inefficient and confusing CMS because they’re afraid of the complexity that comes with building out a new interface.

Fortunately, redesigning your CMS doesn’t have to be a demanding undertaking. With the right expertise, you can develop custom user interfaces with little to no coding required. Personalized content dashboards and defined roles and permissions for each user go a long way toward creating a more intuitive experience.

Improving your backend design is often seen as an additional effort, but think of it as a baseline requirement. And, by sharing our user stories within the Drupal community, we also build a path toward improving the platform for the future.

Use Drupal’s Views module to customize user dashboards

One of the biggest issues with Drupal’s out-of-the-box editorial tools is that they don’t reflect the way any organization actually uses the CMS. Just as UX designers look to provide a positive experience for first-time visitors to your site, your team should aim for delivering a similarly strong first impression for those managing its content.

By default, Drupal takes users to their profile pages upon login, which is useful to . . . almost no one. Plus, the platform’s existing terminology uses cryptic terms such as “node,” “taxonomy,” and “paragraphs” to describe various content items. From the beginning, you should remove these abstract references from your CMS. Your editorial users shouldn’t have to understand how the site is built to own its content.

Powering Our Communities homepage

In the backend, every Drupal site has a content overview page, which shows the building blocks of your site. Offering a full list that includes cryptic timestamps and author details, this page constitutes a floodgate of information. Designing an effective CMS is as much an exercise in subtraction as addition. Whether your user’s role involves reviewing site metrics or new content, their first interaction with your CMS should display what they use most often.

Manage News interface

If one population of users is most interested in the last item they modified, you can transform their login screen to a custom dashboard to display those items. If another group of users works exclusively with SEO, you can create an interface that displays reports and other common tasks. Using Drupal’s Views module, dashboards like these are possible with a few clicks and minimal coding.

By tailoring your CMS to specific user habits, you allow your website teams to find what they need and get to work faster. The most dangerous approach to backend design is to try and build one interface to rule them all.

Listen to your users and ease frustrations with a CMS that works

Through Drupal Views, you can modify lists of content and various actions to control how they display in your CMS. While Views provides many options to create custom interfaces, your users themselves are your organization’s most vital resource. By watching how people work on your site, you can recognize areas where your CMS is falling short.

Drupal content dashboard

Even if you’ve developed tools that aimed to satisfy specific use cases, you might be surprised the way your tools are used. Through user experience testing, you’ll often find the workarounds your site editors have developed to manage the site.

In one recent example, site editors needed to link to a site page within the CMS. Without that functionality, they would either find the URL by viewing the source code in another tab and copying its node ID number. Anyone watching these users would find their process cumbersome, time-consuming, and frustrating. Fortunately, there’s a Drupal module called Linkit that was implemented to easily eliminate this needless effort.

There are many useful modules in the Drupal ecosystem that can enhance the out-of-the-box editorial experience. Entity Clone expedites the content creation process. Views Bulk Operations and Bulk Edit simplify routine content update tasks. Computed Field and Automatic Entity Label take the guesswork out of derived or dependent content values. Using custom form modes and Field Groups can help bring order and streamline the content creation forms.

Most of the time, your developers don’t know what solutions teams have developed to overcome an ineffective editorial interface. And, for fear of the complexity required to create a solution, these supposed shortcuts too often go unresolved. Your backend users may not even be aware their efforts could be automated or otherwise streamlined. As a result, even the most beautiful, user-friendly website is bogged down by a poorly designed CMS.

Once these solutions are implemented, however, you and your users enjoy a shared win. And, through sharing your efforts with the Drupal community, you and your team build a more user-friendly future for the platform as well.

Nov 11 2020
Nov 11

 workflow automation diagram with gears and icons with connection line network in background

If you know us at Mediacurrent, you know we create amazing digital experiences with Drupal. Did you know we also support WordPress websites?

Since 2007, Mediacurrent has been the open source expansion partner for enterprises and global brands. As certified experts, we have a reputation for providing best-in-class digital solutions and growing long-term, strategic partnerships for clients like Weather.com, MagMutual, and Emory University

With thousands of implementations and thought leadership resources completed, we have been continuously looking for ways to add more value to our customers. We've seen a rising need in our Drupal community through hours of partnerships, and that need is more WordPress support. 

WordPress in the enterprise has risen 16%, driven largely by the rise of multiple CMS use.

- Source: The Rise of Multi-CMS in the Enterprise

Why the Expansion?

For over a decade, we have been helping customers migrate from WordPress to Drupal, and we've proven ourselves a trustworthy partner in the migration process. As we've grown, we’ve expanded our Drupal expertise into deep open source strategies—partnering with clients on a long-term basis to solve their technology challenges.

Many enterprise organizations that have standardized on Drupal will still have some non-Drupal sites in their ecosystem. That's where Mediacurrent comes in as a single-source digital partner. 

What We've Done So Far

Currently, Mediacurrent is assisting large-scale enterprises with their WordPress sites. What started as Drupal legacy clients have turned into an opportunity to better serve our customers. Our open source software clients came to us with similar pain points, and thanks to our long-term partnership, we were able to provide crucial benefits that provided a valuable impact on their return of investment, including but not limited to:

  • Engaging UX - Our recent WordPress customers faced the challenge of creating an engaging user experience. Mediacurrent planned for a full redesign of the website's look and feel, providing branding, design, and value proposition workshops and including considerations for persona needs and critical business objectives.
  • Data-driven Strategy - These organizations needed to maximize the return on their digital investment. Mediacurrent is continuing to incorporate best practices for content, page layout, navigation, lead generation, and search engine optimization.
  • Open Source Training - Designs were implemented using the Elementor page builder plugin for WordPress. Mediacurrent’s training team provided specialized instruction on Elementor page design to create page layouts and components. 
  • Post-Launch Support - Monthly support agreements help to optimize for performance and security, providing immediate value to our legacy customers. Security updates to WordPress and plugins can (and do) come at any moment. You must have a dedicated support team closely monitoring and upgrading the code regularly.

Where We're Going

Moving forward, we will expand our support for open source clients who maintain Drupal and WordPress websites within their organizations. If 2020 has taught us anything, it’s that Mediacurrent needs to pivot with our customers' needs and continue to provide the best solutions possible.

As your digital partner, Mediacurrent will evaluate your web properties by assessing several core functionalities including;

  • Security - Making sure your WordPress site stays updated and secure.
  • Responsive Design and Development - Mobile-first designs backed by data and user research.
  • Search Engine Optimization - We consider three factors when it comes to perfecting your on-page optimization: Page load times, Schema.org implementation, and CDN.
  • Content Authoring Experience - A seamless publishing workflow is the key to empower content creators. Tools like Elementor let teams create and design new page layouts on the fly using a drag and drop interface. We've found this very similar to Drupal's Layout Builder, but more advanced and easier to use. 

We see organizations growing, and the need to evolve our services to support others who have more than one CMS to manage. 

49% of enterprises are planning to expand to additional CMSs in the future.

- Source: The Rise of Multi-CMS in the Enterprise

How We Can Help 

Desktop computer background in office and handshake hologram drawing

Mediacurrent is excited to continue to expand our unique value proposition to organizations that aren’t standardized on a single platform and require peace of mind in terms of quality, security, and consistency. We have a reputation as a valued partner that is driven by growth strategy, risk mitigation, solving complex business problems, and producing real, bottom-line value with our solutions.

If you’re already running on Drupal and need help managing additional WordPress sites, or just have a lot of questions about migration, security, or future support, please reach out to the Mediacurrent team. We are available to discuss your websites' future, how we can help you efficiently manage your existing platforms, and provide a strategic roadmap that will keep your multi-CMS organization on the path to success  

Nov 10 2020
Nov 10

Open Source for Everyone

Open source runs the digital world. As a top 10 contributor to Drupal—the software used by 1 out of 30 sites in the world—Mediacurrent feels a deep sense of responsibility to be the change we wish to see. 

From “IDEA” to Reality 

Building a culture that values open dialogue and accountability around issues of diversity and inclusion has always been our goal. This year, we took steps to define our core values and unite our voices for change by launching an employee-led diversity council. Our Inclusion, Diversity, Equity, & Awareness (IDEA) team drives an important mission. The group strives to lift up marginalized voices in tech and address difficult, ongoing challenges including societal racism, racial bias, transphobia, and homophobia. 

logo for Mediacurrent Inclusion, Diversity, Equity, & Awareness team

Opening Up About Privilege 

The IDEA committee brings many voices together. As Mediacurrent’s Director of Project Management, I’m proud to be one of those voices.

We often hear that the benefit of open source communities is that anyone can contribute. Yet, this paints a rosy picture of equality that’s far from the current reality in our Drupal community. (Drupal creator Dries Buytaert presents the issue well in this article: The Privilege of Free Time in Open Source.) My personal mission is to lead a dialogue on understanding how individual privilege can open doors for an open source community that's as wonderfully diverse as Drupal’s end users. 

What can those with privilege do to effect change? I grappled with this question in a DrupalCon Seattle session Putting Our Privilege to Work for Inclusivity in Open Source, below. It represents the types of conversations happening within our IDEA committee:

  • What does privilege look like?
  • Mindfulness and recognizing our own privilege
  • How to address privilege in others...gently
  • How to bring about real change

[embedded content]

The Path Forward

The IDEA team is hard at work on a few upcoming initiatives, including:

  • Sharing new data about our employee diversity 
  • Making socially conscious choices together about the charities we support 
  • Updating job postings to include our values
  • Technical documentation audit for inclusive language

We look forward to introducing more members of the Mediacurrent IDEA team and sharing some of the many in-progress initiatives on our path forward.

Nov 09 2020
Nov 09

[embedded content]

Sarah Durham (00:02):

Hey everybody. Welcome to today’s webinar. I am Sarah Durham, and I am going to briefly introduce my colleagues. They will talk a little bit more in a minute and also we’d love you to introduce yourself as people start to arrive. If you are comfortable doing so, you’ll see a chat panel. And if you could chat in to us your name, the name of your organization, your pronouns, and where you are, where you are geographically, so who you are and where you are, would be great. Theresa, you want to say hi. 

Theresa Gutierrez Jacobs (00:50):

Hi, I’m Theresa Gutierrez Jacobs. I am a project manager at Advomatic. And for today, I’m going to just quickly chat my email. If you have any, I don’t know, tech issues or questions or anything like that, that is more tech related to this webinar. Feel free to reach out to me via my email. Otherwise, you can always chat or ask questions, particularly for this webinar here. And Dave, you want to say a quick hi, before we get rolling.

Dave Hansen-Lange (01:18):

Hello. I’m Dave Hansen-Lange and where I am, I’m about an hour from Toronto. I’m the director of technical strategy at Advomatic. I’ve been with Advomatic for about 13 years. And I’ve been doing work with nonprofits in the web for maybe about 15 or 17 years.

Sarah Durham (01:42):

Okay. So we’ve got a bunch of people who are already with us, a few more people who might join us in the next couple of minutes, but just to keep the ball rolling and use your time thoughtfully, we’re going to dig into our content for today. And as I said a little bit earlier, I will reintroduce myself. I’m Sarah Durham, I’m the CEO of Advomatic and also Advomatic sister agency, Big Duck. Some of you may have noticed that the Zoom we’re using today is a Big Duck/Advomatic shared Zoom. So if you’re wondering what the connection is, there’s some common leadership across both companies. For those of you who might know Big Duck, but don’t know Advomatic, Advomatic builds sturdy sites that support change. We build, and we support websites in Drupal and in WordPress. And Advomatic has been around now for, I think almost 15 years, although it’s partnership and collaboration with Big Duck and my coming into the company is relatively new.

Sarah Durham (02:43):

It’s about, I’ve been in it about two years. And so Dave is going to really take us through our topic today. And Dave, you could advance to your next slide, if you would like, which is this, what should you do with your Drupal 7 website? So Dave’s gonna talk us through why this is an issue and a few other things in a minute. What I am going to do throughout this conversation is I am going to be monitoring both the chat that you can see in the bottom of your screen, a little button that says chat. And if you click on that, you have the ability to either chat privately to the panelists. So if you want to ask a question confidentially, or you don’t want everybody who’s here to see it, just chat to the panelists and only Dave and Theresa and I will see it.

Sarah Durham (03:26):

If you want to chat to everybody and share who you are, like shout out to Rick, who’s already done that. He’s from the National Council of Nonprofits and he’s in the DC area. If you want to share your information with the panelists or to everybody, you can chat to all attendees. Also, you have the ability to specifically ask questions. There’s a Q&A feature in Zoom Webinar. And that will give me the ability to keep an eye on your questions. And some of them I can type back to you and others will be addressed verbally. So throughout the presentation, I’ll be monitoring all of that and we will address your questions perhaps as we go on, certainly at the end if it doesn’t make sense to do so in the webinar. So don’t hesitate to chat, don’t hesitate to ask questions. We are recording today’s session and Theresa will be sending out an email with a link to that recording and the transcript and the resources we’re mentioning later this week or early next week. So you will have all of this and you can share it with any colleagues if that is useful. So with that, we are going to get rolling over to you, Dave, and thanks, Theresa.

Dave Hansen-Lange (04:44):

Okay. Thank you, Sarah. All right. So to kick things off before we get into the details of all the different things that you can do with your website and what might be best for you I thought we should start with some backstory about like, why we’re at this spot and like, what does end of life even mean? Like, it’s software, how can software… and it really all comes down to security. And just to explain a little bit about how security in Drupal works, there is the Drupal security team, and that’s a team of about a dozen people all across the world. And then there’s a group of people even wider than that who contribute things to the team and say, Oh, this could be a problem. We should look into this. And people on the security team, you know, a lot of their time is paid for by their employers or their clients, but a lot of their time they’re just volunteering for free.

Dave Hansen-Lange (05:50):

And you know, there’s a lot of commitment there. Like, they have weeks on call and stuff like that, because security is very important to the Drupal community. And so we don’t want to have those people working forever for free. So the Drupal community at large has decided, okay, thank you for your time of service, people on the Drupal security team, we will let you go after this date. Some of those people work on AAA too. But people are generally committed for like Drupal 7. And so the original date for the end of Drupal 7 was going to be November, 2021. But then COVID happened and the Drupal community decided, okay, there’s this extenuating circumstance. We’ll give everybody one more year to figure out what they’re going to do. So now that the end of life date for Drupal 7 is November 2022, two years from now. 

Dave Hansen-Lange (06:56):

Drupal 8, just as an aside, it’s not really what we’re talking about today. Drupal 8, the end of life is November 2021, a year from now. That’s not what we’re talking about today. And thankfully, if you do have any AAA sites, the situation is a lot simpler. And if you want to get into that a little bit more possibly we could at the end of the presentation. Okay. So today we are going to first cover: these are the options that you have in dealing with your Drupal 7 websites. Then we’re going to look at some example scenarios. And by that, I mean like, okay, here’s an organization, they have a website like this, and because of that, they might consider scenario x. And then I’m going to pass things over to Sarah. And Sarah is going to dive into more of the organizational things, like, how do you plan for this and how do you work with this within your organization? All right. 

Sarah Durham (08:15):

Hang on one second, Dave, before we dig into this, I also just want to remind everybody feel free to chat in questions and comments as you go, and we’re going to take pauses in between each of these sections. So if you have, as Dave goes through the options, if you have a specific question about one of the options, and it seems like it’s universal to some of the other people who are participating today, I’ll probably pop in and ask that otherwise we’ll save Q&A for the end. Alright, sorry for the interruption.

Dave Hansen-Lange (08:41):

No, no, all good. I’m also going to be muting every now and then to take a sip of tea. I’ve got a sore throat. It’s not, COVID, it’s just a cold. And yeah, so I’ll be pausing too, as I go. Okay. So what are your options? So I’ve grouped these into four main options, and these are listed in terms of most expensive, to least expensive, most expensive option being start from scratch and build a new website for most people with a Drupal 7 website your main options are move to Drupal 9 or create something in WordPress. There’s some other options that you might consider, but those are the two that are applicable to most people. Option B is upgrade to Drupal 9 and immediately you’re probably thinking what is upgrading to Drupal 9? How is that different from building a website and Drupal 8? And I’ll explain that when we get there, another option is to switch to something called Backdrop. Many of you have probably never heard of Backdrop. And so I’ll start us out by what exactly that means. Or you could just stay on Drupal 7. And even though it has end of life, that there still are ways to keep going on, on your Drupal 7 website.

Dave Hansen-Lange (10:15):

So moving to a new website like I mentioned the main options for most people are Drupal 9 or WordPress. And so just by saying those two names in the same sentence, we immediately get into the topic of like what’s better Drupal or WordPress and what is right for me? I will touch on this a little bit now, and sort of back up a little bit and say that for starters, it’s really hard to make an unbiased and fair assessment of the two. But in a general sense, Drupal 9 is really great for people that, or on websites and organizations that want to do something a little bit more complicated, a little bit more ambitious, a little bit more technological, with more moving parts. And WordPress is generally more applicable to the organizations whose website, in many ways might be similar to other websites. And yeah, that is a little bit vague. I don’t want to dive too deeply into this topic right now. 

Dave Hansen-Lange (11:54):

If you want, we can come back to this in the Q&A at the end. And we also have another webinar that we did a couple months ago on this topic more generally. And if you’re just, if you can, we can send along a link to that as well. One last thing on this, though, I will say that when most people compare Drupal and WordPress, they’re not really comparing Drupal and WordPress, they’re comparing the website that someone built for them in Drupal or the website that someone built for them in WordPress. And because of that, they’re often comparing the skills of those people who built the website and not necessarily the underlying technology. And that’s part of the reason why this is such a sticky, thorny issue with a lot of people being on one side or the other there about moving to a new website. You don’t have to do the whole entire thing. You can find ways to do this in bits and pieces. I’ll show some examples of that later, but we’re at this point of rethinking what should we generally do with our Drupal website. It’s a great time to think, okay, this section, do we need it anymore? Should it be here? Is there a better way to do this then when we created this website however many years ago?

Dave Hansen-Lange (13:30):

Since many of you may not have seen modern Drupal I’m going to show you, or we’re pressed, I’m going to show you some slides here. So on the left, what we see is I am editing a page on a website and I want to add a new component which is a common term that we use these days, a new component to the page. I can browse through this library of available components and then add one.

Dave Hansen-Lange (14:00):

Or how it’s going to appear on the page. There’s many ways to do this in Drupal. Drupal is kind of known for having many ways to solve a problem. What we see in this screenshot is a tool called paragraphs. That’s a tool that we’ve been using for this problem pretty successfully on several websites. There’s other tools within Drupal 9. You may have heard the term layout builder and there was a couple of smaller ones as well on the right side. We see the administrative listing of all the content on your website for each site, it’s going to be a little bit different, what you decide to list here. But this is just one example of how it looks and comparing this to WordPress on the left. This is also how WordPress looks when you want to add a new component to the page. And so the right column there, we see, the available components that you have, again, on the right, a screenshot that’s WordPress of a list of all the content on the website.

Dave Hansen-Lange (15:20):

Looking at these two sets of screenshots, there’s a couple things that might sort of immediately come to mind. WordPress, the administrative interface generally looks a little bit more polished.

Dave Hansen-Lange (15:39):

In some ways WordPress can be a little bit all over the place in that each plugin or each new thing that you add to your website tends to design things its own way and do its thing its own way and it’s WordPress. Compared to Drupal, each new thing works in a very consistent manner. So it’s easy to move around from section to section on the website. All that to say is really either is probably a big step forward from where you are with your Drupal 7 website.

Dave Hansen-Lange (16:18):

All right, so which Drupal 7 website is this going to be most applicable to, or maybe you shouldn’t at all consider this option? If you are really frustrated with any part of your website, be that like how the content of this is organized, or just the general backend experience the design of the website, if there’s anything about it that you’d just want to just toss and start again fresh, this is a good option to consider. But like I mentioned, when I listed these four main options, creating a new website is going to be the most expensive of the options. And in the age of COVID, many of you are probably dealing with some tight budgets. So one of the other options may be the better choice. Also, this might not be a good choice for you if your existing site is very complex. And one way to think about this is like you built your website so many years ago, let’s say it was five years ago. And you put all this work into doing that initial build, but then over those five years, you’ve also put in some work, to make the website more and more better. And in this new version of the website that you’re gonna create, you want to encompass all of that. 

Dave Hansen-Lange (17:52):

It’s going to be a pretty big project. And so it’s just one way to consider looking at your options.

Okay. Option B, I don’t have a handsome, single flat you can upgrade to Drupal net. So how is this different from just creating a new websiteIn AAA? Drupal 9 has these built-in tools that can take your Drupal 7 website and take all those, all that content, all the content structure all the menus, everything that’s stored in the backend of the website and upgrade it and make it work in a new Drupal 9 website. But what you don’t get is any of the, how that content is presented to visitors, all of that stuff. If you go through this upgrade process, you still need to come up with or you still need to rebuild the way that it’s presented to visitors. Maybe, maybe you’re happy with the design of your Drupal 7 website. And so you can just redo that same design in Drupal 9 or another option since we’re here and we’re creating a new website and Drupal 9, you might want to take advantage of that and do a new design.

Dave Hansen-Lange (19:31):

And so, because of all those things, it’s going to be still a big chunk of work, not as big as just doing a clean slate and starting from scratch. But still a lot of work involved. One thing you do need to look into before you get too far down this road is like, are there any ways in which we solve the problem in Drupal 7, that just there’s no equivalent in Drupal 9. And that has sometimes happened because the Drupal 7 way of solving a problem, one example would be locations. Let’s say you got a content type in Drupal 7 called offices of your organization and they’re storing their address and location. That’s almost certainly done in a very different way in Drupal 9. And there isn’t a way to directly go from one to the other, at least not directly in the same sense of this upgrade process that I talked about before. There may be these situations like that, and you’ll have to do something custom or something else. That’s a little bit more complicated. It’s just important that, you know, these things happen upfront before you get into moving down this road.

Dave Hansen-Lange (21:00):

So who is this good for? I mentioned, you’re going to get the same stuff in the backend as you have now. So it’s, if you’re happy with that, great, consider this option. I mentioned that the visual presentation, you’ve got to redo that. So if you want a fresh design, this might be an option for you. Again, avoid if budget is tight, like I mentioned, it’s still a fairly complicated procedure. All right. A third option is to switch to Backdrop.

Dave Hansen-Lange (21:39):

So Backdrop, I said earlier that your main options are WordPress or Drupal. What’s this, what’s this new Backdrop thing? Backdrop is kind of like a different flavor of Drupal. And in the technical parlance, Backdrop is a fork of Drupal 7. And what does cutlery have to do with software? Absolutely nothing. So by fork, we mean fork in the road. You may know that Drupal and WordPress are open-source software. And that means that anybody, anybody really who has the time available to do it, can jump into the project. You got a problem with the way something works, you want to make it better, you can just do that and you can contribute something and get it rolled into the software. But what that also means is that if you don’t like how something works, you can just take it, copy it, and roll with it.

Dave Hansen-Lange (22:42):

And that’s what’s happened with, with Backdrop so well. Drupal 8 was being developed. There were many people in the community who thought, “Oh, no, like Drupal 8 is looking great and all, but it’s going to be really hard for websites that are on Drupal 7 to get to Drupal 8 and whatever it comes in the future. And they were right. That’s, that’s why we’re here. That’s why we’re having this webinar. And so what they did was they took Drupal 7, copied it, called it Backdrop and started to evolve it and evolve it in some of the same ways that AAA has evolved only keeping with the Drupal 7 way of doing things and the Drupal 7 styles. And so you have an option to take your website and sort of just take that fork in the road and start moving down the Backdrop trail.

Dave Hansen-Lange (23:42):

What this is going to look like for your website is that you’re still gonna have the existing content structure things in the backend of the website, just like that, upgrading to Drupal 9 option. It’s all going to look very similar, if not identical, but different from that upgrade to Drupal 9 option. You can still keep the visitor-facing portion of the website. If it’s going to need a little bit of tweaking to get onto that Backdrop fork in the road. But that is going to be relatively much smaller, a much lighter lift. Not to say that you must keep your existing design, you can make some changes and revisions. You might even consider doing a full redesign. But yeah, you don’t have to, as you’ve heard me describe this, you may be thinking fundamentally that the steps involved, it’s pretty similar to the upgrade to Drupal 9.

Dave Hansen-Lange (25:00):

It is, but still, it is almost certainly cheaper than upgrading to Drupal 9. And mainly the reason is because like I mentioned, it is just Drupal 7 evolved. So the changes that you have to make to your existing website are just immensely smaller, some increased risk. So what I mean by this well, like anybody who works with websites for a nonprofit is probably going to know WordPress, and probably getting to know the word Drupal, probably not going to know the word Backdrop, because it is such a much smaller community. Where there might be that there’s about half a million Drupal websites out there. There may be like a few thousand Backdrop websites out there. And because of that, there’s enough momentum in the community that we know that Backdrop will be here for two years, maybe four years, but it’s harder to sort of see deeper into the future. Whereas Drupal, you know, half a million websites. We know it’s, there’s a lot of people working on this, a lot of organizations, big and small, it’s going to be here for probably at least another 10 years, if not longer. Backdrop, much smaller community. There’s just not as much certainty about the future. 

Dave Hansen-Lange (26:44):

But with that said, Backdrop has committed to like the same sort of upgrade structure that Drupal 8 and Drupal 9 have committed to being. We’re not going to do a huge change again in the future. We’re going to make all these incremental changes that will make it much easier for you to stay up to date and evolve your website over time.

Dave Hansen-Lange (27:12):

Great. I thought it important to show some visuals about what Backdrop looks like and looking at these, you might be thinking, “Oh, this looks pretty similar to my Drupal 7 website, but the colors and fonts are more contemporary”. And you are a hundred percent correct in thinking that like I mentioned, it really is Drupal 7 evolved. But there is more to it. There are some easier things on the technical side of how to work with Backdrop compared to Drupal 7. There’s some different ways of managing page layouts. There’s other new features in Backdrop that Drupal 7 doesn’t have. But the thing is, if you take this sort of upgrade from Drupal 7 to backdrop trajectory, you’re not going to get those things all of a sudden. If you want to take advantage of Backdrop’s fancier ways of laying out content on a page then you’re going to have to have a small project to enable that feature. At first, you’re still going to be working in the same paradigms as you are with Drupal 7. So who is Backdrop great for? Anyone who has a lot of custom code. I was talking earlier about like, why you might want to avoid building a new website and Drupal 9 is if you’ve got a lot of custom stuff. Here in this option, and this would be a good option for you because all that custom stuff probably doesn’t need to change very much, probably needs to change a little. But if it’s not going to be all that significant, this is a good option for you.

Dave Hansen-Lange (29:16):

If you are happy with your existing design that’s going to need a little bit of touch-ups to move to Backdrop. I was trying to be consistent here and come up with a reason why you should avoid Backdrop. I couldn’t really come up with one. I think everyone should at least consider this option. It’s kind of like the middle of the road option. You might not choose this option if you’re wanting to do a full redesign, but if all the rest of the things line up for you, then you could do a full redesign in Backdrop. It would be fine. I guess the only reason that I can think of now is that if you are super concerned about keeping the website that you have the same fundamentally as it is now, four, five years into the future, 7 years into the future—because the future is a little less defined for Backdrop—you may want to avoid it in that case.

Dave Hansen-Lange (30:35):

All right. And the last option stay on Drupal 7. I mentioned even though Drupal 7 has reached end of life, there are ways to continue on with it. If you had any websites that were on Drupal 6 and you were in this sort of situation for Drupal 6’s website, when it reached its end of life, there was a program started called the extended support for Drupal 6. This Drupal 7 version of that program is fundamentally identical. And what this is is that I mentioned that many of the security team are volunteering their time. And so this program gets around by trying to force people to volunteer their time by saying it’s a paid program. The Drupal community has vetted several Drupal agencies to offer this extended support service. And what that means is that as security issues come up, maybe there’s a security issue that comes up in Drupal 8 that might also apply to Drupal 7 this, this team of extended support people work on fixing that problem in Drupal 7.

Dave Hansen-Lange (32:11):

And so there’s kind of two ways to take advantage of this: Number one, you sign up with one of the extended support vendors. You’ll be able to find that list through some links that we’re going to send at the end. One of the mandates of this is that they release all of their fixes publicly. It’s happened for Drupal 6 as well. And so if you are technically savvy or you’ve got someone at your disposal who’s technically savvy and can sort out the details and apply these fixes as they come up, this could be a good option for you, too.

Dave Hansen-Lange (33:08):

I think it’s important though, to like, take a step back at this point and talk about why you might think about security in different ways. And one way to think about security is kind of like two groups of websites on the internet—those who security is really important for, for whatever reason. Maybe they’re doing something that some people find controversial and they have people who are trying to hack into their website. Maybe you are processing credit cards on your website and you, you know, someone might want to try and break in and steal those credit cards. Maybe you are a news outlet and you get hundreds or hundreds of thousands of people viewing your content every day. And if someone could break in and get some sort of message out to those people, that might be an incentive as well. So that’s like one group of websites, people who have some sort of special security concern. And then there’s kind of everybody else—everybody who knows that security is fundamentally important, but it’s not more important than it is for everyone else in this group.

Dave Hansen-Lange (34:33):

It’s just the nature of how I described that most organizations are going to be in this group where security is important, but not more important than anyone else. Some are going to be in this heightened group of security. And for those people, they need to think about things more than just like, am I getting the bare necessity basics? Or am I really doing all that I’m responsible for ensuring the security is as good as it can be. And for those people, this may not be the best option in that you’re not on the most recent and currently secure thing you were on, this thing that’s on extended support. And whether that rationale is purely technical, or if it’s purely optics in that if something were to ever happen to your website and it was discovered, “Oh, they’re running this version of Drupal that was created 10 years ago”. 

Dave Hansen-Lange (35:38):

How can that be responsible? And then there’s all sorts of politics involved. I mean, it’s a situation you want to completely avoid, but for those of us who are in the group of security as important, but not more important than anyone else, this can be a very reasonable option to consider. So stay on Drupal 7, if you have a really tight budget. And I admit that budget is in the eye of the beholder. For some of you a roomy budget would be a tight budget and vice versa. Like I was talking about, if you don’t have any special security requirements avoid, if your site needs a facelift or if you’re frustrated with the backend. So like I mentioned, this is keeping the same website and keeping it the same. And so if you want to rip something out and try again, this is probably not the option for you.

Sarah Durham (36:56):

Okay. So, Dave, I’m just going to jump in here for a second before we continue with your sample scenarios. We’ve got about 20 minutes left in our time together, so we’re going to need to move pretty quickly through our sample scenarios and through the make a plan section. But we did get a really good question that I’d love you to try to answer for us before we continue on. It’s from our friend, Rita, and Rita asks, if you choose to migrate or upgrade to Backdrop, what would that mean for your future options to upgrade to Drupal 9?

Dave Hansen-Lange (37:29):

I don’t think it really changes the landscape for that at all. Whether you’re upgrading from Drupal 7 or from Backdrop, it’s fundamentally the same thing. It is technically almost identical and that’s because well, Backdrop has gone on this new trail at a foundational level. The way the content is stored, it’s fundamentally the same. And so if you want to pull that content out of either version of those websites into a new Drupal 9 website, it’s going to be the same process. That could change though, as it’s a fork in the road. So Backdrop could go further one way, while well, Drupal 7 is not moving anywhere at this point, but it could continue to move on in a way that’s more different from Drupal 7. But in my opinion, it’s unlikely to change all that much for the foreseeable year or two.

Sarah Durham (38:37):

Okay, great. So, so back over to you.

Dave Hansen-Lange (38:40):

Okay. So like I mentioned, those options, they were great in theory, but now let’s try and put some of this to practice. I’m going to show, I think, four, maybe five example websites and what is unique or different about those websites and why they might choose one option over the other. As you’re looking through this, you might think, “Oh, that’s nothing like my website”. But I’m going to try and pull some things out here that hopefully are going to apply or at least show some things that you should consider. And you also might recognize some of these websites. Don’t focus on that. We’re going to focus on what is it about these websites? I’m also not going to tell you anything about these websites that isn’t something… Sorry, everything that I’m going to tell you about these websites is something that you could just go to the website, look at and figure out for yourself.

Dave Hansen-Lange (39:45):

So there’s not going to be any sort of like private information here that I’m gonna show either. So in this first example, we’re going to look at the ACLU. On the left here, we see what their website homepage used to look like. On the right side, we’re going to see what the homepage looks like now. And the prior version of the website, that was Drupal 7. The homepage, and I say that specifically, the homepage, is now WordPress. You may remember back when I talked about the option of creating a new website that you don’t have to do the whole thing. Here’s just the homepage. And they’ve actually done the same thing with the blog section. It used to be Drupal on the left. Now it’s WordPress on the right. You don’t have to do with everything.

Dave Hansen-Lange (40:44):

So this is an example of a case on the ACLU website. And like, this is just one really long page here that is cut up into three pieces. See at the top, this is all just fairly straightforward content. But then in this section, things start to get more complicated. Like there’s all these other bits of content elsewhere on the website that are related to this case. That’s something that you can do in WordPress, but the more complicated those relationships get, the more awkward it gets to do in WordPress. Then down here at the bottom of the page, things get super complicated. Visually it doesn’t look too bad, but that’s because I think the design was done well. There’s hundreds of legal documents that relate to this case, all in these groupings and hierarchy and get super complicated. WordPress is not the best tool for this kind of job. And so this part of the website is still on Drupal. It’s still going to be on Drupal for now. It might evolve in the future, but that’s where it is for now.

Dave Hansen-Lange (42:03):

Another section of the website, there is this sort of intermediary thing where you could show an action within like an article or a blog post or something to say, “Okay, come take this action”. And during the redesign or in moving bits to WordPress, you know, if you’ve stepped back and thought, is this useful? Is this complicated? Is there a way to do this simpler? And this sort of intermediary thing was just checked and now there’s just links to actions and there’s other ways to show actions without this complicated section of the website. Please consider for your website: What should I get rid of? There’s almost always something. 

Dave Hansen-Lange (43:11):

Looking at a different organization, here is one that’s a Drupal 7 website. But you might be thinking, “Oh, this design, it looks fairly current”. And you’d be correct because this organization went through a redesign, I want to say, like, two years ago. And so because of that, looking at those four main options, they can probably throw the create-a-new-website option out because the design still looks great. As long as they’re happy with how the content works on the backend, they could really choose any of the other three options. And, yeah, so consider that.

Dave Hansen-Lange (43:47):

Next, we have a municipality. When I was talking about the option of staying on Drupal 7, that’s maybe not the best option for a municipality in the news all the time. We hear stories of like such-and-such municipality, their website has been hacked, or their computer systems have been taken over by ransomware. And so just the optics of staying on Drupal 7 might not be the best choice for them. The design looks, doesn’t look as fresh as those first two options that we showed. But let me guess a municipality kind of has different requirements in that the number one goal is not a flashy design, it’s getting information out to its residents.

Dave Hansen-Lange (44:32):

And so there may be a way for them to choose one of the non-design related options. And at the same time, maybe consider how it can do any sort of restructuring to better present the information that people need to find. Here’s another organization. In looking at the screenshot, you might be thinking the same things that this organization thinks about this website and that the design is very text-heavy, and it is not quite as engaging as they would really like it to be. And so for this organization, one of the first two options is probably the best choice: creating a new website completely or upgrading this to Drupal 9 with a new design.

Dave Hansen-Lange (45:43):

Lastly, we’re going to look here at, this is not so much a website, but a web platform. AFT has 1,300 websites on this one platform for States and Locals within a state. And the center one up top here, this is for a campaign website. And this is an example of a few things: One, it’s not their primary website, it’s not aft.org. And so if you’ve got more than one website, you don’t have to choose the same option for all of them. You can choose different options. Number two, there’s a lot of custom stuff involved here, as you might imagine. Some stuff around creating a new website, around connecting the information altogether. So because of that, you might lean more to one of the options that works better for custom stuff and doesn’t require recreating all of their custom stuff in a brand new website.

Sarah Durham (47:07):

Thank you, Dave. So a quick question, before we talk about where you go from here. Just want to confirm the ACLU, the sections of the ACLU site that are still in Drupal, or are those WordPress? 

Dave Hansen-Lange (47:22):

That is in Drupal. Yes. 

Sarah Durham (47:26):

Okay, so Dave is going to be advancing some slides for me. So I will ask you, Dave, to go onto the next slide. And basically, before we flip over to your questions and discussion, and in the remaining time we have together, what I want to get you thinking about is how to make a plan. And it’s interesting we’re doing this today because actually I had a call with somebody at a higher ed institution this morning, who’s got an old site and they are debating what their options are. They were describing a lot of feelings of being overwhelmed. I think that, you know, these days with the reality of what’s going on in the world with COVID, with elections, all that kind of stuff, tackling these kinds of big projects is feeling pretty daunting. So I wrote an article about planning and we’ll share links to that article and a bunch of other things.

Sarah Durham (48:20):

Dave has also written a really helpful post about Drupal 7’s end-of-life. At the end of this webinar and also in the follow-up email, we’ll send you one of the things I wrote. The first step is to make a plan and you don’t have to have all the answers. You’ve just got to begin by getting your team on the same page about the implications. I think that’s one of the big barriers that a lot of people are facing is that they’ve got these Drupal sites and there is a real challenge coming up, a real cliff coming up for many of you that you’ve got to begin to get your team aligned around so that you can budget and plan appropriately. Next slide please, Dave. So I recommend that you come up with a plan, which you could do in five slides or in two pages.

Sarah Durham (49:05):

And the intention of this plan is actually to give you an internal document you can use to get your team on the same page and build some buy-in. So you can see first you’d start by outlining the situation. I think we’ve given you some of the ammunition for that conversation and in today’s session or in the articles we’ll share with you, and what the risk is to your organization. You might want to outline some options if it’s clear to you and the people on your team where you should go from Drupal 7. You might go forward with outlining some options or making a recommendation, but honestly, if you’re not sure which way to go, a good partner should help you get there, too. So if you don’t have the answers already in mind, if it’s not clear to you which way to go, it might be that you map out a few options.

Sarah Durham (49:52):

But your recommendation might be more to find a partner to help you navigate that. Of course Advomatic can do that. We would love to help you make a decision about this, and we do regularly do that as part of our work. There are many people you could work with who could do that. I think one of the things that’s also really important in your plan is mapping out a timeline, not so much for the build or the upgrade that you might do, but all the things leading up to it. If you are looking ahead and thinking what you really need to do is rebuild your website or do a significant upgrade, that’s going to take time and a lot of work, and you’re going to want to get your team on the same page about when the budget needs to be approved, and when you’re going to get rolling so that you’re doing it hopefully well in advance of some of the deadlines that are going to be important within your organization and within the Drupal 7 end-of-life timeline.

Sarah Durham (50:49):

You know, in the non-profit sector, one of the key pieces that is in my experience kind of do-or-die for many big projects is building buy-in. So with that plan in mind, I would encourage you to have some conversations, share it, get it into the budgeting process and kind of keep it alive because very often you know, you mentioned these things once or twice, but there’s so many things going on that are taking up so much attention and energy for the leaders of organizations today that I think you’re going to have a little bit of work to do to keep it alive, which is the next step. My next slide. Also, keeping it alive is about not just writing this plan and sending it to people, but keep nudging and keep bringing it up. If you know what your milestones are when people are talking about budgets or budgets are getting approved, you know, those are great opportunities to research, collate your plan and go from there.

Sarah Durham (51:47):

Now, many organizations that we work with and talk to are already doing this, and they’re already talking to us and other people about what they’re doing. And a partner can also help you figure out your timeline. So there are a lot of ways to do this. You don’t have to do the heavy lifting on your own. But what you don’t want to do is you don’t want to wait until you’re, you know, a couple of months away from these deadlines if they pose significant risks or implications for your organization. So we have a few minutes left to go before the top of our hour. And I want to hear a little bit from you. So if you’ve got questions or comments, you can either use the Q&A feature, which you will see at the bottom of your screen, or you can chat them in to Dave and I, as we go. And we’re going to stop sharing our screen. Now we’ll take a few questions and while you chat those in, I also want to just remind everybody that we are going to be sending out a follow-up link to the recording here. And Theresa is also going to chat out a couple of the articles we mentioned. Dave has written a really helpful article about D7 end-of-life. He’s also written an article about D8 and there’s an article I’ve written that’s about how you, how you plan for this change. So Theresa will chat those all out.

Sarah Durham (53:17):

Okay, Dave, first question for you. Somebody is chatting in about administrators and they’re thinking, well, actually, this is sort of a double-barreled question. Let’s take it in two parts. First in option A, you talked about building a new site as option A. You specifically talked about WordPress and Drupal. Both of those are open source technologies. Why are you talking just about WordPress and Drupal and not any other systems?

Dave Hansen-Lange (53:46):

One of the things that I also talked about was like, kind of the momentum of these projects, like Drupal is large. WordPress is ginormous. And there’s lots of movement in those projects. There’s lots of momentum as soon as someone has a new idea or a new technology pops up on the internet, like things move quickly. And there’s a way to do it on your website in short order. And I also talked about the security group, that’s not the official title, but like there’s ways like that in which you’re getting the benefits of someone else volunteering their time for your website, which you just don’t get in in some of the other options that you have.

Sarah Durham (54:37):

Okay, thank you. And the second part of this question was about comparing WordPress and Drupal about administrators and the options there. This person is talking about how there’s lots of different people in their organization, who right now have different layers of access in Drupal 7. And they’re wondering if there are any recommendations you have for new platforms based on that kind of complexity.

Dave Hansen-Lange (55:01):

Yeah, so like the area of editorial permissions and controls, like that’s one of the big differentiators between Drupal and WordPress. WordPress has some basic systems around this role can do this, or this role can do that. In Drupal, we can make things a whole lot more complicated, like people who manage this section of the website, they can upload images. Other people can use those images, but only the original group of people can edit them or ways of more complicated things that you can do in Drupal.

Sarah Durham (55:38):

Okay, so there’s a question here about the difference between a Drupal new build and a Drupal upgrade in terms of cost. And actually, would you mind just bringing it up again, cause somebody chatted to me that they arrived a bit late and they didn’t see your slide. I think it’s your slide number six, which outlines all the options. Let’s just quickly go back to that slide for a second and share that. And I think that the question that just got chatted into me relates to this. So on slide six, you mapped out a bunch of different options ranging from building a new site to staying on Drupal 7. And those were ranked, as you talked about them from most expensive to least expensive. So you said building a new site is the most expensive, staying on Drupal 7 is the least expensive, and then the upgrade or the switching to Backdrop were in between. So the question is about the cost differential between building a new site in Drupal 9 and upgrading in Drupal 9. I assume that there are additional costs for design, for UX, things like that, and building a new website, but how significant is that differential? What other variables inform the cost difference there?

Dave Hansen-Lange (57:06):

Yeah, so I talked about sort of in any of these higher options… well, no, let me rephrase that. In the two middle options, you have the option of how much redesign you want to do, of course. And that’s probably the biggest thing that affects how big or small upgrading to Drupal 9, that project is going to be. But let’s say you wanted to redesign and compare upgrading to Drupal 9 versus creating a new website in Drupal 9. It’s difficult to be put on the spot, but I don’t know, 80%, 90% since you’re doing a full redesign. Upgrading to Drupal 9 and moving to a new website, they start to become more similar. The more you’re redesigning, the similar in cost.

Sarah Durham (58:01):

Okay, thank you. That sounds like what we were expecting. So I am just skimming through your questions and it looks like a couple of other questions that we have here are pretty unique to specific organizations, so I’m going to follow up directly with those organizations since we are just about out of time. I want to thank Theresa and Dave for joining us today. Dave, thank you for imparting your wisdom on this topic. And I want to thank everybody who took the time to log in and watch this. I hope this has been helpful for you. If you have specific questions or concerns or things you want to pick our brain about, you can always email us at [email protected] or [email protected]. We’d be happy to get on the phone with you, talk a little bit about your situation if that is of use to you. And again, Theresa will be sending out a link to these articles and the recording to you in just a few days. So thank you, all. And thank you all for the excellent work you do to make the world a better place. Be well, thanks.

Oct 28 2020
Oct 28

Getting bogged down in the day-to-day, repetitive tasks that a business requires is not only a drain on your mental health, but it could also become a hindrance to growing and scaling your business. Add up the time from all the little tasks you do in a day. If you could automate one-third of those tasks, think about how much more your business could grow! Read on to learn more about business automation and how Drupal could be the answer to your business woes.

  • Business automation is a strategy in which a business like yours finds a way to automate processes and manual tasks to reduce costs/time.

  • The time savings that come from having solid business processes and automation setup, is time that you and your staff get to leverage to grow your business.

  • Since Drupal is an open source platform, it gives business owners a huge opportunity to build custom integrations that can drastically reduce workload and help with business automation.

What is business automation?

Expert advice from an Ecommerce Software Consultant | Acro MediaBusiness automation is a strategy in which a business like yours finds a way to automate processes and manual tasks to reduce costs/time. This is normally accomplished through third party software and integrations.

Business automation can be applied in many areas of a company, including, but not limited to:

  • Marketing & Sales
  • Project Management & Product Development
  • Accounting & Inventory

Why does business automation matter?

At the end of the day what we are trying to do is save time. Think about it… if you can save 30 hours a month because you have solid business processes and automation setup, that's an extra 30 hours a month you and your staff get to leverage to grow your business.

Business automation is a powerful thing, it gives you the ability to scale your business much faster than if you had to do things manually. Here are the steps you should be taking to work on your business automation.

  1. What recurring tasks and processes do you and your staff currently have? Also, take a look at any swivel chair processes you may have and see if they can be eliminated.
  2. Is there a tool, integration or software that is designed to automate this task?
  3. What is the price of that tool and does it justify the time and money saved for automating that specific task?

Follow those three steps over and over again when trying to find ways to automate your business and you will be well on your way to increasing efficiency in your business.

Why Drupal is great for business automation

This one is simple. Since Drupal is an open source platform, it gives business owners a huge opportunity to build custom integrations that can drastically reduce workload and help with business automation.

Yes, lots of software as a service (SAAS) platforms have plugins and apps that can integrate with their system. But, for the most part, these integrations, modules and APIs are very standard. The moment a business requires something custom that they need their website to integrate with, all these other platforms fail to pan out. On the other hand, if your software is open source, and your business needs a custom integration, it’s most likely it can be built on Drupal due to the open source framework. Just ask some of our clients!

Bar Codes Talk

Selling barcodes & labels is a very complex business. It’s a very unique product that requires a lot of unique solutions. In our time working with Bar Codes Talk our main mission has always been the same, how can we streamline the fulfillment process for both barcodes and labels? With some hard work and custom modules, we have created some awesome integrations that have helped with all of this.

  • Nicelabel/NiceForm Module: Communicates with NiceForm (label printing software) and automatically puts the labels purchased in the printing queue.
  • Hubspot: Automatically inputs all Bar Codes Talk customers into the Hubspot CRM and separates each customer into different sales tiers based on their purchase.
  • Stamps: Communicates with the Stamps.com API for enhanced USPS shipping automation during the shipping fulfillment process.

Click here to see Bar Codes Talk full case study.

The Vault Pro Scooters

The Vault Pro Scooters is a client of ours who was struggling with their shipping/fulfillment process. Their staff was performing a lot of the shipping tasks manually, which was eating up a huge portion of their time that they could be using somewhere else.

In this specific scenario, we flew out one of our lead developers to their office/warehouse to analyze and study their shipping/fulfillment process. Because of this, we were able to use the Drupal platform to eliminate a lot of the manual tasks they were performing during the shipping and fulfillment process.

Here are some other modules that have helped automate and streamline their business.

  • Commerce Fulfillment: Allows The Vault to create shipments on their website and automatically send shipment information to FedEx and USPS to generate shipping labels for printing.
  • FedEx Crossborder: Integrates with FedEx's Crossborder platform to automatically provide international shipping rates and submit international order information to FedEx. The Vault then just ships order to FedEx's distribution center and FedEx handles shipping the order to the customer.
  • Commerce Stock: Automatically updates product stock when purchases are made, either through the online check or through the Point of Sale.
  • Drupal POS: We built a POS specifically for the Pro Vault Scooters. The great thing about the POS is that it is built on Drupal. Now all the Pro Vault Scooters inventory, content, product info, pricing, customer data, digital assets, and functionality are all stored in one system. With this one system, you are equipped with an infinite amount of data for personalization, marketing automation, real-time analytics, and business logic. Click here to learn about our POS.

How Acro Media is contributing to business automation

We know the importance of business automation, and while it’s hard for us to know exactly what your business could benefit most from, we tried to create something that could help the majority of our clients.

This is why we created a Drupal Quickbooks integration! Now you can automate all the boring, manual accounting tasks. This integration will sync and automate all your product orders, customers, refunds, credit memos, invoicing… and much more.

If you are looking to save a huge amount of time every month in Quickbooks, you can learn more about our Drupal Quickbooks integration here.

Other Drupal modules that help with business automation

Please note that to be able to use the modules below you will need to own or have access to a subscription for these products.

Hubspot Module: Hubspot is an amazing CRM and marketing tool used by many companies. Some features are free and others are paid. This module facilitates the submission of webforms to the HubSpot Leads API to help in tracking leads through Hubspot.

Mailchimp Module: Mailchimp, in simple terms, is an awesome email marketing tool. This module makes it possible to connect Mailchimp directly with your website helping you automate and build lists that can be directly synced from your Drupal site into Mailchimp.

Marketo Module: The Marketo Module helps you integrate the tracking capabilities offered by the Marketo Automation tool. Webform integration and user registration are key features of this module which also helps you in assessing your website’s ability to capture lead data.

Amazon Module: Syncs your Drupal store with your Amazon store. If you're removing items, adding items, selling items, this module will keep both stores updated and in sync automatically.

eBay Module: Syncs your Drupal store with your eBay account. If you're removing items, adding items, selling items, this module will keep both stores updated and in sync automatically.

CRM Modules: Drupal integrates with many different CRM platforms. If you are currently using any popular CRM, it is most likely there is a Drupal module that will integrate directly with that CRM.

The anything your business needs Module: This is the beauty of Drupal and open source. We can create just about any module for any integration with any software or third party tool you might be using. If there isn’t a module that does what you need, we can build it! This is why Drupal is so superior when it comes to integrations and business automation.

Other cool automation tools

I want to finish this post by giving a list of some other cool tools you can use to help with business and marketing automation. Some of them are free and some of them are paid. Check them out and let us know what you think.

Buffer (free & paid): Looking for a simple way to automate your social media marketing, then this is a tool you need.

Mailchimp (free & paid): If you are looking to do email marketing (which you should), then Mailchimp is a great software we use for most of our clients. It allows you to send automated emails based on customer behaviour and preferences. You can get started with pre-built Workflows or use their built-in segmentation and targeting options to build custom rules.

Spark Shipping (paid): Spark Shipping is dropshipping software that integrates with your existing E-commerce store to automate order fulfillment, provide dropshipping automation and Amazon repricing. If you don’t do dropshipping, you can ignore this one.

IFTTT (free & paid): This tool has a TON (over 340 services) of different apps and integrations that can be automated. Rather than me explaining everything, I suggest you check it out and see what it can do for you.

Conclusion

Now that you know how powerful business automation can be for your business, you should take the time to follow the steps I outlined at the beginning of this article, to find out what you can be automating and see if what tools and integrations can help you automate those tasks.

Feeling a little overwhelmed and need an extra set of hands? Our ecommerce software consultants are business automation pros and would love to chat with you about your business and help you find ways to streamline things so that you can focus more time and energy on the important things that will help you grow your business. Reach out at any time. We are always here to help.

Expert advice from an Ecommerce Software Consultant | Acro Media

Editor’s Note: This article was originally published on August 24, 2016, and has been updated for freshness, accuracy and comprehensiveness.

Oct 27 2020
Oct 27

For many years styling websites with CSS has been pretty standard. A CSS stylesheet exists somewhere in your project which provides styles for your pages or components. Even with the introduction of CSS preprocessors like Sass, Less, Stylus, and PostCSS to mention a few, the ultimate result is for stylesheets to serve styles to your pages and website.  

With the introduction of JavaScript frameworks such as React, NextJS, and others, the approaches for writing and serving CSS styles have become more complex and at times controversial. Things like CSS-in-JS (Reactjs.org defines this as “a pattern where CSS is composed using JavaScript instead of defined in external files"), can make some people question whether we are getting ourselves in trouble and whether we will regret going in this direction. It wouldn’t be the first time we find ourselves undoing practices we have followed for years because we realized there was a better way.

In GatsbyJS, a library of React, we can use different methods for styling a website.  Some of these approaches include:

  • Plain CSS
  • Inline styles
  • Styled Components
  • CSS Modules
  • Others

In most cases, people who lack the in-depth knowledge of CSS will opt for the easier way possible to style a website.  This is not always the best way to go about it, but unfortunately, it is the reality.  As someone who has worked with CSS for many years, I could technically pick any of the approaches above and accomplish my goal of styling a website, but I see issues with some of those practices and prefer to use an approach that provides flexibility, control, and best practices.

Choosing a Styling Method 

Working for an agency where we build websites for clients of all sizes, many times the method we choose for doing something depends on the client’s preferences or skill level of their team.  Meaning that we want to build a website that a client could take over and maintain on their own after our engagement with the client has scaled down.  So even if I have a personal preference but the client has no experience or desire to work with that approach, I would need to provide a way for the client to work with a system or approach that may be more comfortable to them.

The one thing to keep in mind when choosing a method for styling your websites, Gatsby or otherwise, is that at the end of the day, we are producing plain CSS and as such, it should be well-written, and easy to maintain and scale. I am a fan of keeping styles simple, flat, and to a minimum. I don’t see the point of using over-engineered methods that complicate the most simple task.

CSS Modules

My approach of choice for styling React or Gatsby websites is CSS Modules because it most closely resembles the traditional way of styling websites I have grown accustomed to. As I alluded to before, my ultimate goal is to write proper CSS, following best practices, while leveraging styles scope, performance, and scalability. CSS Modules allows me to do all these things while providing an environment I am familiar with. I am not against learning new ways of doing things (I welcome them), but if new approaches don’t offer significant benefits, I don’t see the need of complicating my life and that of clients who will interact with my code.

In a typical Gatsby website, CSS Modules works out of the box without any special configuration. You can create any CSS files in your project, import them into the components you are working with and your styles will work. This is great and can get you very far if you are working with a simple website. However, this only works with plain CSS and not Sass. I personally like Sass because it provides features that are currently not available in CSS. Things like Mixins and nesting to mention a few. I will use Sass and SCSS interchangeably in this post to refer to the preprocessing process of compiling SCSS into plain CSS code.

Add Sass to Your Gatsby Website

Adding Sass to a Gatsby website is relatively easy. It’s a two-step process that includes installing a Gatsby plugin and adding a line of code to gatsby-config.js. Let’s do this now:

  1. While In your Gatsby project root directory, run the following command to install the gatsby-plugin-sass and node-sass plugins:

    npm install node-sass gatsby-plugin-sass
    Gatsby-plugin-sass has a dependency of node-sass and therefore we need to install both.

  2. Edit gatsby-config.js (located in the root of you gatsby project), by adding the new plugin to the plugins array:

    plugins: [`gatsby-plugin-sass`]
    If you already have other plugins in place, you can add each new plugin in a new line within the array.

That’s it! Now Sass is available on your site.

Updating CSS Modules to use Sass

Now that we have Sass available, the last thing to do is to update CSS Modules to use Sass versus plain CSS. This is a two-step process:

  1. Rename any existing .css files to use .scss
  2. Update any imports of these files to also use .scss

Now you can take advantage of CSS Modules and Sass for writing great styles. Let’s go over a quick example of how CSS Modules works.

Using CSS Modules and Sass in Gatsby

Consider the following HTML/JS in your Gatsby Component (hero):

import React from 'react';
import PropTypes from 'prop-types';
import Image from 'gatsby-image';

import Heading from '../Heading';
import Link from '../Link';
import {fluidImage} from '../../global/js/customPropTypes';

const Hero = ({ title, image, body, path }) => {
  return (
    
        
          {title}
        

{body}

Learn more ); }; export default Hero; Hero.propTypes = { title: PropTypes.string, body: PropTypes.string, image: fluidImage, path: PropTypes.string };

Styling the Hero component above with CSS Modules will require we create a stylesheet for the Hero. Assuming you have a Hero folder inside components, which has an index.js for the component’s markup and JavaScript, create a file called hero.scss with the following code:

.hero {
  background-color:$color-white;
  position: relative;
}

.media {

  img {
    display: block;
    height: auto;
    max-width: 100%;
  }
}

.content {
  left: 50%;
  position: absolute;
  transform: translate(-50%, -50%);
  top: 50%;
}

.title {
  color: $color-secondary;
}

And finally, you would update index.js by first importing the hero’s stylesheet as follows:

import styles from './hero.scss';

Then adding the respective CSS classes to each of the HTML elements in the Hero component. The end result of index.js would look like this:

import React from 'react';
import PropTypes from 'prop-types';
import Image from 'gatsby-image';

import Heading from '../Heading';
import Link from '../Link';
import styles from './hero.scss';
import {fluidImage} from '../../global/js/customPropTypes';

const Hero = ({ title, image, body, path }) => {
  return (
    
        
          {title}
        

{body}

Read the full article ); }; export default Hero; Hero.propTypes = { title: PropTypes.string, body: PropTypes.string, image: fluidImage, path: PropTypes.string };
  • When we imported the Hero styles into the component we used styles as the namespace in the import.
  • To apply each of the CSS classes found in hero.scss to the markup in index.js we are using the className attribute since class is a reserved keyword in React/Gatsby.
  • Then in curly brackets we apply each class by prefixing them with styles. For example: 

If you render this component in the browser, what you will see as a result when you inspect the code is something similar to:

Example of HTML code through dev tools

  • Main things to note from the image above are the CSS classes added after css-modules--. These are the classes we created in hero.scss.
  • The end of the class names (i.e. akrigl, woitn, w95ls9), are dynamic strings created by CSS Modules which ensure they are unique CSS classes.  This prevents issues of regression and styles from leaking into other parts of your website.
  • CSS Modules restricts the scope of its styles to only the component they are written for.

In closing

I like CSS Modules because it provides a familiar approach to working with Sass similar to that of a traditional Sass project. This works well with clients who are not well-versed in React or Gatsby but still want to be able to update styles.

[embedded content]

Oct 24 2020
Oct 24

This month’s SC DUG featured Mauricio Orozco posing questions about getting started as a consultant to long-time members who have all done some work with Drupal as a consultant.

[embedded content]

If you would like to join us please check out our upcoming events on Meetup for meeting times, locations, and remote connection information.

We frequently use these presentations to practice new presentations, try out heavily revised versions, and test out new ideas with a friendly audience. So if some of the content of these videos seems a bit rough please understand we are all learning all the time and we are open to constructive feedback. If you want to see a polished version checkout our group members’ talks at camps and cons.

If you are interested in giving a practice talk, leave me a comment here, contact me through Drupal.org, or find me on Drupal Slack. We’re excited to hear new voices and ideas. We want to support the community, and that means you.

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