Upgrade Your Drupal Skills

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

See Advanced Courses NAH, I know Enough
Oct 03 2020
Oct 03

Image credit: Aaron Deutsch

The Drupal project relies on the open source community for funding, promotion, and other contributions. As we know, contributing to open source can happen in numerous ways including code, testing, training, mentoring, organizing, speaking, and more. All genuine contributions are valuable.

One way we organize and make progress on the Drupal project is to create "initiatives" for important Drupal features or other focused tasks. You are likely familiar with some initiatives as they are highlighted regularly in the DrupalCon "Driesnotes".

Drupal 10 Initiatives

At the DrupalCon Global 2020 Driesnote, Dries talked about the new initiatives for Drupal 10. All of but one of these are based on initiatives that have been active for some time.

Source: Screenshot of DrupalCon Global 2020 Driesnote on YouTube

Drupal 10 readiness

The Drupal 10 Readiness initiative, known as d10readiness in Slack, started in June of this year. It evolved from the Drupal 9 readiness (d9readiness) initiative since Drupal 9 launched June 3rd. The focus of this initiative is updating dependencies, removing deprecations, and helping contributed projects be compatible with Drupal 10.

An easier out-of-the-box experience

The goal for this initiative is to improve the "out-of-the-box" (OOTB) experience so users have the best first impression of Drupal. This initiative will be a combination of focus areas from one previous initiative (Layout Builder) and two current initiatives (Media and Admin UI / Claro).

Layout Builder was added as a stable module May 2019 in Drupal core version 8.7.0. The Media entity module was added as hidden in Drupal 8.4.0 and was unhidden in 8.5.0. The Media Library module was marked stable in version 8.8.0 last November. Claro is still an experimental module and the hope is to bump it to stable status for Drupal 9.1.

Note that there was a previous "Out of the box initiative" and this new one is called "Easy out of the box". Hopefully this doesn't lead to any confusion.

A new front-end theme (Olivero)

This front-end initiative began as an idea in 2019. Contributors have worked hard to create a modern front-end theme that should be added to Drupal 9.1 as an experimental theme. Then, it will take additional work to get the theme to a "stable" version that can be officially added to Drupal core.

Automated updates for security releases

The Automatic Updates initiative was first proposed in January 2018. It is currently focused on site readiness checks, code signing and verification, composer integration, custom bootloading, and automated security-release updates. This is the most requested feature and would help Drupal be more competitive with WordPress.

An official JS menu component for React and Vue

The new JS Menu Component initiative idea is born out of the popularity of JavaScript frameworks and headless/decoupled architectures. The goal for this initiative is to build menu components for both React.js and Vue.js. This initiative is in the beginning planning stages.

Drupal 9.1 Focus

Drupal 9.1.0-alpha1 is scheduled for release during the week of October 19th, so this is the last chance to get major things addressed for version 9.1. For many active initiatives, the Drupal core roadmap has goals documented for version 9.1.

If you are looking to make an immediate impact in the next two weeks, the following initiatives could use the most help, but any open issue on any Drupal 9.1 initiative roadmap is a good target. Since the timing is tight, the "get-it-in-before-9.1 issues" would be particularly good for people with prior contribution experience. Novices may want to focus on less time-sensitive issues unless they are being mentored.

Source: How to prepare for Drupal 9 by Dries Buytaert


A large number of Claro issues need finalizing before Claro can be marked as stable for Drupal core. They are documented in the "Must-have issues for stable release" section.


A small number of Olivero issues need finalizing before Olivero can be added as an experimental theme in Drupal core. All "alpha" issues have been addressed so the focus is on the "beta" issues. The four remaining are documented in the "Olivero “beta” criteria (After Core Inclusion)" section.

Drupal Initiatives List

The Drupal project has a large number of initiatives to choose from if you are looking for a place to start contributing. These are grouped into strategic initiatives, core-related community initiatives, and other community initiatives. There are also initiative ideas that you can create, review, or refine.

A good way to get involved in an initiative is as follows:

  1. Read the initiative page, roadmap, and other documentation
  2. Look at several initiative issues to get a feel for the type of work
  3. Join the initiative Slack channel to see what people are discussing
  4. Attend an initiative meeting to observe and ask questions

Strategic Initiatives

Strategic initiatives are "official core initiatives" that have been chosen by Dries. These may be the ones you are most familiar with because of the Driesnotes. We've already touched upon a number of these above.

Admin UI (Claro)

Automatic Updates

Issues in this initiative are *not* well-suited for novices, but testing of the module by novices is welcome.

Composer Support in Core

This initiative is *not* well-suited for novices.

Drupal 10 Readiness


New Front-End Theme (Olivero)

And the remaining three that haven't been mentioned yet are:

Configuration Management 2.0

Documentation and Help

This initiative is well-suited for novices.


Core-Related Community Initiatives

Core-related community initiatives are "unofficial" community-led initiatives that focus on Drupal core.

Bug Smash Initiative

This initiative is well-suited for novices.


Usability / UX

Additional Community Initiatives

Here are a couple community initiatives that aren't core-specific.

Drupal Ladder

This initiative is well-suited for novices.

Promote Drupal

This initiative is well-suited for novices.

Thanks for your help!

If you have contributed to Drupal initiatives already, thanks for your help! If you haven't yet but are wanting to contribute to the Drupal project, initiatives are a great place to start. They provide structure and an existing team to get you started. Hope to see you in the issue queues soon. :)

Image credit: Aaron Deutsch

Apologies, my old website is still on Drupal 6 and looks particularly bad on mobile. I have started playing with the migration to Drupal 9 and hope to be done fairly "soon". :) Please ignore the cobbler's old shoes for now, thanks!

Sep 29 2020
Sep 29

Image credit: Aaron Deutsch

I just started the process of preparing my Drupal 6 (!) site for migrating to Drupal 9. One of the first steps of my migration process was to figure out where to host my Drupal 9 site. Right now kristen.org is on Pantheon. Yes, Pantheon supports Drupal 6! Maybe they don't want me to advertise that though. :)

In this post, I'll discuss my initial impressions of surveying some of the biggest Drupal managed hosting companies. If your favorite hosting provider isn't covered here, let me know and I might do a follow up post.

Drupal 9 support

I've almost always used Pantheon or Acquia hosting for client Drupal projects. If the client was already using something "cheap" like InMotion or Bluehost, I would try (usually in vain) to get them to switch to a more robust managed hosting provider. When I started on this, I looked at 4 of the most popular Drupal managed hosting companies: Acquia, Amazee.io, Pantheon, and Platform.sh.

When I checked the status of Drupal 9 support by these "Big Four", I found that Drupal 9 was officially supported by Acquia, Amazee.io, and Platform.sh. Pantheon has a way to test Drupal 9 on a "multidev" (testing site) but doesn't have official support yet.

At the time of writing, Pantheon Co-Founder Josh Koenig said via Twitter that Drupal 9 should be supported by Pantheon within the next few months in time for Drupal 9.1. If you have an existing site, Pantheon's advice is to upgrade your site to the latest version of Drupal 8.9 and make sure your site is completely compatible with Drupal 9. Then, it will be very simple to jump to Drupal 9 when they flip the switch.

First impressions of Drupal 9 support

I went to each of these "Big Four" hosting companies websites to see if: 1) they supported Drupal 9, and 2) there was a free trial for me to test it. Unfortunately, I found each of the providers had some user experience (UX) or developer (DX) issues when attempting to evaluate Drupal 9. I reviewed companies in the following order.


Source: Screenshot of Pantheon.io Home Page

Of these "Big Four", I have the most experience with Pantheon, and I've always enjoyed their workflow and tools. Since I already have a Pantheon account and my kristen.org site is hosted on Pantheon, I logged in and went to create a new "sandbox". Pantheon allows a small number of free sandboxes to be created for each account.

My thought was that I would create a Drupal 9 sandbox and also create a "migration multidev" for my Drupal 6 site. Then, I would try to migrate directly from the Drupal 6 multidev site to the Drupal 9 sandbox site without using my local machine.

The issue I had on Pantheon was already mentioned previously. It doesn't yet officially support Drupal 9. I found this pretty surprising given that this is one of the oldest Drupal managed hosting providers.

One UX/DX issue I had was that it didn't mention Drupal 9 at all on the page where you choose a CMS. It only had WordPress, Drupal 7, and Drupal 8. I found out via Twitter that Drupal 9 wasn't officially supported yet, and that it would be probably couple months before it would be ready.

My advice to Pantheon is to add text on the CMS-selection page with Drupal 9 information or a link to a Drupal 9 page. That page could explain the Drupal 9 roadmap, including workarounds, so that others don't have to poke around to find out what to do. This would be very simple, but they said it wasn't something they typical do. Seems like a pretty obvious yet easy UX/DX improvement.


Source: Screenshot of Acquia Home Page

I already knew that Acquia supported Drupal 9 because I saw that information fly by on Twitter. This is not surprising since Drupal is the only CMS Acquia supports. But, I wasn't sure if they had a trial version and, if they did, how long the trial was good for.

I searched for "acquia drupal 9" which went to acquia.com/drupal9, but I didn't find that page helpful. So then I searched with "acquia drupal free trial" which had "Create a Free Acquia Cloud Site" that sounded promising.

Side note: I didn't see any mention of a free trial on Acquia's site when I clicked around. Even if I used their internal search. The only way I could get to the free trial was searching via a search engine and finding the correct form. I assume this is by design as they probably want people to contact them and work with their sales team.

I went to the "Create a Free Acquia Cloud Site" page and filled in the somewhat long form asking for the site name, first name, last name, email address, password, and even phone number. Along with, of course, the obligatory and ubiquitous "I'm not a robot" and terms of service checkboxes. In my opinion, this is too much to ask for when I just want to try the service out. I'm wondering how many people drop off here.

So I filled in the form and it asks me if I want a try a free application and there's another checkbox to check (hmm…). Then it created my application and when I clicked the "next" button, it LOGGED ME OUT of the Acquia site to have me log back in. :(

Okay, so I try to log back in and it doesn't work. Since there was only one password field, I was wondering if maybe I typed the password wrong in the original form. (Yes, I know, I should use a password manager, but I haven't set that up yet.) I checked my email to make sure I didn't get an email with a confirmation link I needed to click but I didn't see one anywhere.

So, I reset my password with their form (with another "I'm not a robot"). Then I try to use the password that I thought I had used and get "Passwords must contain at least 1 special character." Ugh. This isn't going well.

At this point, I get back in but am a bit discombobulated (I like that word though not that feeling). I'm on my account page and not sure where to go. I haven't worked on an Acquia site in awhile and when I did it was mostly on the command-line for several sites that are part of a very large multi-site infrastructure. Mostly what I did in the UI was download a copy of the database because drush didn't work for those sites.

I see "DEVELOP", "MANAGE", and "ENHANCE" so I pick the first one. Under "DEVELOP", I see my new "application" (with a typo in its name, whoops). I click on it and get to a more familiar "Dev", "Stage", "Prod" workflow. But now I'm wondering if this is even Drupal 9. Since Acquia only does Drupal (unlike the other providers), I assume it must be. One thing I notice is that it's using PHP 7.3. It would be nice if it was using 7.4.

I clicked on the application link and get a very uninspiring "Welcome to Acquia Cloud" page. The Marketing department needs to help the Engineering team here to make this better. But, what's worse is that the page isn't helpful at all.

At this point, unfortunately, I'm just tired and annoyed and decide to move onto Platform.sh. One side note though was that I had tried this about a week prior to this test. I forgot to take screenshots, so that's why I did it again. It seemed a lot easier the first time around, but I'm not sure what the difference was.

That first time, I did have an issue with that application-creation process where it *appeared* to be hung up, but it really was just taking a *long* time. I gave up waiting for it after about 10 minutes. It took somewhere between 10 and 30 minutes to provision the application. It would have been good if the screen would have told me it was going to be awhile and to go get a drink or go for a walk.


Source: Screenshot of Platform.sh Home Page

I've been curious about trying Platform.sh ever since I saw their first demo at BADCamp many years ago. The fact you could spin up an entire copy of your site by just creating *any* git branch seemed like a dream come true. Pantheon has "multidevs" which I love that are similar to this but are limited to a small number. This feature is much more commonplace these days with services like Tugboat.qa (which is pretty awesome).

