view_args always contains the current date when using ajax pager

Created on 6 March 2017, about 8 years ago
Updated 8 August 2023, over 1 year ago

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.

๐Ÿ› Bug report
Status

Needs work

Version

1.0

Component

Code

Created by

๐Ÿ‡ญ๐Ÿ‡บHungary lonalore Budapest, Hungary

Live updates comments and jobs are added and updated live.
  • Needs reroll

    The patch will have to be re-rolled with new suggestions/changes described in the comments in the issue.

Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • ๐Ÿ‡จ๐Ÿ‡ฆCanada joelpittet Vancouver

    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?

  • First commit to issue fork.
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States nicxvan

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

  • Open in Jenkins โ†’ Open on Drupal.org โ†’
    Core: 9.5.x + Environment: PHP 7.4 & MySQL 5.7
    last update over 1 year ago
    Build Successful
  • @nicxvan opened merge request.
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States nicxvan

    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.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States nicxvan
  • Status changed to RTBC over 1 year ago
  • ๐Ÿ‡จ๐Ÿ‡ฆCanada joseph.olstad

    rerolled in the merge request

  • Status changed to Postponed: needs info over 1 year ago
  • ๐Ÿ‡จ๐Ÿ‡ฆCanada joelpittet Vancouver

    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.

  • ๐Ÿ‡บ๐Ÿ‡ฆUkraine Foxy-vikvik

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

  • Open in Jenkins โ†’ Open on Drupal.org โ†’
    Core: 9.5.x + Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    Patch Failed to Apply
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States nicxvan

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

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States nicxvan

    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?

  • ๐Ÿ‡ซ๐Ÿ‡ทFrance Flodevelop

    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.

  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia arijits.drush India

    For 8.x-1.x

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States nicxvan

    Please use the MR for contribution.

  • ๐Ÿ‡ช๐Ÿ‡ฌEgypt mreda

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

  • Open in Jenkins โ†’ Open on Drupal.org โ†’
    Core: 9.5.x + Environment: PHP 8.1 & MySQL 8
    last update over 1 year ago
    Build Successful
  • Open on Drupal.org โ†’
    Core: 9.5.x + Environment: PHP 7.4 & MySQL 5.7
    last update over 1 year ago
    Waiting for branch to pass
  • ๐Ÿ‡บ๐Ÿ‡ฆUkraine rollins

    patch #35 resolved the issue for me, thanks!

  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia amitrawat056

    Hi everyone,

    Iโ€™m encountering this issue with the Calendar module version 8.x-1.0-beta3. I tried applying the patches from merge requests #35 and #34 to address the problem, but Iโ€™m running into some difficulties.

    The patch from #35 and Merge request 24 is not applying at all.

    The patch from #34 applies successfully, but Iโ€™m still getting an error related to the implode() function:
    implode(): Argument #1 ($array) must be of type array, string given in implode().

    Hereโ€™s the updated path Iโ€™m working with for Calendar version 8.x-1.0-beta3.

Production build 0.71.5 2024