The epic story of the last week of how Drupal's frontend and backend look changed after 11 years at DrupalCon Portland

Submitted by Gábor Hojtsy on Thu, 05/05/2022 - 13:28

Last week was DrupalCon Portland, our first in-person big DrupalCon back together with 1300+ attendees. I was fortunately one of the attendees along with leaders of in-the works Drupal admin theme Claro and frontend theme Olivero. Both Claro and Olivero have been in the works for years, and both were quite close to get done, yet we did not even dream of getting both be the new defaults in Drupal within the week. But we did it!

Claro replaces Seven as the default administration theme and Olivero relaces Bartik as the default frontend theme in both Drupal 9.4.0 and Drupal 10.0.0. Both prior themes have been the Drupal defaults for 11 years, ever since Drupal 7 was released. Both themes received a lot of key contributions throughout the years, so many to even attempt to recount here. This is a guest post by Lauri Eskola (with additions by myself) on the story of how the final week went. Read on to peek into how we worked at DrupalCon to makes these historic changes happen.

Claro became stable and the default administration theme

First Cristina Chumillas (ckrina) organized a BoF discussion about Claro on Monday morning. We promoted the BoF on social media and on the contribution page on the DrupalCon site.

The focus of the BoF was to discuss the remaining scope for getting Claro stable and default in the Standard profile and if there is anything in the scope that could be reduced. We were able to descope a few issues from the roadmap, which got a sign-off from Gábor Hojtsy later that day as a product manager onsite. We also created a battle plan for the remaining issues to make sure that everyone involved knew what needs to happen and who should take action on each of the issues.

After the BoF, we met Matthew Grasmick during lunch, and he half jokingly suggested that we should try to finish the roadmap by Dries’ keynote on Wednesday so that he could announce the good news there. This inspired the team to do the unthinkable; to try to finish the remaining part of the roadmap by Wednesday morning.

On Monday Lauri Eskola worked on the roadmap with Cristina, Emilie Nouveau, Mike Herchel and Kat Shaw. We also received support from Angie Byron and Gábor on making sure that we are on the right track with the solution for the last stable blocking issue that required code changes.

Gábor also did the vast majority of the actual code patches required for marking Claro stable and the default theme.

We were able to land the last stable blocking issue on Tuesday morning. Now all that was left was finishing up on the accessibility assessments. Some of the assessments were done and could be closed, but forced colors mode and focus visibility still needed some more assessment.

We received help from Ben Mullins who was offsite, and in the meanwhile Lauri was able to collaborate with Cristina, Emilie, Mike, Kat, Adam Bergstein, Baddý Breidert, and Ted Bowman onsite at the event.

All of the assessments were done by the evening. This was after we had already left the venue. Angie, Cristina, Lauri and Gábor headed for dinner and Lauri was still trying to file follow-up issues for the problems discovered as part of the assessment from Angie’s car, but he found that Ben already submitted them.

Once we got to the restaurant, all of the issues had been closed and all that was left was for someone to commit the patch that marked Claro stable.

Angie was one of the people who were involved in starting the whole project, so she was the perfect person to commit the issue.

We requeued the issue to mark Claro the default theme in Standard for testing with Claro being stable and went on with our dinner. It was great vegan food by the way, we suggest you check out Blossoming Lotus if you are in Portland.

Afterwards we moved to Gábor’s hotel lobby and Angie committed the Standard profile patch too.

In the meantime, Benji Fischer, who was at the conference but not with us in person noticed that Claro became stable and restarted work on making it the administration theme of the Umami demo profile as well. Since we were at it already, Cristina reviewed and tested this patch and she committed that from the hotel lobby as well.

Twelve hours later, Dries announced the huge milestone at the Driesnote with a photo of Angie's commit from the hotel. Years of work suddenly becoming real in a couple days!

Olivero became the default frontend theme

Inspired by the success of Claro, people started working on the remaining blockers to make Olivero the default theme after the Driesnote. Olivero was already stable, and all that was left was to do quality assurance checks, which was done by Mike Herchel, and to get tests to pass with Olivero being the default theme.

Getting all of the tests to pass with Olivero being the default theme in Standard profile was much more complex than we had anticipated. This had been worked on for months before the event through various spin-off issues by several contributors, but numerous details remained to solve.

The work was finished during the event by Joe Shindelar onsite with the help of Spokje, Lee Rowlands and Amber Himes Matz offsite.