I knew Platform.sh supported Drupal 9 and saw the eye-catching "Free trial" call to action (CTA) button at the top of their site so I started there. In my mind, this was the most compelling CTA of the four. Both Acquia and Amazee.io have "Request a Demo" which sounds like I'm going to have to talk to a sales person. Pantheon does have a "Get Started" CTA at the top as well as a "Start a Free Trial" CTA that's lower on the page but that one is overwhelmed by the bright yellow "Watch the Demo".

The biggest issue I had with Platform.sh right away was I got a "white screen of death" (WSOD) during the registration process. I think it was right after filling in my password. I was still able to go to my account after getting the fatal error and then everything seemed fine. But, this was a huge deal, obviously. Fortunately, Platform.sh fixed the issue right away which I confirmed today by trying the registration process again.

One nice thing I liked about their registration process is that I only needed to provide an email address to start with (or you can connect using Github, Google, or Bitbucket which I didn't try). Fill in your email address, an email is sent, you click on the button in the email, and it brings you to the form to fill in your password.

When going through the registration process again (to check it was fixed), I saw a lot more fields on the multi-step form with all but one required. In my opinion, username, country, and company shouldn't be required fields. Even the first and last name fields shouldn't need to be required. The only required field on the account settings page is username which could probably be defaulted based on the email address if it is really needed.

The other couple UX issues I found were 1) not knowing the password requirements and only finding out after submission, and 2) the multi-step navigation was not working properly (my data would get wiped when I used it).

Once I had an account, the process for creating a new project was very straightforward and I didn't have any major issues. I followed the process below. There is also a quick link on the Platform.sh Drupal 9 template page that will choose the template for you.

All-in-all, other than the WSOD, I was pretty happy with the Platform.sh process. I found it to be pretty straightforward. I was able to look around the page to figure out what I should do next. I appreciated the fairly simple workflow and the wizard to help with dealing with CLI and SSH key configuration. I hope to have a follow up post soon discussing the CLI and setting up Drupal 9.

  1. Click "Add a project" button
  2. Click "Use a template" option
  3. Enter "Project name" and "Region"
  4. Select "Drupal 9" template (you can filter by type of "Drupal")
  5. Wait about a minute
  6. Voila! You have a new Drupal 9 project to configure
  7. Click on the project, click URLs, and choose first URL
  8. Go through the site install
  9. Follow the "wizard" on the right of the project to set up CLI, SSH key, etc.

Platform.sh UX/DX feedback

One minor issue I had was when I looked at the templates. At first, I didn't realize you could scroll for more templates because the scrollbar doesn't show up unless you hover over the template region. Maybe this is obvious to everyone else, but I think it would be best to always show the scroll bar even if this isn't as "pretty".

One other thing was that the project placeholder image shows Error 502 which doesn't instill a lot of confidence. Maybe show the cute rabbit mascot or something more friendly and/or informative.

My final bit of feedback is that when you are on the "Projects" page, it has a link for "Back to projects". This is confusing, so it would be good to change the wording so this is clearer.

Click "Add a project" button

Click "Use a template" option

Enter "Project name" and "Region"

Select "Drupal 9" template (you can filter by type of "Drupal")

Wait about a minute

Voila! You have a new Drupal 9 project to configure

Click on the project, click URLs, and choose first URL

Go through the site install

Follow the "wizard" on the right of the project to set up CLI, SSH key, etc.


Source: Screenshot of Amazee.io Home Page

I heard via Twitter that Amazee.io could do a free trial by request which they call a "demo". When I saw "demo" on their site, I assumed that meant I would sit on a call with a sales person and they would show me their platform. That is not something I was interested in. I just wanted to play with it on my own.

Amazee.io's Founder, Michael Schmid, said he'd hook me up with a free trial. At the time of writing, I haven't seen an email for that, so I'll have to report on that later. I am empathetic here—I know Michael is a busy person—so no judgements! Also, now I'm wondering if I was supposed to fill in the contact form to make trial that happen... hmm...

Regarding the do-it-yourself nature of the other platforms, the Amazee.io founder said it's called Platform-as-a-service, not Platform-do-it-yourself. So, after thinking about this more, since Amazee.io isn't "do it yourself", then it probably shouldn't be included in this "Big Four" list. My goal, for now, was to find SaaS where I could easily create Drupal 9 sites for my personal, contribution, and small business use.

11 takeaways for Drupal hosting companies

Image credit: Aaron Deutsch

It's vital for EVERYONE in the Drupal space to do the best job possible to convert users to Drupal and keep them happy. There are many good alternatives to Drupal. Every hosting provider, freelancer, agency, and service provider needs to put their best foot forward to prevent Drupal going the way of the dinosaur. Even as competitors, we must all try to shine or Drupal can get bad reviews and lose market share.

I had UX issues with all platforms I looked at, some small and some large. Here are some generic and obvious takeaways that apply to any Drupal hosting company:

  1. Have a trial option that lasts at least 30 days
  2. Make it super simple to make an account
  3. Make it obvious how to create a new trial site
  4. Searching for "[company] drupal 9" & "[company] drupal free trial" should get me there
  5. For slow installations, add expected wait time (and a video to watch might be nice too)
  6. Make it easy to find your new trial site and understand the next step to take
  7. Have contextual help text/videos where appropriate
  8. Do user testing to see where people get hung up
  9. Use Lucky Orange, Hotjar, or similar heatmap software to see where people are looking and drop off
  10. Add automated testing for the entire registration and application creation processes
  11. Be very responsive on social media

Regarding that last point, Amazee.io, Pantheon, and Platform.sh responded quickly to me on Twitter, and engaged with others who commented on the thread. From what I could tell, Acquia did not respond, so possibly missed a marketing opportunity. Note that Amazee.io responded even though they weren't even in the original Twitter thread which was a smart marketing move.

I probably could go on and on, but that's good enough for now. For this exercise, the clear winner was Platform.sh BUT, if I had been completely new to Platform.sh as a vendor, then I may have just walked away when the white-screen-of-death (WSOD) came up during registration. For what it's worth, the fact that Platform.sh fixed the issue right after I reported was another good sign.

So, my final takeaway is to always assume your potential users might walk away at any point in your conversion funnel, and test and optimize each piece as if your business depends on it. Because it does.

Side note: I (unfortunately ;) did NOT get paid by any of these companies to review their services. But, if any of these or other vendors want to hire me for focused testing and evaluation, feel free to ping me on Twitter, LinkedIn, or at drupal at kristen dot org. :)

Image credit: Aaron Deutsch

Aug 29 2020
Aug 29

Image credit: Aaron Deutsch

In the last few months, I've been doing a lot of Drupal core contributions and, even though I've done plenty of contributions over the years, I've recently learned some new things when reviewing issues. I've made this cheat sheet for anyone who wants to help review Drupal issues and wants to make sure everything has been thoroughly checked before marking "RTBC" (Reviewed & tested by the community).

There is plenty of great documentation on the development contribution process that explains some of these items further which I've also linked to below. Documentation is also being improved right now so I will update this post as new information is available. For now, hopefully this post can serve as a handy reference.

Special thanks to the Bug Smash Initiative team for recent discussions on this topic!

IMPORTANT: You do NOT need to do all of these steps to move an issue forward. For example, you could do the manual testing and nothing else. Or, make sure the issue summary is in good shape and nothing else.

But, if you are going to mark an issue RTBC, please double check that everything has been covered. This is immensely helpful to make things more efficient for not only the maintainers but for all contributors. Thanks!

Issue RTBC checks

Here's a bulleted version of the most common things to check before marking an issue RTBC:

  1. Title is clear and accurate
  2. Issue summary
    1. Clear and accurate
    2. Uses template
    3. Has steps to reproduce if applicable
    4. Has embedded "before" and "after" screenshots if relevant
  3. Metadata is correct
    1. Project is correct
    2. Category is correct
    3. Priority is correct
    4. Status is changed to RTBC (if all good!)
    5. Version is current development branch, e.g. 9.1.x-dev
    6. Component is correct
    7. Assigned is set to "Unassigned"
    8. Issue tags are relevant and not missing tags
  4. Other issues
    1. Parent issue set if applicable
    2. Related issues set if applicable such as duplicate issues
  5. Files
    1. Only upload screenshots if relevant
    2. Uncheck "Display" for screenshots
  6. Code review
    1. Patch applies cleanly
    2. No coding standard issues in test bot
    3. Documentation is clear
    4. Code addresses issue
    5. Code does not change unrelated things
    6. Previous comment feedback addressed
  7. Tests
    1. New test code added if applicable
    2. New test code tests the specific issue
    3. Tests pass
    4. Test-only patch fails
  8. Manual testing
    1. Issue was reproducible
    2. Patched code fixes issue

A note on "core gates"

There are a number of Drupal "core gates" that aren't obvious to most reviewers for example accessibility or performance related items, so those are best checked by a maintainer or a contributor with those specialized skills. Some items are more easily reviewed by general contributors such as whether or not there should be a change record or if there are missing tests.

But, no one knows everything. If you marked something RTBC and tried to make sure everything was ready, don't feel bad if something is bounced back to "Needs work". Even with checklists, it's easy to miss something. The goal is to try to do as thorough a job as you can to minimize too much back-and-forth on the issue.

Example comment

I've been trying to be very explicit in my comments before marking an issue RTBC. Here's some SAMPLE text. If you use this as a guide, please remove anything that is not applicable to the issue, add anything that is missing, and reword as appropriate. And, don't forget to think as this checklist is not a substitute for stepping back and seeing the whole picture. :)

Thank you for your patch. I am marking RTBC since:

  1. Patch applies cleanly.
  2. Tests pass.
  3. Test-only patch fails as expected.
  4. No coding standard problems were found by the test bot.
  5. Code is clear and addresses the issue from the issue summary.
  6. New test code tests the specific issue from the issue summary.
  7. Feedback from previous comments has been addressed.
  8. Issue title is clear and relevant.
  9. Updated issue summary to use the issue template and clarify issue text.
  10. Issue metadata looks okay.
  11. Manually tested and patch works as expected. See screenshots.
  12. Change record is clear.

Miscellaneous observations

After reviewing a lot of issues the past few months, I've noticed a few things to keep an eye out for:

  • "It works for me": Some contributors will mark issues RTBC with a simple "It works for me" type comment or sometimes even no comment. It's very important to be explicit on what you reviewed so that it makes things easier for the maintainers to review your work.
  • Interdiffs: For new contributors, they often leave out an interdiff when updating a patch. If the patch is very small, I don't normally comment on the interdiff being missing but, for larger patches, I make a comment that it's missing and link to the interdiff documentation. Having an interdiff makes the review process faster.
  • Empty comments: Some contributors will add a new patch but not include a comment. If I see this, I often comment that it is helpful to have a comment even if they think it should be obvious what they did. Empty comments slow down the process because people need to figure out what happened. It's better to err on the side of being "pedantic" and over-commenting than not providing enough detail. That said, if comments are long, they can be hard to follow, so best to use ordered lists for long comments, so that people can refer to the number in the comment.
  • Does it need tests: As a rule of thumb, if the issue is a bug fix then it will need a test added. Sometimes this is a judgement call though. If you don't think it needs a test and everything else looks okay, mark it RTBC and make a note that you don't think it needs a test. Just be prepared that it might get bumped back to add a test.
  • RTBCing own patch: Occasionally, someone tries to RTBC a patch they created. This doesn't happen that much in core, but is more common in contrib. If the project is their project, then that's fine, but sometimes it's not. You can move an issue back to "Needs review" if you see it was marked RTBC by the contributor who created the patch.
  • Old patches: There are lots of issues so many go quiet. If you come across an issue that has been stagnant and has an old patch, if it's old enough, it is good to double check the issue is still reproducible as maybe it was already fixed. If it was fixed, try to find the duplicate issue and close out the old issue and link to the duplicate. If it's not fixed and is reproducible, you'll need to see if the patch still applies cleanly to the current development branch. If not, move it back to "Needs work" and add the "Needs reroll" tag.
  • Followup issues: It's really easy to forget the create followup issues if the issue gets marked fixed or closed. Try to create followup issues as soon as they are identified if possible and add it as a related issue (in both directions).

Additional resources

Errors and improvements

