Upgrade Your Drupal Skills

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

See Advanced Courses NAH, I know Enough
Nov 18 2020
Nov 18

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

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

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

UX principles matter for backend design as much as the frontend

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

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

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

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

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

Use Drupal’s Views module to customize user dashboards

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

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

Powering Our Communities homepage

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

Manage News interface

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

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

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

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

Drupal content dashboard

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

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

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

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

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

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

Claro

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.

Olivero

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

Media

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.

Workflow

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.

Accessibility

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.

Pantheon

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.

Acquia

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.

Platform.sh

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.

Amazee.io

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

Sep 23 2020
Sep 23

Working in digital design and development, you grow accustomed to the rapid pace of technology. For example: After much anticipation, the latest version of Drupal was released this summer. Just months later, the next major version is in progress.

At July’s all-virtual DrupalCon Global, the open-source digital experience conference, platform founder Dries Buytaert announced Drupal 10 is aiming for a June 2022 release. Assuming those plans hold, Drupal 9 would have the shortest release lifetime of any recent major version.

For IT managers, platform changes generate stress and uncertainty. Considering the time-intensive migration process from Drupal 7 to 8, updating your organization’s website can be costly and complicated. Consequently, despite a longtime absence of new features, Drupal 7 still powers more websites than Drupal 8 and 9 combined. And, as technology marches on, the end of its life as a supported platform is approaching.

Fortunately, whatever version your website is running, Drupal is not running away from you. Drupal’s users and site builders may be accustomed to expending significant resources to update their website platform, but the plan for more frequent major releases alleviates the stress of the typical upgrade. And, for those whose websites are still on Drupal 7, Drupal 10 will continue offering a way forward.

The news that Drupal 10 is coming sooner rather than later might have been unexpected, but you still have no reason to panic just yet. However, your organization shouldn’t stand still, either.

Image via Dri.es

The End for Drupal 7 Is Still Coming, but Future Upgrades Will Be Easier

Considering upgrading to Drupal 8 involves the investment of building a new site and migrating its content, it’s no wonder so many organizations have been slow to update their platform. Drupal 7 is solid and has existed for nearly 10 years. And, fortunately, it’s not reaching its end of life just yet.

At the time of Drupal 9’s release, Drupal 7’s planned end of life was set to arrive late next year. This meant the community would no longer release security advisories or bug fixes for that version of the platform. Affected organizations would need to contact third-party vendors for their support needs. With the COVID-19 pandemic upending businesses and their budgets, the platform’s lifespan has been extended to November 28, 2022.

Drupal’s development team has retained its internal migration system through versions 8 and 9, and it remains part of the plan for the upcoming Drupal 10 as well. And the community continues to maintain and improve the system in an effort to make the transition easier. If your organization is still on Drupal 7 now, you can use the migration system to jump directly to version 9, or version 10 upon its release. Drupal has no plans to eliminate that system until Drupal 7 usage numbers drop significantly.

Once Drupal 10 is ready for release, Drupal 7 will finally reach its end of life. However, paid vendors will still offer support options that will allow your organization to maintain a secure website until you’re ready for an upgrade. But make a plan for that migration sooner rather than later. The longer you wait for this migration, the more new platform features you’ll have to integrate into your rebuilt website.

Initiatives for Drupal 10 Focus on Faster Updates, Third-Party Software

In delivering his opening keynote for DrupalCon Global, Dries Buytaert outlined five strategic goals for the next iteration of the platform. Like the work for Drupal 9 that began within the Drupal 8 platform, development of Drupal 10 has begun under the hood of version 9.

A Drupal 10 Readiness initiative focuses on upgrading third-party components that count as technological dependencies. One crucial component is Symfony, which is the PHP framework Drupal is based upon. Symfony operates on a major release schedule every two years, which requires that Drupal is also updated to stay current. The transition from Symfony 2 to Symfony 3 created challenges for core developers in creating the 8.4 release, which introduced changes that impacted many parts of Drupal’s software.

To avoid a repeat of those difficulties, it was determined that the breaking changes involved in a new Symfony major release warranted a new Drupal major release as well. While Drupal 9 is on Symfony 4, the Drupal team hopes to launch 10 on Symfony 6, which is a considerable technical challenge for the platform’s team of contributors. However, once complete, this initiative will extend the lifespan of Drupal 10 to as long as three or four years.

Other announced initiatives included greater ease of use through more out-of-the-box features, a new front-end theme, creating a decoupled menu component written in JavaScript, and, in accordance with its most requested feature, automated security updates that will make it as easy as possible to upgrade from 9 to 10 when the time comes. For those already on Drupal 9, these are some of the new features to anticipate in versions 9.1 through 9.4.

Less Time Between Drupal Versions Means an Easier Upgrade Path

The shift from Drupal 8 to this summer’s release of Drupal 9 was close to five years in the making. Fortunately for website managers, that update was a far cry from the full migration required from version 7. While there are challenges such as ensuring your custom code is updated to use the most recent APIs, the transition was doable with a good tech team at your side.

Still, the work that update required could generate a little anxiety given how comparatively fast another upgrade will arrive. But the shorter time frame will make the move to Drupal 10 easier for everybody. Less time between updates also translates to less deprecated code, especially if you’re already using version 9. But if you’re not there yet, the time to make a plan is now.

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 22 2020
Jun 22

It’s nearly a decade since the release of Drupal 7. During this time, we have seen new legislation in web accessibility, privacy (GDPR), the rise of mobile internet, and the proliferation of high-performance devices. 

The way we interact through technology has changed too. Customer expectation has risen, and interaction has become automated, facilitated by the integration of CRMs and marketing tools. 

The case for 'Versions'

These social changes are why ‘versions’ of technology are released. When the world changes in such a fundamental way, it is illogical to make a historic version continue to fit. Instead, new versions are built with the way we communicate at their source.

Drupal 7 was created in an unrecognisable world by today’s standards, and by staying on D7, you remain in that past world.

If you wish to remain secure, keep pace with innovation, consumer expectations, and meet modern digital standards, it is necessary to migrate your website to a CMS version built for the new world. 

These new requirements are why Drupal 8 and most recently Drupal 9, which I will come onto later, have been released.

What happens at Drupal 7’s End of Life?

Previously, Drupal 7's end-of-life was scheduled for November 2021. Given the impact of COVID-19 on budgets and businesses, the Drupal project has extended the end of life until November 28, 2022. It is important to understand what this means to your organisation:

  • The Drupal Security Team will no longer provide support or Security Advisories for Drupal 7 core or contributed modules (additional components for your website), themes, or other projects.
  • Drupal 7 will no longer be supported by the community at large. The community at large will no longer create new projects, fix bugs in existing projects, write documentation, etc. around Drupal 7.
  • After November 2022, using Drupal 7 may be flagged as insecure in 3rd party scans as it no longer gets support.
  • Best practice is to not use unsupported software, it would not be advisable to continue to build new Drupal 7 sites.

It is important to appreciate that your website does not suddenly become insecure come November 2022, rest assured we present you several options, detailed below.

Drupal 8: What’s new?

Drupal 8 is a massive leap forward for the community and the organisations using it.

There are so many reasons why Drupal 8 (and 9) implementations appeal to Drupal 7 site owners. Here are a few which stand out:

  • Content authoring experience designed with marketers in mind
  • Drag and drop page builder
  • Flexible page layouts with components
  • Introduce modern headless front end
  • Mobile-first by default
  • Fast page load times, great for end-users and SEO alike
  • Media library simplifying work with video, images and documents
  • Social integration
  • Easily exchange data with CRM, marketing and back-office systems
  • WCAG 2.1 accessibility
  • Ability to introduce personalisation

How to decide your Drupal 7 strategy

Your path forward depends upon your organisation’s attitude towards the Drupal 7 site. Which category does your site fall into?

Category 1 Site Owners
  • Our website is critical to our business operation.
  • Our website needs a redesign.
  • To perform efficiently, we additional features now or in the future.
  • Our website must comply with accessibility and/or GDPR legislation.
  • Our website is in active development.

Recommendation: Drupal 8 Re-platform(Click or keep scrolling)

Category 2 Site Owners
  • We have no plans to develop further features.
  • We will retire the site in the next 12-24 months.
  • Our site content and design will remain the same for a number of years.

Recommendation: Drupal 7 Long Term Support program (Click or keep scrolling)

Category 1 Site Owners:

Drupal 8 replatform 

To help you consider what approach to take, consider which of the next set of categories your site falls into. Each results in all the benefits Drupal 8 offers, but takes a different journey to get there.

Level 1/3: Your site is great as is.

Your site functions with minimal issues. You want to spend little time planning and you're migrating for security reasons.

Level 2/3: In need of a refresh.

You need a visual refresh and to evaluate some features, but on the whole, your site operates just fine.

Level 3/3: Time for a big rethink.

Your site doesn't meet your requirements or business goals. It's time for a big rethink.

Recommendation: Lift and shift £

Maintain the same functionality and look-and-feel, but with a new Drupal 8 CMS.

Steps: A Drupal 8 migration.

Recommendation: Minor upgrade ££

A solution similar to your existing site, with a design refresh.

Steps: Short planning phase to deliver new wireframes, creative design, and a Drupal 8 migration.

Recommendation: Major upgrade £££

A solution significantly different to your existing site with a totally new design.

Steps: A discovery, definition, and full design process before the Drupal 8 migration.

Category 2 Site Owners:

Drupal 7 long term support

Staying on Drupal 7 is an option only if you subscribe to extended support, commercially available security updates are made available via a subscription model. This will be available until 2024.

Additionally, patching of Symfony and PHP will be necessary. Over time this option becomes less attractive since innovation is not here, the burden to maintain a secure site will grow.

What about Drupal 9?

Drupal 9 was released June 3rd 2020, built from the final version of Drupal 8. It can be considered a housekeeping release. The release removes features no longer necessary and any “deprecated code” to maintain compatibility with key underlying third-party systems like Symfony. These third-party systems that are also benefiting from security and performance updates. These changes are all centred around keeping pace with the modern web.

Moving to Drupal 8 means you are ready for Drupal 9. Once a majority of modules are ported to Drupal 9, many of which already are, only then should you update to 9.

If you migrate to Drupal 8, ensure your new site does not reference features deprecated in Drupal 9. If you do this, moving between Drupal 8 & 9 will efficient and return great value.

“Moving between Drupal 8 & 9 is the easiest upgrade in a decade.”

Drupal 8 migration audit

When deciding and planning for a migration, you must audit and consider the following:

  • Integrations and 3rd Party features
  • Bespoke modules and design
  • Front end styling and customer experience
  • Live data systems
  • Data housing and quality
  • Page and content structure, volume, and quality
  • Back office processes
  • Workflows and approval systems
  • Security
  • Accessibility

It would be a missed opportunity to not tell you that we offer this service as both an initial review and an extensive audit. If you require these services, please inform me of your concerns and website address on our contact page.

Building a business case for a Drupal upgrade

Once you have identified the risks of Drupal 7, you may need to convince your colleagues, superiors, and peers. We have developed business cases for Universities, the Public Sector, Membership bodies, Legal Professionals, and Not-For-Profit organisations.

The crux comes from the opportunity deficit. While the risks of security and accessibility are clear to most, the opportunity deficit is created first by your technical knowledge, and finally by your creative application. Having been in the depths of Drupal since the beginning, we know the hidden potential of Drupal, and as such, can help you identify the business-critical opportunity a migration can bring.

Useful links

University of West London D7 to D8 Migration

Drupal 7 Roadmap on Drupal.org

Founder of Drupal, Dries' Drupal 7, 8 and 9 Blog

Accelerated Drupal Migrations with CTI Digital

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.



Source: WYDAILY

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.

Thanks!

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:

https://www.drupal.org/project/views_accordion/issues/3100388

  1. Read through the change record for the change

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

  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

    https://www.drupal.org/project/views_accordion/issues/3100388#comment-13...

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.

https://app.slack.com/client/T06GX3JTS/CDDD98AMN/thread/CDDD98AMN-158808...

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:

https://www.drupal.org/project/views_accordion/issues/3091388#comment-13...

  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

    https://www.drupal.org/project/views_accordion

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

    https://www.drupal.org/project/issues/views_accordion?text=drupal+9

  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"

    https://www.drupal.org/project/views_accordion/issues/3131959

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

    https://www.drupal.org/files/issues/2020-01-30/3091388-6.patch

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

    https://stm5ea90733d366a-snjvt0qoedy7maoqy3mzycrx6vzbeixv.tugboat.qa/

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

