Upgrade Your Drupal Skills

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

See Advanced Courses NAH, I know Enough
Oct 26 2021
Oct 26

Are you ready to upgrade to Drupal 9? If you're moving from a Drupal 8 site, it needs to be reviewed and updated to remove any deprecated code that will no longer be compatible with Drupal 9. Luckily, there are a few ways to check existing codebases for deprecated code, get a glimpse of what changes need to be made, and even apply the fixes automatically.

We have other blog posts that go into details about how to plan, prepare, and fix issues with deprecated code in preparation for Drupal 9, so we won’t go into those details here, but rather walk through a Composer issue we recently ran into while trying to get Drupal Check and Rector utilities added to perform our own code deprecation checks.

We hope that this blog post helps others with similar Composer issues figure out ways to understand and debug these cryptic errors and be aware of some options and things to try in fixing them.

The Conflict

The issue we faced was where a developer had already added the Drupal Check utility a while back, and when adding Rector, you may get Composer conflict messages like this:

"Your requirements could not be resolved to an installable set of packages.

Problem 1

    - rector/rector-prefixed v0.3.5 requires phpstan/phpstan ^0.11.19 -> satisfiable by phpstan/phpstan[0.11.19] but these conflict with your requirements or minimum-stability.

    - Installation request for palantirnet/drupal-rector ^0.5.1 -> satisfiable by palantirnet/drupal-rector[0.5.1].

    - Conclusion: remove nikic/php-parser v4.0.2

    - Conclusion: don't install nikic/php-parser v4.0.2

    - palantirnet/drupal-rector 0.5.1 requires rector/rector-prefixed <0.7.19 -> satisfiable by rector/rector-prefixed[v0.3.5, v0.6.10, v0.6.12, v0.6.13, v0.6.14, v0.6.2, v0.6.4, v0.6.5, v0.6.7, v0.6.8, v0.6.9, v0.7.0, v0.7.1, v0.7.10, v0.7.11, v0.7.12, v0.7.13, v0.7.14, v0.7.15, v0.7.16, v0.7.17, v0.7.18, v0.7.2, v0.7.3, v0.7.4, v0.7.5, v0.7.6, v0.7.7, v0.7.8, v0.7.9].

    - rector/rector-prefixed v0.6.10 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.6.12 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.6.13 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.6.14 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.6.2 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.6.4 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.6.5 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.6.7 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.6.8 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.6.9 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.7.0 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.7.1 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.7.10 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.7.11 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.7.12 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.7.13 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.7.14 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.7.15 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.7.16 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.7.17 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.7.18 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.7.2 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.7.3 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.7.4 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.7.5 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.7.6 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.7.7 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.7.8 conflicts with nikic/php-parser[v4.0.2].

    - rector/rector-prefixed v0.7.9 conflicts with nikic/php-parser[v4.0.2].

    - Installation request for nikic/php-parser 4.0.2 -> satisfiable by nikic/php-parser[v4.0.2].

Installation failed, reverting ./composer.json to its original content.

This can be pretty scary to look at and digest what it all means. But, let’s just start at the top.

Step 1

The first problem stated is:

- rector/rector-prefixed v0.3.5 requires phpstan/phpstan ^0.11.19 -> satisfiable by phpstan/phpstan[0.11.19] but these conflict with your requirements or minimum-stability.

So, first, let's look at the composer.json file. We only really care about the “require-dev” section, since we’re only dealing with the development utility scripts Drupal Check and Rector in this example, but these same investigation and debugging steps in Composer can apply similarly to items in the “require” section as well, like Drupal modules and their dependencies.

