Getting Smart Date Dialed Up to 11

I just tagged the first stable release for Smart Date 4.1, a year (almost to the day) since the first stable release of Smart Date 4.0. A lot of work went into this new release, but I'm thankful beyond words to the many people who helped shape it into what it is today.

Ready for Drupal 11

By the time the Project Update Bot submitted its automated Drupal 11 fixes for Smart Date, the most challenging fixes had already been dealt with. A new deprecation was introduced in Drupal 10.2, but I was leery of making changes that would make Smart Date require a very recent version of Drupal. Fortunately, while talking to Matt Glaman about it at Midcamp 2024, he offered to implement Drupal's new deprecationHelper class to make sure the module would work in Drupal 11 while continuing to work with older versions. I was able to use that as a template to similarly replace a call to the deprecated system_time_zones() with the newer TimeZoneFormHelper methods:

    if (!class_exists(DeprecationHelper::class)) {
      return system_time_zones(FALSE, $grouped);
    }
    return DeprecationHelper::backwardsCompatibleCall(
      \Drupal::VERSION,
      '10.1',
      static function () use ($grouped) {
        return $grouped ? TimeZoneFormHelper::getOptionsListByRegion() : TimeZoneFormHelper::getOptionsList();
      },
      static fn () => system_time_zones(FALSE, $grouped)
    );

Many who are already using Smart Date will be aware of the configuration kits that are available accelerate the process of setting up an events system. If you're not familiar with them, they played a starring role in my recent talk at NJ DrupalCamp NJ 2024:

Earlier this month I was talking to Jim Birch about the progress of the Recipes initiative, and mentioned that I had a couple of modules I'd like to convert into recipes. He offered to help, and then he and Taylor Wills of Kanopi made quick work of getting the Smart Date Starter Kit and Smart Date Calendar Kit turned into recipes.

Setting a higher standard

Another change with origins at Midcamp was Smart Date's adoption of Gitlab CI. Ben Stallings made the initial commit during the contribution sprint, and later James Shields helped get it finished, as well as lots of work across a variety of issues to clean up the issues identified by cspell, PHP Code Sniffer, and ESLint.

Inspired by Matt Glaman's Midcamp session about using PHPStan to tighten up your Drupal code, I also got PHPStan to pass. I was surprised at how insightful the issues it identified turned out to be. It identified dead code, pointed out places where an expected variable might not get set, and I even realized I needed to significantly refactor some code I was using in a trait across many of Smart Date's classes.

Looking into the future

There had been work in the 4.0.x branch to address the Year 2038 problem that has been a longstanding issue for applications that use timestamps. There were some lingering issues that are now addressed with Smart Date 4.1, and the duration storage is also increased, so Smart Date can now hold events over 4,000 years in duration.

New views operators

One of the more interesting functional additions in the 4.1 release is new views operators for the module's upgraded Date Filter. The idea (and most of the implementation work) came from Jurgen Haas (of ECA renown) so I asked him to describe his inspiration:

While building a SaaS application for "Animal Pensions" (Pet boarding) with Drupal, where we have dozens of bookings every day, some lists/views are required. Today's allocations provides an overview which animal is located in which room, and the arrivals & departures view is a handy tool for the staff to organize their day and welcome the pet's owners appropriately.

Building views in Drupal with filters to get the correct data for today isn't rocket science:

• Today's allocations have a start date less than or equal to today and an end date greater than or equal to today
• Arrivals and departures have a start date or an end date equal to today

Sounds easy, and all should already be available, right? That's true, until you realize that the client needs an exposed filter defaulting to today, but they need to option to get the lists for tomorrow or even more days in advance. It suddenly becomes obvious that a simple AND or OR combination of filters doesn't work any more if only one value should be exposed to the user.

That's where we required more filter operations that allowed us to associate multiple conditions to a single exposed field, and that's where we extended the smart date views filter plugin.

Thanks to some clever refactoring of the existing Date filter, adding these new capabilities added less than a hundred lines of code. Not every site will need these new options, but having them available is consistent with what inspired Smart Date in the first place: making the sometimes complex management of dates and time in Drupal as easy as possible.

What Else?

I could also mention additional validation, new theme and formatting improvements, additional automated test coverage (thank you Chad Hester), and more, but I hope you'll try out this new version and find out for yourself. And if you have any ideas on how the next version could be even better, please open a feature request!