Goodnight!

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

Apr 23 2020
Apr 23

We’ve been making big websites for 14 years, and almost all of them have been built on Drupal. It’s no exaggeration to say that Four Kitchens owes its success to the incredible opportunities Drupal has provided us. There has never been anything like Drupal and the community it has fostered—and there may never be anything like it ever again.

That’s why it’s crucial we do everything we can to support the Drupal Association. Especially now.

The impacts of COVID-19 have been felt everywhere, especially at the Association. With the cancellation of DrupalCon Minneapolis, the Drupal Association lost a major source of annual fundraising. Without the revenue from DrupalCon, the Association would not be able to continue its mission to support the Drupal project, the community, and its growth.

The Drupal community’s response to this crisis was tremendous. For our part, we proudly joined 27 other organizations in pledging our sponsorship fees to the Association regardless of whether, or how, DrupalCon happened. I ensured my Individual Membership was still active, and I made a personal contribution.

But we need to do more.

You can help by joining us in the #DrupalCares campaign.

The #DrupalCares campaign is a fundraiser to protect the Drupal Association from the financial impact of COVID-19. Your support will help keep the Drupal Association strong and able to continue accelerating the Drupal project.

The Drupal Association

The outpouring of support has been… Inspiring. First, project founder Dries Buytaert and his partner Vanessa Buytaert pledged their generous support of $100,000. Then, a coalition of Drupal businesses pledged even more matching contributions. We are proud to count ourselves among the dozens of participating Drupal businesses.

Any individual donations, increased memberships, or new memberships through the end of April will be tripled by these matching pledges, up to $100,000, for a total of $300,000.

Please join us in supporting the Drupal Association. Your contribution will help ensure the continued success of the Association and the Drupal community for years to come.

Give to #DrupalCares through April to help the Association receive a 3:1 matching contribution. 

Mar 01 2020
Mar 01

It’s that time again! Drupal 9 will be released later this year and it’s never too late to test patches and contribute. Thinking about it, I wondered how to quickly test patches and install Drupal 9 from my local Git checkout. When I say quickly it means it really should be dead simple, by typing one command only. The idea being to make sure I’d always install Drupal from the 9.0.x branch at the latest commit to follow changes.

Check anavarre/d9 on Github

I came up with a Python script to achieve just that on Linux. It should work on Mac but it’s untested. The idea is this:

  • Install Drupal 9 with the --install parameter
  • Wipe everything (really, delete all containers and go back to a clean Git repo) with the --wipe parameter

It looks like this upon installing Drupal:

$ d9 --install
===> Drupal 9 codebase detected
===> Git repository detected
===> composer.json detected
===> Pulling Composer dependencies
===> Creating Lando configuration file
===> Starting app
Let's get this party started! Starting app..
Recreating landoproxyhyperion5000gandalfedition_proxy_1 ... done
Creating network "drupal9_default" with the default driver
Creating volume "drupal9_data_appserver" with default driver
Creating volume "drupal9_home_appserver" with default driver
Creating volume "drupal9_data_database" with default driver
Creating volume "drupal9_home_database" with default driver
Creating drupal9_appserver_1 ... done
Stopping drupal9_appserver_1 ... done
Starting drupal9_appserver_1 ... done
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
100   599  100   599    0     0   1109      0 --:--:-- --:--:-- --:--:--  1109
100 4673k  100 4673k    0     0  2290k      0  0:00:02  0:00:02 --:--:-- 6138k
Drush Commandline Tool 10.2.2
Stopping drupal9_appserver_1 ... done
Starting drupal9_appserver_1 ... done
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
100  811k  100  811k    0     0   111k      0  0:00:07  0:00:07 --:--:--  144k
Stopping drupal9_appserver_1 ... done
Starting drupal9_appserver_1 ... done
Creating drupal9_database_1  ... done
Waiting until database service is ready...
Waiting until appserver service is ready...
Waiting until database service is ready...
Waiting until database service is ready...
Waiting until database service is ready...
Waiting until database service is ready...
Waiting until database service is ready...
Waiting until database service is ready...
Waiting until database service is ready...

BOOMSHAKALAKA!!!

Your app has started up correctly.
Here are some vitals:

NAME            drupal9                                
LOCATION        /home/{your_username}/Sites/git/drupal/drupal 
SERVICES        appserver, database                    
APPSERVER URLS  https://localhost:33335                
http://localhost:33336                 
http://drupal9.lndo.site:8080          
https://drupal9.lndo.site              

===> Installing Drupal

// You are about to create a sites/default/settings.php file and DROP all tables in your 'drupal8' database. Do you  
// want to continue?: yes.                                                                                           

[notice] Starting Drupal installation. This takes a while.
[success] Installation complete.
https://drupal9.lndo.site/user/reset/1/1583080437/QcSKuNYakHrJ53IObRxSQYeq954ohvHPIywgcPHXcGY/login

And upon wiping everything:

$ d9 --wipe
WARNING: This will completely destroy the Lando app. Are you sure? (y/n) y
===> Deleting app
Preparing to resign drupal9 to the dustbin of history...
Stopping drupal9_database_1  ... done
Stopping drupal9_appserver_1 ... done
Removing drupal9_database_1  ... done
Removing drupal9_appserver_1 ... done
Removing network drupal9_default
Removing volume drupal9_data_appserver
Removing volume drupal9_home_appserver
Removing volume drupal9_data_database
Removing volume drupal9_home_database
Your app has paid the IRON PRICE. App destroyed!
WARNING: This will reset your Git repo and pull the latest commit in HEAD. Are you sure? (y/n) y
===> Delete /path/to/git/checkout/drupal/vendor directory
===> Delete /path/to/git/checkout/drupal/sites/default directory
[sudo] password for {username}:
===> Pulling latest changes
Removing .lando.yml
HEAD is now at 44ee417272 Issue #3111244 by bnjmnm, sasanikolic, lauriii: Update SortableJS to 1.10.2
Already up to date.

A few more notes

At the time of this writing I’m using the drupal8 Lando recipe. I filed an issue to get an official recipe for drupal9, which means the script will - hopefully soon - be even simpler (no need to create and manage a .lando.yml file or to install Drush). There’s a PR about it in case you’re interested and wish to contribute.

Feb 20 2020
Feb 20

Drupal Camp London is a 3-day celebration of the users, designers, developers and advocates of Drupal and its community! Attracting 500 people from across Europe, after Drupalcon, it’s one of the biggest events in the Drupal Calendar. As such, we're pleased to sponsor such an event for the 6th time!

Drupalcamp weekend (13th-15th March) packs in a wide range of sessions featuring seminars, Birds of a feather talks, Sprints and much more. Over the weekend there are 3 Keynotes addressing the biggest upcoming changes to the technical platform, its place in the market, and the wider Drupal community.

Check out all of the accepted sessions on the Drupal Camp London website here. Or keep reading to see our highlights…

CXO Day - Friday 13th of March

From Front Room to Front Runner: how to build an agency that thrives, not just survives - Talk from Nick Rhind

Few digital agency start-ups reach their first birthday, let alone celebrate over 16 years of success. Our CEO Nick Rhind will be sharing anecdotes and advice from 2 decades of building the right teams to help his agency group, CTI Holdings, thrive.

Catch up with Nick, or any of our team attending Drupal Camp by connecting with them on LinkedIn, or via our contact form.

Come dine with us - Agency Leaders Dinner London

Hosts Paul Johnson (CTI Digital), Piyush Poddar (Axelerant), and Michel Van Velde (One Shoe) cordially invite agency leaders to join them for a night of meaningful discussions, knowledge sharing, and of course great food, excellent wine, and the best company you could ask for. Details of the dinner can be found here.

DCL Agency Leaders Dinner 2020

Agency Leaders Dinner London

Drupal Camp Weekend

Drupal in UK Higher Education - A Panel Conversation

Paul Johnson, Drupal Director at CTI Digital, will be hosting influential bodies from the Higher Education community as they discuss the challenges facing universities in a time of light-speed innovation and changing demand from students. In addition, they will explore the role Drupal has played in their own success stories and the way open source can solve problems for other universities. Drupal camp panel details available here.

The Panellists:

Adrian Ellison, Associate Pro Vice-Chancellor & Chief Information Officer University of West London - Adrian has been involved in Registry, IT and Library Services in higher education for over 20 years. He joined UWL in 2012 from the London School of Economics, where he was Assistant Director of IT Services. Prior to that, he was IT Director at Royal Holloway, University of London, and held several roles at the University of Leeds.

Adrian is a member of the UCISA Executive Committee, representing the voice of IT in UK education. He has spoken about information technology at national and international conferences and events and co-wrote the Leadership Foundation for Higher Education’s 'Getting to Grips with Information and Communications Technology' and UCISA’s ‘Social Media Toolkit: a practical guide to achieving benefits and managing risks’.

Billy Wardrop, CMS Service Support Officer at Edinburgh University - Billy is a Senior Developer with 15+ years experience and the current technical lead for the migration to Drupal 8 at The University of Edinburgh. He has worked with many platforms but his passion lies in developing websites and web applications using open source such as Drupal, PHP, JavaScript and Python. Billy is an advocate in growing the open-source community. As part of his role in the university, he regularly mentors at events and encourages software contribution. 

Iain Harper Head Of Digital, Saïd Business School, University of Oxford - Iain started his career at leading medical insurer MPS, developing their first online presence. He then ran digital projects at a leading CSR consultancy business in the Community before joining the Civil Service. Iain worked with the Government Digital Service on Alphagov, the precursor to GOV.UK. He then joined Erskine Design, a small digital agency based in Nottingham where he supervised work with the BBC on their Global Experience Language (GEL). He now leads the digital team at Oxford University’s Saïd Business School.

Open source has won. How do we avoid dying from success? - A Panel Conversation

Drupal, founded on a philosophy of open source, has steadily grown into a global community, a feat some may label as having achieved ‘Success’. Drupal users and contributors will be discussing the sustainability of Drupal and the future of open source in an open panel session.

What are the challenges faced by different roles? How can we make the whole ecosystem fair and future proof? What does an open source business model look like? 

Join our very own Paul Johnson and Drupal panellists for this thought provoking discussion on the future of open source. More details on the session are available here.

Why should you attend Drupal Camp?

Share useful anecdotes and up-to-date knowledge 

Discover the latest in UX, design, development, business and more. There’s no limit to the types of topics that could come up...as long as they relate to Drupal that is!

Meet peers from across the industry

From C-Level and Site managers to developers and designers over 500 people attended last year. Meet the best and brightest in the industry at talks and breakouts.

Find your next project or employer

A wide variety of business and developers attend Drupal Camp, make the most of it by creating connections to further your own career or grow your agency team.

Jan 23 2020
Jan 23

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

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

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

Applying Xautoload

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

For example:

xautoload.info

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

dependencies[] = xautoload:xautoload

xautoload_example.module

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

src/SimpleObject.php

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

Hello World

"
,    );

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

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

Using Third-Party Libraries

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

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

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

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

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

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

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

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

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

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

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

Setting up a New Site with Composer

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

composer create-project drupal-composer/drupal-project:7.x-dev --no-interaction

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

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

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

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

Have fun!

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

Jan 05 2020
hw
Jan 05

A long time in a galaxy far away… Not really. But it is over a year since I wrote how to get the current node in a block plugin and promised to write a follow-up post with an easier method. Well, better late than never, here it is!

Update: As many pointed out on Twitter, LinkedIn, and in comments here, the context key I use(d) in this article has been deprecated and replaced by a newer context_definitions key. The article is updated to reflect that.

The previous method works, so why bother with another method? In short, it’s less code and less code is easier to maintain. Also, instead of doing all the work to get the node and set the correct cache contexts/tags, it is better to let Drupal handle that for us. In the method I am going to describe today, we just need to tell Drupal that we need a node and Drupal handles everything for us. Sweet.

Context

Let’s jump to the solution. We want to get the node being currently shown from our block plugin, and we will use the “context” (not to be confused with cache contexts) to ask Drupal to send this to us. We do this with our block plugin annotation. Let’s see how.

