Call to a member function arg_range() on null in _calendar_views_track_current_date()

Happy to entertain patches to improve this, as I don't use this. Please create an MR against 8.x-1.x branch.

I have started some troubleshooting. After making the changes on my local to calendar.module where the calendar_page_attachments function was removed and the CalendarDate was changed to Date in _calendar_views_track_current_date, the next calendar page exploded as it did before. So I guess that's where that issue was.

I'm not entirely sure what the deal with the pager is, but looking at the diff between beta2 and beta3 I think it might just be the fact that all the classes and whatnot are all very different, so our custom theming for it might just be busted, so I don't think, for now, that there are any real problems with the calendar module itself there. I'd have to investigate further on that note.

During my review, I also found this:

Warning: Undefined property: Drupal\datetime\Plugin\views\argument\YearMonthDate::$date_handler in _calendar_views_track_current_date() (line 52 of /var/www/docroot/modules/contrib/calendar/calendar.module)

I did find core/modules/datetime/src/Plugin/views/argument/YearMonthDate.php and it does have a

YearMonthDate</date>  class so that's weird.

Also, intellisense is telling me <code>Undefined property: Date::$date_handlerPHP(PHP0416)

on line 53 of calendar.module:

$date_range = $argument->date_handler->arg_range($argument->argument);

I added some logging to the function:

/**
 * Track the current date as the user moves between calendar displays.
 *
 * This function updates the session with the current date based on the user's
 * navigation through the calendar.
 */
function _calendar_views_track_current_date(ViewExecutable $view): void {
  $user = \Drupal::currentUser();

  $tracking = \Drupal::config('calendar.settings')->get('track_date');
  \Drupal::logger('my_module')->notice('<pre>$tracking before conditional= ' . print_r($tracking, TRUE) . '</pre>');

  if (!empty($tracking) && ($tracking == 2 || !empty($user->uid))) {
    foreach ($view->argument as $id => &$argument) {
      \Drupal::logger('my_module')->notice('<pre>$tracking after conditional= ' . print_r($tracking, TRUE) . '</pre>');

      // If this is not a default date, i.e. we have browsed to a new calendar
      // period on a display we were already on, store the midpoint of the
      // current view as the current date in a session.
      if ($argument instanceof Date && empty($argument->is_default)) {
        $date_range = $argument->date_handler->arg_range($argument->argument);
        $session_date = $date_range[0];
        $days = intval(($date_range[1]->format('U') - $date_range[0]->format('U')) / 3600 / 24 / 2);
        date_modify($session_date, "+$days days");
        $_SESSION[$view->name]['default_date'] = $session_date;
      }
    }
  }
}

It reported the $tracking value as "2" for both before and after the conditional, but twice for before and once for after which I think is interesting.

I wondered if the contextual filter was broken on our view. The view is using YYYYMM as expected.

Our view's URL is `/our-page/the-calendar/202505` which should be the May 2025 calendar.

@loopy1492 please try the dev release, as there are lots of improvements in there.