If you notice errors in this post or want to suggest improvements, contact me on drupal.org.

Image credit: Aaron Deutsch

Apologies, my old website is still on Drupal 6 and looks particularly bad on mobile. I've only started posting here again after many years and I've been very busy reviewing Drupal 9 patches and surviving a pandemic. :) Please ignore the cobbler's old shoes for now, thanks!

AttachmentSize drupal-happy-mask-aaron-deutsch.png804.96 KB drupal-robot-original-aaron-deutsch.png135.98 KB
Jul 01 2020
Jul 01

Image credit: Aaron Deutsch

DrupalCon Global 2020 is in a couple weeks and there are a lot of amazing sessions. Hope you can make it! While preparing my own DrupalCon Global session, I reviewed the other sessions and made a list of ones you might want to watch to help you prepare for upgrading from Drupal 6 or 7 or 8 to Drupal 9.

In some cases, it was very hard to choose just one on a particular topic. For example, there are 3 great layout builder talks! So, while these are some of my top picks, don't forget to check out all the DrupalCon Global sessions and add your favorites to your schedule.

If you are upgrading from Drupal 8 to Drupal 9 and don't need to make any website improvements, then you can focus on the Drupal 9 sessions. If you will be doing a redesign and/or upgrading from Drupal 6 or 7 to Drupal 9, check sessions for dreaming up your new site, planning your new site architecture, and implementing your new site.

Everything you want to know about Drupal 9: the upgrade process from Drupal 6, 7, and 8, making upgrades faster with a new Acquia migration tool, the nitty gritty details on what makes Drupal 9 special, and new features coming in Drupal 9.1.

Discovery, design, and project management are critical for your web projects. These sessions cover how to manage your team, user stories and user experience work, and other important aspects of designing a great website.

Drupal is a great framework for building the website you want by customizing to your needs. These sessions cover foundational features of the Drupal system: media, layout builder, components, admin tools, SEO, and migrations.

If you are new to Drupal 8 and 9, these sessions will help you understand how to work with composer, configuration management, and Twig as well as create custom modules and migrations.

Hope to see you at DrupalCon Global!

Apologies, my old website is still on Drupal 6 and looks particularly bad on mobile. I've only started posting here again after many years and I've been very busy reviewing Drupal 9 patches and surviving a pandemic. :) Please ignore the cobbler's old shoes for now, thanks!

Jun 15 2020
Jun 15

I was researching Drupal 9 content and decided to collect some data. I gathered information related to the authors and the organizations whose content showed up in the top 100 Google results for "Drupal 9" (as of June 12, 2020). Check out the infographic with the data in a pretty format or skip to the plain text.

This is the first infographic I've created. I used Piktochart based on a Twitter recommendation from @akmalfikri. I liked the tool pretty well but was hoping for more mapping options based on region rather than country. If you have a favorite infographic tool, let me know.


Drupal 9 Authors

For the content that had authors listed, I looked at the type of content they contributed, their job titles, and for their drupal.org profiles, if any. If they had a drupal.org profile, I checked if they work on any contributed projects, how long they've been on drupal.org, how many issue credits they have, and how many core issue credits they have. I also grabbed their location, and if they are a Drupal Association member and contributed to the #DrupalCares campaign.

Author Content Types

For content with authors listed, I looked at the type of content they contributed which was lumped into the categories: Blog Post, Video, Code, or Other. The Code category is for Github code that was in the search results. The Other category includes documentation and training material.

  • Blog Post: 90%
  • Video: 5%
  • Code: 2.5%
  • Other: 2.5%

Author Job Role Types

I grouped the job roles into categories: Developer, Executive, Marketer, Writer, and Other. The Executive category includes Founders / Co-Founders, C-Levels, VPs, and Directors. The Writer bucket includes journalists and media outlet content writers as well as in-house writers for larger organizations. The Other bucket includes product managers, project managers, and people without roles listed.

Some people had multiple roles but I picked one. For example, if someone was a CTO & Architect, I used Executive even though they might be doing development.

  • Developer: 31%
  • Executive: 30%
  • Marketer: 23%
  • Writer: 8%
  • Other: 8%

Author Locations

For content with authors listed and drupal.org profiles, I looked their locations which were grouped: USA, Europe, UK, India, Australia, or Other. The Other category includes Canada and profiles that did not have a location listed.

  • USA: 60%
  • Europe: 14%
  • UK: 10%
  • India: 7%
  • Australia: 5%
  • Other: 5%

Author Profile Data

Here's profile information from the 67% of authors who had drupal.org profiles:

  • Have contributed projects listed: 71%
  • Average years on drupal.org: 10.2
    —max was 19.2 for Dries
  • Average issue credits (for past year): 61.3
    —max was 575 for catch
  • Average core issue credits (for past year): 22.1
    —max was 538 which was also for catch
  • Donated to #DrupalCares campaign: 50%
  • Drupal Association member: 60%

Drupal 9 Organizations

For the organizations that published the content (other than drupal.org), I looked at the type of content they contributed, type of organization, and for their organization drupal.org profiles, if any. In some cases, the organization had a personal drupal.org profile rather than a organization profile so those were ignored. If they had an organization drupal.org profile, I checked if they work on any contributed projects, how many people they have on drupal.org, their location, how many issue credits they have, and how many core issue credits they have. I also looked at if they are a Drupal Association member, supporting sponsor or premium/signature sponsor, and if they contributed to the #DrupalCares campaign.

Organization Content Types

I looked at the type of content that was contributed which was lumped into the categories: Blog Post, Video, Landing Page, or Other. The Landing Page category includes topic-specific landing pages as well as registration pages for webinars, training, and guides. The Other category includes documentation and training material.

  • Blog Post: 73%
  • Landing Page: 8%
  • Video: 6%
  • Other: 13%

Organization Types

I grouped the organizations into categories: Consulting, Hosting, Media, Themes, and Other. The Consulting category includes agencies, support companies, and specialty consulting though the bulk was traditional digital agencies. The Themes category is for sites that sell themes (many of these are for WordPress). The Other bucket includes training, specialized software, and technical libraries.

  • Consulting: 73%
  • Media: 6%
  • Hosting: 5%
  • Themes: 5%
  • Other: 11%

Organization Headquarter Locations

For content with organization drupal.org profiles, I looked their locations which were grouped: USA, Europe, UK, India, Canada, or Other. The Other category includes Australia, Ukraine, and profiles that did not have a location listed.

  • USA: 51%
  • Europe: 13%
  • India: 11%
  • UK: 8%
  • Canada: 8%
  • Other: 9%

Organization Profile Data

Here's profile information from the 82% of sites who had organization drupal.org profiles:

  • Have contributed projects listed: 90%
  • Average number of people on drupal.org: 52.7
    —max is 693 for Acquia
  • Average issue credits (for past 3 months): 90.4
    —max is 683 for Specbee
  • Average core issue credits (for past 3 months): 19.5
    —max is 285 which was also for Acquia
  • Donated to #DrupalCares campaign: 44%
  • Drupal Association organization member: 16%
  • Drupal Association supporting partner sponsor: 28%
  • Drupal Association premium or signature partner sponsor: 25%

Organization Anti-Racism Statements

My last blog post discussed Drupal for Justice. While reviewing the top 100 "Drupal 9" search results, I checked all the organizations for any recent blog posts on Black Lives Matter, racism, and social justice. I found a few companies with related statements that are listed below in chronological order. If you know a Drupal organization who has taken a stand on this pressing issue, let me know and I'll add them to my blog post.

Apologies, my old website is still on Drupal 6 and looks particularly bad on mobile. I've only started posting here again after many years and I've been very busy reviewing Drupal 9 patches and surviving a pandemic. Please ignore the cobbler's old shoes for now, thanks!

AttachmentSize drupal-9-look-whos-talking-header.png422.69 KB drupal-9-look-whos-talking-infographic.png897.11 KB
Jun 05 2020
Jun 05

As I'm sure you already know, Drupal 9.0.0 was released yesterday which was the result of thousands of people in the Drupal community coming together to make Drupal even more amazing. The release has a new Drupal 9 landing page and a Drupal 9 video that highlights the journey of Drupal and the Drupal community. We are truly better together.

You are also most certainly aware of the tragic killing of George Floyd as a result of police brutality and the resulting protests throughout the United States and other parts of the world. As an American, it sickens me to see how the Black community is treated in the US. Systemic racism is real and real change is needed urgently. Watching the peaceful protests throughout my country, I feel outrage, sadness, and hope.


For better or worse, I've been on Twitter a lot over the last couple months, and during the last couple weeks, it's been difficult to reconcile the content in my Twitter feed. Violence and anger and grief from yet another senseless tragedy in the Black community. Excitement and pride and joy from years of hard work on Drupal 9. I've struggled to take pleasure in the Drupal 9 release while watching the heartbreaking events unfold in the news.

I wanted to write a post about how amazing Drupal 9 is and how amazing the Drupal community is. Yet I'm preoccupied with thinking how I can make things better, how I can make the world better. Knowing many in the Drupal community, I am certain I am not alone with these thoughts and feelings. I did some research and have found some reactions from the Drupal community in light of recent events that I would like to highlight.

Drupal leadership

It's always important when you are part of a company, organization, or community that the leadership makes a clear statement on pressing social issues. I was encouraged by Dries' Drupal 9 release announcement that he made this statement:

I have always believed that Drupal is a force for good in the world. People point to our community as one of the largest, most diverse and most supportive Open Source projects in the world. While we make mistakes and can always be better, it's important that we lead by example. That starts with me. I am committing to the community that I will continue to learn more, and fight for equality and justice. I can and will do more. Above all else, it's important to stand in solidarity with Black members of the Drupal community — and the Black community at large.

Source: Dries Buytaert blog post

The Drupal Association (DA) published a Statement of Support and Taking Action that includes a list of encouraged actions for the DA team and the Drupal community at large.

Source: Drupal Association blog post

The Drupal Association values equity, diversity and inclusion, and we recognize we still have work to do to create meaningful change. Here are the ways in which we are encouraging our team to take action. We are sharing in hopes that you will take action, too.

I was also motivated by the Twitter thread from @xjm, the Drupal 8 and 9 core release manager.

[1/8] The powerful will do everything they can to stop us from making real change. Protest now, but also work in your community to protect voting rights. Help people register. Advocate for the right to vote by mail so that disabled and working citizens can vote.

Source: @xjm Twitter thread

These are great examples of calls to action from our Drupal leadership in support of the Black community. So how can the Drupal community help bring forth positive change?

Individual action

At an individual level, some concrete acts are listed above from our Drupal leadership. But it's crucial to hear and amplify the voices of the Black community. Bernice King, daughter of Martin Luther King Jr., has some actionable advice.

Source: Bernice King's Twitter account

And, Barack Obama wrote a thoughtful article on "How to Make this Moment the Turning Point for Real Change".

Source: Barack Obama Medium post

For white people or anyone who's not well educated on racism, there is a lot we can read and watch in the Anti-racism resources compiled by Sarah Sophie Flicker and Alyssa Klein.

To donate, here is a list of 115 Ways to Donate in Support of Black Lives and Communities of Color.

Organizational action

It is vital that businesses and organizations leveraging Drupal make a stand against injustice. I searched the home pages and blog posts from the top 50 Drupal organizations on drupal.org to see what they've been saying about the recent tragic events. I also looked at their team or leadership pages to get a sense of their diversity.

I was surprised and frankly saddened to only find ONE article on the topic.

Source: Four Kitchen's blog post

Todd Ross Nienkerk from Four Kitchens wrote "Our Commitment to Social Justice and Racial Equity". Thank you, Todd, for making a statement, donating to causes for justice, and helping your team with resources and education.

Source: Four Kitchens

I encourage other organizations that benefit from Drupal to make a stand and support the cause for justice.

As for organizational diversity, it was pretty much as expected. Most American and European companies appear to be predominantly white. We do have a fair amount of geographical diversity within the Drupal community, so we do see significant engagement within some non-white regions such as Latin America and India. As organizations, we need to continue to push for inclusivity and diversity because representation matters.

Community action