/**
 * Provides a 'TextAdsBlock' block.
 *
 * @Block(
 *   id = "text_ads",
 *   admin_label = @Translation("Text Ads"),
 *   category = @Translation("Ads"),
 *   context_definitions = {
 *     "node" = @ContextDefinition("entity:node", label = @Translation("Node"))
 *   }
 * )
 */

There is a new context_definitions property set to a ContextDefinition in this annotation which tells Drupal what we need available to us. The "node" key lets us get the node in our code (we’ll see that shortly) and Drupal ensures that this plugin is only available when we have the "entity:node" context available to us.

To get the node in your block plugin, use the getContextValue parent method.

  public function build() {
    $node = $this->getContextValue('node');

    return [
      '#markup' => 'The node id is ' . $node->id(),
    ];
  }

Since we’re using the context here, Drupal already knows how to correctly set the cache contexts and tags. We don’t need to handle that ourselves anymore (you still have to set other cache contexts and tags directly related to your block’s logic).

Complete Code Sample

The complete block plugin may be viewed in this gist. This example is modified from a real-life use case and you can disregard some of the implementation details (such as getting the location and checking for node type). I have included the entire code listing to demonstrate how you might use it in a real scenario where you might have additional constraints such as showing the block only on node pages of certain types.

Takeaways

In Drupal and generally in programming, there are many ways to solve a single problem. The best way is rarely the best in all cases. It is up to you and your use-case to see which method would be most appropriate for your requirements. To that, I invite you to read the first post again and compare the implementation.

Regardless, there are general principles that typically lead to better results. And generally, less code is always better.

Jan 03 2020
Jan 03

Ok, the problem is clear:

  • Your composer based Drupal site puts your code base to the /web folder
  • You are using a shared hosting which maps your primary domain to /public_html, and you can't change that

Now your users will have to browse your site as http://example.com/web . And it is not cool.

So how to serve your site from the subfolder /public_html/web but removing the /web suffix so it becomes transparent to users?

Here are the steps, as I learned from this thread on Drupal.org

1. Open your settings.php file and add the following code:

if ( isset($GLOBALS['request']) && '/web/index.php' === $GLOBALS['request']->server->get('SCRIPT_NAME') ) {
    $GLOBALS['request']->server->set('SCRIPT_NAME', '/index.php');
}

2. Create a .htaccess file on the /public_html folder with:


RewriteEngine on
# Redirect to the subdirectory because that's where Drupal is installed
RewriteRule (.*) web/$1 [L]

3. Update .htaccess under /public_html/web folder

Uncomment the line RewriteBase and set it to:

RewriteBase /web

4. Clear the cache and run update.php

Your site should work by browsing http://example.com now (without the /web suffix). Your menu items may still have the /web part, but it will be gone after some hard refresh.

5. (Bonus) If you want to redirect http/https and www/non-www:

On the .htaccess file under /public_html/web, please add those lines between the tag:

This is to redirect non-https + www to https + non-www:

  RewriteCond %{HTTPS} off [OR]
  RewriteCond %{HTTP_HOST} ^www\.example\.com [NC]
  RewriteRule (.*) https://example.com/$1 [L,R=301]

And this is to redirect non-https + non-www to https + www"

  RewriteCond %{HTTPS} off [OR]
  RewriteCond %{HTTP_HOST} !^www\. [NC]
  RewriteCond %{HTTP_HOST} ^(.*)$  [NC]
  RewriteRule (.*) https://www.%1/$1 [R=301,L]

You can see those examples on Htaccess guide.

Dec 09 2019
Dec 09

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

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

The Benefits of Drupal 8

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

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

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

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

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

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

So why wait? 

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

Nov 07 2019
Nov 07
Image courtesy of Acquia

Crafting a user experience that feels customized — but not forced or invasive — is key to successfully creating targeted website content. If you work with Drupal, Acquia Lift is one obvious solution to this challenge. Few other complete solutions for personalizing the user experience integrate with Drupal so well. 

Personalize Drupal content

Acquia Lift is a personalization tool that can help serve up custom content by tracking a variety of user activities on your site:

  • Pages visited
  • Content types or taxonomies viewed
  • Data that relates to location and browser information 

Lift works with Drupal versions 7 and 8, so the tool is available for use by many active sites on the Acquia platform. As an Acquia tool, Lift also integrates with the rest of the Acquia Cloud hosting platform. 

The tool uses criteria that you enter into its Profile Manager to place website visitors into segments. You then use Profile Manager to set up campaigns that target, track, and provide personalized experiences to specific segments. Segment criteria can be as simple as device type or as complex as specific combinations of interactions with the website. This level of granular control improves the quality of your content customization — and in turn, your engagement metrics.

After setting up campaigns and segments, you can select site sections and content to personalize. For example, you might replace a generic hero banner image with a location-specific graphic or swap out promotional content to reflect a visitor’s account status. When used correctly, this type of personalization can elevate the user experience and improve conversion rates. And because Lift integrates with Drupal so closely as a module, the tool has direct access to site content. This approach helps to ensure that the content visitors see doesn’t feel jarring or out of place. 

Focus on personalization, not code

From a technical perspective, installing and using Acquia Lift is not too difficult. Acquia provides a contributed module and library that work well with Drupal. In my opinion, the documentation could be improved, but it provides enough information for most developers to install Lift without trouble. The personalization and swapping of content all happen client-side (outside of Drupal), so after Lift is installed there isn’t much to configure within Drupal. Some handling with CSS is necessary to reduce visual indications of changing content, but the process is included in the documentation and the Acquia team is willing to assist if necessary.

Aside from these specifics, the magic that happens with personalization and setup occurs within the Acquia Lift interfaces. So after Lift is set up, you don’t need a high level of technical expertise for its regular use. The analytics, user data, segments, campaigns, and targeting all occur in the user-friendly Profile Manager. 

Before you decide

Lift does have a few limitations that you need to be aware of. The most significant: Dynamic or “live” content can be tricky to replace or personalize.  Because Lift bases replacements on static versions of content (i.e., rendered HTML), Lift might not replicate or replace carousels, slideshows, and other views with custom displays. Content that relies on data that might change or on JavaScript for rendering might need to be recreated in a different way to generate the same effect. 

Second, differences in documentation between the two available versions of Lift (versions 3 and 4) can cause a bit of confusion during setup confirmation. For example, Version 4 is an integrated tool inside Profile Manager, whereas version 3 works as a sort of pop-up that occurs within Drupal.

Also note that despite the ease of installation and deep documentation, the Acquia team will probably need to be involved to finish the installation. The team is fairly responsive, but this necessity could cause a slowdown in implementation, so you need to be aware of it if you’re deploying Lift close to launch. The extra assistance is even more likely to be necessary when using version 4 because of its more limited documentation and active development. We hope to see improvements in this area in the near future as development on version 4 continues.

Lastly, setting up test campaigns after you’ve installed and configured Lift can be difficult if you only have a few content items and some Lorem Ipsum. This service needs real content and real slots into which to swap that content to be tested properly. You won’t have a problem when implementing Lift into an existing site, but if you plan to use the tool on a new site, be aware that you’ll need to delay implementation until just before or after launch.

A complete personalization experience

All-in-all, few options out there work directly with a Drupal site and provide such a complete experience for personalization. Targeted and personalized content doesn’t need to be difficult to set up or irritating for the user. Tools like Acquia Lift can help make websites feel just a bit more personal. Check out Lift’s informational pages for more details.

Nov 01 2019
Nov 01

It was during his 2015 DrupalCon Europe keynote when Dries Buytaert first discussed the ‘free-rider problem’. Dries proposed improvements to the way Drupal tracks contribution an a scale of “social capital”. This would better recognise all types of work and how contributions can lead to a bigger impact in the world.

We’ve come a long way since that day. Fast forward to DrupalCon Amsterdam 2019 and we can see the Drupal Association have invested in tools on Drupal.org to track all types of contribution.

Event organisers, conference speakers, designers, and marketers are amongst the many non code contributors who are participating in ever rising numbers and critically, their efforts are tracked the same way as code commits. We are winning!

comment-attribution-exampleComment attribution for Drupal Association

As it's a topic I am passionate about, when DrupalCon was going to be hosted in the same venue 5 years on from Dries’s talk, it was a perfect occasion for me to present my session on “How to start contributing to Drupal without code”. 

Excellent ways to contribute *and* benefit for agencies and non-tech people by @pdjohnson @DrupalConEur #DrupalCon #promotedrupal pic.twitter.com/L286A5tpD2

— Imre Gmelig Meijling (@imregmelig) October 28, 2019

Photo: Imre Gmelig Meijling @imregmelig

How to start contributing to Drupal without code

No matter who you are; designer, writer, sales person, agency owner, project manager or end user I have a contribution idea for you. Even if you’re time poor or believe you have little experience, watch the session. If you still need help finding how to start your contribution journey email me or ping me on Twitter @pdjohnson.

[embedded content]

My session on non-code contribution on Youtube

In the spirit of open source and scaling Drupal, my slides are available under a Creative Commons BY 2.0 license for you to take and make your own presentation if you wish. 

Get the slides

Oct 28 2019
Oct 28

Lazy load images in Drupal with BLazy

Recently, we involved in a local project with Ecoparker.com. It is a directory of restaurants, cafes, entertainments, services, real properties ... in Ecopark Hanoi, Vietnam. This site is based on our best selling directory theme BizReview.

On this site, there is a page which lists all kindergartens around the area. It has 20 listings and will continue to grow. It is a very typical page built with Drupal views.

Kindergartens at Ecopark

By curious, we ran a PageSpeed Insight test, a Goolge provided test for accessing how fast your page is loading, to see how it performs.

The score on Desktop was 75, which is quite good. But let's see how we can improve it.

Page speed test - before

Scroll down to the Opportunities section which suggests how to help your page load faster, we see an interesting point "Defer offscreen images" with the suggestion:

"Consider lazy-loading offscreen and hidden images after critical resources have finished loading to lower time to interative

Page speed test - suggestions

Lazy loading is a technique that only serve content when it becomes visible to users, ie, when users scroll to it. If it is off screen, we don't load it to save bandwidth. It will be much useful when your sites contain a lot of images, so we don't have to load them all everytime an user browse the page. Only when the user scroll, images load and become visible.

It brought me to a question that how to lazy load on Drupal.

We had a look a the Blazy module, because it was a prerequisite of another module on our site. Previously we haven't been curious to know what it does. It turns out to be a very popular module with 30K+ sites reporting using this module.

Looking in more details, this module is very promising:

On private benchmarks, Blazy saves a page with lots of images from 14MB to 3MB, 200 http requests to 20, loading time 30s to 3s. Elevating performance grade from F/E to A/B via gtmetrix. Overall ~5-10x better.

On the description page, Blazy offers:

  1. Blazy as field formatter
  2. Blazy filter as HTML filter (on your CKEditor)
  3. Blazy Grid as Views style

That's all we need, so we started to get our hands dirty.

1. Install module:

Install and enable the module as usual, via the admin interface or composer: https://www.drupal.org/docs/8/extending-drupal-8/installing-drupal-8-mod...

Note: if you use Slick module for slideshows, it requires Blazy 1.0. But to get Blazy as a HTML filter, you need the 2.0 version.

2. Blazy configuration:

Blazy configuration is available at /admin/config/media/blazy. There are a bunch of options, like custom placeholder image, offscreen view port etc ... You are good to go with default settings.

Drupal Blazy UI configuration

3. HTML filter

Just go to /admin/config/content/formats, edit the Full HTML format, and enable the Blazy filter.

Drupal Blazy filter as HTML filter

Your HTML content will be automatically applied Blazy filter, ie, images and iframes will be lazy loaded.

4. Lazyload iframe

On our project, we found that images lazy loading works properly, but iframes do not work by default.

After some investigation, we found a workaroud, by manually forcing iframes to lazyload.

First you need to turn off Video lazyload option on the Blazy settings tab of Full HTML filter.

Drupal Blazy, turn off iframe at HTML filter

After that, when you paste an iframe to CKEditor, for example, a Youtube video iframe:

[embedded content]

You need to edit the HTML to add class and data-src, like this:

class="b-lazy" width="560" height="315" data-src="https://www.youtube.com/embed/uLcS7uIlqPo" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen>

