- ๐จ๐ฆ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.
- 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.
- Status changed to RTBC
over 1 year ago 2:46pm 8 August 2023 - Status changed to Postponed: needs info
over 1 year ago 4:27pm 8 August 2023 - ๐จ๐ฆ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 - 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 sufficientIs 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. - ๐ช๐ฌEgypt mreda
I guess that happens because
getPagerArgValue()
fails to retrieve date's granularity from the view. This patch worked for me. - last update
over 1 year ago Build Successful - Merge request !24#2858086: view_args always contains the current date when using ajax pager โ (Open) created by mreda
- Open on Drupal.org โCore: 9.5.x + Environment: PHP 7.4 & MySQL 5.7last update
over 1 year ago Waiting for branch to pass - ๐ฎ๐ณ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.