As a community, we have embraced the Drupal Diversity and Inclusion (DD&I) initiative. And, we have taken some active measures to increase representation within our events and community. But, even our DD&I leadership seems to be lacking in some aspects of diversity as it appears (based on my own personal bias looking at photos) that the team is predominantly white. This is not to dismiss the important work the team has been doing, though everyone knows we can all do better.

Looking to other Open Source communities, I am heartened by the GatsbyJS fundraiser for Black organizations fighting for justice. They will match donations up to $25,000 until June 8, 2020. I would welcome a similar initiative within the Drupal community, perhaps right after the GatsbyJS campaign is done. GatsbyJS has gone further with their support of the protests by postponing Gatsby Days. And some Gatsby team members have written about the topic recently including "My White, Blissful Ignorance" by Jason Bahl.

Source: @GatsbyJS Twitter thread

I do see some positive movement in the Drupal community as well. Heather Rocker, the DA's Executive Director, is looking for training organizations to help underrepresented groups.

Source: Heather Rocker's Twitter account

I also saw Avi Schwab is matching donations up to $1,000 via the #DrupalCaresLocal hashtag. Thank you, Avi!

Source: @ajschwab Twitter account

Drupal for justice

Let's make Drupal stronger by helping make the world a more just place.

If you know of other ways the Drupal community is helping in the fight for justice, let me know and I'll add them to this post.

Apologies, my old website is still on Drupal 6 and looks particularly bad on mobile. I've only started posting here again after many years and I've been very busy reviewing Drupal 9 patches and surviving a pandemic. Please ignore the cobbler's old shoes for now, thanks!

May 18 2020
May 18

As you may have heard, Drupal 9 porting day a couple weeks ago was a huge success! Gábor Hojtsy wrote up a great summary on the event including all the money that was raised for the Drupal Association. And, you can read my porting day recap as well. Thanks again to all who helped out.

The April porting day was so successful that Surabhi Gokte and Gabriele Maira (gambry) encouraged Gábor to organize a repeat performance and, like magic, we have Drupal 9 porting weekend coming May 22 and 23. This is scheduled during the time we had hoped to contribute at DrupalCon Minneapolis. Now we'll join each other virtually in a few days to make Drupal even better.

The goal for Drupal 9 porting weekend is to make more Drupal 8 contributed projects (modules, themes, and distributions) compatible with Drupal 9. As of May 16, 2020, there are 1,617 out of 8,982 projects that already work on Drupal 9. So, during the porting weekend, we'll work on the 7,365 that don't. While that might seem like a daunting number, about half of those (3,405) likely only need a one-line change to make the project Drupal 9 compatible!

There is a wonderful effort underway right now to automate Drupal 9 compatibility issue and patch creation for contributed projects. Even with this effort, we still need your help during porting weekend. We hope you can participate!

Image credit: Aaron Deutsch

I've listed some useful Drupal 9 porting resources you can review and information about collaborating in Slack during the event. I've also added specific sections for preparation depending on the type of contribution you are hoping to do:

There are a lot of Drupal 9 resources, but here are some that are particularly helpful for preparing for patch weekend:

  1. Drupal 9 readiness (#d9readiness) channel on Slack
  2. Drupal 9 compatibility contribution quickstart guide
  3. Drupal 9 Deprecation Status
  4. Drupal 9 compatibility ContribKanban board
  5. Drupal 9 porting weekend ContribKanban board (to be filled in :)
  6. Upgrade Status
  7. drupal-rector
  8. Upgrade Rector
  9. Running PHPUnit tests
  10. simplytest.me
  11. dreditor Chrome browser plugin
  12. Drupal 9 porting day recap
  13. How to prepare for Drupal 9 Porting Weekend
  14. Drupal 9: Status, Resources, and Ways to Contribute

We'll be collaborating in the Drupal 9 readiness (#d9readiness) channel on Slack. If you don’t have access to Drupal Slack click here to get an invite.

When you are ready to join the porting weekend, announce yourself in the Slack channel with something like "I'm here to contribute and will be helping for the next X hours. [insert what you are hoping to do or if you need help here]", e.g.

  1. I will be working on my personal Foobar module and don't need any help but will post status updates here.
  2. I will be working on my personal Foobar module and would like help reviewing/testing.
  3. I will be finding my own issues to work on and will post them here as I work on them so others can collaborate.
  4. I don't have an issue I'm working on but am open to creating patches.
  5. I don't have an issue I'm working on but am open to reviewing/testing patches.
  6. I'm not sure what to help with and need guidance.

We will be using Slack threads extensively during porting weekend. Each project or issue that is being worked on should ideally have a Slack thread associated with it in the channel. Also, if you are responding to questions in the channel, please respond via a thread unless the answer is a simple yes/no type response that won't have other people chiming in. It's best to err on the side of creating threads in order to keep the "chatter" organized so that it's easier for people to understand what's happening and being worked on.

There will be mentors available to help match people with projects and issues. The mentors are listed on the Drupal 9 porting weekend event page. If you have questions, please do not send direct messages to the mentors unless there is a Drupal Code of Conduct issue that you need help with. You can send questions directly in the #d9readiness channel. You don't have to be a mentor to answer questions. If you know the answer and have time to respond, please do so.

Do you want to help out during porting weekend but don't want to think about it until then?

No worries! Show up in the #d9readiness Slack channel and announce your arrival along with what you'd like to help with. If you don't know how to help, that's okay too. The mentors can find something for you. :)

Do you like the idea of helping but haven't done it before and you're not sure you'd like to participate?

No pressure! Join the #d9readiness Slack channel and watch in real time as people contribute together. It's okay to just hang out and see how it happens. You won't be forced to do anything but, who knows, maybe you'll change your mind and jump in after all. :)

Note: If you are interested in livestreaming the event on Twitch.tv or similar, let us know via the Slack channel. Thanks to Ofer Shaal for this great idea!

Have you prepared any websites or contributed projects for Drupal 9 already? Or helped with Drupal 9 compatibility issues in the issue queues?

Nice! We could use your guidance. If you are up for mentoring at this event, contact Gábor Hojtsy and let him know what days and times (with time zone) you can cover. Even if you can only help for an hour or two, that's okay! Ideally, we'd love to get 1 to 2 people covering all times across all time zones over the 2 days. You can check the current coverage on the Drupal 9 porting weekend event page.

After you sign up, make sure to join the #d9readiness Slack channel and arrive during your planned time. If there are other mentors there already, check in with them to see if they need any help with anything. Otherwise, scroll backwards in the Slack channel to catch up on what's been happening and if anyone has asked for help and didn't get a response.

How you mentor others will depend on what they need help with. Someone might need help finding an issue or project to work on. Another might have a technical question when reviewing a patch. If you are worried you might not know how to answer all the questions, it's okay! If you don't know the answer, just let them know and, if possible, see if someone else in the channel knows the answer. This is how we learn together.

If time allows, we hope to have an up-to-date list of issues to start with at the beginning. Stay tuned in the Slack channel for more information about this.

Are you good at searching the issue queues?

Searching the issue queues for existing issues is a very valuable skill that should not be underrated. Sometimes we might forget to check if there is already an issue for our Drupal 9 compatibility problem and create a new one and we end up with duplicates. It happens to the best of us. I've done it myself!

Maybe you aren't up for doing any issue patching, reviewing, or testing but would be happy to look for existing issues or see if issues are duplicates and close out the extras. We'd love that type of help! If you would like to focus on this aspect of contribution, here are some tips:

Check the Drupal 9 plan of the project

A thousand projects set their Drupal 9 plans up for their project pages. Project maintainers can do this by editing their project manually. If a Drupal 9 plan is provided, and it does not say the project is Drupal 9 compatible already, it would be the best starting point for finding the related issues. There still may be other issues that need triage though.

Searching the issue queues

If there was no Drupal 9 plan or even if there was a Drupal 9 plan, looking for other issues may turn up things you can clean up. You'll want to use the "Advanced search" when searching the queue and make sure to look for all issues rather than just open issues. I've made the mistake before where I was only looking at open issues and missed ones that were fixed but closed.

Keep in mind that some issues are tagged with "Drupal 9 compatibility" but not all are. In some cases, issues won't be tagged at all. There is an old tag called "Drupal 9 readiness" that was mistakenly used. If you find relevant issues that aren't tagged with "Drupal 9 compatibility", you can add the tag as you come across them. Only remove the "Drupal 9 readiness" tag if the issue is tagged with "Drupal 9 compatibility".

The issue titles aren't consistent so you'll need to search for various keywords within a project's issue queue, e.g. "drupal 9", "compatibility", "deprecated", "deprecation", "port", "update", "readiness", "core_version_requirement". Searching for these types of keywords using the "Advanced search" should help you find most, if not all, relevant issues.

If you need a refresher on the issue status codes, the "Status settings of issues" documentation is helpful. For the porting weekend, it would be good to work on issues with "Active", "Needs work", and "Needs review" statuses. You can also double check that the "Reviewed & tested by the community" (RTBC) issues were actually reviewed and tested by someone before moving to the RTBC status. The person adding the patch should not set the issue status to RTBC themselves.

What do these issues look like?

It's good to be familiar with what these Drupal 9 compatibility issues typically look like. Here are some examples with their current status as of May 16, 2020:

  1. Info.yml file core_version_requirement changes
  2. Deprecations
  3. Miscellaneous

What issues can be closed?

It's important to only close issues if you know they are duplicates or are irrelevant. If you find more than one issue where they are for the same thing (e.g. updating the info.yml file), then you'll have to assess which, if any, should be closed. This is a judgment call that's handled on a case-by-case basis.

Example 1: Both issue 1 and issue 2 are for info.yml file changes. Neither have had any work on them or any comments. In this case, I'd keep the first issue and close the second as a duplicate and specify the first issue in the "related issue" field on the second issue.

Example 2: Issue 2 had work done on it and has a patch and issue 1 doesn't have any work done yet. In this case, I'd keep the second issue and close the first and specify the first one in the "related issue" field of the second issue.

Example 3: Both issue 1 and issue 2 have had work done. This one is trickier. If it's obvious who did the work first, I'd close out the later issue and add the "related issue" to the other one. If it's not obvious which should be closed, I'd add a comment to both issues and set both of them up to be related to each other.

Example 4: This is a scenario that happened to me recently. Issue 1 was for the info.yml file and issue 2 was for dealing with the jQuery library dependency. Issue 1 had a patch and was RTBC. Issue 2 eventually added the info.yml file fix into the patch for the jQuery dependency changes. This made issue 1 a duplicate so it was closed. The person who did the patch for issue 1 was given an issue credit on issue 2 even though they didn't work directly on that issue. (Issue credits can only be assigned by project maintainers, so when working on issues of projects you don't maintain, please leave a note suggesting to add the appropriate credit for the issues you closed).

When should issues be created?

If it's clear from searching the project's issue queues that there are no existing issues for Drupal 9 compatibility, the next step is to double check using the Upgrade Status module. This can be done using simplytest.me or your local machine.

If it's a module, you would enable the module you want to check and enable the Upgrade Status module. Then you would check the Upgrade Status page for the module's Drupal 9 compatibility info. Ideally, you would check the module's most recent release as well as the module's dev version. This is because it's pretty common for compatibility fixes to be in the dev version but not in an official release yet.

It is useful to have the dreditor Chrome browser plugin when creating issues so that you can follow the issue formatting guidelines. But, don't let this keep you from creating issues. You can look at this issue example for formatting.

Please tag all Drupal 9 compatibility issues with the tag "Drupal 9 compatibility" and, if you are working on it during the porting weekend also tag it with "Drupal 9 porting weekend". Please do not tag it with outdated tags like:

  • "D9 readiness",
  • "Drupal 9 readiness",
  • "Drupal 9",
  • "D9 update",

or create new tags. It is difficult to find issues when lots of different tags are used. Other tags that may be relevant to add are "Novice", "Needs tests", "Needs manual testing", "Needs reroll", and "Needs issue summary update".

Are you a developer interested in creating or updating code patches?

For some projects there are already patches ready for review and testing but, for others, new patches need to be created manually or using the drupal-rector utility or the Upgrade Rector module.

Note: It is very important to check the issue queue first to make sure you are not creating duplicate patches.

Using a local development environment

To create and update code patches locally, you have a number of options. I'm agnostic on local development tools and have used LAMP, MAMP, MAMP PRO, Lando, and DDEV at one time or another. I've known others who've successfully used Docksal and WAMP.