Then iframes will be lazy loaded properly.

5. Views

We editted the view page, on the Image field, there is a new Image format. Choose Blazy and set the image style, Save it.

Drupal Blazy on Views

All images on this view based page are now lazy loaded. If you scroll fast enough, you will see the placeholder are blinking first, then your images will show. Awesome!

After that, we ran the PageSpeed Insight test again.

Page Speed test - after

As you can see, the issue with "Defer offscreen images" is gone. The point have raised to 81, which is slightly better. That's what we need.

In conclusion, please consider to apply the lazy load technique to all of your Drupal sites, as it is highly recommended for a high performance site.

Oct 13 2019
Oct 13

The other day I was reviewing my read later items and stumbled upon the New command line tool to install & run Drupal change record I had completely forgotten about. This was timely because I was extensively testing the excellent Acquia Developer Studio for work and was trying to think about how it could help me review core changes quickly or contribute more easily. Turns out, you can’t ask for a tool to do everything and sometimes it’s important to get back to finding the right tool for the job. And in this instance, quick-start has no equivalent that I know of in terms of ease of use and required dependencies.

After playing with it a bit, I realized I could probably create a wrapper to speed up operations even more. The workflow I had in mind was this:

  • Work exclusively from the local Drupal Git clone
  • Don’t install any dependency like Drush or Drupal Console
  • Install Drupal with a one-liner
  • Optionally select a different install profile
  • Optionally install a patch
  • Clean up everything with a one-liner

And then I came up with this repo (make sure to review the README file!). Disclaimer: I’ve only tested it on Linux. It works very simply with two commands: quick-start and quick-clean.

When I type quick-start, I can either pass a Drupal profile or use the default (standard). The script takes care of pulling Composer dependencies and installing Drupal with default parameters so I can concentrate on the task at hand, not the install process itself. At some point I even experimented with assigning a dynamic port (shuf -i8000-8999 -n1) but that was so over-engineered I gave up. This is how it looks like now:

$ quick-start umami
Drupal codebase detected. Proceeding...
> Drupal\Core\Composer\Composer::ensureComposerVersion
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Package operations: 106 installs, 0 updates, 0 removals
- Installing composer/installers (v1.7.0): Loading from cache
> Drupal\Core\Composer\Composer::vendorTestCodeCleanup
(snip)
Generating autoload files
> Drupal\Core\Composer\Composer::preAutoloadDump
> Drupal\Core\Composer\Composer::ensureHtaccess
Skipped installation of bin bin/composer for package composer/composer: file not found in package
18/18 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓]
Congratulations, you installed Drupal!
Username: admin
Password: UvtRWr-Z82WKfV2Q
Drupal development server started: 
This server is not meant for production use.
One time login url: 
Press Ctrl-C to quit the Drupal development server.

If I want to, I can even pass a patch file:

$ quick-start minimal https://www.drupal.org/files/issues/2019-09-10/2966607-127.patch
Drupal codebase detected. Proceeding...
HEAD is now at 10c41e77a5 Issue #3079810 by jhodgdon, andypost, mikelutz: core/help_topics directory does not work
Already up to date.
--2019-10-15 16:27:51--  https://www.drupal.org/files/issues/2019-09-10/2966607-127.patch
Resolving www.drupal.org (www.drupal.org)... 151.101.194.217, 151.101.130.217, 151.101.66.217, ...
Connecting to www.drupal.org (www.drupal.org)|151.101.194.217|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 33247 (32K) [text/plain]
Saving to: ‘2966607-127.patch’
2966607-127.patch             100%[===============================================>]  32,47K  --.-KB/s    in 0,02s   
2019-10-15 16:27:51 (1,27 MB/s) - ‘2966607-127.patch’ saved [33247/33247]
Checking patch core/lib/Drupal/Core/Cache/CacheTagsChecksumInterface.php...
(snip).
Applied patch core/tests/Drupal/KernelTests/Core/Cache/EndOfTransactionQueriesTest.php cleanly.
> Drupal\Core\Composer\Composer::ensureComposerVersion
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Package operations: 107 installs, 0 updates, 0 removals
- Installing composer/installers (v1.7.0): Loading from cache
(snip)
18/18 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓]
Congratulations, you installed Drupal!
Username: admin
Password: yIk4BtdbLEtyZ80X
Drupal development server started: 
This server is not meant for production use.
One time login url: 
Press Ctrl-C to quit the Drupal development server.

The one annoyance I have is this whole solution doesn’t really scale. I understand quick-start is for dev only and I should keep my expectations low, but it’ll fail randomly when using devel_generate, clicking on too many pages in a short period of time or installing too many modules at once. When this happens to you, just shut down the server (C^) and run quick-start again. This is a severe limitation I’ve reported here.

Anyway, once I’m done and want to clean up my repo, there’s the quick-clean command for that. It’ll wipe everything within your Git clone (seriously, be careful) so you come back to a clean Git state, with the latest commits from upstream. It looks like this:

$ quick-clean
Drupal codebase detected. Proceeding...
[sudo] password for anavarre:
HEAD is now at 03bdf28929 Issue #2860644 by daffie, shashikant_chauhan, dww: Add support of NOT REGEXP operator to PostgreSQL + fix testRegexCondition
Already up to date.

To my knowledge, there’s no easiest nor quickest way to install, test or contribute to Drupal with the bare minimum requirements to run a PHP app. Here’s a demo.

asciicast

Oct 06 2019
hw
Oct 06

One of my sites has a listing of content shown as teaser. The teaser for this content type is defined to show the title, an image, and a few other fields. In the listing, the image is linked to the content so that the visitor may click on the image (or the title) to open the content. All this is easily achievable through regular Drupal site building.

Drupal Manage Fields Page

I wanted to change the functionality so that clicking on the image would open the content in a new tab. This is easy for the title, as the title is linked right from within the template (node--content-type--teaser.html.twig). I just have to add the target="_blank" attribute for the tag for the title and I am done. Doing this for the image is not so easy.

Challenges with the Image Formatter

The reason it isn’t easy for the image is the image field formatter provided by the Drupal core. It provides an option to render the image as a link and link it to either the content or the file itself, but no option to open it in a new tab.

Image Formatter OptionsDigging through the code for image formatter, I found the template that drives it at image-formatter.html.twig. This template also does not help us much directly, as we cannot conditionally modify this template only for teasers for certain content types, like I wanted. If I override this file, it will affect the image formatter everywhere.

I stumbled upon an approach when searching for solutions for this, hoping I will run across an issue in Drupal core which would add this feature. I would simply apply the patch and voila, I would solve my problem, give feedback if it worked, and open source wins. Unfortunately, there was no such issue but I found something related: Image formatter does not support URL/Link options.

Sidenote: I could have created a feature request to add this feature and maybe I’ll do it when I get a chance. Today, I was just eager to get this working.

Back to the issue. I see there is a change in the template to use the link function rather than just writing an tag. This is not very helpful to me. But the issue summary described my problem, and it is strange that the patch (which was committed) does not fix it. So, I dug in more. I read the test in the patch which gave me the approach how I can implement it.

Solution

Since my solution depends on the above patch, it would work only with Drupal 8.7.4 or later. The test in the patch added attributes to the link by accessing the build array and directly setting the attribute on the URL object that is passed to the template. I realised I could do the same with template_preprocess_node.

Usage of template_preprocess_node

In the code sample above, I am targeting the specific content type and display mode (teaser) I want to modify. I use Element::children to loop through all the items in the field and access the URL object. I directly call setOption on the URL object to set the attribute target="_blank".

It might seem a lot of work but this is the fastest way I know (and minimal code change). If you know of a better way, or of the Drupal core issue that would have given this option, please let me know in the comments. I hope this post was useful. Thanks for reading.

Aug 01 2019
Aug 01

We’re thrilled to be attending Drupal Camp Pannonia from the 1st to 3rd August!

Ratomir and Dejan from the CTI Serbia office will be attending Drupal Camp to discover the biggest breakthroughs of the Open Source platform in 2019.

Grand-terrace-palic

The Grand Terrace in Palić, where Drupal Camp Pannonia is held.

Held in Palić, Serbia, near the Hungarian border, Drupal Camp Pannonia brings together some of Europe's top Drupal experts for a weekend of knowledge sharing and Open Source collaboration.

CTI Digital has long worked with a global roster of clients serving international customers. In early 2019, we made a permanent investment in Europe and opened a Serbia office. 

We selected Serbia as the Drupal community is growing quickly and filled with world-class talent. Supporting Drupal Camp Pannonia is a crucial part of our investment in the European Drupal community. If you’d like to chat with Dejan or Ratomir about CTI Digital or Drupal, please email [email protected] to set up a meeting.

Ratomir-and-Dejan-1-1

Dejan (Left) and Ratomir (Right)

We're pleased to announce Dejan (@dekisha007) is also conducting a session on Day 1, Friday 1st August at 15:45. He'll be delving into a new front-end practise we have developed at CTI Digital using Pattern Lab.

Here's what to expect:

  • Pattern Lab and Atomic Design in Drupal
  • Tailwind CSS
  • Advantages of Vue.js over React in Drupal
  • Wrapping all of the above up with CTI’s custom base theme

Be sure to catch Dejan’s talk on day 1, along with a host of brilliant sessions and workshops by checking out the online schedule.

Or follow @dcpannonia and @CTIDigitalUK for all the action on twitter.

Jul 27 2019
hw
Jul 27

This was one of last minute decided and planned Drupal meetups. I was traveling for Decoupled Days and couldn’t plan this meetup well in advance, which meant I only started looking for the venue for the meetup barely 5 days before our regularly scheduled date of the last Saturday of a month. Fortunately, we found a space in 91Springboard, one of our regular hosts.

Since the meetup was announced just three days before, I was not expecting a lot of people able to attend. We had nine attendees in all (out of 15 RSVPs) and we had people traveling from distant areas of Bangalore. Having lived in Bangalore and being stuck in Saturday traffic, I greatly appreciate their dedication to learning.

The meetup started at 10:30 AM with a brief introduction of every attendee. We covered some of the Drupal news such as recent and upcoming events in India and internationally. We also talked about Drupal 9 and other changes in the technology.

Drupal 8 modules for #AI by @paru_523 at the @drupal_bug #meetup in Bangalore. #Drupal pic.twitter.com/nxcGGgLRvc

— hussainweb (@hussainweb) July 27, 2019

At 10:45 AM, we started our first topic with Parvateesam Konapala talking about modules available to utilise Artificial Intelligence capabilities in Drupal 8. The talk was a good coverage of various modules provided by Azure Cognitive Services. Parvateesam also talked about Acquia Lift and how it utilises AI for personalisation.

Next, we have Drupal performance with Big Pipe by @er_pradosh at @drupal_bug #Drupal #meetup. pic.twitter.com/tN7XtFHS6M

— hussainweb (@hussainweb) July 27, 2019

At 11:30 AM, Pradosh Pattanayak walked us through Big Pipe and how it can help performance in Drupal. We covered the traditional sequential rendering of content and the Big Pipe style of rendering with scripting enabled and without JavaScript support.

We then took a short break followed by networking and general discussion on Drupal and related challenges. Discussions ranged from the best way to use entities for complex data structures to how to contribute to the Drupal community more.

We took a group photo and said goodbyes at 1:15 PM. For a barely planned meetup, it was a very organised and a productive day. Once again, thanks to 91Springboard for making the venue available and the support. And thank you to all those who participated and made the meetup successful. Our next meetup is planned on 24th August and I am looking forward to meet you there. You may RSVP by clicking here.

Thank you all for participating in the @drupal_bug #meetup today and all the discussions. pic.twitter.com/T4bl3EQHwS

— hussainweb (@hussainweb) July 27, 2019

Jul 03 2019
Jul 03

When someone thinks of Drupal, they think about scalability, customization, and the oh-so-steep learning curve. What isn’t thought of as much is the smooth and simple editing experience. Though there are many efforts out there to improve the editing experience in Drupal, they tend to still require a bit of tinkering before they are ready for the end user. That isn’t to say that the stock experience is unusable, but for those that are not familiar with Drupal it can be a bit complicated and confusing. We aren’t here to complain about all of that though because there is another solution to this that is gaining traction and we should most definitely talk about it. 

Introducing Gutenberg