We got sign-offs by Thursday morning from Nathaniel Catchpole (release manager) offsite and Gábor (product manager) onsite that Olivero could also be made the default theme of Standard.

We got all of the work done by Thursday afternoon, which raised an idea that we could commit the patch live at the beginning of trivia night. We were anxiously working on this up until the last minute, because DrupalCI was having a very rough day with most test runs across various issues running into random failures.

We were literally watching multiple DrupalCI runs live at the event so that we could start researching any test failures as soon as they appeared.

Final fixes were put in place by Joe Shindelar in the afternoon. Luckily we managed to get green test runs and had a successful live commit at the beginning of trivia to 9.4.x.

Mike got on stage to explain what is going on and offsite Olivero team members Jen Witkowski, Putra Bonaccorsi, Jared Ponchot and Andy Blum all called in via a Zoom meeting. The 10.x clean test result came back a bit later, but we merged to 10.x as well before trivia started.

This was extremely rewarding and a perfect way to end this very successful event! It felt like a full circle as Olivero got started as an idea at the last in-person DrupalCon and got to land at this in-person DrupalCon.

While getting these two themes be the new Drupal defaults was a highlight for us, this DrupalCon was notable for many other reasons. It was great to see our friends again after several years only on video calls. Want to be in the next epic story moving the drop? DrupalCon Europe is coming back to Prague in September, ticket sales are about to start. We plan to be there as well working on the next major things for Drupal!

Gather interest and involve contributors for your projects at Drupal events

Submitted by Gábor Hojtsy on Wed, 04/13/2022 - 14:25

I have decades of experience in event organization starting from student summer camps in high school all the way to developer conferences for hundreds and then thousands of people. Especially with open source events, we found that these gatherings are especially good to get on the same page even on contentious questions and could be very effective to involve new contributors, if you provide the appropriate environment. Here is a model that worked in my experience if you plan to involve people in your projects.

1: Push information in one or more sessions

People like to learn about brand new solutions and approaches, or practical information about well proven areas. Some high profile Drupal projects could get into the regular conference keynote, but it is also worth submitting sessions for your topic in hopes they get approved. Sessions are ideal because you can disseminate a lot of information relatively quickly. They are bad for involving new contributors though, unless starting is very trivial. Which, let's be honest is usually not the case, or you would not invest all this work into it.

DrupalCon Portland is coming up in 12 days and the sessions are all settled. DrupalCon Prague is in the fall though and is accepting sessions right now!


Discussion at Drupal Europe 2018

2: Organize a smaller discussion

I usually suggest people doing a session to also organize a smaller group discussion afterwards. At Drupal events these are called Birds of a feather (BoF) events and have a way to be proposed and promoted on a first come first serve basis. These are great, because people attending do not need to commit to being involved in making your thing, they can sit back and listen. While you don't need to commit to create slides or demos. In fact, the best approach here is if you focus the discussion on problems people have in this area, so you can help solve them. Ideally, show how your proposal solves their problems or at least take this input in your task prioritisation.

For example, I hosted "Multilingual theraphy" BoFs at various Drupal events for years, where people came in to vent about issues with Drupal multilingual support. There were usually other people who solved the same problems before, so the BoF usually ended up with people solving other people's problems and vice versa. So we used this opportunity to grow the community, take the list of problems in our prioritisation and to gather future contributors and testers for our solutions. BoFs are the golden opportunity between sessions and contribution events because the attendee commitment and the organizer commitment are both relatively small if you do it right, but the returns are much higher. Potential contributors who may feel like imposters are more likely to attended a BoF than to show up and ask a question 1-1 or especially to randomly show up to contribute.

DrupalCon Portland in 12 days is still accepting BoF proposals until end of Friday, so now is the time to grab the opportunity. DrupalCon Prague will open this submission later.


DrupalCon Seattle 2019 contribution room map

3: Be accessible at contribution events