"require-dev": {

   "drupal/drupal-extension": "^3.4",

   "drush-ops/behat-drush-endpoint": "^8.2.4",

   "mediacurrent/ci-scripts": "~1.2",

   "mediacurrent/ci-tests": "dev-master",

   "mediacurrent/mis_vagrant": "^5.1.0",

   "mglaman/drupal-check": "^1.0",

   "nikic/php-parser": "4.0.2",

   "phpro/grumphp": "^0.11.6",

   "phpstan/phpstan": "0.11.9",

   "webflo/drupal-core-require-dev": "^8.8.1"


Notice how there is a strict version set for the phpstan package? What’s happening is the Rector tool is trying to add a dependency package, rector/rector-prefixed v0.3.5, but that requires phpstan ^0.11.19 (so 0.11.19 or greater). And because we have a strict 0.11.9 for phpstan in composer.json, it can’t add what it needs.

A first attempt to fix this would be to try installing a version of phpstan that it wants, so we can try something like:

composer require --dev phpstan/phpstan:^0.11.19

After running that, it looks better, but still some issues:

Your requirements could not be resolved to an installable set of packages.

Problem 1

 - Can only install one of: nikic/php-parser[v4.0.2, 4.3.x-dev].

    - Can only install one of: nikic/php-parser[4.3.x-dev, v4.0.2].

    - Can only install one of: nikic/php-parser[4.3.x-dev, v4.0.2].

    - phpstan/phpstan 0.11.19 requires nikic/php-parser ^4.2.3 -> satisfiable by nikic/php-parser[4.3.x-dev].

    - Installation request for phpstan/phpstan ^0.11.19 -> satisfiable by phpstan/phpstan[0.11.19].

    - Installation request for nikic/php-parser 4.0.2 -> satisfiable by nikic/php-parser[v4.0.2].

That issue is caused because of more strict package versions in composer.json -- especially with the nikic/php-parser package.

"nikic/php-parser": "4.0.2"

This version constraint is causing this issue:

- phpstan/phpstan 0.11.19 requires nikic/php-parser ^4.2.3 -> satisfiable by nikic/php-parser[4.3.x-dev].

Step 2

Upon further inspection in the repo and commit history, we’ve concluded that the previous developer added those packages manually to the composer.json file (well, Composer-required them), but they shouldn’t have been added in that way, since they should be letting Composer manage them as dependencies.

Sometimes when debugging Composer dependencies we try one strategy and if that doesn't work we revert back and try something different.

Now that it seems that these packages were added manually to the projects in error, we can pull them out of the codebase and let Composer manage them as dependencies in a way it needs.

Remove the phpstan package from composer.json:

composer remove phpstan/phpstan

It looks like this removed the package from composer.json, and updated the package to a newer version because phpstan is still a dependency of Drupal-check’s constraint set at ^0.11.9. And 0.11.12 is the latest version in that constraint.

But, it’s still not going to be good enough, because remember Drupal Rector rector-prefixed package needs at least 0.11.19 per the ^0.11.19 constraint.

Step 3

Remove the php-parser package from composer.json:

composer remove nikic/php-parser

It looks like it removed the php-parser package from composer.json, and updated the package to v4.4.0

Loading composer repositories with package information

Updating dependencies (including require-dev)

Package operations: 0 installs, 1 update, 0 removals

Gathering patches for root package.

Gathering patches for dependencies. This might take a minute.

  - Updating nikic/php-parser (v4.0.2 => v4.4.0): Loading from cache

That’s fine, we’ll just let Composer manage the dependencies itself, but we’ve cleaned up the composer.json of packages that shouldn’t have been there and were conflicting.

Let’s see if we can get Drupal Rector added now that the conflicting packages are removed:

composer require --dev palantirnet/drupal-rector

Nope, still some of the same issues as in the beginning:

Loading composer repositories with package information

Updating dependencies (including require-dev)

Your requirements could not be resolved to an installable set of packages.

  Problem 1

    - Installation request for palantirnet/drupal-rector ^0.5.1 -> satisfiable by palantirnet/drupal-rector[0.5.1].

    - Conclusion: remove phpstan/phpstan 0.11.12

    - Conclusion: don't install phpstan/phpstan 0.11.12

    - rector/rector-prefixed v0.3.5 requires phpstan/phpstan ^0.11.19 -> satisfiable by phpstan/phpstan[0.11.19].

    - palantirnet/drupal-rector 0.5.1 requires rector/rector-prefixed <0.7.19 -> satisfiable by rector/rector-prefixed[v0.3.5, v0.6.10, v0.6.12, v0.6.13, v0.6.14, v0.6.2, v0.6.4, v0.6.5, v0.6.7, v0.6.8, v0.6.9, v0.7.0, v0.7.1, v0.7.10, v0.7.11, v0.7.12, v0.7.13, v0.7.14, v0.7.15, v0.7.16, v0.7.17, v0.7.18, v0.7.2, v0.7.3, v0.7.4, v0.7.5, v0.7.6, v0.7.7, v0.7.8, v0.7.9].

    - Can only install one of: phpstan/phpstan[0.11.19, 0.11.12].

    - rector/rector-prefixed v0.6.10 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.6.12 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.6.13 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.6.14 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.6.2 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.6.4 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.6.5 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.6.7 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.6.8 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.6.9 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.7.0 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.7.1 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.7.10 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.7.11 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.7.12 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.7.13 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.7.14 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.7.15 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.7.16 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.7.17 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.7.18 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.7.2 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.7.3 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.7.4 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.7.5 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.7.6 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.7.7 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.7.8 conflicts with phpstan/phpstan[0.11.12].

    - rector/rector-prefixed v0.7.9 conflicts with phpstan/phpstan[0.11.12].

    - Installation request for phpstan/phpstan (locked at 0.11.12) -> satisfiable by phpstan/phpstan[0.11.12].

Installation failed, reverting ./composer.json to its original content.

Step 4

So let’s dive deeper. Looking at the Drupal Check’s composer.json, we can see phpstan is listed as a dependency, so why are we including phpstan in our own composer.json?

"phpstan/phpstan": "^0.12"

Well, that’s on the latest (master) version of Drupal check:


Running this command, we can see the version of Drupal check we're currently running is:
./vendor/bin/drupal-check --version

Drupal Check 1.0.13

So, let’s check this version’s composer.json instead:


We can see it’s still 

"phpstan/phpstan": "^0.11.9"
Update phpstan
Loading composer repositories with package information

Updating dependencies (including require-dev)

Package operations: 0 installs, 1 update, 0 removals

Gathering patches for root package.

Gathering patches for dependencies. This might take a minute.

  - Updating phpstan/phpstan (0.11.12 => 0.11.19): Loading from cache

Now we have the right version we’re needing for Drupal Rector.

Loading composer repositories with package information

Updating dependencies (including require-dev)

Package operations: 3 installs, 0 updates, 0 removals

Gathering patches for root package.

Gathering patches for dependencies. This might take a minute.

  - Installing rector/rector-prefixed (v0.3.5): Loading from cache

  - Installing jawira/case-converter (v1.2.0): Loading from cache

  - Installing palantirnet/drupal-rector (0.5.1): Loading from cache


So that seems fishy -- because Drupal Check has a dependency of phpstan ^0.12, but we already have a phpstan 0.11.9 in our composer.json file. Why do we even have phpstan listed in our “require-dev”?

So next, we’re going to try unwinding some things and see if we can get this working.

Step 5

Let’s first remove Drupal Check:

composer remove phpstan/phpstan

This results in a few updates, most notably phpstan being updated to 0.11.12, which matches to the ^0.11.9 constraint set forth for the version of Drupal check we’re using.

Updating dependencies (including require-dev)                                                                         

Package operations: 0 installs, 13 updates, 0 removals

Gathering patches for root package.

Gathering patches for dependencies. This might take a minute.

  - Updating ocramius/package-versions (1.4.0 => 1.4.2): Loading from cache

  - Updating symfony/debug (v3.4.39 => v3.4.40): Loading from cache

  - Updating symfony/finder (v3.4.39 => v3.4.40): Loading from cache

  - Updating symfony/console (v3.4.39 => v3.4.40): Loading from cache

  - Updating nette/utils (v3.0.1 => v3.1.1): Loading from cache

  - Updating nette/schema (v1.0.0 => v1.0.2): Loading from cache

  - Updating nette/finder (v2.5.1 => v2.5.2): Loading from cache

  - Updating nette/robot-loader (v3.2.0 => v3.2.3): Loading from cache

  - Updating nette/php-generator (v3.2.3 => v3.3.4): Loading from cache

  - Updating nette/neon (v3.0.0 => v3.1.2): Loading from cache

  - Updating nette/di (v3.0.1 => v3.0.3): Loading from cache

  - Updating nette/bootstrap (v3.0.0 => v3.0.1): Loading from cache

  - Updating phpstan/phpstan (0.11.9 => 0.11.12): Loading from cache

And we know that this php-parser package was added manually as well, similar to how phpstan was added manually, so we can remove it too. There is no reason to add these dependency packages manually, we can just let Composer manage them.

composer remove nikic/php-parser
Running that results in this output:
Updating dependencies (including require-dev)                                                                         

Package operations: 0 installs, 1 update, 0 removals

Gathering patches for root package.

Gathering patches for dependencies. This might take a minute.

  - Updating nikic/php-parser (v4.0.2 => v4.4.0): Loading from cache

Using Composer why nikic/php-parser, we can see why the nikic/php-parser package is needed

phpstan/phpstan                    0.11.12  requires  nikic/php-parser (^4.0.2)

phpstan/phpstan-deprecation-rules  0.11.2   requires  nikic/php-parser (^4.0)

psy/psysh                          v0.9.9   requires  nikic/php-parser (~1.3|~2.0|~3.0|~4.0)

Step 6

Let's upgrade Drupal check

composer update mglaman/drupal-check --with-dependencies

Updating dependencies (including require-dev)                                                                         

Package operations: 0 installs, 3 updates, 0 removals

Gathering patches for root package.

Gathering patches for dependencies. This might take a minute.

  - Updating phpstan/phpstan (0.11.12 => 0.11.19): Loading from cache

  - Updating symfony/yaml (v3.4.39 => v3.4.40): Loading from cache

  - Updating mglaman/drupal-check (1.0.13 => 1.0.14): Loading from cache

Ah ha! It looks like we’re now on the right version of phpstan 0.11.19 that will support us in adding the Drupal Rector

Let’s try adding Drupal Rector again now:

composer require --dev palantirnet/drupal-rector

Updating dependencies (including require-dev)                                                                         

Package operations: 3 installs, 0 updates, 0 removals

Gathering patches for root package.

Gathering patches for dependencies. This might take a minute.

  - Installing rector/rector-prefixed (v0.3.5): Loading from cache

  - Installing jawira/case-converter (v1.2.0): Loading from cache

  - Installing palantirnet/drupal-rector (0.5.1): Loading from cache

Remember back to the first Composer issue we looked at with the “rector/rector-prefixed” package? We can now see that Rector was successfully able to add it.

Gathering patches for dependencies. This might take a minute.

  - Installing rector/rector-prefixed (v0.7.18): Loading from cache

  - Installing jawira/case-converter (v1.2.0): Loading from cache

  - Installing palantirnet/drupal-rector (0.5.1): Loading from cache

And there are currently no other Composer issues being thrown at us.

The Final Step for a Clean Solution

We discovered that local dependencies were being locked to a specific version and by removing those, Composer was able to correctly reconcile the dependencies for these packages. This is somewhat dependent on and specific to your own build processes and environments, but you should be set to run Drupal Check and Rector and begin your journey and preparations for Drupal 9.

Final cleanest, best solution in our opinion...

Packages added manually, but should have just been added as dependencies and managed by Composer:

composer remove phpstan/phpstan

composer remove nikic/php-parser

Updated drupal-finder

composer update webflo/drupal-finder

Loading composer repositories with package information

Updating dependencies (including require-dev)

Package operations: 0 installs, 1 update, 0 removals

Gathering patches for root package.

Gathering patches for dependencies. This might take a minute.

  - Updating webflo/drupal-finder (1.1.0 => 1.2.0): Loading from cache

composer update mglaman/drupal-check --with-dependencies

Loading composer repositories with package information

Updating dependencies (including require-dev)

Package operations: 0 installs, 5 updates, 7 removals

  - Removing phpstan/phpdoc-parser (0.3.5)

  - Removing nette/schema (v1.0.2)

  - Removing nette/robot-loader (v3.2.3)

  - Removing nette/php-generator (v3.3.4)

  - Removing nette/di (v3.0.3)

  - Removing nette/bootstrap (v3.0.1)

  - Removing mglaman/phpstan-junit (0.11.2)

Gathering patches for root package.

Gathering patches for dependencies. This might take a minute.

  - Updating phpstan/phpstan (0.11.12 => 0.12.23): Loading from cache

  - Updating phpstan/phpstan-deprecation-rules (0.11.2 => 0.12.2): Loading from cache

  - Updating symfony/yaml (v3.4.39 => v3.4.40): Loading from cache

  - Updating mglaman/phpstan-drupal (0.11.10 => 0.12.3): Loading from cache

  - Updating mglaman/drupal-check (1.0.13 => 1.1.1): Loading from cache

composer require --dev palantirnet/drupal-rector

Still not confident about your preparedness to upgrade, or short on time or team capacity? We can help you get ready for Drupal 9

Aug 30 2021
Aug 30

open waters podcast logo

In this episode, we're joined by Damien McKenna to talk about open source security and how that has changed over the years in Drupal core as well as in newer versions of Drupal. Damien directs internal initiatives that strengthen Mediacurrent’s commitment to open-source principles, collaboration, and sharing knowledge to strengthen the Drupal community and is regularly ranked as one of the ten most active contributors on drupal.org.

Episode Transcript

Mark Shropshire: Hi, I'm Mark Shropshire and with me is my cohost Mario Hernandez. We are very excited about this episode of the Open Waters podcast as we welcome Damien McKenna, a prolific Drupal contributor and community leader. We will be talking about open source security, specifically the ins and outs of Drupal security.

Mario Hernandez: Thanks, Shrop. Thank you very much, everyone, for joining us and a special thanks to Damien for joining us today to talk about security and contribution to the Drupal project. So Damien, before we get started into the technical aspects of your role, why don't you tell us a little bit about your role on Mediacurrent and your involvement in open source?

Damien McKenna: Thank you for having me. So I've been involved in Drupal since 2007, but open source as a whole, since around about 2000. I got into it because I had been building my own websites that expanded into building custom content management systems, and I realized I couldn't be the only person who wanted to have a simple CMS to manage their site's content or their clients' content. Discovered hey, there's a whole bunch of people who were uploading complete open source, complete PHP projects, as they were at the time to the net on SourceForge. I can just download it and customize it how I need.

Over the years, I saw a number of patterns emerge with open source communities. A big one was that for any given software project, if it didn't have a security team put together fairly early on, they would need one fairly soon. I saw so many projects that didn't have decent security practices and they eventually ran into a major security problem and had to scramble together the processes to deal with it properly. So I've been very glad that Drupal started their security team fairly early on, and it has been continuing ever since. So at Mediacurrent, I juggle both being a backend developer and project lead along with I lead, cat herd, on some internal initiatives around open source offer and contributing. We try to have a contrib first process so that we are contributing back improvements and things to open source communities and software when it's suitable rather than leading projects to have to maintain more and more custom code and documentation and things.

Mario: I'm gonna go with a follow-up question on that because that's very important what you just said there, Damien, the contribute first. So does that mean when you are tasked with analyzing the project that you about to work on, do you figure out ways in which maybe through this project you can contribute to the Drupal project or the open source in general? Or how does that work?

Damien: Exactly. So there are lots of different situations where it comes up. One example was a few years ago, one of our clients needed to have, requested documentation on how to set up their site to be able to pull in tweets from their Twitter account. And it was just when Twitter had changed the API process. So you used to be able to just pull an RSS feed of the tweets and they changed it to needing to set up a developer account and this custom application in their system.

And it was a bit elaborate and you had to do it from the account that was pulling the tweets because of security best practices. You didn't want to be sharing around these passwords for everybody to log into your Twitter account and accidentally post some screenshot of a picture of a meal out or being with some friends accidentally to a business account. So we put together documentation on how to go through the steps with screenshots and everything, but instead of putting it into a document and sending that to them, we uploaded it to the documentation section for the project that was being used to pull down the tweets so that everybody could then have the same documentation. It was the same amount of work, it was just putting it in one place versus another. So the client appreciated it, they had all of the details they needed, and then everybody else in the world who ran into the same situation then could benefit from the same work.

Shrop: Yeah. That, that's, that's a fantastic example. I mean, I know you have a lot of examples of contrib first, Damien and, personally you're a mentor to me and I appreciate all the guidance you've given me over the years and continue to on how to work in open source overall, but also in the Drupal community. And so I just want to say that I appreciate you and everybody else that does that for the community. It's, it's really great. So I want to jump a little bit into your involvement with the Drupal security team and I think that's an interesting aspect here, since we're talking about open source security today, what's it like being on the Drupal security team and then from a day-to-day standpoint? I know there's lots of things that you have to embargo til advisories come out, but you know what you know, what's it like day day-to-day, what's it look like?

Damien: Sure. So we have different processes that we've, for the most part, documented on drupal.org/security-team. There's lots of details in there, but we have a team of, I forget if it's 20 or 30 so odd people, and one step, I guess, an initial starting point is that we take turns being the initial point of contact. And as it happens, I'm on duty for the next two weeks, so timely. What that means is when somebody opens a security issue for a project, module, theme, or even Drupal core, that we're the first person to respond to that, to review what is submitted, and try and do a little bit of analysis on maybe the person just had one of the settings misconfigured. Maybe they have the PHP module enabled and they're inadvertently letting anybody write PHP code on their website.

Not that that has ever happened, but we do an initial bit of triage on the issues that are opened and then get the maintainers involved, presuming that it requires it, presuming it's a legitimate issue. And then try to guide the conversation between the maintainers and the person who reported the issue and potentially anybody else who's pulled into the conversation. So we might have an issue that is focused on the control module, but it might say affect core or affect somebody in the backdrop community as well, because there's a lot of overlap between the two. Occasionally there might be an identical issue for a similar module, and we try to get conversation focused on moving towards a solid, reliable fix, and then work with the maintainers to prep for release. We also have a mailing list where people can post questions to.

And that is often used as a step towards then having a proper issue in our security issue queue. So then it's, whoever's on duty then is the first person to respond to questions when they come in.

Shrop: How many of those do you think you get in a given week?

Damien: On average, not too many new ones each week. One thing that I found is that sometimes you'll have, especially in the contrib world, somebody will spot...Hey, there's this one situation where this module leaves a security vulnerability open or vector open, and they'll go and check some other modules that have, say, similar functionality or some similar approaches and then they'll, they might discover, say five modules have basically the same bug. But that doesn't happen very often.
Mario: What would you say is the most common security and the Drupal open-source work?

Damien: So the most common one is cross-site scripting, and this is going back to, at least a few years ago, there was an article published on Wiley by Greg Knaddison who wrote the book Cracking Drupal, and he went through and cataloged at all and cross-site scripting was the most common by a good margin where basically the output from a field or some data input was not being properly filtered during display, o that would leave it open for somebody to, say, throw in some JavaScript that would then get executed when the page was viewed. And so that one comes up quite often, and there are some relatively simple means of fixing those bugs. Biggest issue I found is forgetting where in your code something might be filtered already by the time you get it at this one piece.

So sometimes you've got a settings form and it might be available to people who aren't administrators, and you might forget to filter the output because somebody who's an administrator to the site is kind of assumed that they're not going to cause problems for that site. Generally, as a company, employees, don't go bananas and start throwing filing cabinets around. Likewise, they tend not to start throwing in a really bad JavaScript into a site for the purposes of stealing data, et cetera. It's technically possible, I'm sure it has happened, but tends not to happen. So when you're writing code or writing code for a site or for a project, or for a module, you might forget in this one situation, I'm outputting a variable or a configuration object or something and you might forget to filter that one time because when you're testing it, you never try throwing in JavaScript because what silly person would do that? But from the point of view of trying to keep it secure, you need to cover for the situations where somebody might want to do that.

Shrop: If you can execute JavaScript on a site, it's pretty powerful.

Damien: Yes. It's not as bad these days, because Drupal Core and eight and nine don't have the PHP module in core anymore. It was a lot more dangerous when the PHP module was in core because there were so many situations where people inadvertently had that available to all text fields including, say, a comment box for submitting a comment to the webmaster or owners. Yeah.

Shrop: Oh, wow. Yeah, you can think of all kinds of terrible situations that could come with that. Like just reading the settings file in PHP or something. Well switching gears just a bit, because I'm always interested in this and, as you know, in our teams at Mediacurrent, we, we have discussions, we have a security channel in Slack where we discuss when a security advisory comes out, we're always wanting to read it and dissect it as a team and figure out like, all right, what are our next steps for those? Are there mitigations and things like that? I'd love to hear from your standpoint, Damien, in your expertise around this, tell us a bit about those Drupal security advisories and the details they contain. And I mean, just curious about, you know, that coverage for that. I know it's well-documented but there is a lot of information in these advisories, right?

Damien: So there's always a balance between giving enough information and giving too much because you don't want to give people who want to write scripts to attack sites step-by-step instructions on how to do that. You just want to kind of give enough clues that people who are maintaining sites can tell whether or not this is going to affect them right now, and that they need to update right now ahead of anything else they're doing versus, say, it can be just included in the next scheduled deployment.

That could be a week or three from when it comes out. The security advisories will try to give some at least hints on what causes the vulnerability and then, if there are any available, some details on how it can be mitigated. So sometimes it'll be the security problem only happens if you turn off these options or if the person does not have a particular permission. So we'll indicate in the advisory any workarounds that might exist. Oftentimes there won't be obvious workarounds that are feasible, so the only step is to just update the module or theme or whatever it is, or core. We used to do one security advisory per project per week. So per week that there was a security update. So if there were multiple vulnerabilities, they would all be lumped into one security advisory. That policy was changed so that every individual security issue gets its own advisory. And that was to fit with industry standards because Drupal was, I think, just about the only major project still doing it that way.

Shrop: But from my standpoint, it's made it easier for me to comprehend what's going on. I can, you know, read one focus on it. All right. How does that apply mitigations? Are there any, and then you just move on to the next one. And so that's been great from my standpoint.

Mario: Switching gears a little bit here, Damien. So we know that with the release schedule that Drupal has in place, you know, there's a lot of benefits and people have seen things improve, you know, once the new release schedule was implemented. But can you tell us how these release schedule has helped with security, with the Drupal project?
Damien: The schedule has really helped from the point of view of having a plan or a schedule ahead of time that, you know on certain days of the month or certain months of the year, you're going to have security updates available.

Damien: So every Wednesday, starting by the simple thing of all of the security releases are done on Wednesdays. Almost always. There can be some occasional out of schedule updates when there's, say, a third-party library or something that has an update, and we have to scramble to do a core update on a different day, but almost always they're on Wednesdays. And then the core updates are done on one day and contrib updates. So one day a month, there's a window for core to have security updates, and if there isn't one on that day, then there won't be that month. Again, unless there's some or some other issue with a third-party library. And so site maintainers or site owners have a bit of relief knowing that there isn't, almost isn't, going to be a major security release dropping any time of the week, any time of the day, so they can rest easy and just go about their normal business the rest of the week, the rest of the month, and just be able to plan Wednesday afternoon, timezone depending, they will have to do some security updates.

Mario: Good. So what's the story with the Drupal eight reaching end of life? What's, what's going on there?

Damien: Well, it's a standard thing that, or it always has been a standard thing that when a new major release of Drupal core comes out, that the previous release goes into kind of a security updates only mode and then the version before that is marked as end of life so that there won't be any more security updates on that, and pretty much at that point, the community stops maintaining core and contributed modules and themes for that version. In practice, (it) historically meant when triple seven came out, that Drupal five was no longer given security updates and support. When Drupal eight came out, I think it was like eight years after Drupal seven, sorry, after Drupal six had been released, they gave and, if I remember correctly, they gave an extra six months of support just to help bridge the gap of time for sites to upgrade because the development cycle from seven to eight had been so long.

But then, when Drupal nine came out, Drupal seven was still around and still had support. When Drupal 9 came out, the majority of Drupal sites were still on Drupal 7. I forget if it was like two thirds or so of the sites in the world that were on Drupal were still using Drupal seven. So we couldn't just say no Drupal seven is not going to have anymore support, io it was given extra support. Then the plan is that Drupal Ten is going to be released next year, and so there's the knock on effect of you need time to upgrade from core version to core version. And so Drupal eight will be, we'll reach end of life this year. The nice thing is that upgrading from eight to nine is a very, very simple process, especially in comparison to previous sites or previous versions.

We've done some upgrades where a site was fully up to date on contrib modules and was able to be upgraded to from eight to nine with just a few hours of work, and most of that was just poking at Composer to get the right combination of dependencies.

Mario: You're saying that Drupal seven's end of life is actually going to happen after Drupal eight's end of life, yes?

Damien: Yes. So Drupal eight's end of life is tied to the dependencies it has, and its dependencies will run out this year. So I think, it's the big dependency that is causing it is Composer.

Shrop: I think Symphony symphony is part of it, too.

Damien: Composer, symphony. Yes.

Mario: So these end of life decisions are made mainly based on those dependencies, in the case of Drupal seven, it was probably because of the, the adoption that Drupal seven has had gotten, yeah?

Damien: The reason for continuing to support Drupal seven was because of the volume of sites out there that had not upgraded yet and because there wasn't the technical requirement. The dependencies for Drupal seven were still continuing for longer. Drupal seven had fewer third-party dependencies than Drupal eight. So it's easier to say, yes, we're just going to continue it.

Mario: And the future that as the dependencies get shorter and shorter, right, that the actual analyze for future versions may even become shorter than what they are now, perhaps, especially if the upgrade path is such, that is seamless there becomes time where it's just a matter of upgrade and the next installing the next update. And now you're in the next version.

Damien: Yeah. So, keeping a site up to date with the latest version of core, for the major release that you're using, and then keeping all of the contrib module updates, will ultimately mean that it doesn't matter if it's six months or three years between major versions, if it's up to date and you keep it current, it should be a relatively straightforward process. So Drupal eight will hit its end of life this November. Drupal seven has an extra year of support to November '22. So there will be more time for sites to finish upgrading to Drupal nine at that point.

Shrop: I'm glad you mentioned that. They'll just, that'll be the recommended path, just to go straight to nine. You, you won't even have to go through eight at that point, or actually even today, you'd want to go, I think (Drupal) ten is in June, June next year. Yeah. So, so it's moving fast, but it, and I'm glad you mentioned that, Damien, that the upgrade paths are smoother, and that doesn't mean a complex site could have some complications and if you haven't kept things up to date, but from any of us who've been in the community a long time, it, you really don't have to approach it like we're going to build a new site and then migrate all the content. Now it's like actually true upgrades and there's migration paths and it's really great.

Damien: Yeah. So it's more of a traditional once you get onto Drupal eight, plus it's more of an upgrade rather than a rebuild. That's the last major upgrade. Yeah.

Shrop: So get up, get on the new Drupal train then, and I think train is a good visual representation that the community's used to illustrate the end of life for some of these, the train tracks end at a certain point, you want to be on the train track that keeps moving forward. Damien, what kinds of Drupal security resources do you think folks listening should know about?

Damien: So the most important one, I would say, is the security advisory newsletter that everybody can subscribe to off of their profile on Drupal.org. There's just a nice, if I remember correctly, a nice checkbox for that. The security advisories are also available through an RSS feed, and they're also published on Twitter through the website. There are separate feeds for core, contrib, and public service announcements.

So depending on how you like to get your security updates, do all three. Then there's also, as mentioned before, documentation on the security team's processes, and under the Drupal eight documentation, there are pages that describe best practices for writing secure code. So you can avoid security problems while you're building the site rather than dealing with them later. There are a number of books out there, most notably the Cracking Drupal book by Greg Knaddison mentioned earlier. It was written before Drupal eight came out, so it's a bit out of date, but the general practices are still reasonable. And for every function it mentions, you can find the equivalent Drupal eight or nine replacement through documentation online.

Shrop: Well, Damien, we really appreciate your your time on the podcast today and for coming on and talking about, you know, specifically Drupal security, but also, you know, a lot of these concepts, like you were mentioning about Greg's Cracking Drupal book, you know, security is evergreen, it does change over time, there's maybe new things, of course, we learn about securing our systems, but some of those old things are still out there like cross-site scripting. They just are probably going to be for a long time.

Mario: They don't go away.

Shrop: Yeah, exactly.

Mario: Well, Damien, thanks again for joining us today and sharing with us your expertise when it comes to security and the Drupal project. I also personally want to thank you for always being available and helping us with any security or contrib questions that we have. You recently helped me contribute to a project, and that was pretty rewarding to be able to do that.

Damien: You're very welcome.

Shrop: Thanks for listening. You can find us at mediacurrent.com/podcast and subscribe with your favorite podcast app. If you enjoyed this episode, share it with your friends and tag @Mediacurrent on Twitter. For more resources on open source technology, web design, and web strategy. Visit us at mediacurrent.com.



Jul 27 2021
Jul 27

open waters podcast logo

Open Waters Podcast: Season 2, Episode 4 

In this episode, we're joined by Randy Fay from DDEV to discuss features and benefits of DDEV, the future of the project, and how you can get involved with contributing to the Drupal community. Randy provides his perspective on DDEV and the ways in which both developers and non developers can use it for projects.

Episode Transcript

Mario Hernandez: Hello, everybody welcome. We are very excited here. Shrop and I are very excited to have with us, Randy Fay, who will be talking to us about DDEV and what's coming down the pipe with that. We are very excited about that because we here, at Mediacurrent, use DDEV for most of our projects, and we are loving the product and looking forward to what's coming ahead. So thanks for joining us, Randy. We appreciate it. We just had you actually do a knowledge share for our team, our development team, not too long ago. It was just last week. I believe it was. And now you're back with us. So we appreciate you taking the time from your really busy schedule and talk about DDEV. There is some great news happening with DDEV, but before we get into that, tell us a little bit about your role today and how you became interested in open source. What brought you to this point as a prolific maintainer of a key piece of open-source software like DDEV?

Randy Fay: You bet, I'm glad to be here. Again, my name's Randy Fay, I'm R. Fay most places, Randy Fay some places, and I live in far western Colorado, right near the Utah border in a little town called Palisade. And I ended up here because my wife and I took a long bicycle journey through the Americas from 2006 to 2009, and at the end of that time, my parents were getting old and we decided to come, you know, take a turn. Our turn history ended up being quite long now, but take a turn with helping them out. And so that's, that's where they were and that's where we are. But the open source thing is, of course, when we took two and a half years out of our life to do bicycle touring, there was going to be a change when we got back, and I've worked in various kinds of software development since the early eighties, but of course, like everybody else, I got more and more excited about web stuff and I'd never, I benefited from open source over the years.

Randy Fay: I've done lots of, you know, Linux work over the years and all that kind of thing, but I benefited from open source, but never contributed at all. And so one big thought was, well, how could I, how could I figure out what this open source thing is? And so when we were restarting our life after our bike tour, Drupal was there. I felt like I had some idea what was going on with Drupal. And I said, well, maybe I could figure out how to contribute to Drupal. And you know, how Drupal is, if you stick your finger in there and you figure out who the players are, you will be sucked in. And you know, you can spend the rest of your life...just working on that. And I did that for a couple of years and had had a great time, met wonderful people and got very involved in the Drupal community, but it was Drupal that brought me into the open-source world.

Randy Fay: So anyway, so I did that for a long time and then I burned out pretty good. I even did a whole series of sessions at a Drupalcon and stuff like that on burnout. And I got flamed out pretty good. Couldn't do it anymore. Worked on various things for a few years, but about maybe five and a half years ago, something like that, I went to work for a company named DRUD that was developing a Golang Kubernetes hosting product. And they also had DDEV going, although it was very much in its infancy, and I really liked DDEV. I liked it a lot more than the hosting part. Maybe because, I don't know, I just, I just liked it a lot. And I started to feel like it was useful and they were amazingly generous. They just let me go ahead and maintain DDEV for, it must have been at least four years and paid me to do it and rarely asked anything in return. Every so often they'd want some kind of integration with the process and that kind of thing. But that's how I ended up maintaining DDEV and got to continue doing that through their amazing generosity. That was a long answer to a short question.

Mark Shropshire: That's great. I love hearing these stories, you know, about how people get to where they are today, because, you know, it's also humbling to hear these stories, but you know, Randy, when I've interacted with you, it just amazes me how quickly you respond and support the community. And you're just always had such a great positive attitude. But you seem like this, this huge persona, you know, coming in like that, like the maintainer of DDEV and they got real personal with Mario and Shrop and helped, helped us with our problems and all that. But it's great to hear just this real human stories. There's, there's the human behind the keyboard, right?

Mario Hernandez: I can definitely attest to Randy's generosity with helping. I mean, no matter what I ask him, he's always there. He never judges, is always willing to help and has got me out of some pretty big holes with things that I work on with DDEV. So that's excellent to hear.

Randy Fay: It's lovely being a member of a community where you feel like you have something useful to do. I mean, I, I love it when people ask questions and everybody is at a different place. I mean, there's so many things going on in our heads, trying to understand all the different technologies we're working on, and there's so many different layers of all those technologies. It is astonishing and crazy. And so we're all at a different place and how much we understand on those. And so it's, it's always great to work with people at whatever level they're at to try to go to the next level, even though it's...I can't, it's hard to believe anybody can do any of this stuff with all the layers of stuff you have to know. It's crazy.

Mark Shropshire: I agree. I agree. And that, that's some of what you just said is part of why I love open source so much. And I know we've said the word, or if you want to call it a word, DDEV a lot so far, cause that's really what one of the things we're here to talk about, and in addition to Randy you, as a community member, but so while I know a lot of our listeners are really familiar with DDEV and what that means, and we love it here at Mediacurrent, it's our go-to environment. We made that choice a while back and and have been really pleased with it. But for those who don't know what DDEV is, what that means, can you give us a high level overview of this really fascinating open-source project?

Randy Fay: You bet, you bet. So everybody needs, in web development or really in any other context, a developer has to be able to work in an environment that's their own, where they're not going to break something else or break somebody else's world or that kind of thing. And I mean, probably most of us, sometime in our shaded past, actually edited files on a server and hoped that it worked out, but don't do that, right? If you're going to be a real developer, you're going to have your own environment to develop in, and you're going to be able to see the results of what you do locally before you inflict it on somebody else and you're going to have processes to make that work. So DDEV is a local development environment. It's, it's a way for people to do web development. It works with PHP, works with HTML and JavaScript, and probably you could do lots of other things with it, but the most of the communities that are involved with it are PHP, Drupal, and TYPO3 are the biggest ones, but the big idea is it's a, it's a wrapper written in Go on Docker Compose and Docker.

Randy Fay: And so it basically runs a web server and a database server inside containers. So they're actually running inside Linux containers. So it's more like a real-world situation but it looks the same on every platform. So, and so, in other words, the containers are the same on every platform. They're exactly the same. So if you're working on windows or WSL Two, or MacOS or Mac M1, or...people even work on Chromebooks, or if you're working on Linux, I mean, Chromebook just offers Linux. So if you're working on any links, distribution, everything works the same. It's using the same containers underneath.

Mark Shropshire: Sorry, I didn't mean to interrupt, but I was just thinking I'm pretty sure I got it working on my Raspberry PI a while back, thanks to all the work from the community, too, which is I had to do it just to do it.

Randy Fay: It actually works pretty well on Raspberry Pi. The trick about Raspberry Pi, it's ARM 64. So you'd have to set up, I think, I think you have to get the current version of Ubuntu, it's the easiest way. I wrote a blog post about it, so you could search for DDEV and Raspberry Pi, and it, it actually is decent. It it could be a little faster, but it's decent.

Mario Hernandez: So you mentioned earlier, Randy, that you worked for DRUD, a company who was building this product and DDEV, and we know that, some of you may know, that the company split up and for a while, the community was wondering what was going to happen with DDEV, but just this week we heard some great news. Sounds like great news. DDEV has been acquired by Fruition. And is there something you can tell us about this? What does this mean to DDEV? What does it mean to the community? What should the community expect about this new acquisition?

Randy Fay: Yeah, you bet. So the company named DDEV, you know. Companies, come and go, it was called DDEV, it used to be called DRUD, it went by several names, but, you know, not everything always works out and the money doesn't always hold out. And it's just the way it is sometimes. And somebody pulled the plug. I don't know who, but somebody pulled the plug. And so the company named DDEV shut down. The DDEV project was never in any question. The DDEV local project was never in any question because I'm committed to it and it's an open-source project and it was going forward anyway, but there was a little bit of uncertainty about whether the project might have to be forked, or the name might have to change because there is a trademark, a DDEV trademark.

Randy Fay: So there was some uncertainty about that. And the company named Fruition in Denver has bought the what, what, what would it be? The software that (the) DDEV company wanted to make money off of, and didn't end up doing that. They bought that software and they got the DDEV trademark name with it. And they've been very generous to say that they're gonna make sure that the DDEV local project remains open source, and then it doesn't have to change its name. And...the thinking isn't fully thought out, but they're, they're thinking that they would like to be the the central place to try to organize financing for the project as it goes forward. So there's a number of companies that have stepped up and said that they'd like to support the project and you know, maybe even Mediacurrent will want to, and it may be that we're, you know, these are things that we're still talking about, but Fruition may want to organize that financially, or maybe we'll figure out another way to do it, but anyway, they're just putting their foot in there and trying to make sure that it's clear to everybody that there's nothing wrong.

Randy Fay: Everything's good. And and that the name will continue and there's, there's no problems.

Mario Hernandez: Will you be still involved in maintaining the product, and how do you feel about this news about Fruition acquiring DDEV?

Randy Fay: I'm glad that they got it worked out. It doesn't change anything for me right now because I'm just supporting the project. I'm the maintainer of the project, and I continue to be the maintainer of the project. So it doesn't change anything for me. I'm not becoming a Fruition employee. They're, you know, they've been through a lot getting this done, so they haven't even been able to think about the finances yet. I'm sure. But for me, it just resolves the primary thing it does is resolve some ambiguity about whether we would have to fork or, you know, or change the name or something like that. So it's all, it's all very good and they're very nice people and have been very generous trying to sort this out. And they...I think they're taking on a big task with their ambitions, with the hosting software as well. So they've got a lot going on right now and we'll see how this all, how this all plays out. It's all good.

Mario Hernandez: It sounds like it's a great win for the community.

Mark Shropshire: Yeah, this is such great news. And it's it's kind of a testament how open source can continue even around business changes and things that happen in that world. That's not to say it always works out. We've all read stories and heard things, you know, but it's great to hear this and, and we're really happy that you're there and there's still keep supporting that, Randy, and I'd love to talk more about like what kind of support you need, too, later in the podcast. But because I'm sure, you know, you'd love to continue to have more PRs and people helping the project. But yeah, go ahead. Did you have, did you have anything immediate in mind on that, Randy?

Randy Fay: No. That's, good. I, like I say, the thinking isn't done and stuff, but it's all good. It's all good. It's gonna work out great. And, there've been a couple of excellent things that have happened in the funding realm already. TagOne has been supporting specific features. And so that's an easy way to support the project. So they just made me a contractor and have been paying me to do features that are important to some of their projects. And so I, you know, I just work a few, a few hours a week on their project, you know, on their features. And those are big wins for the whole community. And I expect Fruition is going to do the same kind of thing.

Randy Fay: And I think there's other companies that may want to do that. And there may be other companies that just say, Hey, we'll take five hours, we'll take five hours a week. And just, you know, just support the community or just, or, or, you know, maybe dedicated to what they actually need as far as features, but it's all, it's all good. So TagOne stepped up, now Fruition stepped up. There are other companies that have certainly made noise, but of course, as you know, it hasn't been clear how we would do that until this part sorted out. So that's another reason. This is really good is that now that this is sorted out, we can sort out the, all the people that have wanted to financially support the project.

Mark Shropshire: Yeah. That's so great to hear. Thanks for the additional detail on that. So, jumping back to the tech a little bit on DDEV, what are some of the key advantages that you see of around DDEV over other local development tech that's maybe been around or is around currently?

Randy Fay: You bet. You bet. So the original way that you did local development with the website is you'd put Apache on your computer and you'd put MySQL on your computer and you would hook them up and it actually would work great if you were if you were a whiz at Sysadmin, I was always a whiz at Sysadmin. It was my thing, you know, I liked it. It was, you know, I do Linux and I do Windows and I do Mac and it was all, I thought it was great. In fact, I was pretty skeptical of DDEV when I first started using it, because if you're a whiz, then you can just run that stuff. You can, you know, it all runs on every computer and it's great. But not everybody wants to spend their life configuring Apache or Engine X or MySQL, and the thing that amazed me when I started working on DDEV that really really shown for me was that every project could have different configuration.

Randy Fay: So back when I used to maintain everything on my own computer, that wasn't true, right? You have it set up for PHP 5.6 and that's it. You couldn't have one project on PHP 5.6 and another one on PHP 7, PHP 7 wasn't around then, but you just, it wasn't something you could do. And so I started realizing that with DDEV, you could have every project be different and customized, and you could do it right. And so that's because it's a Docker based, DDEv uses Docker underneath and all the stuff underneath is per project, and it is configurable for that project. So that's the huge difference between the Docker generation and the on the machine generation. The difference between DDEV and other Docker based local development environments like Lando or Doxil, which by the way, are great, great products and have lots of supporters and lots of great things to say about them.

Randy Fay: DDEV has got full cross, full support across all these platforms. So many different platforms, which you won't really find that level of support. DDEV is actually tested on all the different platforms. So it runs the full test suite on all the different platforms. DDEV is interoperable with many different versions of Docker. And we think the performance is great. On MacOS it's always a challenge. I'm still working on new ways to improve that in MacOS. So you can look for mutagen, mutagen integration coming up. I think the biggest thing, though, and this actually was playing out in Twitter today, is that DDEV doesn't assume that it owns your machine. So when you install DDEv, DDEV is going to be as respectful as it can. The only thing that I know of that requires you to use Sudu is if you're not using the regular DDEV.site URLs or host names and then it has to...edit the Etsy host's file, but in general, DDEV tries not to do anything to your machine. It won't install Docker, it won't overwrite Docker, it won't kill off your Docker, all of those kinds of things. And I think that's a big deal. But maybe, maybe you can put in the notes. I wrote a thing called "What's so different about DDEV Local?" Maybe you can put a link to that in the show notes.

Mario Hernandez: So I can certainly personally attest I was trying to, I originally got an M1 Mac and was trying to get other development environments set up and I was unfortunately not able to, but DDEV just worked for me, you know, the first try. And so, so that's great to have that kind of support. But, as far as you know, the efficiencies that DDEV provides besides the support, what are other efficiencies that DDEV provides to help teams? Is it something that non-developers can use to run their sites locally and test, or is this mainly just for developers?

Randy Fay: No, actually lots of, anybody who needs to evaluate a site will often do it or, you know, to evaluate or to test a site. It, all those kinds of things, there's actually an obscure feature where you can actually run websites using it. I call it casual web hosting, but I run my little websites using DDEV. That's that's not what DDEV was intended for, but people asked for it for years. And so they finally did it and it actually works pretty well. But it is definitely, it is definitely not managed web hosting or anything like that. So you wouldn't, you wouldn't put a big customer site on that under any circumstances. So the biggest thing about teams is that you check in your configuration for the project. So each project, you just check in the DDEV directory, the dot DDEV directorty, you check it in, and then everybody can check that out and DDEV has already configured for them.

Randy Fay: And so usually a team lead would configure and check in DDEV, and then all the other members of the team can just DDEV start and DDEV launch and get to work and it's already configured, even if they're even if the team lead was on windows and somebody else is on Mac or Linux, it'll just go. And obviously there's going to be caveats there, but really it pretty much works that way. So we're going to do at at Drupal Camp Colorado, I don't know whether, you know, Truls (Steenstrup Yggeseth) who's a Norwegian developer who is kind of an expert at setting up DDEV for teams. He's done it for two different companies. He's the guy that makes that work for two different companies. So he and I are doing a session, an hour-long session at Drupal Camp Colorado, which is free. And we're gonna, it's about, it's about teams and DDev. So we'd love to have you at that.

Mark Shropshire: Oh, that's great. Yeah. And you know, just to reinforce, this we'll definitely add a lot of these links and items to the show notes, so that it's all available. So don't worry. And if you're listening, go Google for it, just check out the show notes. And we've already got that link in our notes here from you, Randy, so thank you for that. So I know you mentioned earlier you know, some of the platforms or frameworks that run on DDEV include, you know, Drupal, TYPO3, what are some of the others of interest? And are there any others that, you know, are maybe coming up? But I know you've got quite a few.

Randy Fay: Yeah, yeah. I mean, we got a really all versions of Drupal six to nine, WordPress, Oracle, TYPO3, Shopware six, Magento one, Magento two, I might've forgotten about one or two, but really, lots of people....you know, because we have explicit support for these and we create settings files and stuff, it doesn't actually mean that much to anybody that understands how to do a settings file. So, all it means basically is that DDEV will generate some settings files for you, so you can get up running really, really fast. There's...no PHP project that you can't run on DDEV, really no HTML, JavaScript, Node, whatever you can run them all on DDEV. It just, it requires the same setup that you would do in any other, in any other environment. Just...DDEV, it just makes like Drupal so easy.

Randy Fay: Cause you do a DDEV config and a DDEV start, and it's already configured. You don't even, you don't know where the database is, you don't care where the database is. You don't, you didn't do the settings file. It's just there, but that's just a settings file. It's not like, we all know how to do a settings file so we could all do that by hand. Then I'm pretty sure on like on Lando and Doxil, you have to do the settings file yourself. Well, that's fine. There's nothing wrong with that. It just makes it, I don't know. It's a little addictive. So that that's mostly what the framework stuff is. It's icing on the cake, but it's not the fundamentals, but it feels like the fundamentals because everybody gets used to it.

Mark Shropshire: It does, because I know when I'm in development mode and not a DevOps mode, I want to just worry about the code and get into the code. And so if it saves, you know, that automation save that time and you know, in an agency situation like Mario and I are in, we're popping in different projects all the time and spinning things up, spinning things. I mean, it becomes even more so a benefit, even though you do that settings file once, you know, usually, and then it's done, but yeah, totally agree. That's great insight. And I think, Mario, we've even had, we've even had some projects where we've run Gatsby in DDEV and some other node things like Randy mentioned.

Mario Hernandez: You know, shameless plug here. I actually, with the help of Randy, I wrote a blog post. I think it was late last year where I configure an environment and since I do a lot of training myself, training workshops, I configure an environment where the students would just run DDEV start and they will have everything from, you know, obviously Drupal, PHP, everything else, but also NVM, NPM, node and everything pre-configured and running from the containers, including Pattern Lab, which will run from the containers. And by sharing some ports, you can literally have an NPM watch task watch your changes and everything in the containers. Pattern Lab will even reload the browser for you, all running from the container. So it is incredible what you can do with it. So highly recommend if you are a developer to look into it. So, now that we talked a little bit about the DDEV, what it does, what it can do and how cool it is, what can you tell us, Randy, about what's coming up for DDEV?

Randy Fay: Well, I'm really excited about what I've been spent working on the last the last few weeks I already mentioned it. It's mutagen passing speed up. The big problem on MacOS and to some extent on Windows is that Docker is slow updating files between the host and the container. And so there's a workaround for that. You can call it caching, or you can call it asynchronous updates. But there's a project called mutagen that's another open source project that has been working on trying to solve that problem for some time. And it actually has pretty good potential. Basically what happens with it is when you make a change in the container, that change is immediately available to like the web server or a PHP FPM. And so it doesn't have to wait for that to sync before it is used.

Randy Fay: So that's not the way it is in current Docker setups. In, current Docker setups, every file change requires everything to happen immediately. Anyway, mutagen can be two to 10 times faster at like a, at like a Drupal nine installer or something like that. I've been doing some timing on it. Very, very impressive. And that's fast, I'm talking about faster than NFS, which is the other technique that we've been recommending for a long time. The complexity of mutagen is that...you can introduce conflicts by touching something on the Windows side or the Mac side, and also inside the container. The consistency stuff is hard and mutagen is good at it. But there's a lot of workarounds that DDEV is having to do to make that go. But I think you'll see an alpha of that in the next couple of weeks.

Randy Fay: And I hope, I'd love to have everybody try it and get their feedback. It is lovely to work with. The worry always is about consistency. Would some files suddenly go away on you that you didn't mean that to happen, that kind of thing. So consistency is the big deal. Also (developer) Ofer Shaal has been working like crazy making gitpod work with D dev. So there's a whole project called DDEV gitpod, (https://github.com/shaal/ddev-gitpod) that will just bring you up a whole Drupal, a whole Drupal nine set up, boom, there you are. By the way, Ofer likes to say boom. So I'm going to say boom a few times, you can put the boom into the release notes. And so, you can try that out and it's just lovely, but the next step, he's transforming that for Drupal contributions so that you can just say here, and this, this project is called Drupal pod capital D capital P.

Randy Fay: So Shaal drupalpod, and he's got it to where you can visit an issue on drupal.org and you can do an issue fork or contribute to an issue fork right there in your browser. Now I should have started by saying what gitpod is. Gitpod is a way to run a Linux computer in the browser. It's basically giving you a free Linux computer that's fully configurable in the browser with VS code. So it's got a very nice IDE. So if you bring up DDEV gitpod, for example, you have all of DDEV right there in your browser, all of it. You can, immediately do debugging. Ofer has done a number of demonstrations of this. You just spin up, you go to any PR or you go to any project on GitHub, click the gitpod link, and boom, you have got that boom in there, again for you, Ofer, you have it up and running and you can debug with XD bug in VS code without doing anything, nothing at all.

Randy Fay: So it's right there. It's got great potential for DrupalCons for contribution days. Both of these have enormous potential for that because you don't, if you've ever worked in that, one of the contribution days at DrupalCon about half the day can be spent helping people get a local environment set up and they've all got their own computer and it all has to be set up differently. And with with these various ideas that Ofer is spinning off so fast, all that goes away and it can all be done consistently in gitpod. It's an amazing demonstration. I don't think it probably works as well on a podcast.

Mark Shropshire: Yeah, yeah, that's right. This is audio only, but Ofer, he is on tour. It seems like giving demos, he gave a demo or a Drupal Camp Asheville unconference, and it blew my mind. I was immediately posting links and I've already got those listed now for the show notes, but I was posting links in our developers channel cause I was so excited. I saw the potential in Drupal pod, but I don't think I realized there was DDEV gitpod. So thanks for mentioning that, Randy.

Randy Fay: Yeah, well that's what Drupal pod is, too. Drupal pod just uses DDEV inside gitpod, but it's focused on Drupal issues. So it's focused on Drupal. And so that, I mean, that's gitpod is DDEV in gitpod.

Mark Shropshire: I see. Yeah, that makes sense. Drupal pod is for the issue queue side of things.

Randy Fay: Ofer and I are going to do a demo of a Drupal pod probably at Drupal Camp Colorado. I think, don't they always have like an IT day? I think we have a slot on that.

Mark Shropshire: That is fantastic. I guess we're at a point here where we can we can start to wrap up a bit. I mean, you've mentioned a few fantastic trainings already. So I would tell everyone to kind of check out the Drupal Camp Colorado website. We'll get links in the show notes. And also I think there's some training coming up with, with Mike Anello, too, Randy.

Randy Fay: Yeah, we're doing we're doing at, at Drupal Camp Colorado. We're doing a half day training with Mike Anello. If you haven't done one of Mike's classes, every one he does is wonderful, but he's been doing DDEV for years. He does this whole, like year-long Drupal thing to take you from zero to expert in a year. He does, he does all kinds of wonderful things. But he also does Composer, which I highly recommend his Composer class, but he and I are doing DDEV local, beginner to expert half day at Drupal Camp Colorado. Yeah.

Mario Hernandez: Mike...I have worked with them before and attended this class, actually. Mark Shropshire: He's fantastic. And a great community member. I highly encourage folks to check that out for sure. So I think that should do it for today. We really appreciate it there, Randy, taking the time to join us again and give us all this great information, especially it looks like the future looks very bright for DDEV and makes us all very happy here at Mediacurrent and I'm sure a lot of the community members out there, so boom, there you go.

Mark Shropshire: I like it. I'll drop a boom in now. It's like, it's so much better.

Mario Hernandez: So thanks again, Randy. We appreciate it. And anything else, Shrop, you'd like to close with?

Mark Shropshire: No, no, just encourage everybody to, if you haven't used DDEV, go check it out. We've got links for all of Randy's. Well, not all of Randy's places on the internet, but at least some places I know I looked for Randy and that's his website, GitHub links and Twitter. So definitely check that out and I encourage, also, this is open source, you know, Randy can't do everything, and I encourage folks to help with the project in whatever way they can, organizations or individuals.

Randy Fay: Yeah. Yeah. That's what I was going to follow up with that, too. DDEV Is a community of people and it's, you know, when there's a whole bunch of different Slack groups, there's DDEV in the Drupal slack and in the TYPO3 Slack, but DDEV depends on everybody learning new things and pioneering new approaches and helping each other more than anything else. And those communities where people are listening and helping people at all levels when they land are wonderful things. So remember that DDEV is a community project and you're part of it. And you're welcome there.

Mark Shropshire: Well, that can't say it any better than that. Thank you so much for your time today, Randy. We really appreciate it. And now we know it's precious, so thank you.


Jun 22 2021
Jun 22

open waters podcast logo

Open Waters Podcast: Season 2, Episode 3 

In this episode, we're joined by Shane Thomas of Gatsby to talk about decoupled Drupal and how features in Gatsby make it easier to make decoupled websites using Gatsby and other CMS like WordPress or Drupal. Shane gives us insight into what makes Gatsby unique as well as some sneak peeks into upcoming features. 

Episode Transcript 

Mark Shropshire: All right. Welcome everybody to the Open Waters podcast. And today we have a very special episode. We are going to be talking about decoupled websites. We'll get into decoupled Drupal. We'll get into some Gatsby because today we have Shane Thomas of Gatsby, who's our guest today, and I'm here as usual with Mario Hernandez as a cohost. Gatsby provides development teams and open source front-end framework for creating dynamic, optimized websites and cloud platform for delivering them on a blazing fast edge network. That's a lot of words, but it all makes sense. And it sounds fantastic. So Mario, I'm gonna kick it over to you and we'll kind of start chatting it up with Shane.

Mario Hernandez: Excellent. Thanks a lot, Shrop. I appreciate it. Very excited to be on this episode two of the Open Waters podcast, season two. And thank you so much, Shane, again for joining us. We appreciate you taking the time from your busy schedule to join us one more time. I think we had you on the first season of the podcast. Tell us about your role at Gatsby today and how you became interested in the decoupled Drupal architecture.

Shane Thomas: Yeah. So I've been working with Drupal since I think 2009. And I started a little web agency doing, starting with Drupal 6 websites. So I've been working with Drupal for a long time. I used to run a website and I guess I still do, but it's not really active called codekarate.com. So I've done a lot of videos and all kinds of different content for Drupal. When I was really using it heavily. I worked at a Drupal agency in the past as well. I've been part of some startups. Then I started to really get interested in hearing about, you know, headless Drupal and decoupled Drupal. And what does it mean? And there are a lot of new JavaScript front-end frameworks that were coming out about this time. And you may have heard of static site generators that are popular and maybe pulling data from some of CMS systems like Drupal and other CMS providers.

And so that got me really interested in digging into it a little bit more. And I kept hearing at actually at Drupal camps, I kept hearing talk about this Gatsby thing. What does this Gatsby thing? And originally it was just, oh, it's a static site generator, just make all your content static. And then when I really dug into it, I realized it's not just a static site generator, it's really a React framework. So if you're familiar with React, it's it's a way to it's a JavaScript front end in front end library to build websites and web apps and gets these built on top of that. And so then I started playing around and realized like Gatsby is really kind of an ecosystem for building websites and web apps. And now with Gatsby Cloud, there's kind of this entire platform that really makes it easy to do that. And so I started met with some of the people at Gatsby, saw them at some conferences, and I guess the stars aligned and I was hired as an engineer to work on the Drupal integration. So it kind of all kind of coincided pretty well with my back background in Drupal. And from there spent quite a bit of time working on the Drupal integrations, which I'm sure we'll talk a little bit about. And then eventually took over as an engineering manager for our integrations and collaboration squad at Gatsby.

Mario: That's pretty neat. Code Karate I know Shrop, he gave a thumbs up. I benefited a lot from that myself.

Shrop: Yeah. That is a great kind of background review Shane where, where you, you know, where you've been and how you got to where you're at today. And you mentioned some of the work you've done, like with Drupal and Gatsby, and Gatsby and Drupal working together. Can you give us a high level kind of perspective of where Gatsby fits in to the decoupled discussion?

Shane: Yeah. So, what Gatsby allows you to do, and I guess that's kind of the, one of the best benefits of Gatsby is you can bring your content from anywhere. So there's a lot of different CMS systems that marketers and content editors like to use. Drupal's a great choice, right? You can model your content and set it up however you want. There are other ones like WordPress or Contentful, and Gatsby is not opinionated about which framework you use to build your content. So essentially you bring the content and then we provide the front-end framework for it. And the reason you might choose to do that is because a lot of CMS providers like Drupal, like WordPress there, they tried to do all things. And so sometimes when you try to do all things, you don't do everything as well as something that's very specific or focused.

And so by Gatsby being very focused on just the front end of your website, it can be, uh, more performance and you can get a better Lighthouse scores, which can help conversions because your users or your customers are experiencing a faster, more app-like website. And so their load times are better. It seems they don't get frustrated if the page takes too long to load those types of things. And so that, that's kind of how it fits in. As you know, it's not necessarily a replacement for Drupal or WordPress or any CMS provider. It's kind of just taking the theming layer, if you've heard of WordPress themes or Drupal themes, and saying rather than use what's provided with within the framework, use Gatsby instead for that part, and then still use or WordPress or Contentful or whatever for all your content.

Mario: You know, we've been working with Gatsby for a little while now, and certainly we can see the benefits, but but one question that, you know, we, we get quite a bit is, you know, why would a site owner look into going the decoupled architecture route? So let's say, for example, why would a marketer, you know, we'll find this appealing, right? What are some of the benefits and from let's say, security, performance hiring, and that kind of thing. What are some of those things that you think are beneficial for a marketer to look into the couple of architecture?

Shane: Yeah. So deciding to go to decoupled is certainly, it's not an easy decision to make, and there's a lot of considerations. It's. Especially if you built sites, not decoupled before, it's, it is a change and you need people with a little bit different engineering backgrounds. However, it is getting easier to hire JavaScript engineers. There's, you know, that's definitely something that people are interested in and learning about. And so they're coming out fresh from school or from, you know, other industries and they're digging right into JavaScript. So they're literally, I'm not saying that engineers are easier to find, but there's more interested engineers. It seems like than hiring someone very specific or specialized, like it's Drupal engineer. And so by separating that out, you can have someone focused on the back end and then someone focused kind of on the front end or the framework side.

So by decoupling, you kind of split those concerns off a little bit. Also, you really, one of the big drivers of decoupling is performance, which I had mentioned a little bit before your, your speed of your website matters because if your customers are having a better experience, they're more likely to either buy it from you or call you, if you're trying to get them to call and use your services or sign up for your product, whatever it is. They're more likely to convert if the website is so well-designed fast and it feels like they don't have, you know, it's a seamless experience for them. And that's where front-end frameworks and going decoupled can help with that because you can use a framework that's specifically focused on performance. And the other thing is just security. So using a front

You're not necessarily exposing everything available through your, your website. So you have kind of an API, you can kind of hide certain things you don't want to see. And it does help that, you know, everything's static. So you it's secure and it's it's faster, it's highly available. So you don't necessarily have to have a running server for a lot of your stuff. So if you ever had a website go down and you're wondering why, why is my website always going down? Well, that's not saying it never could happen, but it's a lot less likely to happen when you're just serving more static content and less where every, every request has to go back to a web server to generate that information. So, and then those are some of the reasons, um so there's definitely trade-offs though, you know, good at good and bad for both, but there's a lot of good things about deciding to to look into a decoupled architecture.

Shrop: I know we were talking a little bit before we started well, before Mario hit the record button, then you know, we do have a lot of Drupal folks listening to this today. But I do want to mention that when you dig into Gatsby, what's what I really like is that you can even have markdown be your backend. You know, that could be the source of content. You can have so many, like you said previously, Shane, It's it's not really opinionated about the content. You know, you bring the content in different forms and, and I'm pretty sure that you can but you tell me, Shane, here on this, if I'm right or wrong, but I mean, you could have Drupal and WordPress and markdown, you could actually have multiple sources even for different pieces of content into a Gatsby site. It might get complicated, but it's interesting.

Shane: Yeah. So, you see that quite a bit, especially as the sites get more complex, that you might have a Drupal for dynamic lead building landing pages, right? Because Drupal, you can model content. You can set up, you know, if you're familiar with Drupal using, you know, paragraphs or something like that, to set up a really dynamic landing page builder, and that builds onto your Gatsby site, but maybe you have products, too. So you use Shopify for your for your e-commerce part of your site. So your products are served from Shopify, and maybe you have a marketing team, you're a big organization and they just are, they love WordPress. They just have a blog, that's all they need. And so they could be using just the blog parts of WordPress. You can have all three of those systems and everyone, you know, the developers who are building these landing pages and, you know, making that available and using Drupal,

And then, you know, you have your marketers that are blogging and WordPress, and then, you know, people managing all your products in Shopify and it all kind of ties together and gets pulled into all into one Gatsby site. So it's kind of referred to as the content mesh, it's something that the Gatsby likes to call it internally. And I think we have, you know, posts on what the content mesh really is, but it's really a, you bring the content from anywhere and Gatsby's kind of your source of truth that pulls in that content and build your website. You're certainly not locked in as much to just using the tools that you're given. You can kind of look for the best tool for the job.

Mario: It'll meets at the end, right. At the front end. Yeah, exactly. So, so once you've done your homework and you know, you've done a little research and you say, okay, this is the way I like to go. And, you know, you arrive at that decision to go to decoupled, what are some of the marketing benefits that a content manager or a marketer should expect to see, besides some of the things that you already mentioned?

Shane: I mean, definitely, you know, we talked about performanceReally the benefits are I w I would say, and of course the a, if you're a marketer, you want to test this, right? But I would say conversions are the, are the biggest thing, right? If you have a better website, you provide a better experience. You're going to get more conversions. Your, your analytics are going to go up into the right, which is what you want, if you're a marketer. So, so that, that's the biggest selling point. There are certainly some trade-offs though, that you have to consider because it's, it's not the same, right? If you're familiar with working in WordPress, or you're familiar with working in Drupal, and now you have this kind of decoupled architecture, you know, this, you, whether it's a Gatsby site or another framework like Next.js or some, some other, you know, front-end framework, that's decoupled your back end from your front end.

Now, there are some considerations, things that you kind of took for granted, like live preview are a little bit more complicated and, not saying they don't work, but there there's some differences in how your content editing workflow might change from what it was before to what it is with the decoupled architecture. So those are things that you certainly need to keep in mind when you're, when you're choosing to make that decision. And also making sure that your developers understand that the first time you do it, there's a learning curve to moving to a decoupled architecture. And so you have to go through that, you know, just like you did when you first built it, you went from a, a static HTML website to a WordPress or Drupal website. You know, there's, there's learning curves at each step. And so this is no different.

Now, I do believe that once you, once the development team learns how to, how to use it and how it all ties together, that most of the time that I've seen, they don't want to go back. They love the love working in that, with that model, like separating out the concerns between the back end and the front end, and being able to I think in a lot of ways people think it's going to take a lot longer to build the decoupled sites. And I think at the beginning it does, but in the long term, I think it actually is as fast or maybe even faster, because you can work on the back end and front end in parallel rather than a lot of times it seems like with in the past, you'd have to kind of build, you couldn't really do that. You had to build the backend stuff first, and then you'd have a front and themer or designer come in and build the front end pieces. So this kind of allows you to do both at the same time, at least to more of an extent.

Mario: Yeah, I can, I can see, you know, when you mentioned talking about being able to bring the content from any source, right. I mean, when we build a site, let's say Drupal-WordPress site you know, things can get pretty complicated just within that platform. So I can only imagine how things get a little more complicated and complex if you're bringing any more tools, right? Like Gatsby or combining WordPress and Drupal together, markdown or something else. So certainly something to keep in mind. And I say this because a lot of people say, oh, Gatsby is great. And I love to use it. I want to use it, but yeah, you need to take a step back and kind of consider, okay, what is this going to mean to my workflow now? What is this going to do to my build of my site? How has this complexity going to affect performance from the editing point of view deployments and that kind of thing. So a lot of those things a lot of people don't consider, you know, they just see this shiny thing, which is great, but there's a lot of things that need to be considered when moving into something like this, where the complexity is drastically increased.

Shrop: One of the things I'm excited about speaking of taking complexities of decoupled and just website building in general is a lot of the work that Shane you and the Gatsby team have done with Gatsby Cloud. Could, could you just briefly mention a few of the things that Gatsby Cloud gives you know, gives the development teams and marketing teams, that sort of thing.

Shane: Yeah. Yeah, definitely. So one of the things you have to keep in mind with, if you choose to build a website with Gatsby specifically, is that we talked to her a little earlier about how it creates everything kind of as a static website. And there's the when you have that process of taking all your content from a CMS, like Drupal, and then building a static website, there's that build process that has to happen. And you can think about it as if you were using a Drupal website and you didn't use any kind of caching or anything like that, every time you go to that page, the server is doing work to generate that content. That means every user that goes to that page, the server's doing work for every single user that views it. And now of course you can add caching layers and things to try to prevent that and make it faster.

But Gatsby kind of flips that model on its head. So rather than adding layers of caching, it's just fast by default. And you have to, I think I've heard someone say you have to work pretty hard to make Drupal websites fast. It's certainly possible, but you have to really work at it. And it's kind of the opposite. You have to work pretty hard to make Gatsby websites slow. I've certainly seen it, but it's really out of the box, it's pretty fast. So but there's that build process that has to happen. So it happens once and then all your users get the benefit of that build process. But you have to keep that in mind that there's, that when you change content, when you you know, update your site and, you know, update your version of Gatsby, there has to go through this build cycle.

And especially if you're with a website that has tens of thousands of pages, that process can take a long time. So it Gatsby Cloud has incremental builds and cloud builds that speed that up. So rather than rebuilding the entire site, it'll only rebuild pages that have changed, and that speeds up your build times from, you know, maybe 5, 10, 15, 20 minutes, if your site's really big to tend to 30 seconds or less, depending on how the size of your site and what kind of change you made. So that's the first thing that Gatsby Cloud provides is really an optimized build service. So it, your site gets built faster. Again, Gatsby's an open source framework. You can certainly do all of this yourself, but Gatsby Cloud, we'd like to think is the best way to build a Gatsby website. On top of that, it also offers a live preview service for content editors.

So, one of the things you lose with going decoupled is it's harder to preview your content. If you're editing in a CMS, you're used to be able to click on view something that's not published yet, or click the preview button and see what it's going to look like. You kind of lose that. And Gatsby Cloud provides a service. So you get that back. So as a content editor, you can feel confident that when you click the publish button, it might take five or 10 or 15 seconds for it to go live. But when it's there, you know what it's going to look like. And then the last thing that Gatsby Clouid offers, so kind of the third tier, is a hosting service for your Gatsby site. So you can kind of have it all under one roof. You can build it, you can preview it. And then once you're ready, you hit deploy and then published. And then it goes, and it's hosted all kind of within Gatsby Cloud.

Shrop: It's got to be, you know, Gatsby's open source, but you've provided these tools on top of that. That's like the best practice way that you've like the Gatsby team believes to do all these things like hosting and, and builds and previews. I think that's fantastic.

Mario: You mentioned Gatsby preview, which is definitely something that we have seen in the early stages of Gatsby being an issue. And we definitely have also seen how much work your team is putting into making sure that that is something that works as people would expect it to see. Can you give us a little bit more on the Gatsby preview, specifically, and how that can benefit the content authoring experience, and maybe perhaps where you, where you and your team are with Gatsby preview, anything else coming down the pipe with that?

Shane: Yeah, I'll see. I'll have to be careful. I don't share too much information about what's what's coming up. Marketing team might not be happy if I divulge too much too quick, but preview is really important to what we're doing and it's not an easy problem to solve when you have, you know, potentially multiple systems funneling into one Gatsby site, right? You might need to preview content from WordPress or Drupal or Shopify. There's all these different sources. And when you change, let's just make a simple example of changing content in a blog post. You want to be able to preview that before you click the publish button. It seems like an easy problem, but when you have all those systems working together, it's actually a little more complicated. And so we've been one coming up with, how do we make preview more reliable?

You know, there there've been issues that just in the past with, you know, all those different systems working together, that sometimes things come up and your, your preview server stops running, or something happens where the developers that built the Gatsby site didn't correctly think about all the different possibilities. And so that causes your preview to break in this certain scenario where they add certain fields and don't add others or something like that. So there are all these different things. And what we've really been focused on is, one, reliability, making sure that it works, and if it doesn't work, we, you know, why. Is it a problem with the previous server and Gatsby Cloud? Is it a problem with the sites? And so that's been a big focus of making sure we're one preventing those problems. And two, if there are problems servicing it in an actionable way.

And on top of that, we've been releasing recently, we released something called preview UI. I guess that's, I don't know if that's an official public name yet, or if that's just an internal name, but essentially it provides kind of an indicator where, if your previews rebuilding or someone saved content, it tells you the status of that. And it gives you links to the air logs. It provides you the ability, you know, simple little things like, oh, click here to copy the link and send it to somebody so they can view it, give you the okay, and then you can publish it. And that's really where we're interested in figuring out is how do we make the content editing experience more collaborative, better? Because content editing, there's this weird fear (for) marketers, there's this weird kind of in-between stage of, you know, you need to build some content, you maybe write the first draft, and then there's all these edits that happen are these requests from different parties.

And a lot of times that might be happening outside the CMS in general, like in a Google doc. And then someone goes in and pastes it in the CMS, and then they do another round after it actually decides how it looks like. So we're trying to make that easier. So we're providing one solution for that, so they can build it in their CMS of choice, preview it, collaborate on it, make sure it's right, and then eventually publish it. So that's where I would say the next steps are that we're not there yet is kind of those, those features to help content editors and marketers collaborate on their content before they're ready to publish. And so that's not to tip our hat too much, but that's where we're, we're really looking to improve for all Gatsby users in the future.

Shrop: One thing that you mentioned earlier, you alluded to the preview button and I think about Drupal's preview button and Mario, you and I talked about this the other day you know, preparing a bit for, for this episode and I've kinda, I've become accustomed now both on mediacurrent.com and on some other projects we're working on, with having preview in, and there's also the Gatsby Drupal module that you started working on, Shane, and really pushed that along. That's what you mentioned that earlier, but all these pieces I'm, I'm, I'm really digging the Gatsby preview over that hitting the preview button Drupal experience because there's, depending on also Drupal set up, sometimes that preview button in Drupal, doesn't do what you exactly think it should, for various reasons. And, you know, once everything's set up correctly, like I feel like the Gatsby preview is really giving you a more correct show of what the website would look like. And that's the exciting part for the authoring experience. Mario, you're, I see you nodding a little bit. What are your thoughts on that?

Mario: Absolutely. Yeah. You know, I think as a content editor, right? Or content creator, you want to be able to see a more accurate representation of what your page will ultimately look like on the front end. Right? So having that preview give you that is definitely something that will be appealing to people who work on content. Yeah, go ahead, Shane.

Shane: I was going to say, and the one interesting thing is, especially on Gatsby cloud, the preview service uses the same build process as our build service. So I'm not going to say it's not possible, but there should be almost no reason. It's not identical every time, because, you know, unless you coded something, you can, of course, Gatsby's a framework, you can, you can break preview in your Gatsby site if you wantdc to and make it work for nobody. But assuming nothing is too wild in your setup, it's going to be the exact same every time. So, you know, when you're previewing something, you're actually, the cool thing about it, when you click the preview button in Drupal, for instance, you're only seeing that page, right? That one Drupal page, if it's a blog post, you're seeing that one page. You're not seeing the state of the site, like, how is this going to show up in the blog listing page? How is this going to show up in the footer of related posts with your Gatsby site? It's a full site. You can click the links, you can navigate and see where this content might show up in other places. And so it's really it provides you that really accurate representation of what it's going to look like when it does go live. So that is one benefit. Again, that, that process of updating it and all those places does take a little bit more time. So that's the trade-off is it might be a little bit slower to get that preview, but you know what you're looking at is going to be right. And when you click the publish button, you can click publish with confidence.

Shrop: Well, just shifting gears, a little bit back to decoupled overall. Are, are there any gotchas for a site owner, marketers, developers that they should be aware of before jumping into decoupled?

Shane: Just that it's going to be different than websites you built in the past. So, be prepared for, you know, no matter what kind of front end framework you're using or what kind of decoupled backend you're using, just prepare that it's a learning curve. There's going to be a few headaches along the way. You know, all the frameworks try to make it as seamless as possible, but every, every website's different, right? Every website's unique. And so there's all of these, you know, ideas, and while they're being used by huge companies, there's always, you know, new kind of edge cases that you might run into and you might have to work through, especially as your developers or engineers are really getting up to speed with how it's all built. And then as a marketer or site owner, just know that how you interact with your content is going to have to change a little bit.

Shane: And so you're going to, it's a learning process there, too. The one gotcha, I would say, a lot of times especially I've seen, when people start to build a decoupled website, they don't think about the content editor or the marketer until the website's about done, because they're like, the website is ready to go, let's publish it, and they put all the initial content in, and now the marketer or content editor wants to change something, and it doesn't quite work. The preview doesn't work right. The, the experience, they weren't prepared for it, there was no training there. So I would say if you're looking into that, just make sure you don't forget about that and kind of punt that until the end, because otherwise you're going to maybe be scrambling a little bit and the marketers might throw their hands up and say, this isn't what I signed up for. I thought this was going to be, the site's fast, but I can't do anything with it. I can't change the content. I don't know how it works. So making sure that you have documentation or trainings or whatever, to bring everyone up to speed rather than waiting till the very end to figure that stuff out. That, that'd be one. Gotcha.

Shrop: That's so good. And Mario, Shane said the training word that I know that had to excite you a bit.

Mario: Well, absolutely. You know, it's, you don't want to forget about the people who ultimately will probably be using the website more than anybody else. Right? And so you want to keep it in the mind from the beginning, there is about their experience, not just the visitor experience, but I think that's all the questions we have. I mean, this was really informative and feels like we, we talked to the Gatsby team quite a bit. And, you would think that a lot of this stuff is not going to get us excited or anything, but this stuff is pretty cool, especially the preview. That's something that I'm really excited about.

Shrop: Yeah. This was great. Well, Shane, thanks so much for coming on today to talk to us about decoupled and and to learn a little bit more about Gatsby. I'll always, Mario, I think you agree, it sounds like that's where you're headed. Like I always learn something every time, every time we talk to somebody from Gatsby or talk to someone else just about decoupled in general. So there's all these different experiences. It's not you know, it's not a one experience fits all kind of thing, but, but really appreciate you coming on today and talk and talking to us about all this.

Shane: Yeah, definitely. Thanks for having me. It was fun.

Jun 18 2021
Jun 18

Drupal 7's end of life is scheduled for November 28, 2022. Up until then, the Drupal Security Team will continue to provide patches to Drupal 7 core and contributed projects should any security threats arise. After that point, however, the Drupal Security team will no longer support Drupal 7.

Is it Safe to Stay on Drupal 7?

If your organization is currently running Drupal 7, you’re faced with a decision on whether to upgrade to Drupal 9 or not.

Crafting a business case can help with your decision because it contains projections for initial costs and ongoing costs for making the upgrade investment vs. maintaining the status quo, as well as projections for revenue and savings. The business case exercise can further forecast the break-even point for your upgrade investment. However, in the case of future security threats, we can’t be confident of what the future ongoing costs will be, because we can’t predict when such security threats will arise, nor will we know the severity of them. 

What we can do, however, is make organizations that use Drupal aware of the risks of not upgrading. There are three general areas of risk: security, integrations, and functionality.

Security Risks

After Drupal 7 reaches the end of life, whenever security issues are identified in core or contributed modules, there won't be very much support to fix them. Site maintainers could find themselves in the position of having to spend a lot of time searching for security holes and fixing them. This risk gets compounded if there are a lot of contributed modules in your Drupal configuration. 

There will be a few agencies that will offer the service of maintaining your Drupal 7 platform post end-of-life. This will help greatly to secure your site if you’re willing to invest in hiring such an agency. One of their main tasks is to backport fixes for core and contrib issues. These fixes will of course not be included in the D7 upgrade path because there won’t be an upgrade path at all. As a point of reference, after Drupal 6 had reached its end of life, there weren't a disproportionate amount of security fixes needed for its core nor contributed modules. Still, the risk is not zero. Every aspect of a Drupal application must be considered to ensure there are no security gaps.

Another aspect of taking this path is that much of the time maintaining a site like this is spent managing and mitigating security risks rather than making improvements or implementing new features. For a good many developers, this is not rewarding work. 

In the history of previous Drupal security fixes, some have been pretty small -- one-line changes that take an hour to review and fix -- while others have taken days or even weeks of development time to analyze and produce a solution for. 

An advantage of choosing to upgrade a Drupal 7 site to Drupal 9 is that you gain all of the advantages of security improvements that were included in Drupal 8 and each subsequent feature upgrade. In this blog post, Peter Wolanin of Acquia details some significant security improvements included in the initial Drupal 8 release. Drupal 9 has additional advantages such as support for PHP 8.0.

Integration Risks

Certainly, security risks will come along, but another risk area in maintaining the status quo is that key integrations will eventually start to fail. For example, your Drupal environment may be integrated with another platform, and a key API on that platform is getting deprecated. Because the Drupal module that connects to it is no longer being actively maintained, you (or an agency you hire) will have to update the module or write a new custom module to keep integration working.

Functionality Risks

As the Drupal community continues to diminish the amount of activity on Drupal 7 core and contributed modules, especially after end-of-life, you basically lose those “free” updates. This is especially so with bug fixes. This forces you to either live with them or to fix them, or again, hire an agency to do it. If you do hire someone, that person won’t be as familiar with the project as one of the maintainers would be, so you’d have to factor in that additional investment. Indeed, some of these risks can be so critical that you end up rewriting large chunks of code to deal with them.

Not only do you miss out on the security improvements of Drupal 8/9 discussed above, not upgrading means you're missing out on many other improvements. Drupal 8 and 9 are built around a modern PHP stack including features such as Composer compatibility, Symfony components, modern OOP coding techniques, and more. While Drupal 7 has served our community well, it is not built upon the latest PHP libraries and development workflows that developers expect. This allows Drupal 8/9+ site owners the advantage of further enhancing their security posture by adding the Guardr security distro or module. While Drupal 8 and 9 have good security features, Guardr adds additional community vetted modules and settings which meet industry security requirements.

Talk To Us

As already mentioned, there are too many future unknowns to create a blanket business case for an upgrade investment. However, we can craft a business case specific to you based on the complexity of your existing Drupal 7 solution. We will factor in the number of modules you’re using, their complexity, the nature of your integrations with external systems, and more. 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!

Jun 01 2021
Jun 01

Are you still on Drupal 7 or 8?

All software, even that of Drupal’s top world ranking open source community, comes with a shelf life.

Drupal 7 is now a decade old, with the advent of Drupal 8 falling just four years behind. These previous major Drupal versions weren’t left in the dust with the release of Drupal 9 in the summer of 2020. But that support has an expiration date coming soon. Both versions 7 and 8 have set “End of Life” dates which means they will no longer be supported by the official Drupal community.

Version 9: Drupal in its Prime

Organizations are moving to Drupal 9 to reap the benefits of fresh features and community-supported innovation. The pace of adoption is faster than ever. It took one month to go from 0 to 60,000 sites on Drupal 9 compared to taking 7 months to get 60,000 sites on Drupal 7. Although good progress is being made with organizations moving to Drupal 9, there are still thousands of Drupal 7 and 8 sites live. If you have a Drupal 7 or 8 site, you need to start planning immediately to ensure you are prepared for support ending.

So, what is Drupal 7 and 8 End of Life?

End of Life marks the date when the Drupal community officially stops supporting older versions of Drupal. The Drupal community has always supported the current and previous versions of Drupal but with the launch of Drupal 9 last year and Drupal 10 scheduled for June 2022, “End of Life” is quickly approaching for Drupal 8 and Drupal 7’s days are numbered as well.

key dates for drupal 7 and 8

State of Drupal presentation (April 2021)

It might come as a surprise (and seem a little odd) that Drupal 8’s End of Life occurs before Drupal 7’s. There are a couple reasons behind this. First, the transition from Drupal 8 to Drupal 9 is not a significant effort in most cases. Drupal 9 is not a reinvention of Drupal, with only two key differences; updated dependencies and deprecating APIs. The Drupal Association illustrates the transition from Drupal 8 to 9 as just a station on the same track (versus moving the train to a different track entirely for previous upgrades). The other reason is Drupal 8 is dependent on Symfony 3 and Symfony 3’s end of life is November 2021.

drupal upgrade train track illustration

Source: Understanding How Drupal 9 Was Made, Drupal.org

For Drupal 7, the original end of life was set for November 2021 but due to the impact COVID-19 had on many organizations who are still on Drupal 7, no dependencies on Symfony 3, and the effort needed to upgrade from Drupal 7 to Drupal 9 (requiring a migration and site rebuild), the date was pushed out a year.

How does this impact you?

Drupal is an Open Source project with a uniquely robust security model:

  • Drupal has a dedicated team of Security professionals who proactively review core and contributed modules for vulnerabilities.
  • When a security vulnerability is identified, the Drupal Security Team is notified and code is quickly fixed to remove the vulnerability.
  • When a fix is available an announcement immediately goes out and a patch is released to the community. Drupal sites are also automatically notified that they need to upgrade.

When Drupal 7 and 8 support ends, there will be no more Drupal core updates to Drupal 7 and 8 - even for critical security issues. The contributed modules that power your site will also no longer be actively tested and reviewed, patches and security evaluation will depend on your internal resources.

A recent study indicates that nearly 12 million websites are currently hacked or infected. Ensuring you correctly handle the security implications of Drupal 7 and 8’s End of Life is essential.

What do YOU need to do?

Without taking active steps to protect your website, you are going to be vulnerable to a security breach. Drupal 7 and 8 are widely-used content management systems that have served as a platform for some of the world’s largest websites. It is public knowledge that support for it will be ending. It’s likely that hacking groups are waiting for official support to end to use security exploits that they have already discovered to increase the number of systems they can access before they're patched.

Mitigating this risk is much easier with an experienced partner. We advise our clients to take the following steps:

  1. Ensure your website will be secure after Community Support ends. You can do this by developing an internal plan to monitor future Drupal 7 or 8 security releases, or engaging with your Drupal hosting provider and agency to cover you while you plan and execute the move off of Drupal 7 or 8.
  2. If you’re on Drupal 7 or 8, it’s likely that the time is now for a reassessment of how you use the web. Partnering with an expert Drupal agency like Mediacurrent will help you to reassess your website plans, determine if your Digital Strategy is effective, and ensure your next platform serves your needs now and can adapt in the future.
  3. Once you have identified the correct platform, plan and execute your migration. By taking care of security first, and securing the right partner, you can take the time to correctly plan and build your next Digital Platform in Drupal.

Learn to love the upgrade

While Drupal 7 and 8 End of Life might mean more work for you, we view it as an opportunity. The way we consume information on the web has changed drastically since Drupal 7 and 8 launched, and if you are still on these versions and not planning on innovating, you are likely putting yourself at a serious competitive disadvantage.

In the longer term, sticking with Drupal 7 or 8 not only means you will be fighting a constant battle against security vulnerabilities, but also that you will be doing so with a dwindling number of allies. As time goes on, Drupal 7 and 8 sites will disappear. Fewer agencies will offer any sort of Drupal support for these versions. The talent pool of developers will dry up - anyone who learns Drupal today will be learning on newer releases.

Upgrading from Drupal 7 or 8 to Drupal 9 is the opportunity to revolutionize the way you think about the web as a business tool. If you have a Drupal 7 or 8 site, you have almost certainly had it for at least five years. How many little usability improvements have you considered in that time? Is your design dated? Does your site build reflect modern practices in SEO (Search Engine Optimization), accessibility, and user experience?

With Drupal 9, Upgrading is about more than just security

Out of the box, Drupal 9 offers a significantly more powerful feature set that allows you to build the modern digital experiences you need to compete on today’s web.

At this time, no new features are being added to Drupal 7 or 8. All the innovation is happening in Drupal 9!

Look at Drupal 9’s core features:

All the best of Drupal 8 - Drupal 8 came with many new features such as an improved authoring experience with Layout Builder, an API-first architecture that opens the door to a decoupled CMS, TWIG templating engine for improved design capabilities, and built-in web integrations to name a few. All of these features are carried over to Drupal 9.

Intuitive tools - Improving Drupal’s ease-of-use remains a top priority. Easy out of the box, a new front-end theme, and automatic updates are among the strategic initiatives for Drupal core.

Future upgrades - Upgrades will be seamless for future releases. You will no longer be forced to replatform as new versions are released.

Stay on the edge of innovation - Adopting Drupal 9 will give you access to the latest new feature releases, happening twice a year.

Powerful Distributions - If you’re planning a Drupal 9 project, you don’t have to start with a blank slate. Drupal distributions like Rain CMS can be used as the “starter” for your next Drupal project.

Prepare for an upgrade with a Drupal 9 Audit

Upgrading can certainly come with challenges. As you start planning for an upgrade, a good starting point is performing a readiness audit. An audit assesses the level of effort and provides recommendations for a smooth migration path to Drupal 9.

For more information on our Drupal 9 Readiness Audit, or to start the discussion about transitioning to Drupal 9, 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.

May 25 2021
May 25

open waters podcast logo

Open Waters Podcast: Season 2, Episode 2 

In this episode of the Open Waters Podcast, Donna Wicks, a Web Strategist at Kettering University joins us to discuss web accessibility in higher ed. We explore engaging accessibility-related topics including marketing to prospective students, user experience, accessibility tools and training, and much more.

Episode Transcript 

Shrop: I'd like to thank everybody for joining us again on the Open Waters podcast again. With us today is Donna Wicks from Kettering University. Donna, welcome to the podcast. We're excited for you to be here today. We also have Susan Cooper co-hosting today.

Donna: Thank you. I'm excited to be here.

Susan: I'm excited to talk about accessibility today!

Shrop: Yes, especially accessibility within higher ed. It certainly applies to all of the web but higher ed has its own demands and concerns. It's great to talk to Donna and learn a little bit more about it. For Kettering's site, for example, how important is accessibility when it comes to generating leads?

Donna: It's very important. The pool of applicants is shrinking everywhere. We all know that the number of high school students going on to college has decreased. So now you're talking about needing to really compete for every available body up there. It becomes even more important in today's age when you need to be hyper-focused on every single lead. So we pay attention to the accessibility issues that anyone might have.

Susan: Could schools be turning potential students away by not providing accessible websites? 

Donna: I would think so. For those of us who do the marketing side of websites for schools, we have to be very mindful that we are often that first impression of what a campus might be like. So we really want to pay attention that people can get to the information in a way that makes it as easy as possible for them to get to and in a way that they can consume it. Accessibility is definitely something that could affect their decision of whether to continue to pursue an interest in the university or even come to campus to see what it's like.

Shrop: Has accessibility always been at the forefront of Kettering's goals for a good user experience? If not, what has made accessibility more noticeable in recent years?

Donna: I would say that it's becoming bigger as time goes on. I started in my position in 2012, but prior to that, I had been a system administrator for our learning management system. And of course, accessibility has always been at the forefront with that. So I was mindful of it, but I don't think I was quite aware of all the standards that we should be meeting and all the difficulties somebody might have.

As time goes on, the admission staff, the marketing staff, everyone's becoming more aware of the accessibility issues. It's starting to get some more attention. All visitors to a website benefit when we concentrate on meeting accessibility standards.

Susan: Now that there is more awareness and accessibility is more at the forefront, do you perform routine accessibility audits? How do you know that you're upholding the standards that you're trying to keep?

Donna: Best practices are that we should be doing audits and it is something I strive to do. We're a small university, with a small web team. Some of the things that I do are anytime that I see content being created, whether it's for our marketing sites, that I directly am responsible for a digital ad, or even some of our print pieces. I am constantly pointing out information, as I understand it, that might not meet the accessibility standards that we should be striving for. It's easier to do that sort of education for anyone involved in the process of marketing so that they become aware of where they should be shooting. As they become more educated, I have less to worry about going back and looking, I can begin to set up some of those audits. Maybe check with me next year and I can proudly say, yes, we're doing audits on a regular basis. And we don't have problems that exist longer than 24 hours on the website. We'll continue to strive for it.

Shrop: I'm involved a lot in the security side of web development and we have the same attitude. We want security to be something that everybody thinks about and asks questions about and is always concerned with.

Susan: I think most schools have good intentions to comply with accessibility guidelines. But what are some of the reasons that they may fall behind? What are some of the struggles?

Donna: Well, from my personal experience, the amount of information out there is simply overwhelming. I of course started with just looking up accessibility guidelines. They're out there and they're spelled out in great detail, but it's a matter of trying to figure out what are the important things I should focus on initially. What can I reasonably do? From my perspective, I would love to find a group or start a group of some kind focused on higher ed and what accessibility means for, in particular, the marketing materials that we send out. I think higher ed has done accessibility very well on the learning side. But for reaching out to prospective students, many universities have been doing it, but not necessarily in a standard way. We all sort of pick and choose which standards we want to reach. 

The great thing about higher ed is universities love to collaborate with each other and user groups are a great way to go. People love to share information, and I simply just have not stumbled on it. Maybe it's out there. So if one of the listeners knows and wants to ping me at Kettering, I'd be happy to take a look. But to me, it's the amount of information. I think people look at it and they simply go, whew, I'm not going to worry about it until somebody points a finger and says you can't do that. We have to figure out as a group, how do we do this so that people are proactive about the issues rather than trying to be reactive to either a complaint that's come through or somebody who has noticed something saying thou shall not.

Shrop: It sounds like accessibility is very challenging, especially in a university setting. With that challenge, do you know of any cases where legal action has been taken against the school or lack of accessibility compliance?

Donna: The US Department of Education will randomly select some schools to tell them that they may open an investigation. We ourselves received a notice about a year and a half ago, and then they did follow through with an investigation. That sounds very scary. And it was kind of a long involved process, but the US Department of Education will work very well with you. They meet with you, they go through everything that they found, and that's not just necessarily on one web property. They will look at multiple web properties. If you've got a PDF that you've linked to, they will look at that and run their accessibility tools against it. 

For us, most of the corrections could be taken care of within a matter of days. The problem that I was running into is that the site that I was using at the time really hadn't been developed with an accessibility focus. It had the tools for me there to use, but it wasn't forcing me to use them. And as we all know, we get in a hurry and it's easy to skip that alt tag. It didn't force me to use certain colors, so we would start getting into color contrast issues.

This came at a time when we were working with Mediacurrent to move to and develop a Drupal 8 site. One of the first things we did was create a whole style guide around ensuring that we were going to meet those minimal accessibility standards that everybody should be meeting.

Susan: You mentioned alt tags as low-hanging fruit for accessibility. What are some other simple improvements that higher ed websites should be thinking about making that can really make a big difference in someone's experience using the sites?

Donna: One of the things that anyone should be testing as soon as you've created navigation and or a page, is just to do that simple tab, keyboard, accessibility test. So you're just taking the tab key and tabbing through the page. Color contrast -- that's a no-brainer. Our site was developed with a color palette. I can't stray off that, as much as I might want to! That way, I know if I'm putting text on top of a color, that it will need the highest level of accessibility. Another issue that I've run into is when our marketing department develops images for social media or digital ads where they have taken this wonderful graphic and put all this text in it. I simply won't use it on the website anymore. That text is either too long for an alt tag or there is no reason for the text to be embedded. That’s another win. Don’t use images with words in them. You want to make sure you’re keeping images as clean as possible for every visitor on the site.  

Susan: We have one final question for you that's not necessarily related to accessibility, but it is related to marketing in general. What's something that you think every marketer should read, listen to, or watch this month?

Donna: Besides this podcast? [laughing] For me, one of the things that I have found I've been doing for the past month so I was, I've also been looking at SEO and what we need to do for SEO and stumbled onto Google Trends. It is absolutely fascinating to me to go out every day and see what's been trending on Google for the past day or past week, or what's actually currently trending on Google.

I recommend it highly - anybody who's in marketing should be looking at Google trends. We can't always tell people they should be interested in us; we have to figure out what they're interested in and show how we're relevant to those interests

Shrop: Thanks again so much for your time today, Donna, this is fascinating learning more about accessibility in higher ed. I know Susan and I learned a lot about it.

May 18 2021
May 18

php code on a laptop screen

To keep your organization at the forefront of open source security and innovation now's the time for a Drupal upgrade or migration to Drupal 9. Drupal 7’s end-of-life is November 2022, but if you’re currently on Drupal 8 the end-of-life hits in November 2021.

In this guide, we’ll cover Mediacurrent’s tried and tested approach to upgrading sites of all sizes. Kick-off with a codebase audit. Then, tackle code and compatibility issues. In the final mile, run a first-attempt upgrade to find and fix any remaining issues. And finally, the actual Drupal 9 upgrade.


As you think about your upgrade path (whether moving from Drupal 7 or 8), a good starting point in preparing for Drupal 9 is performing a readiness audit. An audit will assess the level of effort and provide recommendations and preparations for a smooth upgrade or migration path to Drupal 9.

At a high level, a Drupal 9 upgrade process would look like this:

  1. Audit the codebase for deprecated code

  2. Audit the codebase for composer compatibility

  3. Fix deprecated code issues

  4. Fix composer compatibility issues

  5. Attempt Drupal 9 upgrade and see what’s left

  6. Perform actual Drupal 9 upgrade

In the first blog post of this Drupal 9 Upgrade series, I will focus on the first two steps and show you how to audit a codebase for Drupal 9 readiness. By the end, you will have a better understanding of the process and level of effort required for a successful upgrade and be more prepared to estimate a budget and timeline.

Audit for Drupal 9 Readiness

Performing an initial audit on the codebase is straightforward. This process should result in tickets in your task management system of updates to be performed way before the actual Drupal 9 upgrade release date.

Scan for deprecated code

Drupal-check is an invaluable tool for scanning files in a codebase to check their Drupal 9 readiness by looking for deprecated code -- basically code that was previously lingering around in Drupal 8 but is now removed from Drupal 9.

If drupal-check helps you during this process, and I’m sure it will, consider sponsoring the ongoing development and improvements of the project.

Install drupal-check

The most typical way to install drupal-check is to install it as part of the project via composer as a dev requirement. Be sure to review the drupal-check installation documentation.

composer require --dev mglaman/drupal-check

Run drupal-check

The drupal-check command can be run on any single file or directory. These steps assume it was installed in the project with composer, therefore the executable exists in the “vendor” folder and can be run as follows.

Here is an example of running the command against a contributed module that contains some deprecated code issues:

vendor/bin/drupal-check docroot/modules/contrib/allowed_formats

drupal-check error report

Now would be a good time to create a task in your task management system for addressing that deprecated code issue. Thankfully a solution already exists for the Allowed Formats contributed module that fixes this one particular issue.

That issue and fix were found by visiting the module’s project page that you are working on making Drupal 9 ready, search for “drupal 9” in the issue search box, and review what Drupal 9 related issues exist.

Allowed Formats module drupal 9 issue search

There is typically an issue labeled “Drupal 9 Deprecated Code Report”, but it may be named something else, and there may also be multiple related issues.

Allowed Formats module Drupal 9 issue list

Here is another run of drupal-check against another contributed module, which in this case, has no deprecated code issues.

vendor/bin/drupal-check docroot/modules/contrib/crop

drupal-check success report

While it appears at this time that this module is Drupal 9 ready per the drupal-check tests, it may not be completely Drupal 9 ready yet. In the next section, we’ll look at ways to check composer compatibility, which once the module is both composer compatible and no code deprecations present, it will be in great shape for the Drupal 9 upgrade.

Good, but not perfect

The drupal-check tool is very helpful, but it is not perfect. Again, consider sponsoring the project to help continue future development and improvements!

One of the false positives drupal-check may report relates to class usage. For example, it may be validating a class that is used by a module that no longer exists in the codebase, e.g. old code from a Drupal 7 migration that’s no longer used, so there’s nothing to do about that.

Also, sometimes drupal-check does not catch certain issues. For example, the codebase had a custom module that still contained a call to the `path.alias_manager` service, but that service is no longer available in Drupal 9 and was moved to `path_alias.manager`. However, drupal-check did not report this as an issue - I only found out about this issue once the Drupal 9 site was built and I tried to access the page that was controlled by the code that contained that old, removed service class call.

An alternative to drupal-check is to use the contributed module, Upgrade Status, to check on the Drupal 9 readiness of your existing site.

You should now have a good understanding of what custom and contributed packages need work to make them Drupal 9 ready. Be sure to keep notes or skip to the Issue Tracking section below.

Check composer compatibility

In addition to the deprecated code issues, the codebase also needs to be compatible with Drupal 9 from a composer perspective. Without packages being Drupal 9 supported in composer, composer will simply not allow the codebase to upgrade to Drupal 9.

What’s Not D9 Compatible?

A quick test you can do right away is to run this command, which will list all packages that are only supported by Drupal 8. These will need to be updated to also support Drupal 9.

composer why drupal/core | grep -Ev "\^9"

Essentially, this command tells us which other packages depend on Drupal core that do not yet have a 9 version in its composer metadata. Composer will not allow a Drupal 9 upgrade. Read more about the Composer Why command.

The output of the command will look something like the following:

Composer compatibility check results

These values come from the composer.lock file and are basically the list of packages used in the codebase that depend on drupal/core, specifically packages that only work with Drupal 8. This should be pretty much all of the themes, modules, and profiles, unless they have been kept updated on a regular basis and when security releases are available and necessary.

Just to be clear, the first lines that start with “drupal/core” can be ignored, the only ones to focus on are the other lines that reference contributed (or custom) modules.

For instance, in the example above the Facets module has a current version of “1.4.0”, or 8.x-1.4. This module will need to be updated to a later version, or a patch added that makes it Drupal 9 compliant; it might also be worth testing the current dev snapshot, the necessary fixes might have been committed, just not available as a full release yet. It appears for Facets module, the 8.x-1.5 version adds the Drupal 9 support.

Results in this output should be added as new tickets in the ticket management system of packages needing updates to address the deprecated code and composer compatibility issues.

Issue Tracking

To track the status of packages and their Drupal 9 readiness, I recommend creating a spreadsheet that helps track the ongoing upgrade process and what needs to be done. The below is just a small subset of changes needed, but I do recommend having multiple rows per package, in the cases where there may be multiple Drupal.org issues to cover all the D9 related fixes you’ll need.

Without getting too deep into it right now (saving for the next blog post), I’ve seen deprecated code issues be addressed in one Drupal.org issue, and the fix was committed to the latest version. But simply updating to the latest version did not make it Drupal 9 ready, because there were still composer compatibility fixes, and in some more rare cases, even still some deprecated code issues that were missed in the first pass. So, those issues may be split among multiple issues on Drupal.org.

Tracking Drupal 9 issues in spreadsheet

This planning, tracking, and documentation will help you as you continue through the Drupal 9 Upgrade process and keep tabs on what is remaining along the way. It may also serve as a good starting point or baseline for the next Drupal 9 upgrade process you may be involved in.


This blog post focused on the up-front audit process and preparation work required to understand the amount of work required to get into Drupal 9 readiness status. In the next blog post in this Drupal 9 Upgrade series, we will work on fixing the deprecated code and composer compatibility issues we discovered and documented as a result of this audit process.

Mediacurrent is a top 10 contributor on Drupal.org and has created solutions to accelerate, ease, and enhance the upgrade process. We can help you prepare for a Drupal 9 upgrade. Reach out anytime if you want to discuss your Drupal upgrade path or are interested in our team performing a Drupal 9 audit on your site and how we can help you succeed.

May 14 2021
May 14

When you are used to working in Drupal 8 and beyond, having to make changes to custom Drupal 7 code can be unpleasant. If you’re lucky, the code was well written and maintained and you can make your changes without feeling like you’re adding to a house of cards. Too often, though, the code is in a state where it could really use refactoring.

One of the many nice changes Drupal 8 brought about was changing most of the code over to object-oriented programming, or OOP. There are many benefits to this and one of them is that it organizes most of the code into classes. In Drupal 7, all that code was dumped into the .module files because that’s how things were done back then. But it doesn’t need to be that way.

Why Add OOP?

Drupal 7 may not have the OOP framework that Drupal 8 built, and you still need the hooks, but there are benefits to adding OOP to your refactor:

  • Upgrades - It gets your custom code closer to Drupal 8/9. If there is any thought of an upgrade in the site’s future, having the custom modules as close to Drupal 8/9 as possible will make that upgrade easier.
  • Clean Code - It makes your Drupal 7 code cleaner and easier to maintain. Even if an upgrade is a long way off, having clean and organized code is much easier to maintain and reduces the chance of knocking down that house of cards when you need to make a change.
  • Easier Refactoring - It makes refactoring easier because you can work on a copy of the code that is moved to a new place rather than trying to do everything in place. As you move and refactor each function, you can easily see what code is refactored and what is still the old code.
  • Testing - It makes it easier to test your refactored code. There’s more on that in the “Testing the refactoring” section below. If you are following along with this blog post and making changes to your module as you go, you’ll want to read that section before you start.

An Example Module

For the purpose of examples, let’s say we are refactoring a custom module called XYZ Events. Our site is for company XYZ and this module is where we stored all the custom functionality related to our events.

This module has custom menu items, blocks, and a bunch of miscellaneous helper functions all sitting in the .module file and we want to clean that up.

I’ll reference this fictional module to provide examples along the way.

Make class loading simple

To make using classes much easier, start with a very handy contributed module: X Autoload. X Autoload lets you make use of the automagic class loading that Drupal 8 has just by putting your classes in the proper directories and setting the namespace. With that in place, you are ready to start moving your code into classes.

Whenever you add a new class, be sure to clear the cache before you try to use it.

Services for all the miscellaneous functions

While hooks and a few other things need to stay in the .module file, chances are there are a lot of miscellaneous functions that can be organized into one or more service classes. These won’t be true D8/9 services with the service.yml and all of that but they serve the same purpose. In theory, you could write your own service container if you wanted to push this even further but even just regular classes help.

Make the events service:

  • Add the directory “src” to the root of the xyz_events directory.
  • In there, add EventsService.php. It’s not required to have “Service” in the name but it helps make the purpose clear.
  • The basic outline of the class looks like this:

Move the code:

For each of the non-hook, non-callback functions in the .module file (and .inc files), copy it into the appropriate class. Some functions might make more sense in a site-wide utility class if they aren’t directly related to the module’s “theme”. Once it’s in its new home, do the cleanup and refactoring:

  • Change the function names to camel case and remove the module name (ie: xyz_events_get_event_list() becomes getEventList())
  • Add the public, protected, or private designation to the front. Since these used to be in a .module file, most of them are likely to be public. But, if any functions are only used by other functions that are now in the same class, those could be changed to protected or private.
  • Now is a good time to clean up any coding standards issues. I like to use Drupal 8/9’s standards if I know I’m on a PHP version that supports it such as using short array syntax. This gets it as close to D8/9 as possible.
  • Do whatever refactoring is needed to make the code easier to follow, improve performance, fix bugs, etc.

Update calls:

Using grep, check your whole site to find out all the places where that function was being called. For any place it’s being called that isn’t already in the class, change the call from the old function to the new method:

  • Add $events_service = new EventsService(); if that isn’t already in scope.
  • Change xyz_events_get_event_list() to $events_service->getEventList()

If the call is within the class already, change it to use “$this” instead of the service reference variable:

  • xyz_events_get_event_list() to $this->getEventList()

You now have all the miscellaneous custom code in a service (or multiple services if it makes sense to divvy them up). When moving to Drupal 8/9, all that’s needed is to update the class so that it’s a proper service container service and then change the calls to go through the container rather than using “new SomeClass()”.

Block classes

Drupal 8 introduced blocks as classes which is much cleaner than the old style that used multiple hooks. If you have multiple custom blocks each with a chunk of code, hook_block_view() can get quite long and hard to follow. While the hooks themselves are still needed, the actual code can be split off into classes. hook_block_info() stays the same but hook_block_view() becomes much simpler. 

  • If you haven’t already, add a directory “src” at the root of the module directory.
  • In “src” add a directory structure “Plugin/Block”.
  • For each block in hook_block_view():
    • Add a file in “Block” that is BlockNameBlock.php. Like services, the “Block” at the end isn’t required but makes it clearer what the class does. For our example module, we end up with UpcomingEventsBlock.php and FeaturedEventsBlock.php.
    • Take all the code for generating that block out of the hook and put it in the class.
    • Replace the content in the hook with a call to the class.
  • If your blocks have a lot of similar functionality, you can take advantage of inheritance and move the common functionality into a base block. In our case, since both blocks are listing events, we add EventListingBlockBase.php.

In the .module file we have:

 * Implements hook_block_info().
function xyz_events_block_info() {
  $blocks = [];

  $blocks['upcoming'] = [
    'info' => t('Show upcoming events'),

  $blocks['featured'] = [
    'info' => t('Show featured events'),

  return $blocks;

 * Implements hook_block_view().
function xyz_events_block_view($delta = '') {
  $block = [];

  switch ($delta) {
    case 'upcoming':
      $block_object = new UpcomingEventsBlock();
      $block = $block_object->build();

    case 'featured':
      $block_object = new FeaturedEventsBlock();
      $block = $block_object->build();

  return $block;

And then our blocks:


EventsService = new EventsService();

   * Builds the content for the block.
  abstract public function build();
   * Format the content into the array needed for the block.
   * @param string $title
   *   The block title.
   * @param array $items
   *   The complete list of items.
   * @param string $empty
   *   The text to print if there are no items.
   * @param string $theme_hook
   *   The theme hook for the block content.
   * @return array
   *   The block content array.
  protected function formatContent(string $title, array $items, string $empty, string $theme_hook) {
    // Only keep the empty text if there are no items.
    $empty = (count($items) == 0) ? $empty : '';

    $variables = [
      'items' => $items,
      'empty' => $empty,

    $content = [
      'subject' => $title,
      'content' => theme($theme_hook, $variables),

    return $content;


UpcomingEventsBlock.php and FeaturedEventsBlock.php both use the following code, just altering the “upcoming” to “featured” as appropriate.


    // What it should print if there aren't any.
    $empty = t('There are no upcoming events.');

    // The theme hook to use to format the contents of the block.
    $theme_hook = 'xyz_events_upcoming_events';

    return $this->formatContent($title, $items, $empty, $theme_hook);


Now all the content for building each block is encapsulated in the class for that block. When moving to Drupal 8/9, add the block annotation that it uses to identify blocks and remove the block-related hooks from the .module file.

If your blocks need configuration, this can be taken a step further by adding the form code and save code as methods on the block class and then referencing those from hook_block_configure() and hook_block_save().

Menu items to controllers

While hook_menu itself usually doesn’t get too overwhelming due to the actual code for the menu items being in separate functions, it does contribute to the .module file bloat. It’s also a lot nicer to have the menu items be in individual controllers like in Drupal 8/9.

To make this happen:

  • If you haven’t already, add a “src” directory at the root of your module.
  • Add a “Controller” directory under that.
  • For each menu item, add a file in there that is SomeController.php. Like services, “Controller” isn’t required but it makes it clearer. Another option is to use “Page” if the item corresponds to a viewable page rather than an API callback. For our example module, we end up with “UpcomingEventsController.php” and “FeaturedEventsController.php”.
  • As with blocks, a base controller can be used if the controllers have similar code.
  • Replace the hook code with a reference to the class (explained below).

There are two ways that the hook_menu() code can reference your class. Using a static function on the class and calling it directly or using a wrapper function to call the object.

Static method:

  • In hook_menu:
    'page callback' => 'UpcomingEventsController::build',
  • The build method on the class needs to be static.

Wrapper method:

  • In hook_menu:
    'page callback' => 'xyz_events_controller_callback',
    'page arguments' => ['controller_class' => 'UpcomingEventsCoursesPage'],
  • function xyz_events_controller_callback() needs to be in the .module file. (see below)
  • The build method on the class does not need to be static as we are instantiating an object.

In the .module file:

 * Implements hook_menu().
function xyz_events_menu() {
  $items = [];

  $items['events/upcoming'] = [
    'title' => 'Upcoming events',
    'page callback' => 'xyz_events_controller_callback',
    'page arguments' => ['controller_class' => 'UpcomingEventsController'],
    'type' => MENU_NORMAL_ITEM,

  $items['events/featured'] = [
    'title' => 'Featured events',
    'page callback' => 'xyz_events_controller_callback',
    'page arguments' => ['controller_class' => 'FeaturedEventsController'],
    'type' => MENU_NORMAL_ITEM,

  return $items;

 * Menu callback that wraps the controllers.
function xyz_events_controller_callback($controller_class) {
  $controller_class = "\\Drupal\\xyz_events\\Controller\\$controller_class";
  $controller = new $controller_class();
  return $controller->build();

The classes:


eventsService = new EventsService();

   * Builds the content for the page.
  abstract public function build();

UpcomingEventsController.php and FeaturedEventsController.php have the same code with “upcoming” changed to “featured” as needed.


    $content = theme('xyz_events_upcoming_events', ['items' => $items]);
    return ['#markup' => $content];


The rest of the hooks

While Drupal 7 relies on a lot of hooks and these need to be in a .module or .inc file so they can be found, there’s nothing requiring the actual code for the hooks to live in the functions. Like we did with blocks and menu items, the hook functions can serve as a wrapper around a call to a class where the actual code lives.

Testing the refactoring

While writing actual tests is the best way to test, that isn’t always possible with time and budget considerations. Still, you want to be sure your refactored code gets you the same results as the old code. Moving functions into classes while refactoring helps with that.

  • Add an include file to the root of the module. Ex: xyz_events_replaced_functions.inc
  • At the top of the .module file, add include_once 'xyz_events_replaced_functions.inc';
  • As you move functions into the classes, copy them into this file instead of deleting them from the .module file.

This keeps all the old functions active at the same time as the new ones which lets you test them in parallel within the same site.

Add this to the top of the module file:

 * Implements hook_menu().
function xyz_events_menu() {
  // Adds a testing page for dev use.
  $items['admin/code-test'] = array(
    'access arguments'  => array('administer content'),
    'description'       => 'Place to test code.',
    'page callback'     => xyz_events_test_code',
    'title'             => 'Code testing',

  return $items;

 * Place to put test code that is called from admin/code-test.
function xyz_events_test_code() {
  print("Test completed.");

Within xyz_events_test_code() you can do something like this:

Within xyz_events_test_code() you can do something like this:

$events_service = new EventsService();
$old_list = xyz_events_get_event_list();
$new_list = $events_service->getEventList();

Set a breakpoint at the top of the function and then visit /admin/code-test on the site. You can then step through and compare what you get running the original function vs running your refactored function and make sure the result is either the same or has any differences that you intended with the refactor.

Once you have finished and are ready to commit your refactor, delete the include file, the include line, and the testing code.

Wrapping up

At this point, your .module file should be much smaller, consisting of just hooks and things like callback functions that can’t be moved into a class. Your directory structure should look a lot like a Drupal 8/9 module with all the code wrapped up into classes. There will still be work needed to move to Drupal 8/9 in dealing with the API changes but the actual structure of the code and where things are found shouldn’t need much changing. And maintaining the Drupal 7 code until that time should be a much more pleasant experience.

Further reference

This blog post came from actual client work but that work was inspired by others. These two were my biggest sources for reference:

I didn't get into forms above but here's an article that covers them: https://roomify.us/blog/object-oriented-forms-in-drupal-7/

May 05 2021
May 05

Selecting a CMS for a university can be a challenging decision. There are so many needs and nuances to consider - costs of implementation and maintenance, a wide range of technical ability among site administrators, developers, and content editors, a variety of end-users looking for different information...and the list goes on and on. While your answer likely isn’t as easy as, “let’s just do what everyone else is doing,” better understanding why other universities made the choice they did can shed light on your decision-making process. 

Drupal is far and above the most used CMS in higher education - 26% of all .edu domain sites are in Drupal, including 71 of the top 100 universities. 

So why are universities like MIT, Georgia Tech, Butler, Stanford, Harvard and the rest of the Ivy League universities choosing Drupal? 

Simply put, Drupal makes good business sense, especially with the added benefits of Drupal 9. At Mediacurrent, we believe your website is your greatest digital asset and can be leveraged to accomplish organizational-wide goals. Drupal makes that possible. Here’s how:  

Communicate With All Students - Prospective, Current, and Alumni 

If you want to reach your full recruiting and fundraising potential, you need to communicate with your entire audience. There are a variety of Drupal features that ease the stress of common communication challenges. 


Not only are their multiple languages spoken within the U.S., but our country hosts over a million international students. Drupal makes creating a multilingual digital experience simpler. Native language handling is built directly into Drupal 8 and 9 core APIs, giving you over 100 languages to choose from. With that functionality, it is easier than ever to engage with prospective students across the globe in a meaningful way.


The CDC estimates that 20% of U.S. adults identify as having a disability. These disabilities often hinder people’s ability to interact with the average website. Drupal is an inclusive community and has committed to ensuring that all features of Drupal conform with w3C and WCAG 2.0. Pair Drupal’s built-in accessibility tools with a strong higher-education-focused accessibility strategy and your potential audience could grow by 20%. The Siteimprove Drupal module can help you keep a close and proactive eye on your overall web accessibility. 


 According to the College Explorer Market Research Study, the average college student owns 5.6 devices and spends 137+ hours on them! This may seem like common sense now, but if you want to engage with students, you need to account for a variety of screen sizes. Thankfully, Drupal 8 was designed with a mobile-first mentality and includes out-of-the-box responsive functionality.  And that mobile mindset continues with Drupal 9. Features like editorial workflows, Layout Builder, and media management can support content delivery that is optimized for mobile access.  


 Universities face added complexity when it comes to digital strategy due to the broad audiences they appeal to. With so many unique people coming to the same pages, content strategy, conversion path mapping, and optimization, and defining strong calls to action can be a struggle. By incorporating personalization into your content strategy, whether that is personalized based on user authentication or by integrating tools like Acquia Personalization or Salesforce Marketing Cloud, you can speak to the masses but make them feel like you’re speaking specifically to them. 

Reduce Overhead Costs + Increase Operational Efficiencies with Drupal

Drupal can have a dramatic impact on reducing overhead costs and increasing operational efficiency. Universities have a big need for multiple websites: departments, colleges, libraries, and student organizations all want their own website. The direct cost of supporting this many sites along with resourcing the training and support is expensive and encourages unnecessary technology sprawl. As an open source technology (no licensing fees!) along with the multisite feature, creating sites for these different groups is exponentially easier, more cost-effective, and ensures brand consistency. 

You can also increase efficiency, ensure content consistency and improve the user experience by creating a “source of truth”.

Write content once and publish it anywhere it’s relevant.

Having to update content such as a curriculum or an academic calendar on multiple pages is inefficient and unnecessary. Write once, publish everywhere, save time. 

Improve Brand Equity + Amplify Digital Strategy

As a university, your brand is a powerful asset. You spend significant energy and resources on building loyalty to bolster several organizational goals from recruiting efforts, engaging current students on campus, and fundraising among alumni.

With your website being the hub of your marketing strategy, it is critical for your CMS of choice to play nice with your marketing efforts.

Drupal is very SEO-friendly out of the box. There are also advanced configuration options available to support a more sophisticated SEO strategy. You can amplify your digital strategy by integrating your marketing tools and communication platforms directly with Drupal. And the 26% percent of other .edu sites using Drupal make integrating your university-specific tools to your website easier. 

Reduce Risk

I’d be remiss without mentioning open source security and GDPR compliance. As a university, you hold sensitive information about the students who have attended your school and they are trusting you to keep that secure.

The Drupal community is passionate about security and has an industry leading global security team to ensure your site is protected.

Additionally, as the landscape of privacy rights changes around the world, it’s in your best interest to stay on top of it and reduce the risk of being penalized for data collection practices. 

Speed up Your Time to Launch 

RainU logo

Drupal has a lot to offer to universities from the moment of install. We created RainU CMS to bring that out-of-box experience to the next level with a tailored approach. RainU is Drupal-based development platform that helps colleges and universities accelerate the web development process. 

Have questions about how Drupal and RainU can benefit your university? Let us know. We’d be happy to chat. 

Editor’s note: This post was originally published on July 18, 2018, and has been updated for accuracy and comprehensiveness.

Apr 28 2021
Apr 28

open waters podcast logo

Open Waters: Season 2, Episode 1 

Welcome to season two of Mediacurrent's Open Waters podcast! In this episode, we welcome Sheree and John G from our creative team. If you are a marketer, designer, or tech lead in the higher ed space, this episode is for you.

Episode Transcript 

Susan Cooper: Welcome to season two of Mediacurrent's Open Waters podcast! Mario Hernandez and Mark Shropshire will be coming to you each month to explore the intersection of open source technology and digital marketing. In today's episode, we'll be speaking with Sheree Hill, Creative Director at Mediacurrent, and John G, Digital Designer at Mediacurrent. Both have been doing extensive work in higher education - building design systems, addressing pain points of scale and velocity, and bringing brand stories to life.


Susan Cooper: We will explore some of the challenges facing marketers and designers in higher ed, touch on learning modalities, and how they function in web and marketing teams, as well as some quick and easy tips to help sharpen your school's brand strategy and maximize some production workflows. If you are a marketer, designer, or tech lead for higher ed, this episode is for you.

Susan Cooper: Glad to have you here. Can you tell us about yourself? What are your roles?

Sheree Hill: I'm Sheree Hill and I am the Creative Director here at Mediacurrent. For those of you who might not be familiar with what creative directors do... We work with awesome designers like John and some of our UX and UI designers to help bring creative visions to life. We help to establish colors and themes and really design brand experiences that are memorable and connect to audiences.

John G: I'm a Digital Designer here at Mediacurrent. I work directly with Sheree to produce branded elements, both in house and for clients.

Challenges in Higher Ed Web Design 

Mario Hernandez: Great. Well, thanks for being here, both of you, we really enjoy and appreciate you taking the time to join us. The first question that I have, I know there's always challenges when it comes to design or working on that project, but can you give us a little bit of information about some of the challenges that our client's face, especially higher education clients, when it comes to design?

Sheree Hill: Right now clients in higher ed are really facing challenges when it comes to pivoting from what's happened with COVID and building coursework that connects with students online. There are different audiences in higher ed and different challenges with those audiences. For example, for the content authors or for the marketer, there are certain challenges that they have in producing content, as well as reaching leads and reaching students versus a faculty member who might be wanting to share some of the knowledge that they're building and to find the best students, their programming. Some of the other challenges that are faced are really looking at creating consistent experiences across different channels. And that's something that John and I have been able to work with on a few different clients. 

Sheree Hill: John, do you want to talk a little bit about how the design debt is managed for schools?

John G: Yeah, absolutely. So design debt is a pretty big problem with a lot of education facilities starting from the top all the way to the bottom. Everybody needs different branded content, you know, emails, papers, that sort of thing, and trying to keep everything consistent so that you've got a brand that everybody recognizes and understands is pivotal.

Sheree Hill: And then when you think about producing content, this is something that everyone in digital, every brand faces today, and that's content production. Back in the day schools or universities or different brands would have a designer on staff and they would produce an annual report or there would be flyers that would be produced. That's not how it is today. Today, the cadence is that on social media, there are daily postings on different websites. We really need to look at how schools can scale and how is work produced across teams? Because marketers aren't the only ones that are producing content. Brand ambassadors at schools, teachers, students, they're all producing content that helped the schools reach new prospects and help to build the school's reputation. So it's important that any brand has the tools that they need to be able to create consistent brand experiences across channels.

Branding Strategies

Mario Hernandez: As a follow-up, let me ask you, how does your team work on addressing these challenges that you just outlined?

John G: One of the first things that we do in order to establish that brand is we have brand workshops that inform all of our design decisions and asset production. And then we develop that into an entire brand guide that helps kind of, kind of reduce that design debt and keep everybody consistent. So they've all got that same page to follow.

Sheree Hill: When you think about the voice and the personality of your brand, every brand sounds different. When you think about Harvard, for instance, the institution is very traditional. It has a lot of legacy and a lot of history that it's rooted in and its mission and vision is going to be different than a modern art school like RISD (Rhode Island School of Design). It's important to understand what a voice sounds like. And we can explore that through the brand workshop that John just mentioned, and we do that through design thinking and what's great about design thinking is everyone has a voice. So because of COVID, as we mentioned earlier, we're able to do these virtually and we do virtual brand workshops in Mural, and everyone uses different sticky notes, just like if we were in a classroom doing it together and we can gather those findings and then distill it into the brand strategy.

Sheree Hill: And those guidelines define everything from how the logo looks to how the brand sounds to all of the different distinct brand elements. So the different designs, the actual grid, the typography, all the things that you see in different design elements are defined in the brand guide.

Creating Design Systems 

Susan Cooper: Awesome. So tell us a little bit more about designing for higher ed.

Sheree Hill: One of the things that's unique in service-based design is that we're creating a service and a system, right? So that's different from product design that reaches the consumer. Amazon, when you think about a business to consumer it's different challenges. In services, and we're looking at providing a service to schools, providing education as a service. But we also productize it and by creating digital products like component-based design. As we define the system and the design system and all of the elements we call it atomizing the design system, right? We're not really building so much on templates anymore. We're really creating those key elements that are used throughout the system. When you think about challenges like scale or velocity, and being able to produce that content quickly and have the teams produce the thought leadership and the content, we create the systems that allow the team members to do that. 

Sheree Hill: John, do you want to talk a little bit about the challenges that you've seen in producing and working with higher ed institutions?

John G: I think the two main challenges that I've seen are first off content migration. And so with educational systems, we've got hundreds of pages of content. We've got blogs, we've got books, eBooks, we've got all of these different classes and classwork. And along with that comes the second challenge, which is division of labor. And so in order to get all of that content migrated, we have to work directly with the school's team. And we also have to build out a team of internal people to kind of work up a system, to get all of that content moved in an orderly fashion. And so one of the things that really helps with that is component based design so that we can drag and drop. So that it's easy for, for everybody, not just developers, but people on their team to help us with that lift. That's great.

Collaboration Tools 

Mario Hernandez: You mentioned that nowadays there are a lot more people involved in the content creation process. What are some of the tools that can help marketing teams in their productivity?

John G: Cloud collaboration for starters, cloud collaboration is extremely important these days. So one of the things that we did for an online college is we developed these Google doc templates for their eBooks, for their internal communication, for their external communication, so that they have this kind of rigid structure based on their brand guidelines that everybody can modify, not just people with Adobe cloud software, but also people on the ground level.

Sheree Hill: And hand in hand with that, one of the things we think about, cause we have training here at Mediacurrent when we build Drupal systems, but we also create processes for cloud collaboration. For example, one of the things that we found here in our brand, our own brand evolution moving from one brand to another is that there is a level of effort when it comes to obtaining documents. A cool hack that John discovered is a methodology to update different brand elements to the new brand. And so we've captured those findings from what we've learned and we create recreated processes that we can share with marketing departments and with schools so that it's a lot faster and easier to update those documents. Historically it has taken hundreds of hours. It can take hundreds of hours to update on old brands, to new brands when there are different flyers and documents. And it's not just letterhead anymore. When you think about schools there's so much information and content that’s shared that has to be updated. We've worked to build those processes that are quick, easy, and efficient.

John G: And alongside that with cloud collaboration in mind, we have also found ourselves using Canva an awful lot. I mean, like I said, not everybody has access to Adobe cloud software and Canva really helps people keep digital graphics consistent. We've got graphics for email graphics for social media, we've got animated graphics. And if you use the brand guide to build out a brand, a kit in Canva, you can kind of establish these parameters that makes it a lot easier for people to follow and also helps reduce that design debt.

Sheree Hill: One of the things that we talk about here is does it pass the litmus test? How can you tell your content from another school's content? It's so important any time there is a brand moment like there's a moment that you are speaking or reaching out to a prospective student, that's called an impression you're making an impression of who you are as an institution and the value that you can add to their life. It's important that your brand stands apart and has those different elements of identification so that you're easily recognizable.

Branding with Purpose 

Susan Cooper: Many marketers and brands these days are placing higher importance on mission and values. Why is that important for higher ed and how do they apply that to a design system?

Sheree Hill: Absolutely. As a brand, any brand, your mission is your guiding light. It's why you get up in the morning. It's really why you do what you do and your mission will help to inform how you make decisions. There are so many different points of decisions for brands and organizations and team members. And the vision really helps us keep the story. The mission really helps us keep aligned in that and the vision is how you do it. When you think about what that looks like the vision is really how that would look in the future. So when we think about how that informs the design system, we think about how it feels, right? Because the design system really has a lot to do with emotion. 

Sheree Hill: For example, when we were working with Emory Goizueta Business School, their vision is really about preparing principal leaders and they're known for being rigorous. When we created the design system, we selected and created images that reflected passion and discipline, and collaboration, which are all characteristics that are representative of principal leadership. And we carry that throughout the design system. And then when we think about the different shapes, we used different angles that were pointed upwards that were inspirational and driving, and motivating. That really helps to tell the brand story without using words, it's an energy, it's an emotion of how you connect with the audience.

Mario Hernandez: You know, I had the pleasure of working on that project. And it was a very challenging project from a design and development point of view. But I, at the end of the day looking at the end product of the project, I really thank you for pushing us because that was something that really pushed our team and, you know, it was challenging, but at the end of the day, it just, it made us so much better. That project came out really nice. And I was very happy with the decisions that you made from a design point of view there. So how, how do schools build that brand story as a service organization? How is that brought to life?

Sheree Hill: Absolutely. That's a great question. What we do when we look at the brand story is we examine the different facets of the value system of the school. Schools all have a value system that helps you inform your brand strategy. We look at all of those different pieces and we build out a complete brand strategy and that brand strategy, we look at different personality values and those different personality values. 

Sheree Hill: We have a workshop where we place images with those different values and we create a mood board and that mood board is then shared with the team and we get feedback. And that's something that John was able to work with an online college on and really help create a unique design system for them that doesn't look like any other school that I've seen. John, do you want to talk a little bit about that process and what that looked like?

John G: Once we put the mood board together, we can start using their mission and vision to kind of inspire the visualization of developing design elements and bring that across the entire system. For example, right now we're working on a campaign for DrupalCon and we've got this system that's based entirely around open source and open source expansion. And so we're creating visuals that kind of follow along with that mission and expanding on the expansion element of it.

Sheree Hill: Some of the visuals that John selected have outer space and rocket ships, and really the idea of going where people haven't gone before because that's really what open source is, right? It's us collectively exploring and building new frontiers together. We're able to harness the excitement of that and just use these beautiful visuals of space that light the imagination to inform the design system for the event campaign. So that's everything from a virtual booth to different media types to ad placements, to email campaigns all of the different parts of the system.

Open Source Design 

Mario Hernandez: So Mediacurrent is pretty big. It sets up, you know, we set ourselves apart because we have a huge commitment to the open source community and giving back to the community. Are there any tools that your team has either put together or found that you would with the community that can help other organizations implement the systems that you have?

Sheree Hill: Well, yes, we do. In fact, from the project that we worked on together, we built out the Rain CMS component matrix template from Emory Goizueta together. So that's something that we have created into a tool that we've designed into a tool. We can share that with anyone that's listening to the podcast. And then the other piece is the brand strategy guide. We have that as a template as well. We'd be happy to share that with the community. [Author’s note: These resources are linked at the end of the post!]

Book Recs for Higher Ed Marketers 

Susan Cooper: I bet that'll be really useful for folks. So what's something that every marketer should read, watch or listen to. This is a question for both of you.

John G: Right now, one of the things that I'm really big into reading about is a book called What's Your Enneatype, which is an essential guide to the Enneagram. I've been reading an awful lot about personality typing and more importantly, how you can market to different kinds of personality types to really improve that follow-through. And I think that's something that's absolutely important for marketers is just learning as much as you can about personality types, learning how you can market to those people. There are so many different books and so many different methods of thought on each of those topics. It doesn't have to be Enneagrams. There's Myers-Briggs, there are all of the other different types, and none of it is an exact science, but it's something that'll put you on the right path.

Sheree Hill: It comes down to relationships, right? Sales and marketing are all about relationships. And it's about understanding who we are as people. And it's understanding how someone else thinks and really having empathy. I also read the Enneagram. It's something that I believe in, it's not just right for marketers to sell, but also to work in teams. It's something that John and I have worked on together, understanding who we are and, and how to work together, and how to motivate and collaborate. So it's great, not just for sales, but also for teamwork. 

Sheree Hill: The other piece that I would say to that, and that's something that we're doing as a team is the CXL coursework in digital psychology and persuasion. And what it is is it's a psychological framework to improve our different platforms like our websites. And it teaches us how to understand behavior as well and influence purchase patterns. So why that's important is because if we can understand behavior, then we can influence and we can help our clients meet their goals.

Susan Cooper: It's incremental, right? With behavior change. You can't have people completely change the way they go about their day or the way they approach something. It's, it's incremental. You can change one thing at a time to get them where you want them to go and not in a manipulative way, but in a way that is helping guide their experience.

Sheree Hill: Absolutely. Yeah. We call it nudging and we just about how can, how can we influence them? And, and that's really where that mission and vision comes to play as well. Because if we have a mission and a vision that is looking to change the world for good and looking to change people and help them grow, then that's incremental and we can help people reach the best version of who they are.

See you next time!

Susan Cooper: Well, thank you so much for joining us today. I'm excited to have you all on our first episode of the second season.

Mario Hernandez: That was a lot of great information guys. We look forward to making this available to our listeners.

Susan Cooper: You can find us at mediacurrent.com and subscribe on your favorite podcast app. If you liked this episode, share it with your friends and tag @ mediacurrent on Twitter.


Apr 22 2021
Apr 22

As DrupalCon comes to a close for the crew at Mediacurrent, we’ve all had a chance to reflect on the experience. Here are the top 10 things we loved and learned at this year’s event.

1. Opening New Doors to ‘Discover Drupal’

Drupal talent is in high demand and The Drupal Association is focused on cultivating that talent with an emphasis on diversity, equity, and inclusion. That’s important to our team at Mediacurrent, too. We love helping young professionals get started in a Drupal career (like our two student interns who experienced their first-ever DrupalCon last week!) and we jumped at the chance to become a training partner for the just-launched Discover Drupal program. We will be mentoring students and providing an opportunity to intern with us after they have finished their scholarship.

Discover Drupal offers a 12-month scholarship and training program for underrepresented individuals in the open source community. Learn more and support the program

Speaking of training, our booth offer this year was a drawing for a free 4-hour training workshop in one of our most popular topics: Front-End Development, Decoupled Drupal with Gatsby, or Drupal Component-Based Theming. We are very excited to be drawing the names of 3 winners this week, who will learn about current technology demands and best practices using active discussion and a hands-on workshop. Watch our Twitter channel to see who wins!

2. Bright Horizons Ahead for Drupal 10 

Dries reinforced that the sun is quickly setting on Drupal 8, with community support ending this fall. Drupal 7’s days are numbered as well. If you haven’t already, it’s time to think about your Drupal 9 action plan.

Key dates for Drupal 7 and 8

The community’s innovation efforts will focus on Drupal 9 while also looking ahead to June 2022 — the target release date for Drupal 10.

Drupal 9 and 10 timeline

3. Going Back to Our Site Builder Roots

Drupal’s roots are about empowering site builders to build ambitious websites with low code. 

-Dries Buytaert, State of Drupal Keynote - DrupalCon North America 2021

What made YOU fall in love with Drupal? 

In his State of Drupal keynote, Dries reflected on Drupal’s core strength to find focus for the year ahead. He reasoned that to help our community grow and become even more successful, we need to give every user a clear reason to adopt Drupal. 

Many Drupal love stories share a common spark; the feeling of being quickly empowered by Drupal’s low code approach. To give site builders that “love at first site” feeling, Dries announced the Project Browser Initiative. That goal is to make site builder basics like installing a module as easy as installing an iPhone app and rise to the competition of Wix, Squarespace, and WordPress. 

Drupal program browser initiative

4. Building a Better Foundation for Future Features

Everyone wants to know what comes next for our favorite digital experience platform. As always, DrupalCon sessions and the Driesnote shed some light on the innovation that lies ahead, highlighting both core and contrib initiatives that the community is working to advance.

Visitors to the Mediacurrent booth saw how Rain CMS speeds up development and gives content creators the authoring experience they crave. (If you missed it, Rain CMS now ships with Layout Builder to make page building a breeze) 

Dries shared a progress update on the core strategic initiatives that are blazing trails for future functionality and improvements in Drupal core. These initiatives shaped the program content, with a different one assigned to each day of the conference. 

  • Easy Out of the Box - This initiative is improving Drupal's ease-of-use remains a top priority.
  • Decoupled Menus - This initiative is positioning Drupal as the go-to for decoupled. Now, non-module Javascript projects have a home on Drupal.org.
  • Automatic Updates - By getting automated security updates into Drupal 9 core, we can help site owners sleep soundly.
  • Drupal 10 Readiness - Drupal 9 is just under a year old but the community is already looking ahead. Dries called for community support to hit the target release date for Drupal 10.

5. Celebrating and Encouraging Community Contributions 

Drupal continues to shine as of the most scalable, robust, and mature development communities in open source. We heard from Heather Rocker, Global Executive Director of the Drupal Association, about some of the initiatives that are making it easier for first-time and non-coding contributors to get involved.

Both individual and company-level contributors were celebrated on the DrupalCon stage. Congratulations are in order for AmyJune Hineline, the recipient of this year’s Aaron Winborn Award. The award honors individuals for their outstanding commitment to the Drupal project and community. (Check out our interview with AmyJune from season one of the Open Waters podcast.) 

Giving back to Drupal remains a core priority for the Mediacurrent team. This year, we’re proud to show our support for the Drupal Association as a Diamond Drupal Certified Partner and excited to maintain our rank as one of the top five organizational contributors. 

top companies sponsoring Drupal

6. The More Sites, The Merrier

How do you manage and maintain dozens or even hundreds of sites effectively?

That’s the question Jay Callicott, VP of Operations at Mediacurrent, set out to answer in his DevOps track session on scaling Drupal with the power of multisite. Drupal’s multisite capabilities are a standout feature, setting it apart from other CMS platforms. Yet there’s a lot to consider - configuration, deployments, site provisioning, and more. 

This session recording is now available to registered attendees with public access coming in a few weeks. Stay tuned!

Drupal multisite presentation slide shows a decision tree

7. Making Sense of Open Source Security 

Mediacurrent’s Drupal security pros took the stage to tackle a timely topic: open source security for marketing and business leaders.

As open source software like Drupal continues to become widely adopted, sticking to security standards is a challenge. The global losses from cybercrime totaled nearly $1 trillion last year (csis.org), raising the stakes on security even higher. 

Be on the lookout for the session recording for a playbook on how to optimize your Drupal security. They covered how to become a security-first organization, embrace process automation, harden Drupal security, and create clear security policies.

these Drupal modules protect from OSWAP

8. Higher Education: The Stage for Ambitious Digital Experiences

DrupalCon’s industry summits are always a great accompaniment to the regular program, and this year was no exception. At the Higher Education Summit, Director of Development Dan Polant was joined by one of Mediacurrent’s ivy league partners  to co-present a case study session. We saw how the university relies on Drupal to model complex data and got a behind-the-scenes look at the decoupled architecture with Gatsby. 

A decoupled approach lets us choose a dedicated solution for a given job

9. Drupal is Powering Hope 

At this year’s DCon, we saw how Drupal is powering some of the most impactful organizations in the world. All but one of the major COVID-19 vaccine-producing companies use Drupal. 

Major nonprofits like Habitat for Humanity also rely on Drupal. Through its website, the organization has helped more than 5.9 million people build or improve the place they call home. Mediacurrent has been honored to support Habitat’s mission and partner with them to build a maintainable platform that thrives on support from the Drupal community. The Drupal Showcase session recording for Habitat for Humanity: Building a foundation for digital success will be publicly available soon. We’re grateful for the opportunity to reflect on the success we achieved through our partnership, and we hope others can learn from it. 

Covid vaccine sites Pfizer, Modern, J&J run on Drupal

10. The Momentum Continues With Drupalfest 

DrupalCon has ended but the celebration continues with Drupalfest. 

Interested in learning more about contributing to Drupal? Let Mediacurrent’s Community Lead Damien McKenna be your guide. Join Damien for Contrib Open Hours through the end of April. 

Watch the State of Drupal Keynote 

Check out the recording of the State of Drupal keynote below.

[embedded content]

Cheers to 20 years, Drupal! We look forward to gathering again next year.

Apr 20 2021
Apr 20

open waters podcast logo

New Year, New Faces, Same Focus

We’re back! Season 2 of Mediacurrent’s Open Waters podcast is officially on its way. We recorded a special trailer episode to celebrate. 

Mark Shropshire and Mario Hernandez are returning as hosts. Just like last season, our purpose is to explore the intersection of open source technology and digital marketing. We’ll share the challenges and solutions we see with our own clients and in the market.

During season 2, we'll be covering topics including:

  • How to optimize your digital strategy
  • Accessibility as a business imperative
  • UX design principles
  • How it all works together using open source technologies like Drupal

Welcome to Season 2

Meet the Hosts 

Mark "Shrop" Shropshire 

Shrop headshot

Role at Mediacurrent: Senior Director of Development 

Podcast creds: Shrop can be found talking about open source security, leadership, mentoring, and more on his two personal podcasts: goServeOthers and SHROPCAST

What are you most excited about for season 2? The opportunity to learn more about what other talented folks are doing in the marketing and tech industries. It is easy to be comfortable with what you know today, but I find that having conversations with others can really challenge you to think differently and learn new niches.

Mario Hernandez
Mario headshot

Role at Mediacurrent: Head of Learning 

Podcast creds: Member of the original cast of Open Waters  - Mario co-hosted the first season of our podcast.

What are you most excited about for season 2? I am looking forward to interviewing industry leaders to discuss all things open source. I am also really excited about teaming up with Shrop. He has vast experience in podcasting and I am ready to learn from him.

Podcast release schedule 

New episodes will be released monthly on the Mediacurrent blog and wherever you follow your favorite podcast. You can also follow us on Twitter for updates.

Subscribe to Open Waters

Visit mediacurrent.com/podcast to hear the latest episode and subscribe to the podcast on your favorite podcast app. Share the podcast or tell a friend about it - tag us @mediacurrent on Twitter. 

How can I support the show?

Subscribe, leave a review, and share about us on social media with the hashtag #openwaterspodcast. Have an idea for a topic? Get in touch with our hosts at [email protected]

Mar 30 2021
Mar 30

Rain logo updated

The best open source distribution for Drupal just got better! The latest version of Rain University and Rain CMS now ship with Layout Builder pre-configured to make page building faster and easier. So how does it work? Check out below!

Editing Layouts

Now, when you navigate to any page with layout builder enabled you can edit the layout by clicking on the “Layout tab” under Tasks. Alternatively, you can click on the same tab while editing a page.

Rain editor experience with layout builder
Rain CMS homepage

Rearranging Blocks

With layout builder you have an instant preview of any blocks added to the page. That being said, it’s usually easier to move blocks around with preview turned off. Drupal provides a checkbox that makes it simple to toggle preview on or off.

Rain CMS, rearranging content blocks

Rearranging blocks in Rain CMS

Adding Blocks

To add a block to the page click the “Add block” link in any section. Rain CMS ships with 15 block types out of the box that you can easily drop onto the page. Each component has a preview wireframe and label to help the author understand the look and function of each component. 

Rain add block

Adding blocks in Rain CMS

Layout Controls

One of the big benefits of Layout Builder is now you have more control over the layout of a page. Editors can easily add new sections with various layouts where blocks can be placed. Layouts can be customized per project.

adding sections in Rain CMS

Adding sections in Rain CMS

Rain University CMS

The Mediacurrent team has also updated our RainU CMS to ship with Layout Builder. Same great experience, but tailored specifically for universities.

Rain University homepage

Rain University homepage layout

Want to Know More?

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

We are also happy to demo Rain University or Rain CMS for organizations interested in partnering with Mediacurrent for your next redesign project. To schedule a free demo, please visit our contact page or chat with us right now (see bottom right corner of the page). 

Mar 19 2021
Mar 19

rocket blasts off against a starry sky

DrupalCon North America 2021 is right around the corner! Check out the ever-growing schedule of sessions, industry summits, and special events on the official event site, and mark your calendar for these Mediacurrent sessions. 

Our Sessions 

The Mediacurrent team is proud to support this community event as a platinum sponsor. We’ll be presenting several sessions at this year’s online conference.

Whether you’re a site builder scaling up with multisite, a marketing leader in search of current guidance on open source security, or a Drupal community member of any kind looking for inspiring real-world case studies, we’ve got you covered. 

Here’s what we have in store for sessions and case studies in Drupal innovation:

Unlock The Power of Multisite 

DrupalCon program speaker card with Jay's headshot

Join Jay Callicott, Mediacurrent’s VP of Technical Operations, for a comprehensive approach to manage your Drupal sites at scale.

Interested in evaluating multisite options for your organization? Jay will cover several ways to scale your Drupal platform from one site to many dozens or even hundreds.

Register here to join the session and learn best practices for governing multiple sites from one codebase, how to configure a multisite installation, and considerations for your hosting solution. 

Open Source Security for CMOs

DrupalCon program speaker card with Mark and Krista's headshots

As open source software continues to become widely adopted, adhering to security standards is becoming more challenging. So what's a CMO to do?

Inspired by our ebook, The CMO’s Guide to Open Source Security, this session will help you navigate the terminology, expectations, and tools to ensure security is a priority for your web properties.

You can register here to join the session led by Mediacurrent’s resident Drupal security experts Mark Shropshire and Krista Trovato.

Case Study: Habitat for Humanity 

Imagine a world where everyone has a decent place to live. That’s the vision fueling Habitat for Humanity to create ambitious digital experiences with Drupal. 

This session will present a case study covering how Drupal is being used to bring mission-driven innovation to reality for this international nonprofit. Both Drupal site builders and non-technical roles are encouraged to attend. 

You can register here to join the session led by Mediacurrent Project Manager Vicky Walker and two members of Habitat for Humanity's web team.  

Drupal for Higher Education 

The year 2020 called for higher ed leaders to accelerate digital marketing strategies. For many, Drupal was a key part of the equation. This rang true among a spectrum of Mediacurrent’s higher education partners, including an Ivy League university that chose a decoupled architecture for its breakthrough knowledge platform.

Dan Polant, Director of Development at Mediacurrent, will share that story in a co-presented session at the Higher Education Summit. The session will explore the University’s driving mission to build toward a brighter financial future on a Drupal and React-based platform.

Join the session on April 20 at the Higher Education Summit.

Connect with Us

There's more to come! Check back for Rain CMS demos, Drupal 9 info sessions, giveaways, and more coming soon to our DrupalCon 2021 event page.

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.

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

  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

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. 


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 = ({
}) => {

  // If the `to` prop exists, return a link.
  if (to) {
    return (

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

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

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


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

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

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. 


Standalone Drupal

Decoupled Drupal with Gatsby

Initial License






Hosting (average)






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


Standalone Drupal

Decoupled Drupal with Gatsby

Ongoing License



Maintenance and Support









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



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




Status Quo CMS

Initial License



$0 (already paid)









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. 




Status Quo CMS

Maintenance and Support




Ongoing License








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. 




Status Quo CMS

Annual revenue




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.

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. 


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

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 (


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 {
  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 (


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 14 2020
Oct 14

Acquia Engage is coming soon (October 20 and 21) to a screen near you. There’s still time to register and join us! The Engage 2020 conference will be fully virtual and free for all attendees. 

This interactive event will inspire business and technology leaders to learn and connect on the path to bringing outstanding digital experiences to life with Drupal and Acquia. As a sponsor, we are excited to network with the Acquia community, connect with old friends, and meet new ones. 

Come connect with the Mediacurrent team at our virtual booth. Here's our Acquia Engage schedule so that you can plan your visit. We’ll be sharing best practices, case studies, and info sessions throughout the event. Drop in any time to chat with us.

Acquia Engage Mediacurrent Schedule

Digital Experience Case Studies 

Mediacurrent has been selected as finalists across three categories for the 2020 Acquia Engage Awards. These three finalists exemplify world-class digital experiences in healthcare, financial services, and emergency communication. Stop by our booth to learn best practices from these Acquia Open Experience Platform projects.

Acquia engage awards banner

Area Alert - Open Source Giants 

Area Alert is an open source solution for organizations that need to quickly build highly performant, low-cost, and easy-to-update emergency websites during the COVID-19 pandemic and other large-scale emergencies. The Area Alert Drupal distribution delivers a head-start for faster deployment with special design consideration for the user experience in times of crisis.

Montefiore Medical Center - Building a Better Tomorrow 

The Bronx’s Montefiore Health System, which served one of the hardest hit areas in New York City, saw that existing and prospective patients were delaying the care and treatment they needed due to fears of COVID-19. Montefiore endeavored to create a new microsite to reassure patients of the steps the health system was taking to ensure patient safety, and encourage patients to return for the care they required. With just over one month to launch, a speedy end-to-end solution was needed to launch the COVID-SAFE Care microsite.

BDO Alliance USA - Leader of the Pack (Financial Services)

Become an indispensable resource to Alliance firms. This was BDO’s main goal when they approached Mediacurrent to expand its portal functionality and increase customer acquisition, retention, and satisfaction. BDO Alliance USA is among the industry's largest associations of accounting and professional service firms. The Alliance Portal, a private Drupal-based platform, is available to members of firms who are members of the BDO Alliance USA. BDO took a big step in the evolution of its Alliance Portal with the move toward a more integrated, relevant, and metrics-based platform.

Stump the Drupal Experts 

Lately, we’ve been focused on gearing up for Drupal 9 with our Rain install profile, increasing conversion rates with Acquia Personalization, and decoupling Drupal with Gatsby...but you can ask us anything.

Try to stump our Drupal experts with your digital dilemmas – they welcome the challenge!

Sleep Better with a Secure Drupal Site

Mark Shropshire, Open Source Security Lead, will give a rundown of the 10 most common website security vulnerabilities and Drupal best practices to mitigate these risks. 

Drupal 9: Roadmap and Tools

Everyone’s buzzing about the strategic advantages of Drupal 9. We’re here to bring those Drupal 9 visions to reality with these open source tools:   

  • Rain: Go from zero to launch in 30 days. This Drupal installation profile enables rapid development and gives editors the ability to build robust pages with over a dozen pre-built components.
  • Automated Updates: Speed up the update process 3x faster. Managing updates in Drupal can be a challenge as core and contributed projects are frequently updated. There’s a better way to streamline the management of your Drupal application.
  • Mediacurrent Multisite+: Spin up a new site in minutes — no development help required. 

Connect with Us

Mediacurrent team holds Acquia Engage Award trophy in 2019

Conferences looked a little different in 2019!

We’ll miss in-person networking this year but our team of Drupal and digital strategy experts will be just a few clicks away. Stop by Mediacurrent’s virtual booth or book a 1:1 meeting with our attending team members:

  • Josh Linard, CRO
  • Michael Silverman, VP of Strategic Growth
  • Client Success Team: Mary Pat Kelsey, Scott Liberman, Madison Smith. and Carlos Lee
  • Damien McKenna, Community Lead
  • Kevin Basarab, VP of Delivery 
  • Jay Callicott, VP of Technical Operations 
Sep 03 2020
Sep 03

Mediacurrent is at the forefront of what’s next for the future of decoupling Drupal. We’re excited to team with Netlify to bring the modern Jamstack architecture to customers for better performing websites and web applications. By joining the Netlify Agency Partner Program, together we’re continuing our commitment to deliver transformative digital experiences to customers and run web projects at a global scale.

Delivering Modern Jamstack Websites and Web Applications

Jamstack, pioneered by Netlify, is a web architecture to make the web faster based on decoupling the front end pages from the back end apps and databases that enables site prerendering and global delivery. Netlify provides a platform to enable the Jamstack with modern build workflows, serverless functions, and a global multi-cloud edge network to deliver better performing, more secure, and scalable websites and applications. Netlify helps developers and teams to be productive, agile, and responsive to change throughout the project lifecycle and to deliver performant, dynamic digital experiences.

“Jamstack is an approach to build for the web that has generated a large global community and movement over the past five years,” said Sarfaraz Rydhan, director of partner ecosystem, Netlify. “Netlify is focused on bringing this community together and enabling the benefits of Jamstack with its platform alongside partners and customers. Working with Mediacurrent as a member of our agency partner ecosystem helps our combined customers to achieve their digital and web goals faster. We look forward to working with them to bring the benefits of productivity, performance, and speed to customers’ websites and web apps.”

A decoupled architecture can be a great approach for sites that require functionality beyond what Drupal normally supports. Organizations keep the best-in-class authoring experience of Drupal while adding the website performance, streamlined developer workflows, and design flexibility that comes with a Jamstack site. Learn more about our decoupled approach for MagMutual.com and the city of Sandy Springs.

To join the Netlify Agency Partner program, agencies apply and demonstrate understanding of the Jamstack architecture and Netlify’s platform. Netlify agency partners have the opportunity for deeper levels of collaboration with Netlify on their projects. As part of this agency program, partners can offer the full suite of Netlify features and products to customers.

Is decoupled Drupal right for your site?

Contact us today to learn more about decoupled architectures and whether it is the right approach for your organization.

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