Those that are at all familiar with WordPress will already know about the Gutenberg editing experience. The classic editor for WordPress is basically just a rich text editor that is great for writing content, and more specifically blogs posts, but requires some more understanding of markup if you want to build an actual page with it. That is where the idea for Gutenberg comes in. With this editor you build your content with blocks. These blocks handle most things you could want, such as: basic paragraphs, headings, layout, embedded videos, and more. Since Gutenberg is included and set as the default editor mode in WordPress 5.0+, everyone is going to be making use of this soon.

This really changes the way the typical WordPress page is going to look without a lot of custom work. Something that has been missing from the WordPress experience has been a way to make things look more consistent between pages. Gutenberg blocks provide this consistency while also allowing editors to build pages without much restriction.

Gutenberg in WordPress still makes use of the same shortcodes that could be entered manually to save the layout configuration and data. It just does this automatically for the user while they configure the page visually. This reduces the barrier for making interesting and varied pages that used to require a lot more intimate knowledge of the platform. 

Since Gutenberg is largely built with React, it is also very flexible and extendable. The community has put together a large collection of ready-to-use blocks in the Gutenberg Cloud plugin. This means that very little work should be required to create a wide array of pages with this editor and anything that is missing should be fairly easy to develop.

Why bring Gutenberg to Drupal?

There has been a concerted effort in Drupal 8 to bring more focus to the editing experience and overall UI of the platform. As I mentioned before, they are lacking still despite major strides in version 8 from 7. This leads to a great deal of curiosity into what other CMS are doing to solve this problem. It wasn’t too long before whispers of a port of the Gutenberg plugin came around and an alpha version of Gutenberg for Drupal came to be. 

On the surface, it can seem a bit duplicative to have something like Gutenberg in Drupal. While block-based layout and reusability may be a game changer for something like WordPress, it is old hat for the Drupal ecosystem. Creating pages using different sorts of blocks and widgets is practically one of Drupal’s claims to fame as a CMS. Not to mention, other existing solutions and modules, like paragraphs, already address something like this in a much more Drupal-y sort of way. Why both bringing in another solution with language around blocks and tokens to a system that all but invented it? 

Though it may seem redundant, it actually makes a lot of sense to do this. For one, familiarity is a luxury that Drupal can rarely offer to those new to the platform. Everything in the UI is almost entirely originated from the Drupal ecosystem and can be a bit unintuitive. Having an offering that was made popular in the CMS with a market share of somewhere around a quarter of the internet is a good way to do that. Another reason for it to be on Drupal is because the idea behind the tool isn’t a wholly WordPress specific need. Editors want to be able to build these pages without a need for expert level platform knowledge. They want to be able to create content and not worry about tokens, shortcodes, blocks, fields, etc. WordPress has a deceptively simple problem and Drupal has that for engineers by engineers feeling that isn’t always welcoming to editors.

That isn’t to say that Gutenberg for Drupal is the answer to our UI prayers, however. It is a nice solution, but it is one that comes with caveats as these things usually do. At the moment, the module has an all or nothing approach for the editing experience. The content types that have the Gutenberg experience enabled will need to have a long text field on them for it to work. It will then use that field for storage and all other fields will be stashed in the Gutenberg sidebar on the edit page. (Currently, the Gutenberg module will look for whatever field matches the description and use the first one it finds for this. Something to watch out for it you add this to an existing content type.) It fully takes over the display of the edit form as it will now be replaced with the React-based experience that Gutenberg brings.

Another thing to note on this is that the Gutenberg module does support some Drupal core blocks out of the box and should mostly support custom Drupal blocks as well. The cool part about this is that in theory you can set up things like ads, content embeds, and views ahead of time for use in many content pieces. The less cool part is that not all blocks will work, and it isn’t clear which ones do and why others do not at this time. Keep an eye on the Supported Blocks page on Drupal.org for more details as they are available.

Is Gutenberg ready for use?

Gutenberg for Drupal 8 is a very promising module that solves a lot of problems in the traditional Drupal editing experience and it is making great strides. At the time of this writing, 8.x-1.2 has been released and solves many of the issues that previously would have made this a harder module to recommend. The better question right now would be if it is worth checking out and I would say that it absolutely is. Whether you enjoy building content in Drupal or not, the Gutenberg experience is something worth trying and considering for your editors.

Apr 30 2019
Apr 30

Drupal is to release its latest version, Drupal 8.7, on the 1st May 2019. Review the entire Drupal product roadmap here.

Drupal 8.7 is a significant update for Marketers, Copywriters, Site Managers, and Creatives. It brings a new Media Library and Layout Builder, Drupal’s first drag-and-drop content manager, recently revealed at DrupalCon Seattle 2019

[embedded content]

 DrupalCon Seattle 2019

This update sees Drupal 8 retain its relevance in an emerging world of instant site builders, like Squarespace and Wix. Where Drupal has always stood out for its back-end capabilities and flexibility with API integrations, the new Layout Builder empowers Content Managers and Marketers. The user-friendly system allows Content Editors to maintain control over their content, throughout its journey to the end user. It also provides enhanced reactivity to the customer experience, as Site Managers can make edits without the assistance of a developer.

Of course, this isn’t just a standard drag-and-drop editor. Drupal 8.7 comes with a whole host of features you won’t find on low-end editors. These include instant multi-page management and the flexibility of powerful editorial workflows.


What is the Drupal Layout Builder?

The Drupal Layout Builder is a drag-and-drop content management tool. It allows non-technical individuals to design layouts in a structured way that adheres to the standard across the site. The new Layout Builder encourages users to take control, introducing blocks which help them to achieve designs and functionalities previously only editable in the developer's domain.

Key features include:

  • Modular template builder
  • Drag-and-drop paragraph editor
  • Permissions workflows
  • World-Class Accessibility 

[embedded content]

 Drupal 8.7 Layout Builder Recording

 

Simple, Reactive Page Management

Using the layout builder, Site Managers and Marketers can create new pages from templates. To build on these templates, users can insert new blocks from the pop-out sidebar that do not exist elsewhere on the site. Once the Site Manager has added a block, they can preview it instantly. At this point, if the editor isn’t happy, they can swap out blocks or replace images, text, buttons and more!

Users have recognised that it can be challenging to move huge, pre-built blocks and paragraphs in full preview. Using the preview toggle, users can now switch out of the full ‘Content Preview’ mode to a slicker block view. This simplified interface makes reordering blocks quick and easy. This differs from alternative drag-and-drop editors as the collapsed block editor sits within the same page. Therefore, editors can drag blocks across columns, as well as up and down.


Accessibility

The Drupal project has a long-standing commitment to accessibility and has been a leader in accessibility for many years. In 2018 Drupal Founder, Dries Buytaert, reaffirmed this commitment by stating that the forthcoming Layout Builder must be fully accessible.

The full 8.7 system is navigable by keyboard, in order to conform to Web Content Accessibility Guidelines, as recommended by the World Wide Web Consortium. This means that the drag-and-drop editor was designed with consideration for Site Managers, Marketers and Developers amongst us with specific accessibility requirements. Ultimately, the latest Drupal update will make agency life and in-house marketing that much more accessible to everyone.

[embedded content]

 Navigating Layout Builder by Keyboard

Workflows

The Layout Builder supports essential activities such as adding, saving and previewing content, or publishing data. The latest update also supports more complex features, such as content staging or approval workflows, using granular controls and notifications for the governance of each layout. This is a great win for marketing teams, as it de-centralises the content management process. Site managers can submit site updates safely, with version controls and final permission escalation.

For more complex updates, Drupal 8.7 supports workflows which push pages through multiple teams. For example, an initial submission which is then passed via testing teams, SEO managers, translation and localisation experts for international audiences, and final senior sign off.


Templates

The Layout Builder also includes a templating feature, useful for sites with large quantities of content. For enterprise sites, Content Managers can edit collections of pages all at once using the Layout Template Editor. Not only can they be edited in unison, they can also be rearranged while retaining their unique content. The ability to re-structure multiple pages at once saves a huge amount of time when one block needs to be changed across multiple locations.

Layout-Builder-template-modeThe Layout Builder in template editing mode

The Drupal Layout Builder was built entirely on Open Source contributions made by 123 contributors and 68 worldwide organisations.

Drupal 8.7 Layout Builder Contributors

The 123 contributors (DrupalCon Seattle 2019: Driesnote)

Media Library

Drupal 8.7 included the release of a Media Library, to make asset management faster for Site Managers, particularly within the drag-and-drop format.

[embedded content]

 The Media Library in action

The Media Library is a pop-out window from which images and video can be inserted into the webpage. The library pulls content from the organisation’s existing bank of images, hosted within Drupal. Or, users can upload media directly from their cloud or hard drive.

The addition of the Media Library allows Site Managers to insert or change images or video more efficiently than ever. The user selects the area where the image will be added and opens the Media Library. They can then select from existing images or upload multiple new assets at once. Once uploaded, users can remove or reorder any images ready for import. Once happy with the images, the user can add metadata and any extra information (like links), or change the format to video.

The Media Library was made possible by Open Source contributions from 310 individuals and 122 organisations.

Drupal 8.7 Media Library Contributors

The 310 contributors (DrupalCon Seattle 2019: Driesnote)

Technical updates

There have also been a host of additional updates and tweaks to Drupal, improving its speed and background functionality. Such updates include adding JSON:API as a core module and providing a consistent way of displaying JavaScript Messages. For the full list of technical updates, visit the Drupal website here.

What’s Next?

Administration UI - Drupal 8.8 or 8.9

The administrative side of Drupal, where site managers navigate the back end and manage content, has been close to untouched for the past 10 years.

The User Interface (UI) is currently being redeveloped to be aligned and reflect the software behind Drupal, giving it a modern look and feel. This includes better use of space (and white space) and more contrasting features. The additional space also means its more accessible, and will receive a WYSIWYG integration.

Drupal 8.8 UI

Proposed UI for Drupal 8.8

Sign up to email alerts to find out more or talk to our Drupal Web Development Experts about upgrading your Drupal Platform.

Get in touch
Mar 13 2019
Mar 13

Note: This post refers to Drupal 8, but is very applicable to Drupal 7 sites as well

Most Drupal developers are experienced building sitewide search with Search API and Views. But it’s easy to learn and harder to master. These are the most common mistakes I see made when doing this task:

Not reviewing Analytics

Before you start, make sure you have access to analytics if relevant. You want to get an idea of how much sitewide search is being used and what the top searches are. On many sites, sitewide search usage is extremely low and you may need to explain this statistic to stakeholders asking for any time-consuming search features (and yourself before you start going down rabbit holes of refinements).

Take a look for yourself at how the sitewide search is currently performing for the top keywords users are giving it. Do the relevant pages come up first? You’ll take this into account when configuring boosts.

Using Solr for small sites

Drupal 8 Search API comes with database search included. Search API DB has come a long way over the years and is likely to have the features you need for smaller sites. Using a Solr backend is going to add complexity that may not be worth it for the amount of value your sitewide search is giving. Remember, if you use a Solr backend you have to have Solr running on all environments used in the project and you’ll have to reindex when you sync databases.

Not configuring all environments for working Solr

Which takes us to this one. If you do use Solr (or another server-side index) you need to also make sure your team has Solr running on their local environments and has an index for the site. 

Your settings.php needs to be configured to connect to the right index on each environment. We use Probo for review sandboxes so we need to configure our Probo builds to use the right search index and to index it on build.

Missing fields in index or wrong type

Always included the ‘Rendered HTML’ field in your search index rather than trying to capture every text field on all your content types and then having to come back to add more every time you add a field. Include the title field as well, but don’t forget to use ‘Fulltext’ as its field type. Only ‘Fulltext’ text fields are searchable by word.

Not configuring boosts

In your Processor settings, use Type-specific boosting and Tag-boosting via HTML filter. Tag boosting is straightforward: boost headers. For type-specific boosting you’re not necessarily just boosting the most important content types, but also thinking about what’s in the index and what people are likely looking for. Go back to your analytics for this. 

For example, when someone searches for a person’s name, are they likely wanting the top result to be the bio and contact info, a news posting mentioning that person, or a white paper authored by the person? So, even if staff bios are not the most important content on the site, perhaps they will need to be boosted high in search, where they are very relevant.

Not ordering by relevance