Pick your favorite or try something new. If you want to be more efficient during the porting weekend, I highly recommend you set up your local environment a few days beforehand. You'll want to make sure you know how to "blow away" your testing site easily and recreate it.

Generating patch files

If you are new to creating patches for Drupal projects, I highly recommend scanning the Advanced patch contributor guide. Since I don't create patches regularly, this is where I go to refresh my memory every time I make one.

For additional information for creating patches manually or using Drupal Rector, Tsegaselassie Tadesse (tsega) wrote a great post for the event: "How to prepare for Drupal 9 Porting Weekend".

Are you a developer who understands Drupal coding standards and has an eye for detail?

For every patch that gets committed, it's best practice for someone who didn't write the patch to review the code. Code patches might be simple, one-line changes or complex changes that span many files.

The patches we are focused on for the porting weekend will be mostly deprecation patches and info.yml file patches. Sometimes these are combined into one issue and sometimes they are split out. You can review some example issues above. For the info.yml file patches, these are trivial to code review. Ideally, someone should test the patch as well before marking these issues RTBC.

For reviewing deprecation patches, you'll likely need to check the change record for the deprecation to see if the code is updated properly. Some of these are pretty straight forward such as replacing drupal_set_message with the Messenger service while some will be more involved like handling the removal of jQuery UI from Drupal core.

If the changes look good and you have time to successfully test the patch as well, the issue can be marked RTBC. If you review it but don't test it, add a comment with your notes and make it clear that it still needs manual testing and add the "Needs manual testing" tag. If the patch needs changes, add your comment with feedback and move the issue back to "Needs work".

When doing code reviews, it's very useful to use the dreditor Chrome browser plugin". This will provide a UI for reviewing the code as well as some shortcuts when editing your comment.

Do you like testing things?

Manual testing is a vital part of fixing issues. For each project that's made Drupal 9 compatible, we need people to try out the updates to make sure they don't break anything. How you test depends on the project. Some will be easy to test and some won't be. Ideally, you'll need to be familiar with the contributed project features to test properly though, for simpler projects, looking through the project page and README file might be enough to get you going.

Testing using simplytest.me

In many cases, you can test using simplytest.me. If you haven't used this wonderful tool, you've been missing out! There are times when I don't want to install a site locally but want to contribute by testing a patch. This is very common for me right now because my laptop is almost out of disk space. ;) But, it could be that you are on a computer that doesn't have a development environment set up or you just don't want to set one up for whatever reason.

If you'll be using simplytest.me, I highly recommend installing the dreditor Chrome browser plugin so that when you see patches in the issue queue, you'll see a SIMPLYTEST.ME button. Click that and it will open a new tab with the relevant project and patch. You don't have to install the plugin though; you can go directly to simplytest.me and choose the project and add the link to the patch.

Note, at the time of writing, simplytest.me is working for testing Drupal 8 versions but not Drupal 9. For contributed projects that are sticking with a Drupal 8 version and making that version Drupal 9 compatible, then you can test the Drupal 8 version on simplytest.me. For projects that are making a Drupal 9 version, then you'll need to test locally. If you are able to help with updating simplytest.me for Drupal 9 support, please contact Adam Bergstein (@nerdstein) in the #simplytestme Slack channel.

Side note: When testing core patches, something to double check is that you are testing the correct version. The version selected automatically on simplytest.me is the same as the version on the issue. This isn't always the version for the patch you are testing. This is not a problem with contributed project issues as long as the version on the issue is correct.

Testing with a local development environment

If you want to test locally, you have a number of local development options. One advantage of local testing compared to simplytest.me is that it's usually faster to spin up and refresh your site in between testing different patches. With local testing, you can also test what happens when you are on an older version of the project and update the code with composer.

Reporting your results

As you manually test a project's features, it's good to take screenshots of key things as you go so that you can upload a select number in your comment. You don't have to take tons of screenshots, but you especially want to screenshot any bugs you find during testing and also copy any error text you encounter.

When you are done testing, it is very helpful to explain your steps in a bulleted list. For example, here's a Smart Trim issue comment I added with steps to reproduce and screenshots. Bonus points if you add the testing instructions to the issue summary so it's easier for others (and yourself!) to find it later.

Please add information about your testing to your issue comment instead of a "works for me" type comment. It is much more helpful to know what you tested, if it worked as expected or not, error text if available, and select screenshots showing it working or not working.


Big thanks to Gábor Hojtsy and Ofer Shaal for reviewing and fine-tuning this post. It takes a village to make Drupal its best! We hope you join us for Drupal 9 porting weekend, no matter how you'd like to participate.

Image credit: Aaron Deutsch

p.s. Apologies, my old website is still on Drupal 6 and looks particularly bad on mobile. I've only started posting here again after many years and I've been very busy reviewing Drupal 9 patches and surviving a pandemic. :) Please ignore the cobbler's old shoes for now, thanks!

Apr 29 2020
Apr 29

These are the steps I went through on "Drupal 9 porting day" on April 28, 2020, which was initiated by Drupal core "Initiative coordinator coordinator", Gábor Hojtsy. It was focused around timezones: Australia & New Zealand, Europe, and Americas.

Image credit: Aaron Deutsch

I'd like to dedicate this post to Hook 42 and to my family in lockdown (sons Aaron & Jacob, husband Josh, and mom Merleigh). Hope everyone reading this is healthy and safe!

Please pardon my super crude Drupal site (especially if you are on mobile)! I haven't written blog posts here since 2013, and it's running on Drupal 6! o_O Yes, the cobbler needs new shoes, and I hope to get some in the next few months. Meanwhile, this was important and timely enough information that I didn't want to wait to update the website before putting it out into the world. And, it's pretty ironic I'm writing about Drupal 9 patches on a D6 site ;)

Thank you!

Huge thanks to Gábor for the porting day idea and coordination as well as the amazing #DrupalCares Drupal 9 module challenge! The Drupal community is very lucky to have you.

Also a big thanks to the many porting day coordinators and participants listed in order of Slack participation (if I missed someone, please ping me on Twitter or Drupal.org and I'll try to add quickly): heddn, xjm, berdir, longwave, mondrake, penyaskito, ccjjmartin, drumm, damienmckenna, nterbogt, larowlan, shrop, kimb0, dww, surabhi.gokte, Peter Wong, jungle, Ankush Gautam, Ankush Gautam, Ankit Pathak, VladimirAus, mirom, dan2k3k4, klausi, Kiran Rao, geerlingguy, DuaelFr, renatog, svenbergryen, neetumorwani, shaktik, bircher, Matroskeen, alexpott, Jeevan, Atul Sharma, Manuel Garcia, piyuesh23, Nitish Singh Guleria, wizonesolutions, rahulrasgon, renatog, Paulo Calaes, JayKandari, Amit Sharma, Sonal, Matroskeen, Tejas Shah, kristen_pol, nerdstein, Nitesh, jrockowitz, mikelutz, jurgenhaas, eojthebrave, KarinG, Leeotzu, mixologic, japerry, Vishal Chaudahry, mikelutz, Aimee Rae

Step 0: Resources used

There are a lot of Drupal 9 resources out there but here's what I focused on for the porting day:

  1. Slack readiness channel
  2. Drupal 9 compatibility contribution quickstart guide
  3. Drupal 9 Deprecation Status
  4. drupal-check
  5. Upgrade Status
  6. drupal8-rector
  7. Upgrade Rector
  8. Running PHPUnit tests
  9. State of Drupal 9
  10. Various Drupal issue queues and change records

Image credit: Gábor Hojtsy

Step 1: Checking in via #d9readiness

I woke up early due to an Ash-throated Flycatcher repeatedly pecking the window. Since my family was asleep, I checked the #d9readiness Slack channel to see what was going on. I saw a message from Gábor asking if anyone needed help picking a project to work on. Someone else said they wanted help finding a project, and Gábor suggested they look at projects from "group 100" in the Drupal 9 Deprecation Status report that only need info file updates. Earlier others had already been looking at "group 50".

I chimed in saying that I couldn't sleep so would try to find one from the list as well. I went to get (decaf) coffee (yes, I know) and more importantly chocolate to keep me going. The person asking for help chatted that they couldn't find anything in "group 100" so they were going to start looking in "group 200". So that is where I started. (Side note that it did turn out there were projects in "group 100" that could have been worked on but I found that out after picking something from "group 200".)

Step 2: Looking at an existing Slack thread for example

Gábor suggested looking at a Slack thread to see the process with a real example for D8 Editor Advanced link module. He went through the analysis roughly as follows:

  1. Searched issue queue and found existing D9 deprecated report that showed no errors: https://www.drupal.org/project/editor_advanced_link/issues/3042615
  2. Checked in the dev code that the info file hadn't been updated yet
  3. Scanned the dev code and found it was "very simple"
  4. Suspected there might be JavaScript deprecations but they were using core so "ok"
  5. Double checked deprecations with Upgrade Status module to get a more complete picture (has more detail than drupal-check) and found no issues
  6. Concluded that only the info file needs updating
  7. Was going to submit an issue for the info file but found existing one: https://www.drupal.org/project/editor_advanced_link/issues/3105317
  8. Added comment with review process and tagged the issue with "Drupal 9 porting day": https://www.drupal.org/project/editor_advanced_link/issues/3105317#comme...
  9. Pinged a project maintainer via Slack to see if it could be committed
  10. Maintainer is busy but will hopefully will commit it soon
  11. End of work on this project... time to move to another one :)

Step 3: Finding a project

Needed to find a project that isn't D9 ready but isn't being actively worked on by others.

  1. I went to "Drupal 9 Deprecation Status" for <=500 for projects that appear to only need info.yml file updates

    Although I was only looking specifically at <=500 for info.yml file issues, you can find all projects that need an info.yml file update or all projects that still need any type of work for Drupal 9 compatibility.

  2. Decided to work backwards from the end of the list of "Group 200" because other people are probably going in top-to-bottom order. This is the order I will check:
    • views_accordion 1.3
    • override_node_options 2.4
    • ckeditor_font 1.0
    • workbench 1.1
    • field_formatter_class 1.1
    • contribute 1.0-beta8
    • block_content_permissions 1.8
    • auto_entitylabel 3.0-beta2
    • menu_admin_per_menu 1.0
    • search_api_autocomplete 1.3
    • media_entity_browser 2.0-alpha2
    • username_enumeration_prevention 1.0
    • colorbutton 1.1
    • panelbutton 1.2
    • real_aes 2.2
    • schema_metatag 1.4
    • antibot 1.3
    • token_filter 1.1

  3. Checking views_accordion

Step 4: Info patch review

The info patch was the easiest to review so I started there:


  1. Read through the change record for the change


  2. Reviewed the patch and, for Drupal 8, the patch is correct (note that for D9, the info file will need to be updated)

  3. Tests are failing so checked the note from @katherined about $defaultTheme and confirmed that it's fixed in the other issue (see below)

  4. Downloaded the module code

    git clone --branch 8.x-1.x https://git.drupalcode.org/project/views_accordion.git

  5. Downloaded the patch

    wget https://www.drupal.org/files/issues/2020-03-21/3100388-3.patch

  6. Applied the patch
    [mac:kristen:views_accordion]$ patch -p1 < 3100388-3.patch
    patching file views_accordion.info.yml
  7. Added comment with findings and unassigned issue


Step 5: Checked back into with the #d9readiness channel

It's a good thing to check in with the relevant Slack channel regularly if you are doing a sprint or contribution day. Fortunately I did because I saw @penyaskito pointed to an earlier message from the module maintainer, @Manuel Garcia, related to the issue I was about to review.


They were worried the patch might break existing installations. The thread had a helpful discussion with @berdir and @penyaskito on how to proceed. This is a great example why the Drupal community is amazing!

Step 6: jQuery UI patch review

