I created a calendar view with a block display, and I enabled ajax mode. But the pager didn't work because view_args always contained the current date (instead of next/prev date) in the ajax request.

I think I fixed it, I'll attach my patch file soon.

Issue fork calendar-2858086

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

lonalore created an issue. See original summary.

lonalore’s picture

StryKaizer’s picture

Status: Needs review » Needs work

While this patch does fix the ajax pagination for months, it also adds a GET parameter on month view pages which do not use ajax, resulting in urls like this:

/my_month_view/201705?view_args=201705

lonalore’s picture

Status: Needs work » Needs review
FileSize
853 bytes

Thank you! I fixed it.

recidive’s picture

Re-rolling patch in #4.

interdruper’s picture

Status: Needs review » Reviewed & tested by the community

#4/#5 work like a charm. Thanks.

shaktik’s picture

#4/#5 working fine!
Thanks.

johnsicili’s picture

Status: Reviewed & tested by the community » Needs work
Related issues: +#2810739: Calendar Pager not rendering contextual filters

I believe this patch is conflicting with another one recently accepted:
https://www.drupal.org/project/calendar/issues/2810739

I have an updated patch that I plan on uploading once I spend a little more time with it.

johnsicili’s picture

This patch seems to be working for me. I removed if ($this->view->ajaxEnabled()) and its still working with ajax enabled on the view. Let me know what you guys think.

johnsicili’s picture

Status: Needs work » Needs review
icurk’s picture

@johnsicili I tested your patch, but it didn't work for me. There were missing view_args in links. Here is a patch that worked for me.

johnsicili’s picture

@icurk, several months later and I also notice an issue with my patch. Applied yours in #11 and works great, thanks.

+1 RTBC

johnsicili’s picture

Status: Needs review » Reviewed & tested by the community
solide-echt’s picture

I just re-checked this and cannot reproduce it. There have been multiple improvements in views from core to handle ajax paging in blocks; similar issues have been reported for e.g. faceted search. Are we sure this issue still exists?

joelpittet’s picture

Status: Reviewed & tested by the community » Postponed (maintainer needs more info)

Looking for a reply to #14

arijits.drush’s picture

vlad.dancer’s picture

Status: Postponed (maintainer needs more info) » Needs review
FileSize
1000 bytes

I'm upgrading client's project from D8 to D9 and previously we've used lots of patches for the calendar module.
I've checked them and @solide-echt is right about

"There have been multiple improvements in views"

and also this module received lots of patches since 2018.

But unfortunately ajax issues is still here.
We have a calendar block with enabled ajax and pager links don't work without setting view_args.
Below is an updated patch to fix the problem.

Additionaly I've changed function's return type and value to be consistent.
I think Url object if more universal because someone could want to alter let's say an url access, etc.
The only palce where pager links are used is calendar-pager.html.twig.
So there shouldn't be any problems with sending Url object.

akalam’s picture

Patch #17 is working for me.

jillh68’s picture

The error I was receiving was: Error: Call to a member function setOption() on string in Drupal\calendar\Plugin\views\pager\CalendarPager->getPagerUrl(). Patch #17 fixed the issue.

arijits.drush’s picture

If views calendar Ajax is enabled, and produced within a Block an that block got integrated within a Panels page and panels page also have some parameter within it, then no patch is not providing desired result.
The reason is

 $url = $this->view->getUrl($arg_vals, $this->view->current_display);

creating route from view rather than calculating parent page route

ram4nd’s picture

Status: Needs review » Reviewed & tested by the community

Patch #20 worked for me correctly.

joelpittet’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs reroll, +Needs steps to reproduce

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?

nicxvan made their first commit to this issue’s fork.

nicxvan’s picture

@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.

nicxvan’s picture

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.

nicxvan’s picture

joseph.olstad’s picture

Status: Needs work » Reviewed & tested by the community

rerolled in the merge request

joelpittet’s picture

Status: Reviewed & tested by the community » Postponed (maintainer needs more info)

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.

Foxy-vikvik’s picture

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

Foxy-vikvik’s picture

Successfully resolved issue 30 with the implementation of patch 31.

nicxvan’s picture

@Foxy-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?

nicxvan’s picture

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?

Flodevelop’s picture

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.

arijits.drush’s picture

For 8.x-1.x

nicxvan’s picture

Please use the MR for contribution.

mreda’s picture

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