Whoops. This is a very common and devastating mistake. All your boost work be damned if you forget this. The View you make for search results needs to order results by Relevance: Descending.

Using AJAX

Don’t use the setting to ‘Use AJAX’ on your search results View. Doing so would mean that search results don’t have unique URLs, which is bad for user experience and analytics. It’s all about the URLs not about the whizzbang.

Not customizing the query string

Any time you configure a View with an exposed filter, take the extra second to customize the query string it is going to use. ‘search’ is a better query string than ‘search_api_fulltext’ for the search filter. URLs are part of your user interface.

No empty text

Similarly, when you add an exposed filter to a search you should also almost always be adding empty text. “No results match your search” is usually appropriate.

Facets that don’t speak to the audience

Facets can be useful for large search indexes and certain types of sites. But too many or too complex facets just create confusion. ‘Content-type’ is a very common facet, but if you use it, make sure you only include in its options the names of content types that are likely to make sense to visitors. For example, I don’t expect my visitors to understand the technical distinction between a ‘page’ and a ‘landing page’ so I don’t include facet links for these.

A screen shot of facets in DrupalYou can exclude confusing facet options 

Making search results page a node

I tell my team to make just about every page a visitor sees a node. This simplifies things for both editors and developers. It also ensures every page is in the search index: If you make key landing pages like ‘Events Calendar’ as Views pages or as custom routes these key pages will not be found in your search results. 

One important exception is the Search Results page itself. You don’t want your search results page in the search index: this can actually make an infinite loop when you search. Let this one be a Views page, not a Views block you embed into a node.

Important page content not in the ‘content’

Speaking of blocks and nodes, the way you architect your site will determine how well your search works. If you build your pages by placing blocks via core Block Layout, these blocks are not part of the page ‘content’ that gets indexed in the ‘Rendered HTML.’ Anything you want to be searchable needs to be part of the content. 

You can embed blocks in node templates with Twig Tweak, or you can reference blocks as part of the content (I use Paragraphs and Block Field.)

Not focusing on accessibility

The most accessible way to handle facets is to use ‘List of Links’ widget. You can also add some visually hidden help text just above your facet links. A common mistake is to hide the ‘Search’ label on the form. Instead of display: none, use the ‘visually-hidden’ class.

Mar 05 2019
Mar 05

Running a business is demanding. To be successful requires leadership be equipped with a broad range of skills from financial astuteness to empathy for staff. Whilst developers have ample resources from which to draw reference on best practice, for managers and business leaders knowledge gained is often be deemed competitive advantage and so kept secret or is accessed only through expensive training or courses.

Working in open source brings many benefits including the fostering of knowledge transfer that transcends merely code. It is to the benefit of all that business leaders in Drupal share this openness and are willing to reveal lessons learnt or formulae of success, that in other industries would remain behind closed doors. A fine example of this mindset is DrupalCamp London CXO, this years incarnation was no exception.

Prof. Costas Andriopoulos, Cass Business School, spoke about leadership and innovation in scaling enterprises. He explained that it’s far wiser to sort out your business early, when you are small and well ahead of scaling because what kills businesses is success, age and size.

Prof. Costas Andriopoulos

 

Success: breeds complacency, overstretching, even arrogance. All of these can be the downfall of your business.

Age: of leadership and team leads to them becoming slower, more stuck in your ways. Andriopoulos stated that curiosity drops with age — a child asks over 400 questions per day. By adulthood and towards later life this drops dramatically.

Size: brings bureaucracy, slowing the pace at which information disseminates. Layers of management become more risk averse. Humans are natural hoarders, it’s normal he says for people add but we hold on to things too long. This slows businesses down.

To maintain momentum in decision making he recommended all meetings and team sizes should be manageable — 4 or five, the best team is 2. There’s nowhere to hide here. You have to participate. In large meetings people repeat one another often or may say nothing at all.

Andriopoulos recommended when facing challenging projects do a pre-mortem. Split the team in two, half of them imagine the plans has been put in motion and failed terribly. Then write a story of what happened. The other half imagine that it succeeded and write their story of how that happened. Doing so equips you with a variety of scenarios to consider before the work beings.

Rasmus Lerdorf founder of the programming language PHP

 

Rasmus Lerdorf, founder of the programming language PHP, gave a potted history of how the language came to be and prospered. What struck me was how innovation and breaking free of the norm were key drivers. In the early days where hardware and networks were far slower than we know today, Rasmus questioned the merit of querying databases without the ability to reduce verbosity of responses. He introduced the “LIMIT” clause, something we all take for granted now, to introduce efficiency gains in early internet applications.

Upgrading to PHP 7 across the web would remove 7.5 BN Kg carbon dioxide emissions

Rasmus Lerdorf

 

This ethos remains today. Lerdorf stressed the importance of upgrading to PHP 7 or above as the dramatic performance improvements significantly reduce the physical hardware required to support PHP applications. Since PHP powers >70% internet sites, our efforts combined will contribute to he estimates a 15B KWH energy savings and 7.5 BN Kg less carbon dioxide emissions.

Michel Van Velde, founder of One Shoe agency

 

Michel Van Velde, founder of One Shoe agency, spoke openly of the challenges his business faced in 2017 and how a combination of reading and hiring a personal coach helped him evolve his approach to leadership, behaviour and in doing so the actions of his staff.

His presentation was a shining example of how business leaders in open source act differently. Whilst on the face of it counterintuitive, by sharing how he overcame adversity in his life with his potential competitors, what Michel was actually doing was helping his peers to avoid these pains meaning we all rise. Doing so he is contributing to a virtuous circle.

Van Velde put his success in 2018 down to a combination of three factors, rooted in knowledge of three leadership models and an appreciation of how to apply them to his circumstances.

The Drama Triangle: defines any conflictual situation to have victim, rescuer, persecutor. An oversimplification is to say a victim typically takes the “poor me!” stance, Rescuers are those who might choose to say “Let me help you!”, Persecutor adopts the “It’s all your fault!” stance.

Radical Candor: is the ability to Challenge Directly and show you Care Personally at the same time. “Radical Candor really just means saying what you think while also giving a damn about the person you’re saying it to”

Transactional Analysis: considers that we each have internal models of parents, children and also adults, and we play these roles with one another in our relationships. If we grow an appreciation in our daily conversations, meetings and conflicts what state we and others are in (parents, children, adults) we can begin to realise how to avoid or deal with conflict.

Van Velde explained that by rewiring how he dealt with his staff not meeting expectation, dealing with situations in such a way to offer his team the opportunity to realise their shortcomings themselves, providing opportunities to address their behaviour he was creating a positive environment in which his staff could grow.

Melissa Van Der Hecht’s presenting on “Why we need to be more open about diversity in tech”

 

Melissa Van Der Hecht’s presentation on “Why we need to be more open about diversity in tech” was a breath of fresh. I can never hear enough on this topic. I found her angle refreshing.

Rather than specifying diversity through gender, race, religion she saw diversity as that which makes us stand out, what makes us special. She talked about the fact that as a female in tech you have to work harder, a lot harder, to convince men you are worthy of respect and have your ideas recognised as having merit. Van Der Hecht said this is unrelenting. At best exhausting and worst leads to burnout, reporting those from minority groups suffer double burnout rates over those in the majority.

Van Der Hecht went on to explain that unconscious bias really hard to adjust. She spoke of the “Surgeon’s dilemma”, a test for unconscious bias and admitted she fell for this riddle. I compel you to take the test, how did you fare?

Watch this short video, as a further example used in the presentation illustrating the point. For me, rather than despair, it actually gave hope that generations soon entering the workplace could bring a tidal wave of impressive minds.

[embedded content]

 

Van Der Hecht highlighted that diverse teams are more productive, more innovative and creative. There is a strong correlation between diversity and increased innovation.

According to Forbes.com companies with more diverse teams reported 19% higher revenue due to innovation

 

I always remember Erynn Petersen, Executive Director of Outercurve an OSS foundation, speaking at DrupalCon Austin. She cited data showing that diversity leads to better performance in business. It’s hard to ignore these facts, unwise not to act upon the evidence.

I couldn’t help but notice while Melissa was speaking to an audience of ~100 people, only 3 were female, few of mixed race. True they were from across Europe, but the male dominance alone was striking. The Drupal is committed to diversity, during the weekend event it was striking to me how more diverse the attendee mix was. There is clearly a way to go in terms of fostering diversity in management, agency leadership. We should all consider how in our businesses we create cultures which foster diversity. We all have a lot to benefit from that.

I’ve strived in our business to create a culture which embraces all. It takes time and we are constantly learning, listening and evolving. These things don’t happen overnight and take commitment and a willingness to change.

We are fortunate in Drupal to have a vast community with many inspiring contributors from diverse backgrounds. Next time you are on Slack, at a meetup, DrupalCamp or Con why not take time out to open a conversation with someone quite different to you. It’s quite possible you’ll begin to realise being different is what makes them special. Thanks Melissa!

 

Feb 05 2019
Feb 05

Outlets for contributing to Drupal beyond code, whilst abundant, are not always evident to those having interest to do so. I want to help people become better acquainted with ways to get involved and how to start their contribution journey. Be they completely new to Drupal or simply yet to find an outlet.

At DrupalCamp London 2019 I will be speaking about non-code contributions and invite you to share your experiences and ideas. Open my eyes to the many ways individuals can create impact with their time, without knowing code at all.

Your participation will ensure attendees discover a multitude of ways to get involved well beyond my experiences alone. In doing so you are embodying the principle of contributing without code.

Therefore I have set up a Google Form to collect suggestions from the community. Please complete it with as many ideas as you have and I look forward to reading your suggestions!

Share your ideas

Jan 30 2019
Jan 30

Drupal Camp London is a 3-day event celebrating the users, designers, developers and advocates of Drupal and its community! Attracting 500 people from across Europe, after Drupalcon, it’s one of the biggest events in the Drupal Calendar.

CxO day, on Friday 1st March, is dedicated to businesses using Drupal, encouraging them to lead development and innovation of the Drupal platform.

The weekend (2nd & 3rd March) then packs in over 40 sessions covering seminars, Birds of a feather talks, Sprints and much more. Over the weekend there are also 3 Keynotes addressing the biggest upcoming changes to the technical platform, its place in the market, and the wider Drupal community.

Drupal camp 2018 Ryan SzramaRyan Szrama delivering a session at Drupal Camp 2018, Photo Cred: @pdjohnson

Our Weekend Sessions

Our Drupal Director, Paul Johnson, will be focussing on contributions to Drupal, but not as you know them. The session will be diving into a whole host of ways to contribute to Drupal that don’t require code. From content writing to photography, this session includes something for everyone and is guaranteed to spark some inspiration for new Drupal community initiatives.

Our UX specialist, James Genchi, will also be speaking at Drupal Camp London about UX and accessibility. With a background in development and a passion for user experience, James’ understanding of accessibility within design and development is vast. Following a substantial redesign for the University of West London, James will be sharing the unique design considerations he applied to achieve global accessibility within the website. In particular, he will be highlighting how accessible design is not just for people with a permanent disability, but also for those with a temporary and situational disability.

Be sure to follow us on twitter  so you don't miss either of these sessions!

Why should you attend Drupal Camp? 

[embedded content]

 

Exchange knowledge

Discover the latest in UX, design, development, business and more. There’s no limit to the types of topics that could come up...as long as they relate to Drupal that is!

Network

From C-Level and Site managers to developers and designers, over 500 people attended last year. Meet the best and brightest in the industry at talks and breakouts.

Recruit and be recruited

A wide variety of business and developers attend Drupal Camp, make the most of it by creating connections to further your own career or grow your agency team.

Reasons for attending the weekend eventImg Cred: Drupal Camp

We hope to see you there! Grab your ticket while you still can on the Drupal Camp website.

Tickets 

And be sure to follow us on your social platform of choice to find out when our sessions are!

Jan 28 2019
Jan 28

SDSU Extension is a South Dakota State University organization that provides educational outreach programs for the citizens of South Dakota. They provide farmers, ranchers, agri-business people, communities, families, and youth with the research-based information they need to succeed.

Solutions Four Kitchens Provided

SDSU Extension wanted to improve content creation and editing workflow on their website and provide a better navigation experience for users. They wanted to assure that content was presented in a consistent manner and that all information was the most up to date.