Besides the info file, there was a blocker for D9 compatibility due to the use of jQuery so I moved on to reviewing the related patch:


  1. Reviewed the change records
    • https://www.drupal.org/node/3064015 - "Modules and/or themes depending on jQuery UI should remove it as a dependency and manage their own libraries."
    • https://www.drupal.org/node/3067969 - "The jQuery UI asset libraries not in use by Drupal core have been marked deprecated and will be removed from core in Drupal 9." Note: has an explicit example for switching to the jQuery UI Accordion module
  2. Reviewed the patch against the example in the change record
    1. Info file is updated with dependency: jquery_ui_accordion:jquery_ui_accordion
    2. Reference of core/jquery.ui.accordion changed to jquery_ui_accordion/accordion in libraries file
    3. Fixed failing tests by adding:
      protected $defaultTheme = 'stark';
    4. Also updated composer.json with dependency:
      "drupal/jquery_ui_accordion": "^1.0"
    5. Looks good
  3. Downloaded patch

    wget https://www.drupal.org/files/issues/2020-03-21/3100388-3.patch

  4. Applied the patch successfully (note that it was applied on top of the info file patch to see if they were compatible)
    [mac:kristen:views_accordion]$ patch -p1 < 3091388-6.patch
    patching file composer.json
    patching file tests/src/Functional/ViewsAccordionTest.php
    patching file tests/src/FunctionalJavascript/ViewsAccordionTest.php
    patching file views_accordion.info.yml
    Hunk #1 succeeded at 5 with fuzz 1 (offset 1 line).
    patching file views_accordion.libraries.yml
  5. Searched the code for "jquery.ui.accordion" after applying the patch and found a reference to it in the documentation
  6. Added comment, marked "Needs work", and unassigned
  7. Next steps needed are to update this patch with minor change and manually test the updated patch and the info file patch together on Drupal <8.7.7, 8.8, and 9 (optionally, an update function could be added for the new module dependency)

Step 7: Review project page

Note that this should have been done before step 4 but I forgot to check until after reviewing the issues I found by manually looking at the issue queue.

Project maintainers can add Drupal 9 information and link to relevant issues as noted by in https://twitter.com/DropIsMoving/status/1130868996771844096. Adding D9 information to the project page will potentially help the previous two issues get worked on faster and avoid duplicate issues.

  1. Reviewed the views_accordion page for D9 info but nothing was there


  2. Checked the issue queue to see if a related issue was already created but didn't find anything relevant


  3. Created an issue to add the Drupal 9 info to the project page and tagged it for "Drupal 9 porting day" and "Drupal 9 compatibility"


Step 8: Install D8 site to check deprecations

For this round, I decided to use simplytest.me to check again for deprecations after adding the jQuery patch above, the jQuery UI Accordion module, and the Upgrade Status module. Note that initially I applied both patches but got an error that I created an issue for: https://www.drupal.org/project/simplytest/issues/3131964

  1. Go to https://simplytest.me/
  2. Open "Advanced options"
  3. Type "views_accordion" for "Enter a project name" text field
  4. Choose 8.x-1.x for version
  5. Click "Add an additional project" button
  6. Type "jquery_ui_accordion" into text field
  7. Click "Add an additional project" button again
  8. Type "upgrade_status" into text field
  9. Click "Add a patch" button
  10. Copy/paste the patch file URL


  11. Click "Launch sandbox" button
  12. Wait for simplytest.me to finish installing
  13. Success! You'll get a URL similar to:


  14. Log into site (admin/admin)
  15. Go to Upgrade Status report at /admin/reports/upgrade-status

  16. Go to the CONTRIBUTE PROJECTS section

  17. Choose Views Accordion
  18. Click "Scan selected" button
  19. Found 5 warnings
  20. Click on warnings link to view warnings and really found 3 things
    1. Class Drupal\Tests\BrowserTestBase not found and could not be autoloaded.
    2. Class Drupal\FunctionalJavascriptTests\WebDriverTestBase not found and could not be autoloaded.
    3. Add core_version_requirement: ^8 || ^9 to views_accordion.info.yml to designate that the module is compatible with Drupal 9. See https://drupal.org/node/3070687.

  21. I assume a and b are due to running via simplytest.me (I looked at other deprecation issues and didn't see anyone "fixing that") and c is handled by the other patch so this should be covered
  22. Updated Slack channel thread with note about the autoload warnings

Step 9: Go to bed :)

I was hoping to do more poking around but it got late and I got tired. So… this will have to do. I updated this blog post and went to bed. :)


p.s. I'm zonked so probably made some mistakes... please let me know if you find any.

Jun 07 2013
Jun 07

I'm working with the Private Message module and applied a patch for Views integration from dawehner (yay!). The patch works pretty well so I was able to create an admin dashboard that shows private messages and lets you filter the messages by subject text, body text, has been read, etc.

Then, I noticed that messages with the same message id were showing up in the results. This is because you get one private message sent to the recipient and one "sent" to the author (i.e. you get a copy for yourself when sending private messages). Ok, easy enough (I thought). I enabled Distinct in Views but that didn't work. Then I enabled Pure Distinct but that didn't work either. Bummer.

Ok, so then I remembered something about using aggregation in Views so I enabled Aggregate. Then all my results were gone except for one :/ I started googling and eventually found an issue comment that says you can't use Aggregate with Pure Distinct. Oh!

So... I turned off of Pure Distinct and low and behold I only had one result for each message id. Great! Until I looked more carefully. The "From" (author) and "To" (recipient) fields were the same for some results. Which is what I was trying to get rid of in the first place. Doh!

Then, I decided to scratch the "distinct" method altogether and do a hook_views_query_alter to add the where clause I needed:

where pm_index.recipient != pm_message.author

Should be easy, right? I tried to use the:


but couldn't figure out how to add my where clause. It appears that add_where is similar to DBTNG's condition() which is good for adding where clauses like:

where pm_index.recipient != 43

If you know how to add this where clause in Views, PLEASE LEAVE A COMMENT :) Or, better yet, if you know how to configure Views in the UI to do field1 != field2 that would be awesome!

Then I decided I would use hook_query_alter to add my where clause after Views was done with it. I've used condition() (which isn't what I needed) and looked through the docs and googled couldn't find what to do (maybe I was too tired by this point and claiming defeat :P). Then I had the recollection that I had used addExpression() before so I went down that path (whoops!). That was a dead end.

Meanwhile, I sent my plea to the twitterverse and a wonderful Fox replied with:

outside of views, api.drupal.org/api/drupal/inc…?

Well... silly me. There is a where() in DBTNG too. How did I miss that??? Thanks, Fox!!!

I figured my woes were solved and celebrated in advance :)

Then, I added the wonderfully simple code to my hook_query_alter:

$query->where('pm_index.recipient != pm_message.author');

and this is what ended up in the where clause:

where (11 is NULL) and (pm_index.recipient != pm_message.author)

What the?

I assumed I must have had some query alters left over... I searched and didn't. I assumed there was something wrong with my filters so I looked and all seemed fine (they were all exposed filters so none were in the query string by default). Then I used one of the exposed filters and the "11 is NULL" went away from the query.

I googled the "11 is NULL" thing and funnily enough I see it on some sites that have their query strings exposed on the page (maybe a coincidence?). But, no mention to how it gets there. I checked the Views issue queue for "11 is NULL" and "11" (though that is probably too short) and didn't notice anything obvious.

No worries! I just added a filter (not exposed) that I knew would always be okay. I set a filter so that it only grabbed messages if the body text was not null.

Voila :) Happy dance! After lots of pain and suffering, my view has my where clause added. It only needed 5 simple lines of code:

function mymodule_query_alter($query) {
  if ($query->hasTag('mytag')) {
    $query->where('pm_index.recipient != pm_message.author');

I'm writing this up so that maybe it will help someone even if that someone is just my future self ;)

Note that I removed that body filter to try to reproduce the "11 is NULL" issue and it no longer shows up. So... my guess is that this post will be high in google for "11 is NULL"... if you are seeing this issue, my suggestion is to add a Views filter and then remove it and see the "11 is NULL" goes away ;)

Happy Friday!

Adding some keywords so that people might find this when they are running into a similar problem:

  • compare fields in views
  • compare columns in views
  • field comparison
  • column comparison
  • comparing two fields
  • comparing two columns
AttachmentSize views-field-comparison.png49.21 KB
Aug 16 2012
Aug 16

Here are steps I use to update Drupal site code to the latest core and contrib module versions. This can be done via the command line using drush.

Doing 'drush up' (all by itself) is popular to update the site code but I don't use it. I suppose if you have a *very* simple site with very few modules that are all using pretty recent stable releases, then it is fine. But, I almost never deal with sites like that (except for simple test sites).

More typically, sites will have development versions of contributed modules or modules that shouldn't be updated for some reason and doing 'drush up' can't be used without qualifying what explicitly needs to be updated. For this reason, I use 'drush up [project]' (or 'drush upc [project]') rather than just 'drush up'.

1) Backup database and files directory

To back up entire site (db+files+code), you can use:

> drush archive-dump

Here's a tutorial on using archive-dump and archive-restore:

To just back up the database, you can use:

> drush sql-dump

To zip up the files, you can:

> tar czvf site_files_backup.tgz [path/to/files]

Note: I haven't seen a command for zipping up files via drush though you can create your own drush commands. I use my own scripts to tar up the files (and also for backing up the database).

2) Make sure your repository is ready

Before you start your update, make sure your repository is ready for updates. Resolve any issues before proceeding.

> git status

3) Tag repository and keep note of tag

> git tag [tag-name]
> git push --tags

4) Update Drupal core only

I like to update core separately from contributed modules.

> drush up drupal


> drush upc drupal
> drush updatedb

If you don't want drush to backup the code first (which isn't really necessary when using a code repository), then you can use:

> drush up --no-backup drupal


> drush upc --no-backup drupal
> drush updatedb

You can also use the --no-backup option if you have an error that shows up that is unrelated to your update. Otherwise, the update will roll back if it encounters errors.

5) Apply patches if necessary

If you have any patches that need to be applied, apply them, e.g.

> cd [project]
> patch -p1 < [patch-file]

6) Test your site

Click around and make sure all is well, and check your error log at:


7) Research any errors

If you are getting an error, there might be a patch available to fix it so search for your error via Google or your search engine of choice. If you find a patch, try it out and see if it fixes the problem. If it does, make sure to marked the issue RTBC (if not already) and leave a comment that it fixes your issue. If not, mark the issue as "Needs work" and leave a comment that explains the patch does not fix the issue. In both cases, provide any details you can so the module maintainers and patch contributors have more information to work on the issue.

8) Revert if necessary

If something is wrong and can't be fixed with a patch, revert your site using the tag and backups you just made.

9) Backup site and tag again

If all is well, backup the database and files again. Then commit the changes to repository and tag repository again.

> cd [project]
> git status (to see what files have been changed)
> git add [files] (to add new files)
> git commit .gitignore .htaccess *
> git push
> git tag [tag-name]
> git push --tags

10) Update contrib modules one-by-one or in batches

I don't update all modules at once because typically there are some modules that should not be updated because development versions are being used or custom patches have been applied.

It is a good idea to check the release notes of a module before updating to see if there are any significant changes that require extra testing.

You can update each module and test/backup/commit/tag in between each update (time consuming) or you can update batches of modules (easier). If there are modules that might cause problems, those should be updated separately (and last).

> drush upc [module1] [module2] [module3]

Then apply patches if needed and run the database update, e.g

> drush updatedb

This works for theme updates too, e.g.

> drush up [module1] [theme1] [module2]


> drush upc [module1] [theme1] [module2]
> drush updatedb

11) Repeat steps 6 to 9

* Test your site
* Research any errors
* Revert if necessary
* Backup site and tag again

12) Repeat 10 and 11 as needed

If you have a favorite shortcut or method for updating your Drupal code, leave a comment :)

Aug 02 2012
Aug 02

I love the Drupal Admin Menu module (in fact, I almost can't live without it!), but I guess I'm getting old because I find the microscopic font hard to read ;) Others have this problem as well, but it hasn't been made configurable yet, so here are your options:

0. Use the Admin Menu Toolbar

Admin Menu comes with 2 options. If you just enable the main Admin Menu module, then the font is small. If you enable the Admin Menu Toolbar module, then the font is bigger and matches the core Toolbar better. The Admin Menu Toolbar module used to be kind of buggy but I tried it recently and it was working pretty well. Just make sure to disable the core Toolbar module afterwards or you'll have 2 toolbars.


  • Easy to do.
  • No CSS required.


  • Requires enabling an additional module. (It really should be the default configuration!)

1. Change the font size in the browser