Once you disseminated your info at your session and started involving folks at your BoF, the final part is rolling up sleeves at a contribution event. DrupalCons and other events are really good at providing an open space for contribution events. You can show up randomly and claim a table or part of a table and put up your name for it on the contribution board. Consider how many things compete for attendeee attention at these events, and you will realize randomly showing up at contribution does not necessarily have the desired effect. How would others know when to find you there to be involved? If they show up before/after you've been there, it would leave them with a sour feeling. So as with BoFs, it is best to think ahead and pin down when you plan to be actively at the contribution event. Then visibly mark your spot in the room with whatever technique is available. If you want to involve new contributors, I think this usually only works in conjuction with the previous two components, as you would have the folks who got to know your vision and direction as well as discussed their concerns and problem areas with you. Showing up randomly at a contribution event requires a certain amount of courage and the previous two steps help build up the familiarity that would help you be successful here and ease any impostor feelings with new contributors.

4: Wrap this all up and use for promotion

Once you planned your three ways of engagement for contributors, make sure to publicise it far and wide, so people can find you in their right way and format. DrupalCon Portland in 12 days has a summary page with key initiatives posting their plans for sessions, contributions, BoFs, who to look for and what are the focus areas people can help. If you plan to work on a topic at DrupalCon Portland and not yet on that page, feel free to reach out to me and I can help.

Drupal 9 and Drupal 10 readiness at Drupal Global Contribution Weekend 2022

Submitted by Gábor Hojtsy on Thu, 01/27/2022 - 15:29

This weekend (Friday to Sunday) is Drupal Global Contribution Weekend 2022! While there are some in person events such as in Ukraine, there are various online events that allow anyone to join. I'll highlight three opportunities to work on your Drupal 9 or Drupal 10 readiness.

  1. Wim Leers just announced an opportunity to try CKEditor 5 with step by step instructions. He will be available for some office hours on all three days to consult with. CKEditor 5 is going to be the content editor available in Drupal 10, replacing CKEditor 4. So getting ready for it sooner than later is a good idea. A beta experimental version of the integration already exists in Drupal 9.3 to take for a test ride.
  2. Joel Pittet with the UBC Computer Science department is hosting a Zoom event to work on Drupal 9 and 10 readiness from 9am to 5pm on all three days Vancouver time (UTC-8). Folks working on other tasks are also welcome.
  3. I'll be available on Friday 9am to 5pm as well CET (UTC+1) in both the #d9readiness and #d10readiness channels on Drupal slack (https://drupal.org/slack).

Some common tasks that I think are good to take now:

  • If your contributed project is not Drupal 9 compatible yet, it is a good time to do that now. You can use Upgrade Status on Drupal 8 and Drupal Rector to find problems and automate fixes.
  • While your project cannot be surely Drupal 10 compatible yet, most deprecated APIs for Drupal 10 were marked in Drupal 8. You can use Upgrade Status on Drupal 9 to identify problems and use Drupal Rector again to fix most of them.
  • Drupal 10 will require PHP 8 at least, so setting up testing for your project on PHP 8 and/or manually testing on PHP 8 are good ways to make sure this part of compatibility is taken care of. All Drupal 9 core releases support PHP 8, so this does not pose a risk for your existing users on supported Drupal versions.

With my and Joel's events, there will be 2*8 hours of Drupal 9/10 readiness contribution on Friday with an hour of break inbetween. That is followed by 8 hours each on the weekend days as well. Join either to get help on your journey and contribute to Drupal!

Major Drupal configuration schema cheat sheet update - 7 years later

Submitted by Gábor Hojtsy on Wed, 12/22/2021 - 17:11

I apparently released the Drupal configuration schema cheat sheet 7 years ago (wow!) to help people adopt the then new format to describe configuration structure. I keep getting questions and requests about it, so decided to make a major update to it now and bring it to the present day for Drupal 9.


Updates from 1.5 (April 2015) include:

  • Double the pages, more extensive examples and pointers to core definitions
  • Includes description of config ordering introduced with Drupal 9.3
  • Documents how to pick schema keys for various use cases, such as config entities
  • Documents where to put the schema files and when to use multiple
  • Explains common string subtypes and recent additions to base scalar types
  • Contains a whole section on translatability
  • An entire new section to explain basics of mappings and sequences, the most common request
  • Explains potential of string keyed sequences 4 or so times, so hope it goes through :)
  • Suggests to use common mapping subtypes like mail and text_format
  • Covers ignore and undefined
  • Adds a whole new intro to dynamic typing to make the examples easier to understand
  • Makes all dynamic examples contain all definitions instead of abbreviations for easier understanding
  • Uses the same data to explain the [%parent] and [childkey] dynamic typing, to show the differences better
  • Cites various common core extension points, such as third party settings on themes and config entities
  • Explains advanced properties such as nullable lists
  • Updates test base class names for Drupal 9