SDSU Extension took full advantage of Four Kitchens UX and strategy expertise to get them on the right track for a new site. This was a necessary step in the project that proved to be a critical component of delivering a solid end product for the project.

SDSU recently rebuilt their main site (sdstate.edu) with Drupal 8 and SDSU Extension was ready to follow suit. SDSU Extension was on a very old ExpressionEngine install that became difficult to manage content and users. Four Kitchens built a Drupal 8 solution that solved their primary concern; more versatile content management while keeping a consistent look and feel for their content. We took the time to define a content architecture plan to match the needs discovered with our UX and strategy work.

The Drupal 8 build was based on the Thunder distribution which provided a great starting point and gets us an improved administrative experience out of the box. We used CircleCi to build, test, and deploy the application on Acquia Cloud where the site is hosted. We took advantage of paragraphs and custom entities and to give SDSU Extension the tools they need to create consistent and rich page layouts for all content. We built a custom site search solution based on Solr with facets to allow users to search by text and filter results.

SDSU Extension content is generated and created by SDSU Extension faculty and staff. Most of these users already have profile information on sdstate.edu. We worked with their IT staff to help them expose this profile information with JSON API so that we could consume the data and display it on their profile on the new SDSU Extension site. This allows them to have a canonical point of data entry for the profile information while displaying it on both sites.

Kudos to team members

The SDSU Extension team was lead by Alex Hicks as the project manager and Adam Erickson as the tech lead who also molded the architecture plan for the project. Donna Habbersat led the UX strategy for the project and shared the project owner responsibilities with Adam. Randy Oest crafted a beautiful new design for the project and assisted Evan Willhite who lead the charge on implementing the design and provided some frontend magic. Joel Travieso handled much of the backend heavy lifting while contributing valuable input to architecture improvements. This group was like a ‘well oiled machine” as quoted by the client. A huge shout out to Lindsey Gerard and the SDSU Extension staff for all the hard work and efforts on their side to make this project a success.

Jan 28 2019
Jan 28

At Four Kitchens, we take accessibility very seriously. It is why we choose tools like Drupal that take it seriously as well. We are always looking for ways to improve our efforts on this front, which is why on a recent project for SDSU Extension, we implemented automated testing in our prototyping tool and Drupal 8 theme, Emulsify. This means that every custom component we now build in Emulsify gets automatically tested and any errors/warnings are flagged to the developer immediately. Awesome! Let’s dig into some of the details.

SDSU Extension

Education, among some other fields, has strict requirements around accessibility. We work hard with these clients to ensure their project meets the expected standard, but we also expect a certain baseline of accessibility on any project we deliver regardless of whether accessibility is a stated goal. For the SDSU Extension project, we needed to meet and/or exceed WCAG 2.0AA standards. Drupal core and many of the contributed modules put such a heavy focus on meeting that standard that an enormous amount of foundational work is done for us. However, when it comes to us designing and coding custom components, it is up to us to also deliver up to that standard. This is where automated testing comes in.

Automated Testing Using Pa11y

Even with the best intentions, vendors and clients often find themselves putting off best practices (accessibility, performance, documentation) in favor of deadlines. This is why automated testing is so important. With automated tests, accessibility issues are surfaced immediately during the build process and ideally then fixed within the scope of that same deliverable. This ensures the component is not only accessible upon delivery but also avoids the stress of last-minute fixes in the final phase of the project.

There are many tools out there for running automated tests, but one of the most popular is pa11y. Having had good experiences with their testing suite on a recent React project for PRI.org, we decided to use it in Emulsify as well. The results were fantastic! We were able to set a baseline of WCAG 2.0 AA but offer that and many more options in configuration to make it easy to change that for a given project. See below for more technical details.

Technical Details

Unlike much of Emulsify Gulp, instead of writing a Gulp command to accomplish a task, we instead created a function to simply run a pa11y test (code). This has been added to our CSS and Pattern Lab Gulp (watch) tasks, so basically it is run whenever a component stylesheet or Twig file is saved. The test is run not just against the component code but the rendered Pattern Lab url that is generated from that component. This means that it tests the final code but also catches visual errors such as color contrast. Besides errors, we also show notices and warnings by default, exposing the handy recommendations that pa11y gives for things that automated tests can’t verify.  However, these settings and many more (including the standard itself) are available to be changed via the configuration file (see here for instructions on creating a local config in Emulsify).

Final Note on Accessibility Testing and the Future

Automated testing is a great tool in verifying the accessibility of a project but is only one tool and it does not guarantee a fully accessible product on its own. That said, we are so excited to have this in place for all our Drupal projects moving forward (and to offer it back to the community) as an important step towards building more accessible and responsible products for our clients. Also, we hope to add even more automated tests into our toolchain soon. Here’s to building a more accessible web!

Jan 28 2019
Jan 28

Begin with the end in mind—defining our goals

Our collaboration with South Dakota State University’s (SDSU) outreach arm, SDSU Extension, began by defining the user experience and branding issues that the previous site had. The visual design was in need of an update, the team wanted to make information easier for people to find, and mobile users were forced to view the desktop version of the site.

With these issues defined, we put together a series of goals that fell into two major groups—user experience and branding. For the user experience goals, we defined a user-centered approach to ensure that the work we were doing was going to help people using the site engage more with the site and more easily find what they were looking for. For the branding goals, we wanted an improved, modern look and feel that felt like a part of the larger South Dakota State University brand.

Creating a palette to work from (e.g. creating Style Tiles)

Every design project at Four Kitchens starts with a visual alignment in the form of style tiles, a design deliverable showing colors, fonts, and elements that helps create a common visual language for the project.

These are presented to everyone using InVision Freehand so that as we discuss the options we can add notes directly on the style tiles. For SDSU Extension we had two rounds of style tiles, landing quickly on one that we all agreed was the right direction.

Figuring out what we’ll need (e.g. wire-framing all the things)

Design systems are all the rage in the industry and with good reason. They allow projects to move more quickly by having a library of reusable parts that are ready to go. So at this point in the process for SDSU Extension, it was time to define what those parts needed to be.

We did this by reviewing the current site and discovery document to suss out what was going to be important for the new site. As a group—Four Kitchens and SDSU Extension—had discussions to detail what sorts of things would be vital and what would be nice-to-haves.

From there we worked up a series of wireframes that showed both a component library—a page with every possible thing on it, like cards, quotes, and video callouts—and a few samples of how the new pages could be assembled from these parts.

This process worked out the kinks for trickier components, like the many-level deep navigation on mobile while minimizing effort. The cycle of posting, review, and implementing feedback was quick leading us to a final collection of wireframes.

Making it come to life (e.g. comps)

As soon as wireframes were approved we moved into the next step—breathing life into them. We took the visual language that was defined in the style tile and applied it to the wireframes. The designs included all of the components at small, medium, and large screen sizes.

These components were then quickly assembled into mock pages to show what they would look like when the site was done. Having a wealth of work already done in the form of style tiles and wireframes, we hit on the right direction quickly. Once the first few comps were finalized there was a flood of comps as we built them out faster and faster using previously approved components.

A great collaboration

Working with SDSU Extension on this project was marvelous and we’re happy that it is live and shared with the rest of the world.

Dec 17 2018
Dec 17

Drupal is an enormously welcoming community with countless online forums and community events to learn about the platform. Its open-source knowledge sharing and peer review is arguably second-to-none, and thanks to Acquia's Drupal certifications the Drupal learning process is becoming more consolidated.

However, nothing can quite beat the quality, focus, and hard work that goes into publishing a book. We’ve quizzed our Drupal developers and members of the Manchester tech community to find out which books every Drupal developer must read.


Drupal-Specific Books

 

Drupal 8 Module Development

Drupal 8 Module Development: Build and customize Drupal 8 modules and extensions efficiently

By Daniel Sipos

This book is a great welcome to Drupal 8, introducing you to the architecture of D8 and its subsystems, for a thorough foundational understanding. It guides you through creating your first module and continues to build upon your skills with more functionalities that all modern developers need to know.

View on amazon

Drupal Development Cookbook

Drupal 8 Development Cookbook - Second Edition: Harness the power of Drupal 8 with this recipe-based practical guide

By Matt Glaman

Using a fun, easy-to-follow recipe format, this book gives you an expansive look at the basic concepts of Drupal 8, in a step-by-step fashion. While this sometimes misses out on the ‘why’ of an action, it makes building new modules approachable and unintimidating for any level of developer.

View on amazon

Ambitious, intelligent, and a great Drupal developer? Check out our careers page.

CTI Careers

Drupal 8 Explained

Drupal 8 Explained: Your Step-by-Step Guide to Drupal 8

by Stephen Burge

Written in no-nonsense plain English, this book is great for any Drupal beginner. It’s been praised as the day-to-day reference book that any new developer should keep handy on their desk.

View on amazon

Drupal 8 Blueprints

Drupal 8 Blueprints: Step along the creation of 7 professional-grade Drupal sites

By Alex Burrows

This Drupal 8 guide will take you through 7 real Drupal 8 sites to demonstrate the latest practices in action. This all-encompassing view provides a look at the reasoning and methodology behind certain practices, and context for their larger impact on the site.

View on amazon

Definative Guide To Drupal 7

The Definitive Guide to Drupal 7 (Definitive Guide Apress)

by Benjamin Melancon

While new sites are being built in Drupal 8, it’s important the remember that many of the sites you’ll work on and maintain are in Drupal 7. This comprehensive book provides the nuts and bolts of any Drupal 7 site, to build a powerful and extensible system. Some concepts are slightly dated, so we’d recommend cross-checking online occasionally.

View on amazon

Pro Drupal 7 Development