Most browsers let you adjust your font size. For example, Control + will increase your font in Firefox, Chrome, and others.


  • Easy to do.
  • No CSS required.


  • Must repeat steps when starting new browser windows.
  • Other things on the page increase as well which may or may not be desirable.

2. Modify your custom theme

If you have a custom theme and only need the Admin Menu to be adjusted for that theme only, you can add some CSS to your theme like:

#admin-menu-wrapper a {

and then refresh your caches. Where the CSS goes depends on your theme.


  • Change will affect any page using that theme.


  • Requires a CSS change.
  • You must know how to update your theme.
  • Change will ONLY affect any page using that theme. Other themes are not affected.

3. Modify a custom module

If you have a custom module and want the Admin Menu to be adjusted for all themes, you can add some CSS to your module as follows:

Create mymodule.css

Put this in your mymodule.css file:

#admin-menu-wrapper a {

Update your module code

Update mymodule.module to add the css file upon init:

function mymodule_init() {
drupal_add_css(drupal_get_path('module', 'mymodule') . '/mymodule.css');

and then refresh your caches.


  • Change will affect any page using any theme.


  • Requires coding.
  • You must know how to update your module.

4. Use CSS Injector

If you want the Admin Menu to be adjusted for all themes without a custom module, you can use the CSS Injector module as follows:

  1. Install and enable CSS Injector
  2. Clear the cache
  3. Go to: [yourdomain]/admin/config/development/css-injector
  4. Click create a new rule
  5. Add a Title (e.g. Admin Menu Font Size Adjustment) and the CSS, e.g.

    #admin-menu-wrapper a {

  6. Click the Save button.


  • Change will affect any page using any theme.
  • No custom theme or module is required.


  • Requires an extra module.

5. Get a magnifying glass!




  • You might lose it.

Cheers and happy eyes!

Jul 19 2012
Jul 19

Here are my notes for setting up a brand new Linux/Ubuntu server for Drupal development. If you are cool with the command line, then you might find this handy.

1. Install Apache/MySQL/PHP via tasksel

Reference: https://help.ubuntu.com/community/ApacheMySQLPHP

> sudo apt-get update
> sudo apt-get install tasksel
> sudo tasksel install lamp-server

You will be asked to provide a mysql root password.

Test installation worked:

> apache2 -v
> mysql --version
> php -v

2. Install gd

Reference: http://www.cyberciti.biz/faq/ubuntu-linux-install-or-add-php-gd-support-...

> sudo apt-get install php5-gd
> sudo service apache2 restart

Test installation worked:

> php5 -m | grep -i gd

3. Install mail server via tasksel

Reference: http://askubuntu.com/questions/54960/how-do-i-set-up-an-email-server

> sudo tasksel install mail-server

You will be required to provide the main/default domain for your server, e.g. example.org

Test installation worked:

> echo "This is a test." | mail -s Testing [email protected]

4. Enable Apache mod_rewrite for clean URLs

Reference: https://www.drupal.org/node/1572984

> sudo a2enmod rewrite

This will create a link from /etc/apache2/sites-enabled/rewrite.load to /etc/apache2/sites-available/rewrite.load.

> cd /etc/apache2/sites-available
> sudo cp default default.orig
> sudo vi default

Search for 'AllowOverride None' and change 'None' to 'All' and save.

Repeat for default-ssl.

> sudo service apache2 restart

This will be tested once Drupal is installed.

5. Install Drush

Reference: https://www.drupal.org/project/drush

> sudo apt-get install php-pear
> sudo pear channel-discover pear.drush.org
> sudo pear install drush/drush

Test drush:

> drush

If you get a message that Drush needs to download a library, do:

> sudo drush
> sudo chown -R [youruser]:[youruser] ~/.drush/cache

or download/install library yourself

Test again:

> drush

6. (optional) Install phpmyadmin

Reference: http://www.allaboutlinux.eu/how-to-install-drupal-7-on-ubuntu/3/

I don't use this, but you can install with:

> sudo apt-get install phpmyadmin

7. Install Drupal via drush

Reference: http://drush.ws/help/5#site-install

Make it so admin users can create directories in /var/www:

> cd /var
> sudo chgrp [admin-group] www
> sudo chmod 775 www

Install Drupal:

> cd www
> drush dl drupal
> mv [drupaldir] [sitedir] (e.g. mv drupal-7.14 examplesite)
> cd [sitedir]
> drush site-install standard --db-url='mysql://root:[email protected]:port/dbname' --site-mail=[site-email] --site-name=[site-name] --account-mail=[account-email] --account-name=[account-name] --account-pass=[account-password]

8. (Alternative to drush Drupal install) Install Drupal manually

Reference: https://www.drupal.org/documentation/install/download

  1. Grab Drupal zip file from https://www.drupal.org/project/drupal.
  2. Unzip and rename/move directory to /var/www/[sitename]
  3. Create database in mysql, e.g.

    > mysql -u [user] -p[password]
    > create database [database-name];
    > exit;
  4. Copy /var/www/[sitename]/default.settings.php to /var/www/[sitename]/settings.php and make writable with:

    > cd /var/www/[sitename]/sites/default
    > cp default.settings.php settings.php
    > chmod a+w settings.php
  5. Create files directory with:

    > cd /var/www/[sitename]/sites/default
    > sudo mkdir files
    > sudo chown [admin-user]:www-data files
    > sudo chmod 775 files

    I used to use 'chown www-data:www-data files' but the ownership shown above for files works best with drush: https://www.drupal.org/node/759970

  6. From browser, go to: http://[yourdomain]/[sitename]/install.php
  7. Run through installation process

9. Check out your new site!

Go to http://[yourdomain]/[sitedir] in a browser to see your new Drupal site. Login using the account name and account password used above.

To see if clean URLs are working, go to http://[yourdomain]/[sitedir]/user or any other page that should be accessible.

10. (optional) Install git

Reference: http://docs.oseems.com/operatingsystem/ubuntu/install-git-client

Since I use git for development, I'll add that too:

> sudo apt-get install git-core

Check installation worked:

> sudo git --version

I use git on the command line but there are a number of GUI-based git clients including gitk, giggle, git-cola, git-gui, and gitg.

When setting up git repositories, use:

git config --global branch.autosetuprebase always

from Randy Fay's article on automatic git rebasing.

11. (optional) Install debugging, testing, and performance tools of your choice

Here are some from: https://klau.si/dev

> sudo apt-get install php5-xdebug php5-curl php-apc

Add a comment with your favorite debugging and testing tools...

12. (optional) Create public ssh key

I use a public ssh key so that I can login to other machines easily and access git repositories that require keys.

> ssh-keygen -t rsa

Use a passphrase if desired.

It will create a file .ssh/id_rsa.pub. Copy the .ssh/id_rsa.pub contents to the .ssh/authorized_keys file of the machine you want to connect to or to any repository host services.

Also copy any .ssh/id_rsa.pub contents from other machines to this new server's .ssh/authorized_keys so that connecting will be easy.

13. (optional) Copy bash files from other machine

I have a lot of bash settings and aliases configured that I like to use on all my development machines.

Copy .bash_profile, .bashrc, .bash_logout, and .bash_aliases from an older machine to the new one.

It is easy to get confused which machine you are on, so I usually update the .bash_profile file so that the prompt starts with a custom string to indicate this, e.g.

PS1="[mydev:\u:\W]\$ "

This will show the user for the \u and the leaf directory for the \W.

14. (optional) Copy vim settings from other machine

I'm using vim for editing and need to copy the .vimrc file and follow the directions to install the Drupal vimrc project .vim files:

> cd
> wget https://ftp.drupal.org/files/projects/vimrc-7.x-1.x-dev.tar.gz
> cd .vim
> tar xzvf ~/vimrc-7.x-1.x-dev.tar.gz --strip-components 1 --exclude=README.txt

To use ctags in vim:

> sudo apt-get install exuberant-ctags

Check installation worked:

> ctags --version

15. (optional) Copy existing Drupal site to new server

Often I need to pull over one or more Drupal sites to my new machine like the following. I have scripts that do many of these steps, but this is a manual way to do it:

On old machine:

  1. Create a dump of site database:

    > cd [path-to-drupal-site]
    > drush cc all
    > mysqldump -u[user] -p[password] [database-name] > mydbdump.mysql
    > gzip mysqldump.mysql
    > mv mysqldump.mysql.gz ~
  2. Create a tar ball of site files:

    > cd
    > tar czvf myfiles.tgz [path-to-drupal-site]/sites/default/files
  3. Copy database .gz file and files .tgz file to new server

On new machine:

  1. Set up code:

    > cd /var/www
    > git clone [user]@[domain]:[project] [sitedir]
  2. Set up database:

    > cd
    > mysql -u [user] -p[password]
    > create database [database-name];
    > exit;
    > gunzip mydbdump.mysql.gz
    > mysql -u [user] -p[password] [database-name] < mydbdump.mysql
    > mysql -u [user] -p[password] [database-name]
    > show tables;
    > exit;
  3. Set up files:

    > cd /var/www/[sitedir]/sites/default
    > mv ~/myfiles.tgz .
    > tar xzvf myfiles.tgz
    > sudo chown -R [admin-user]:www-data files
    > sudo chmod 775 files
    > sudo chmod -R g+w files
  4. Set up settings.php:

    > cd /var/www/[sitedir]/sites/default
    > cp default.settings.php settings.php
    > vi settings.php
    [edit mysql user, password, and database]
  5. Clear cache and try it:

    > drush cc all

    Go to http://[yourdomain]/[sitename]

16. (optional) php.ini settings

Reference: https://klau.si/dev

If this is for a development-only machine, the php.ini file can be adjusted to help with debugging, etc. Don't make these changes for non-development servers.

memory_limit = 256M
error_reporting = E_ALL | E_STRICT
display_errors = On
display_startup_errors = On
track_errors = On
html_errors = On
session.gc_probability = 1

17. (optional) Update settings.php with development settings

If you don't want to mess with your global php.ini settings (#16 above), then you can set these php settings within each Drupal site's settings.php file. You can also set variables such as turning off caching, e.g.

// display all errors and set high memory!
error_reporting(E_ALL | E_STRICT);
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);
ini_set('track_errors', TRUE);
ini_set('html_errors', TRUE);
ini_set('memory_limit', '256M');

$conf['securepages_enable'] = 0; // don't use secure pages
$conf['preprocess_js'] = 0; // don't zip js files
$conf['preprocess_css'] = 0; // don't zip css files
$conf['cache'] = 0; // no page caching
$conf['block_cache'] = 0; // no block caching
$conf['googleanalytics_account'] = "UA-XXXXXXX-X"; // don't track in GA

18. (optional) Create additional users

If you need more user accounts on your development server, first create the account and set the password:

> sudo useradd -d /home/[username] -m [username]
> sudo passwd [username]

Then add the user to the desired groups and verify the groups:

> sudo usermod -a -G [group] [username]
> id [username]

If anyone knows how to do any of these steps in an easier or different way or there are steps that you think are missing, feel free to leave a comment.
May 24 2012
May 24

It's a Drupal site... it's good if you actually know Drupal

I'm working on a Drupal 7 project right now where the site was built by another company. This isn't the first time I've “inherited” a project, and I'm sure it won't be the last. Before this project, my other experiences with taking over existing Drupal sites weren't terrible. Yeah, there were issues with the sites and things could have been better architected but, on the whole, I could jump in and figure out how things were glued together and fix issues or make improvements as needed without too much head-scratching.

This project, on the other hand, might send me to the doctor due to deep wounds in my scalp! Ugh. And, unfortunately, I pretty much saw it coming. The folks who built this Drupal 7 site weren't Drupal developers at all. They were Ruby developers. I don't know anything about Ruby but, I do know if I was asked to build a complex site with Ruby on Rails, I would graciously decline the request and, ideally, point the would-have-been client to a better fit.

Unfortunately, the Ruby development company didn't do such a thing and decided to build this Drupal 7 site... making them unhappy (they built such a strange beast and then their client left them), making their ex-client unhappy, and ultimately making every developer who has to touch the site unhappy too. I keep trying to find out how certain things were implemented and thinking... “WTF, why did they do that?” Or... “It would have been so much simpler if they had done xyz instead.” And, so forth.

Which got me thinking...