I regularly receive feedback about people using the cheat sheet, so I hope this will help make config schema somewhat easier to grok. Improvement suggestions still welcome!

Kudos to Rene Bakx for his most recent questions that tipped me over to update the sheet.

The big Symfony 4 to 6 jump plan in Drupal 10 and potential benefits down the line for future versions

Submitted by Gábor Hojtsy on Mon, 11/29/2021 - 22:25

As you may know, we are planning to release Drupal 10 in 2022 (as early as June), because Drupal 9's Symfony 4 and CKEditor 4 are both end of life the year after, around the end of 2023. So we plan go give enough time for people to update to Drupal 10 before Drupal 9 goes end of life. A similar situation happened with Drupal 8 to 9 driven by Symfony 3 to 4. However, moving Drupal 10 from Symfony 4 to 5 would again only give us a couple years of time to move on to Symfony 6 next, so the current plan is to move to Symfony 6 straight.

How is it possible to move Drupal 10 from Symfony 4 to 6? Symfony 6.0 was just released a few hours ago and is stable, so by the time Drupal 10 would be released, it will already be at least on Symfony 6.1.

However, the exact same thing happened with Drupal 8, and we did not do a double Symfony version jump update from Drupal 8 to 9 for two reasons: (a) even though Drupal core minor versions are supported for 12 months, Symfony minor versions are only supported for 8 months other than the last LTS minor version and (b) jumping two versions would mean that scanning for and acting on minor version to minor version all deprecations is challenging. Those two did not resolve themselves so to speak, however we have plans to mitigate them.

Symfony security extension for Drupal-used packages

First of all, Symfony normally supports minor releases for 8 months starting with Symfony 5. On the other hand Drupal minor releases are supported for 12 months, so if there are security fixes to be made, this would not be possible on a non-LTS version of Symfony. However we made arrangements with the Symfony team to have two of the Drupal core committers be part of the Symfony security process and be able to backport security fixes as needed for components used by Drupal even if the given Symfony minor version would be normally out of support. The two Drupal core committers involved are Alex Pott and Lee Rowlands! I don't believe there was an official announcement of this agreement yet, however it was in place since September 2019. Special thanks for the open minded collaboration of the Symfony leads as well!

Bridging the deprecations jump with Symfony 5.4

Second is bridging API deprecations. Nathaniel Catchpole outlined the plan for this recently. The problem is that Symfony 4 deprecated some APIs for removal/changes in Symfony 5 and them Symfony 5 deprecated some APIs for removal/changes in Symfony 6. Jumping through two versions gives Drupal 10 a potentially longer lifetime but with a need to solve identifying all deprecated API uses for both. Now that both Symfony 5.4 and 6.0 are out, the plan is to open the Drupal 10.x-dev branch for development very soon and update to Symfony 5.4 as well as other big dependency updates. Then release a Drupal 10.0.0-alpha1 that is based off of Symfony 5.4, which would allow contributed projects and custom code to check against deprecated APIs towards Symfony 6. And only later update to Symfony 6. This way there is a middle-point that allows to make the necessary updates and check deprecated APIs against.

As jumping two major Symfony versions is not something we did before, let us know in the Drupal 10 issue if you can poke holes at the grand plan. While it looks like this will be entirely possible, it would be best to find any potential pain points ahead of Drupal implementers hitting them.

A proposal with overlapping LTS release versions of Drupal core

Lee Rowlands went even further and presented the potential benefits of this plan down the line with Drupal 11 and Drupal 12. Releasing Drupal 10 on Symfony 6 would allow us to support it longer, up to November 2027. However it does not mean that we cannot release Drupal 11 earlier than 2026 let's say. Releasing earlier would allow us to jump faster to Symfony 7 while it would still give Drupal 10 users a more comfortable, longer support timeline. Then we could take advantage of the full Symfony 7 support timeline.

That would result in Drupal users not needing to update every 12 months to keep security support but needing to update every 2.5 years instead, which would lower cost of ownership of Drupal considerably.

Check out this video where Lee explains the details and discuss in the issue titled Adopt a 2 year major release cadence and a 6 month LTS-to-LTS overlap period for Drupal 10 and beyond. (This is not yet a firm policy, it is under discussion).