Pro Drupal 7 Development (Expert's Voice in Open Source)

by Todd Tomlinson

This book is for slightly more ambitious developers as it quickly jumps through the basic modules to the more complex. Breaking down the development of APIs and improvements to Drupal 7, this book will have any Drupal Developer producing complex modules in no time.

View on amazon

Essential Development Books

Many coding principles span development languages and frameworks. Here are our essentials for any developer seeking the ability to produce high quality, clean code.

The Clean Coder

The Clean Coder: A Code of Conduct for Professional Programmers

By Robert C. Martin

This book delves into the difference between good and bad code. Split into 3 parts, the book first discusses principles, patterns, and practices of writing clean code. Real world case studies follow, before the book finishes with the signs of bad code and problem solving skills needed to de-bug and refresh any code base.

View on amazon

CSS

CSS Secrets: Better Solutions to Everyday Web Design Problems

by Lea Verou

CSS Secrets explains how to code common 'real world' solutions with CSS. Condensing the most useful and practical examples, this book is a more exciting read than the often extensive paperbacks which try to cover absolutely everything.

View on amazon

PHP and Javascript

Learning PHP, MySQL & JavaScript 5e (Learning PHP, MYSQL, Javascript, CSS & HTML5)

By Robin Nixon

Begin expanding your language stack with this multifaceted book. PHP is essential for any Drupal developer as it forms the core language of the Drupal framework. Meanwhile, learning Javascript, CSS and HTML5 will empower you to deliver more complex solutions.

View on amazon

And lastly, an open source book about… open source

The Cathedral & the Bazaar

By Eric S. Raymond

While this piece is slightly dated, it’s underlying concepts are still highly relevant and give great insight into the origins and essence of open source. It’s also free, so definitely still worth having a skim through… if you can handle the formatting!

Read it for free

I hope you've found some great reads here, if you've got a personal favourite please let us know below. Also if you're interested in advancing your Drupal career, please check out our careers page to see if there's a position perfect for you.

Careers at CTI Digital

Dec 10 2018
Dec 10

Zivtech is happy to be offering a series of public Drupal 8 trainings at our office in downtown Philadelphia in January 2019. 

Whether you consider yourself a beginner or expert Drupal developer, our training workshops have everything you need to take your Drupal skills to the next level. 

Our experience

The Zivtech team has many years of combined expertise in training and community involvement. We have traveled all over the world conducting training sessions for a diverse range of clients including, the United States Department of Justice, the Government of Canada, CERN, Howard Hughes Medical Institute, Harvard University and more. 

We pride ourselves in educating others about open source, and attendees will leave our trainings with the knowledge to build custom Drupal sites, solve technical issues, make design changes, and perform security updates all on their own. We also offer private, onsite trainings that are tailored to your organization's specific needs. 

Our public Drupal trainings for January 2019 include:

Interested in learning more about our upcoming trainings? Click here. You can also reach out to us regarding multi-training and nonprofit discounts, or personalized trainings. 

We hope to see you in January!
 

Nov 06 2018
Nov 06
Jody's desk

Hardware

After a long run on MacBook Pros, I switched to an LG Gram laptop running Debian this year. It’s faster, lighter, and less expensive. 

If your development workflow now depends on Docker containers running Linux, the performance benefits you’ll get with a native Linux OS are huge. I wish I could go back in time and ditch Mac earlier.

Containers

For almost ten years I was doing local development in Linux virtual machines, but in the past year, I’ve moved to containers as these tools have matured. The change has also come with us doing less of our own hosting. My Zivtech engineering team has always held the philosophy that you need your local environment to match the production environment as closely as possible. 

But in order to work on many different projects and accomplish this in a virtual machine, we had to standardize our production environments by doing our own hosting. A project that ran on a different stack or just different versions could require us to run a separate virtual machine, slowing down our work. 

As the Drupal hosting ecosystem has matured (Pantheon, Platform.sh, Acquia, etc.), doing our own hosting began to make less sense. As we diversified our production environments more, container-based local development became more attractive, allowing us to have a more light-weight individualized stack for each project.

I’ve been happy using the Lando project, a Docker-based local web development system. It integrates well with Pantheon hosting, automatically making my local environment very close to the Pantheon environments and making it simple to refresh my local database from a Pantheon environment. 

Once I fully embraced containers and switched to a Linux host machine, I was in Docker paradise. Note: you do not need a new machine to free yourself from OSX. You can run Linux on your Mac hardware, and if you don’t want to cut the cord you could try a double boot.

Philadelphia City Hall outside Jody's office
A cool office view (like mine of Philly’s City Hall) is essential for development mojo

Editor

In terms of editors/IDEs I’m still using Sublime Text and vim, as I have for many years. I like Sublime for its performance, especially its ability to quickly search projects with 100,000 files. I search entire projects constantly. It’s an approach that has always served me well. 

I also recommend using a large font size. I’m at 14px. With a larger font size, I make fewer mistakes and read more easily. I’m not sure why most programmers use dark backgrounds and small fonts when it’s obvious that this decreases readability. I’m guessing it’s an ego thing.

Browser

In browser news, I’m back to Chrome after a time on Firefox, mainly because the LastPass plugin in Firefox didn’t let me copy passwords. But I have plenty of LastPass problems in any browser. When working on multiple projects with multiple people, a password manager is essential, but LastPass’s overall crappiness makes me miserable.

Wired: Linux, git, Docker, Lando
Tired: OSX, Virtual machines, small fonts
Undesired: LastPass, egos

Terminal

I typically only run the browser, the text editor, and the terminal, a few windows of each. In the terminal, I’m up to 16px font size. Recommend! A lot of the work I do in the terminal is running git commands. I also work in the MySQL CLI a good deal. I don’t run a lot of custom configuration in my shell – I like to keep it pretty vanilla so that when I work on various production servers I’m right at home.

Terminal screenshot

Git

I get a lot of value out of my git mastery. If you’re using git but don’t feel like a master, I recommend investing time into that. With basic git skills you can quickly uncover the history of code to better understand it, never lose any work in progress, and safely deploy exactly what you want to.

Once I mastered git I started finding all kinds of other uses for it. For example, I was recently working on a project in which I was scraping a thousand pages in order to migrate them to a new CMS. At the beginning of the project, I scraped the pages and stored them in JSON files, which I added to git.  At the end of the project, I re-scraped the pages and used git to tell me which pages had been updated and to show me which words had changed. 

On another project, I cut a daily import process from hours to seconds by using git to determine what had changed in a large inventory file. On a third, I used multiple remotes with Jenkins jobs to create a network of sites that run a shared codebase while allowing individual variations. Git is a good friend to have.

Hope you found something useful in my setup. Have any suggestions on taking it to the next level?
 

Oct 29 2018
Oct 29

At this year's BADCamp, our Senior Web Architect Nick Lewis led a session on Gatsby and the JAMstack. The JAMStack is a web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup. Gatsby is one of the leading JAMstack based static page generators, and this session primarily covers how to integrate it with Drupal. 

Our team has been developing a "Gatsby Drupal Kit" over the past few months to help jump start Gatsby-Drupal integrations. This kit is designed to work with a minimal Drupal install as a jumping off point, and give a structure that can be extended to much larger, more complicated sites.

This session will leave you with: 

1. A base Drupal 8 site that is connected with Gatsby.  

2. Best practices for making Gatsby work for real sites in production.

3. Sane patterns for translating Drupal's structure into Gatsby components, templates, and pages.

This is not an advanced session for those already familiar with React and Gatsby. Recommended prerequisites are a basic knowledge of npm package management, git, CSS, Drupal, web services, and Javascript. Watch the full session below. 

Oct 02 2018
Oct 02

Whilst at Drupal Europe last month, I was privileged to be invited by Drupal’s founder, Dries Buytaert, to a round table discussion, aimed at further marketing the Drupal project.

Bringing together a number of leaders from the Drupal community, we all shared the same desire to boost the marketable assets of the open source platform. One of the ways we hope to achieve this publicity is by creating a comprehensive, customer-facing "Pitch Deck".

The session began as a workshop, facilitated by Adam Goodman. He primed the group to start  identifying and explore opportunities to better convey the benefits of Drupal to the uninitiated. The ultimate objective is to encourage the adoption of the Drupal platform. Consensus was reached that we focus upon three separate initiatives.

  

We're not competing with one another, yet we’re not helping each other either. Our role as leaders is to activate the assets that already exist in the community. Bert Boerland

The initial plan it to create a marketing resource that will present Drupal’s credentials in a persuasive manner. This slide deck will also contain impressive exemplar case studies, to ease the process of convincing an organisation or client to choose Drupal.

The Team

I volunteered to take overall responsibility for the creation of the end result. Joining forces with Suzanne Dergacheva and Ricardo Amarowho bring rich, varied perspectives and skill sets, I feel confident providing the basis for this universal toolkit. But we can only be truly successful if many others contribute to our initiative. We need sales people, marketers, copywriters to join our cause.

Get Involved Today

Providing a single and persuasive resource, available for all Drupal promoters, to sell the powerful advantages of Drupal will benefit all who use it. With strong consistent messaging, and bolstered by the many Drupal success stories, the deck will position all advocates better to expand the Drupal market share across many scenarios.

With a core team of fellow Drupal professionals, we plan to cover as many topics as we can identify, from security, accessibility and performance functionality through to specific industry verticals, like Higher Education or Media. The key intention is to show how Drupal can adapt to fit projects of all shapes and sizes, across all industries.

 

The Benefits

Many of Drupal’s competitors (think Wordpress, Squarespace etc.) are widely publicised and, consequently, innately popular. In many cases, Drupal may well be the ideal platform for a project, but it risks losing out to competing CMS providers as the success and potential of Drupal is not easily demonstrated.

Our intended users are sophisticated purchasers. As they ask more and more questions, our responsibility grows to equip agencies with comprehensive information. By using the collaborative resource, agencies will be able to accurately sell the Drupal platform, whilst spending more of their energy and resources focusing on the services they deliver. Freeing up time from writing and re-writing duplicated Drupal sales, organisations will be left to promote their unique strengths.


The Plan

We plan to kick off the project by identifying the high-level requirements and the mechanism to create the slide deck. From there, we hope to crowdsource for support, and seek volunteers from the wider business community. By recruiting sales people, marketers, copywriters and subject matter experts, we hope to create a well-rounded resource, targeted at the varied stakeholders of a new Drupal development project.

Brainstorm Notes from Drupal Europe RoundtableBrainstorm Notes from Drupal Europe Roundtable - Photo by Meike Jung

By working together, embracing open source ideals, we hope to rapidly achieve the first incarnation of the slide deck, ready for it to be built upon in the future. The sooner we create a draft, the sooner we can share the potential of Drupal with a wider audience. Projects like this prove that you needn’t be a web developer to be part of the welcoming Drupal community.

Get Involved!

If you’re interested in getting involved with this innovative project, please get in touch via our web form. Any contributions, big or small, will be gratefully received, as we strive to convert this idea into a reality.

Join the cause, let’s make Drupal better together!

Get Involved Today

Drupal.org Issue: Drupal "Pitch Deck" for Presenting to (Potential) Customers 

Sep 29 2018
hw
Sep 29

Another month, another Drupal meetup in Bangalore. This month’s meetup was held at Athenahealth office on Lavelle Road in Bangalore. Since the last month’s meetup was scheduled a week early, there was more than usual gap since the last meetup. This time, we had a full schedule and exciting sessions planned. For all this, we were in a beautiful room on the 17th floor overlooking the gorgeous cityscape of Bangalore (as you can see in some of the photos below). This was thanks to Athenahealth, our gracious host for this meetup.

Drupal Meetup

We started at around 10:30 AM with introductions of everyone present in the room. We had about 30 attendees in total, out of which about 7-8 were first time attendees. After introductions, Taher started the day by talking about updates to Drupal, mainly Drupal 8.6, 8.6.1, and talking about Drupal 9. He also mentioned upcoming events and mainly talked about important dates for DrupalCon Seattle 2019 including session submission deadlines.

We begin today's #Drupal #meetup with @devtaher covering what's new in Drupal. pic.twitter.com/NoITmOOtPI

— hussainweb (@hussainweb) September 29, 2018

Sessions

The first session of the day was about Drupal 8 Plugins and Plugin API by Manoj Kumar of Athenahealth. Manoj described common confusions between plugins and services in Drupal 8 and when to use each of them. He talked about the plugin API itself, specifically plugin discovery and factories. He walked us through a demo of how to create our own plugin type and creating plugins of that type. This included a very lively and engaged discussion about plugins.

First session of the day about #Drupal plugins by @manojapare at @drupal_bug #meetup. pic.twitter.com/RMGrcb1Lp5

— hussainweb (@hussainweb) September 29, 2018

This was followed by a lightning session on using Alexa with Drupal by Rakshith of Axelerant. Rakshith described how a service like Alexa integrates with Drupal, demonstrated the Alexa developer console and described concepts like intents. He also demonstrated tying this together with Drupal where Alexa could respond to user queries like “Read article” or getting a list of articles.

Rakshith talks about using Alexa with Drupal at the @drupal_bug #meetup today. pic.twitter.com/tWc1maQlN7

— hussainweb (@hussainweb) September 29, 2018

Break

This was followed by a few announcements and a break, with refreshments courtesy of Athenahealth.

Thank you @athenahealth for hosting us for this month's #Drupal #meetup and providing a beautiful venue and refreshments. pic.twitter.com/C0p6elSWBH

— hussainweb (@hussainweb) September 29, 2018

And more sessions

After the break, we resumed sessions with an introduction to the paragraphs module by Parvateesam Konapala of TCS. Parvateesam started by explaining what Paragraphs module provides and some of the modules which extend paragraphs’ functionalities. He also gave a demo in which he created paragraph types, adding them to content types, and how to use paragraphs in your site building workflow.

Back from a break and we have @paru_523 giving an introduction to paragraphs module in #Drupal. pic.twitter.com/vOO7Wmw2iJ

— hussainweb (@hussainweb) September 29, 2018

The last session of the day was on using Tome by Malabya Tewari of Specbee. Malabya started by summarising static site generators and how are they different from the conventional approach. He talked where static site generators might be used and their benefits. After talking about a few other systems, Malabya started talking about Tome and how it works. He demonstrated a workflow of a static website

The last session of the day on Tome (static site generator using #Drupal) by @malavya88 at @drupal_bug #meetup. pic.twitter.com/lyC0MNEkNC

— hussainweb (@hussainweb) September 29, 2018

End of the day

We had a quick questions and answers round where people brought up various issues they are facing and we collaboratively discussed on solving them. This was quickly followed by closing announcements and of course, crediting all the speakers and organisers on our meetup planning issue. We also discussed a bit about the format of our meetups and what we can do to improve. After a great discussion on couple of topics on what else we could do, the meetup ended at 2 PM with a group photo. There are more photos below.

Drupal Meetup Bangalore - September 2018

Pages

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web