There aren't a lot of resources I've come across that give tips and strategy on application or site architecture in Drupal. You can find tons of “how tos” on Views or Panels or Drush, but what about discussions of when to use or not use Panels or what content should be in a block versus a node versus a Panel pane or what type of navigation mechanism best serves your site audience.

So, for now, I'm going to sketch out some buckets of things I think of when I'm architecting a new Drupal site. Please leave a comment if you have more ideas or you have good resources for Drupal site/application architecture.

Content is still king and queen...

Content is the reason for a website. Before Drupal 7, content was synonymous with nodes. In Drupal 7, things have been abstracted and content now includes all “entities” such as core entities (nodes, users, comments, and taxonomy terms) and custom “entities” (Commerce products, Organic Groups memberships). And, you can also add content via the configuration of blocks, views (e.g. headers / footers), panel panes, etc..

Knowing where to put your content is a big part of the application architecture in Drupal. Some things will be obvious (user fields should belong to user entities) but some might not be so straightforward such as an address that might be applicable to several pages. In the latter case, the “best” method (or methods) for storing the address information depends entirely on the short and long term use of that content. Just because it is easy to throw something in a block and enable it on a page doesn't mean that is the best solution to the problem.

It is important to think carefully about what type of content you have and how it maps to Drupal's entities and components. Think about how content might be reused across the site or consumed in other ways (email, feeds, search, etc.).

To Panel or not to Panel...

Site structure is another big Drupal architecture item. There are several different approaches to handling the structure and layout of a Drupal site. You can go for out-of-the-box “simplicity” and stick with the core block administration. This would be fine for a very simple site where the layout is the same across the whole site. But, once you need more flexibility, then you'd be better off choosing a different option such as Panels (and friends), custom theme templates, Context+Spaces+Display Suite, etc.

There are always trade-offs when choosing one strategy over another but there tends to be two camps:

  • I love Panels
  • I hate Panels

I happen to fall into the first camp so I haven't ever even played around with Spaces. It would be good to read some intelligent and thoughtful discussions comparing these strategies. I'm sure there are some out there (leave a comment!).

Cross your fingers and press the deploy button...

I wish there was a good, simple, reliable “deploy” button in Drupal. Maybe some day... For now, we have several technologies that we need to consider when thinking about deploying our site from development to staging and from staging to production. Remember that we need to consider deploying both “configuration” and “content.” One way to handle content would be to allow editing on the production site but set up revisioning and workflow logic that makes sense for the site. If you want to edit content on the staging server and then publish that out to the production site, hats off to you if you get that working well (and leave a comment! :).

For the some of configuration pieces, we can use fun tools like Features, Apps, Drush, rsync, Jenkins, Hostmaster/Aegir, etc. Again, there are trade-offs as usual. No doubt your system administrator will have a strong preference on what technologies to use (or not use). Some times the client won't have a preference or sys admin and you will get to decide what to do, and other times there will be little room for creativity.

It's not just the pretty stuff...

One other application architecture bucket is theming. Do you need a mobile-friendly theme, a responsive theme, or an adaptive theme? These all mean different things. Do you want to work on a grid system? Do you want to build a theme from scratch, use a base theme, or take an existing theme and modify it?

Zen is a popular base theme but is very bloated. Some themers like the flexibility available with verbose themes like Zen while others prefer to build themes from scratch so they have minimal markup. This is another area where there are definite “camps” of themers though the number of camps is probably pretty large...

Of course there are more...

I've just touched upon some of the things that I think about before developing a new Drupal site. There are many more things too!

  • Use of taxonomy terms and categorization
  • Navigation structure at different levels of the site
  • On-site search engine optimization
  • Language needs and internationalization

What do you think about?

Leave a comment :)

Apr 18 2012
Apr 18

This post explains how to configure some Drupal Commerce module package functionality for multiple countries and languages. This information was originally going to be part of my Drupal 7 Multilingual Sites book but I ran out of room!


If you need ecommerce functionality for Drupal 7, your choices are Ubercart and Commerce (which is a complete rewrite of Ubercart). It shouldn't matter what your hosting provider is as long as you can install Drupal 7 in the normal way. For my multilingual demo site, I chose the Commerce package since it's new and shiny. I've used Ubercart in the past and it is totally fine. If you want to use Ubercart, there are lots of tutorials as well as a Drupal 6 Ubercart book available by George Papadongonas and Yiannis Doxaras.

The main things to consider for ecommerce localization are product content, currencies, taxation, and shipping. For products, just translate content as needed such as names and descriptions. For currency support, you might allow different currencies depending on your payment processing company. Taxation and shipping charges typically vary depending on the shipping location, so you'll need configure the rates accordingly.

Commerce Product entity type

The Commerce package creates a custom Commerce Product entity type which is used to define a product. To *display* a product, you must create a product display content type with a reference field for one or more products. Ryan Szrama has a great post on configuring product display content types for your Commerce products.

Drupal 7 Multilingual Sites explains how to configure content types for multilingual support using the node translation (via the core Content translation module) and the field translation (via the Entity translation module) methods. You will need to configure your product display content type using one of those methods. And, if there are product fields to localize as well (in addition to product display fields), you also need to configure field translation for the Commerce Product entity type using the following steps:

Configure entity type

  1. Enable the Entity translation module.
  2. Go to Configuration | Regional and language | Entity translation.
  3. Select the entity type, e.g. Commerce Product.
  4. Click Save configuration.
  5. Edit the entity, e.g. for a Book product entity, go to Store | Products | Product types | Book | Edit.
  6. Select Enabled via Field translation checkbox.
  7. Click Save button.

Configure fields

Note that steps 2 to 4 below will change once this Entity translation module patch gets committed: drupal.org/node/1279372. Translations will be enabled/disabled on the main edit page (bottom of form), rather than on the Field settings page.

  1. Edit entity field, e.g. for a Book product entity, go to Store | Products | Product types | Book | Manage Fields and click edit for a field.
  2. Click Field settings tab.
  3. Select Users may translate this field checkbox.
  4. Click Save field settings button.
  5. Repeat for all fields to localize.

Translate content

  1. Edit entity content, e.g. for a Book product entity, go to Store | Products | List and click edit for a particular Book product.
  2. Choose language and save.
  3. Edit entity content again and click Translate tab.
  4. Click add translation link for a language.
  5. Translate content and click Save translation.
  6. Repeat for all languages.

Currencies, taxes and shipping

If you have international customers, you'll likely need to configure currencies, taxes, and shipping for them. Let's walk through this for the Commerce package. Start with installing these modules:


By default, the US Dollar currency is enabled, but it's easy to include other currencies. Navigate to Store | Configuration | Currency settings, click on Enabled currencies, choose your currencies, and click Save configuration.

This is the same place you can change your store's default currency, if desired. Once the currencies are enabled, you can use them when adding products, shipping rates, etc.

For example, I used Euros for a book price and now it shows up looking very European!

To extend the Commerce currency support, try out the Commerce Multicurrency module. It lets you define exchange rates, synchronize rates with the European Central Bank, and provides hooks to add custom exchange rates. Nice!

What currency the actual payment process uses will depend on your payment methods and what they support. For example, you can set up Commerce Paypal or Commerce Authorize.Net modules to use the currencies you have on your site. That way a customer can buy a product in Euros, US Dollars, etc. For more payment options, check out the Drupal Commerce payment FAQs.


To configure taxes, navigate to Store | Configuration | Taxes and click Add a tax rate. You'll see a form to add the tax information such as the rate and type of tax (e.g. Sales Tax, VAT tax). Once you've added all your tax rates, it will look something like this:

Now click configure component to setup the tax rate rules. This part is a little trickier. Click add condition and then choose Commerce Order: Order address component comparison.

You'll be shown a somewhat daunting form. Fill out the form as follows:

  • Order: Data selector => commerce-line-item:order
  • Address: Value => Shipping information: Address
  • Address Component: Value => Country
  • VALUE: Value => put in the country code, e.g. de

Then click the Save button and you'll see an overview page with your configuration.

Just click Save changes and then repeat the process for each country that needs taxes applied.


For shipping rates, we'll assume we want a flat rate for each country. Here's the process:

  1. Go to Store | Configuration | Shipping.
  2. Click Add a flat rate service link.
  3. Fill in the Title (e.g. German Shipping) and Base rate (e.g. 10 EUR).
  4. Click Save flat rate button.
  5. Click configure component link.
  6. Click Add condition link.
  7. Choose Commerce Order: Order address component comparison option.
  8. Fill in form with the same values as with taxes except the Order: Data selector field should be set to commerce-order.
  9. Click Save button.
  10. Click Save changes button to see the overview.

  11. Repeat for each flat rate.

Have fun with your multilingual Drupal Commerce site!

If you have a question, feedback, or find an error, please leave a comment below. Thanks!

Mar 26 2012
Mar 26

I'm sitting in the Denver airport killing time before flying back to California. As everyone in Drupal-land knows, we just finished up the very successful DrupalCon Denver conference with over 3000 attendees!

Unfortunately, I missed the main part of the festivities (sprints/BoFs/parties) due to family illnesses but I will watch the videos!

I flew into Denver Thursday night, met up with some Bay Area friends, and went off to the Drupal trivia night. My team did so badly on the trivia questions that we won!! Our prize included some awesome Build a Module videos courtesy of Chris Shattuck. Thanks, Chris!

I *was* fortunate enough to participate in the DrupalCon sprints that started on Friday...

What the heck is a Drupal sprint?

A Drupal sprint is when a group of people get together to make Drupal better. Note that I didn't say Drupal *developers*. You don't need to be a developer or coder to help out in a sprint. Sprints can be for:

  • Writing and improving documentation
  • Testing issues
  • Hashing out architectural design ideas
  • Writing patches
  • and more...

Check out the new contributors docs on drupal.org to learn more.

Why should you help?

We all know that Drupal is only as strong as our community. We make Drupal better by coming together no matter what our backgrounds or strengths or weaknesses. Sprints are not just for the "beautiful people" or "in crowd" (which is something I used to believe). Every person can help.

The great thing about being in a Drupal sprint is not only do you get to hang out with wonderful people, but you feel like you've made a positive difference. Because of your work, Drupal just got a little bit better. And, maybe you also learned something in the process!

Newbie contributor sprint

An awesome thing about the DrupalCon Denver sprints was there was a "newbie" room dedicated to those new to contributing to Drupal core issues. I have been a Drupal developer for nearly 8 years, have contributed modules, given Drupal camp presentations, etc. but contributing to "core" sounded intimidating and mysterious. I didn't know the process. I didn't know what to work on. I didn't know how to start.

After a few minutes in the newbie room, I could see that the barrier to entry is actually quite low. There are things for everyone to help out with and the process isn't as daunting as you would think.

Thanks to the sprint leads for their help and inspiration! In particular, thanks
to Jess for giving the big picture and to Angie for showing us how core patches are committed.

Drupal 8 Multilingual Initiative (D8MI) sprint

After going through a few Drupal core issues in the newbie room, I joined the D8MI sprinters in the other room. D8MI is out to make language support awesome for Drupal 8! I just finished writing my multilingual Drupal 7 book and was in a perfect frame of mind to dive into helping with D8MI.

The D8MI lead is Gábor Hojtsy who, not only is a very nice and smart guy, but has been leading the initiative very effectively. He created a initiative "rocketship" that rocks :) and helps us see very easily what tasks need love and attention.

The process was pretty simple. Gábor would direct us to an issue on the
rocketship and we'd work on it and then leave a comment with our feedback, patch, documentation, etc. I worked on several issues which fell into 3 buckets:

  • Review and write documentation.
  • Review UI improvement mockups and provide feedback.
  • Test patches for new functionality and provide feedback.

I didn't need to write any code (though there were certainly others doing that). In this case, the documentation did need a fairly technical understanding of the multilingual architecture but that isn't always the case for documentation. The mockup reviews didn't need much technical expertise, and the patch testing just required that you know how to get a fresh code repository, apply the patch, and test the particular feature.

Kudos to the D8MI team on a job well done!

Ready to start contributing?

Sprints often happen as part of a DrupalCon, camp, etc. and they can be virtual as well. And, you don't need to wait for a sprint to start contributing. Check out the Boston Initiative to see how they are getting more Drupal people contributing to core.

See you in the issue queue!

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