[This content was originally published in the Digital Echidna Blog on May 15, 2020]
There is a lot of excitement in the Drupal community about the release of Drupal 9. In particular, one of the most appealing elements is how the transition to Drupal 9 promises to be the easiest major upgrade in more than a decade.
In reminiscing with other community members about some painful upgrades from long ago, it got me thinking about how the nature of the majority of Drupal modules has changed.
Early Days - Modules as Solutions
My first big Drupal project was using the 4.6 version of core. One of the things I remember was the way many of the modules available tried to anticipate a particular use case and provide a “solution” -- essentially an attempt at a fully-formed (if configurable) way to make Drupal meet a set of needs.
An example of this is the Job Search module I helped to maintain for a time. It had a preconfigured relationship between jobs and resumes, and permissions associated with different actions you would expect users to take: post jobs, apply for jobs, and so on.
There were frequent requests from users who wanted it to work just a little differently from how it was made. Sometimes these changes got incorporated back into the module, but sometimes they remained a special case - a customization that was really only useful in the context of their site. That started to change with the rise in popularity of toolsets and modules like CCK, which were more about making Drupal more flexible so it can be quickly customized to meet a very specific set of needs.
Rise of the Toolsets
What we’ve seen since that time is an increasingly powerful set of modules that extend the capabilities of Drupal, but leave it up to the site builder to decide how these capabilities should be applied. Image API, Responsive Images, Metatags, and many more are examples of modules that gave Drupal important new abilities, but without any recommended starting point on how they should be used.
Even a tool like Features was built to help make those configuration decisions portable between sites or environments on the same site. But increasingly all decisions on how these should be set up fell entirely on the site builder. Which was fine for those of us used to Drupal (or fortunate enough to work among an experienced team of Drupal experts) but more daunting for someone trying to put together a simple site.
In that time we’ve seen Drupal become the CMS of choice for governments, record labels, and major universities, but we’ve seen competitors slowly take over niches where Drupal used to be popular, such as startups and charities. Having to build from scratch can be less attractive for an organization with limited resources, so it’s understandable they’d be tempted to go an easier route, if available.
A Middle Way
Distributions have been one attempt at addressing this problem, such as the popular Commerce Kickstart, which helped to install a ready-to-use e-commerce site. The challenge we’ve seen in using distributions is that they’re complex to maintain, so often you’re not able to use the latest versions of core or popular contrib modules. Or when it comes time to upgrade, it has built-in assumptions about what’s installed, which can make it more complex to upgrade the component pieces. And finally, a distribution is typically only an option when you’re starting to build (or potentially re-build) a site, not for adding incremental functionality.
One of the exciting features Drupal introduced in version 8 was configuration management.
In addition, Drupal Console gives us an easy way to export individual elements: a content type, a view, and related dependencies. At Digital Echidna we’ve been experimenting with using these to create modules that are effectively just sets of related configuration meant to be a starting point to help us quickly address a particular use case: a locations map, an events calendar, and yes, even a jobs board.
Now, I’ve adapted this approach to help anyone interested in using (or even just trying out) the Smart Date module I’ve mentioned many times in this blog. It’s easy to install the Smart Date Starter Kit and it will give you a functional (if basic) Event content type and a view with displays to show upcoming and past events.
It isn’t preconfigured for recurring events (since not every site needs that) but if you want to add that, it’s as simple as installing the Smart Date Recurring submodule and then updating the configuration of the “When” field to allow recurring events. That’s it! The view has already been set up to properly aggregate events with multiple events.
If you also need your events to show in a calendar, you can use the Smart Date Calendar Kit. Installing it via composer gives you all the dependencies (including Smart Date and Fullcalendar View) plus everything described above in the starter kit. The calendar is connected to the list views as navigation tabs, so it should be a robust starting point to manage events on your site.
Both of these are just an initial set of configurations so you can add as much additional complexity as necessary to suit the specific needs of your site. And we’ve tried to build in some admin experience best practices, such as built-in administrative links to add content, so it’s intuitive to maintain out of the box.
I hope you’ll try them out and post an issue if you think there are ways these could be made even better.
The recent Drupal business survey posted by Dries hints that there may be similar conversations already happening elsewhere in the community, so it will be interesting to see the results when they’re announced at DrupalCon Global in July. It’s yet another reason to be excited about Drupal 9, and the future direction for this platform. With all kinds of innovations happening each and every day, it is an exciting era in the history of Drupal.