Improving Drupal with the help of your clients
Our client, ServiceNSW, is a committed open-source contributor, working closely with us to improve their customer experience while sharing these advances with the Drupal community.
by
adam.bramley
/ 19 December 2023How is client-backed contribution made possible?
It helps when you work with a client that understands the value of contributing development time back to the Drupal community. ServiceNSW are members of Drupal and have co-presented with us at DrupalSouth, so they’re truly invested.
Solutions to client challenges, such as core patches or contributor modules, require upfront work. Doing this in a community setting is far more beneficial, allowing everyone to contribute and further improve it. That’s why SNSW recognises the future benefits of investing in the work done now.
We also put a lot of focus on performance and security. This means SNSW receives the latest upgrades for both Drupal core and contributed modules, helping move issues along and ensuring they have the latest and greatest, including being one of our first clients to move to Drupal 10.1. In fact, during the lead-up to the release of Drupal 10.1, we committed over a dozen large core issues in collaboration with the SNSW development team.
The patches we worked on pre Drupal 10.1 upgrade
Over a period of three months, in the lead-up to Drupal 10.1, we targeted patches that were large and/or conflicted with other patches we were using. These were becoming increasingly hard to maintain. SNSW understood that these fixes would be a net gain to developer productivity and an improvement for the community.
- Issue #3198868: Add delay to queue suspend
- Issue #2867001: Don't treat suspending of a queue as erroneous
- Issue #2745179: Uncaught exception in link formatter if a link field has malformed data (a 7-year-old bug!)
- Issue #3059026: Catch and handle exceptions in PathFieldItemList
- Issue #3311595: Html::transformRootRelativeUrlsToAbsolute() replaces "\r\n" with " \n"
- Issue #2859042: Impossible to update an entity revision if the field value you are updating matches the default revision
- Issue #2791693: Remove sample date from date field error message and title attribute (another 7 year old one!)
- Issue #2831233: Field tokens for "historical data" fields (revisions) contain a hyphen, breaking twig templates and throwing an assertion error
- Issue #3007424: Multiple usages of FieldPluginBase::getEntity do not check for NULL, leading to WSOD
Revisions everywhere!
One of our largest pieces of work was Implementing a generic revision UI
Originally opened in 2014, this issue paved the way for one of the most sought-after features from our client - having Revisions for all entity types and a consistent user experience for them.
This was originally committed to the SNSW codebase in July of 2018 using this patch when we added a Block Content Type for a Notice feature on the website.
~3.5 years, ~250 comments, and a huge effort from PreviousNext and SNSW developers, along with many other community members and it was committed to 10.1.x.
This spawned several other core issues for other entity types:
- Block Content - This was also committed to 10.1 alpha.
- Media - which is committed and will be available in 10.2.0!
- Taxonomy terms - which is currently RTBC and looking promising for 10.3!
Plus contributed projects to extend contributed module entity types with revisioning support, such as Micro-content Revision UI.
The patches committed to Drupal 10.1 that we were able to remove
With all this pre-work, we were well positioned when the 10.1 upgrade came around. As you may have noticed, we like to get the ball rolling early, and we had a Pull Request going for the 10.1 upgrade in late June (the day 10.1.0 was released, in fact). This allowed us to figure out which modules needed help, what patches needed re-rolling, and to catch any bugs early.
It wasn't until mid-August when that PR was finally merged, with multiple developers touching it every now and then, when there was some movement.
Here's a full list of Drupal core patches we were able to remove, thanks to the contributions from SNSW.
- Issue #2350939: Implement a generic revision UI
- Issue #2809291: Add "edit block $type" permissions
- Issue #1984588: Add Block Content revision UI
- Issue #3315042: Remaining tasks for "edit block $type" permissions
- Issue #2859042: Impossible to update an entity revision if the field value you are updating matches the default revision
- Issue #3311595: Html::transformRootRelativeUrlsToAbsolute() replaces "\r\n" with " \n"
- Issue #3007424: Multiple usages of FieldPluginBase::getEntity do not check for NULL, leading to WSOD
- Issue #2831233: Field tokens for "historical data" fields (revisions) contain a hyphen, breaking twig templates and throwing an assertion error
- Issue #3059955: It is possible to overflow the number of items allowed in Media Library
- Issue #3123666: Custom classes for pager links do not work with Claro theme
- Issue #2867001: Dont treat suspending of a queue as erroneous
- Issue #3198868: Add delay to queue suspend
- Issue #2984504: Access to 'Reset to alphabetical' denied for users without administer permission
- Issue #3309157: RevisionLogInterface is typehinted as always returning entity/ids, but cannot guarantee set/existing values
- Issue #2634022: ViewsPluginInterface::create() inherits from nothing, breaking PHPStan-strict
- Issue #3349507: DateTimePlus::createFromDateTime should accept DateTimeInterface
Service NSW, a true Drupal partner
Service NSW has (at the time of writing this post) contributed to 19 Drupal core issues that were committed over the past three months.
We look forward to continuing this incredible partnership and contributing in the coming months!