view_args always contains the current date when using ajax pager

This one needs a reroll, and it's tricky to understand the steps to reproduce, can anybody boil it down so I can test it out? Does panels need to be involved?

@joelpittet, I'll reroll this on an issue fork. The issue is when calendar is called via ajax the arguments don't get passed to the view. Panels isn't required.

Ok I've updated this, it works for me without changing the return type from a string. I think the pager can handle a string or a url object and since we previously returned a string I kept it that way, we just moved the toString to the return statement.

I've added a screenshot to show the situation this occurs in.
There is a calendar modal.
When the patch is not applied, if I click next I get the ajax spinnner the modal refreshes and it's still on August no matter how many times I press it.

When the patch is applied, when I click next I get September as expected. Sometimes it takes two clicks to start changing, I think there is something on my preprocess not setting the default argument correctly so it's not a bug in this patch.

rerolled in the merge request

I'm a bit torn on this and why it works...

Because the same thing looks to be done here already:

function views_views_pre_render($view) {
  // If using AJAX, send identifying data about this view.
  if ($view->ajaxEnabled() && empty($view->is_attachment) && empty($view->live_preview)) {
    $view->element['#attached']['drupalSettings']['views'] = [
      'ajax_path' => Url::fromRoute('views.ajax')->toString(),
      'ajaxViews' => [
        'views_dom_id:' . $view->dom_id => [
          'view_name' => $view->storage->id(),
          'view_display_id' => $view->current_display,
          'view_args' => Html::escape(implode('/', $view->args)),
          'view_path' => Html::escape(\Drupal::service('path.current')->getPath()),
          'view_base_path' => $view->getPath(),
          'view_dom_id' => $view->dom_id,
          // To fit multiple views on a page, the programmer may have
          // overridden the display's pager_element.
          'pager_element' => isset($view->pager) ? $view->pager->getPagerId() : 0,
        ],
      ],
    ];
    $view->element['#attached']['library'][] = 'views/views.ajax';
  }

  return $view;
}

Which makes me think that this is a core Views bug and we might be shooting ourselves in the foot by fixing it here.

Re-used #5 patch.
Works fine with php 8.0.27 Drupal v 9.5.10

@goxy-vikvik, why did you change how the return value works?

Is it just to get the base path included?

Are you able to contribute using the issue fork rather than a separate patch?

I have a few further questions / comments on the patch in comment 31.

1. Why are you setting query to input instead of just using the input variable? I'm not sure it's more clear.
2. The work you do in the ajax is enabled check duplicates what you do in the url each time, e.g. you're imploding in the check then again in the return
3. I'm still not clear why toString was not sufficient

Is there an additional use case you were hitting that the current patch didn't work for that we can address in the issue fork?

Hello,
I update the patch from #17 on my Drupal 9.5 + Calendar Beta 1 and the ajax pager in my views block is working fine.

For 8.x-1.x

Please use the MR for contribution.

I guess that happens because getPagerArgValue() fails to retrieve date's granularity from the view. This patch worked for me.

patch #35 resolved the issue for me, thanks!