Calendar doesn't show results when using pagination "Calender by month"

Thank you for reporting this issue and please forgive the inconvenience.

Can you please provide more information about your View?

I cannot reproduce the issue on D10 nor D9.

The view is filtered on the content type "programma" but also has a relationship with a paragraph. The date field of the paragraph is used for the calendar.

Oh okay.. Thank you for the details.

I can reproduce the bug indeed when using a relationship (e.g. a date field from a paragragraph).

The issue is caused by the new query filtering which apparently does not work correctly on relationship 🤔

I unfortunately don't have a fix for now so I will provide an option to enable/disable the query as a workaround for now

Marking this issue as active and critical as it breaks previously working functionality.

Hi, I have no relations and pager by month doesnt work

The latest commit contains a couple of typos/errors:

• Line 365: _blanl should be _blank
• Line 369: the default value needs to be the calendar_query_filtering option
• Line 627: the code $this->view->query->addWhere(0, $conditions); needs to execute and should not be commented

@matthieuscarset would you mind tagging a release for that? Would help a lot to continue with our internal development here.

I'm experiencing this too. Thank you for looking into it.

Oh... please forgive the inconvenience. I will make a new release asap (im away from the computer right now)

Version 2.0.9 → released.

@daniel-ortega can you please give me more details about your View?

I'd like to test and reproduce the issue.

I reproduced the issue on Views with relationship - the query conditions apparently return no results and don't know why yet 🤷

But the conditions are working fine for any other simpler Views for me, without relationships.

@matthieuscarset

Oh... please forgive the inconvenience. I will make a new release asap (im away from the computer right now)

Dude, volunteers never have to apologize! I was just tagging along. I appreciate your efforts.

I also had an issue with strange behavior in the CKE5 editor. Turns out there is some recent change to the way jQuery libraries work.

There is a small chance it might be related so it could be worth a peak at

https://www.drupal.org/project/drupal/issues/3222107 🐛 Library order asset weights do not work properly when a large number of javascript files is loaded between two jQuery UI libraries Fixed

I can attest that content isn't being dispayed with paging turned on in version 2.0.9. When I turn off paging, I see my content, but then I have no way to go to the next month.

I'm sorry there are issues with the content not being displayed.

This is certainly caused by the query filtering added recently.

Can you please attest if the View works correctly if you disable this filtering?

To disable the filtering, open the Calendar settings, scroll down and uncheck the box saying Performance: filter query by dates.

Also, I still cannot reproduce this issue.

Can you please provide more context about your View?

Are you talking about the page view settings?

because I don't see any performance settings.

I tried disabling that option and now it works properly. Note: I do not pull the date from a relationship (I have no relationships defined in my view).

Patch #5 works for me. Thx

Uhg, is there a quick composer hint someone can share? I need to google how to apply patches but I am not too proud to take a quick hint.

@jjflynn22 i think you are running the latest version of this module.

Maybe the quickest way to help you right now is to use the dev branch which includes the fix:

composer require drupal/calendar_view:2.0.x-dev

Marking this issue as need work because there is obviously a bug with the query filtering and I need to dig into it.

So in my quick look at this where I am seeing the issue with a specific content type not being shown when performance mode is on. My first content type is a smartdate, my second (not shown) is a datetime. The query that is being built in performance mode is comparing timestamps. Smartdate is stored as timestamps, but datetime is stored as a date string.

It's really weird, but it seems like it's putting the start and end timestamps the wrong way round into the query:

SELECT "node_field_data"."nid" AS "nid"
FROM
{node_field_data} "node_field_data"
LEFT JOIN {node__field_tutor} "node__field_tutor" ON node_field_data.nid = node__field_tutor.entity_id AND node__field_tutor.deleted = '0' AND (node__field_tutor.langcode = node_field_data.langcode OR node__field_tutor.bundle = 'student')
LEFT JOIN {node__field_start} "node__field_start" ON node_field_data.nid = node__field_start.entity_id AND node__field_start.deleted = '0' AND (node__field_start.langcode = node_field_data.langcode OR node__field_start.bundle = 'event')
WHERE (((node__field_tutor.field_tutor_target_id = '17')) AND (("node__field_start"."field_start_value" > '1682895599') AND ("node__field_start"."field_start_value" < '1677628800'))) AND (("node_field_data"."status" = '1') AND ("node_field_data"."type" IN ('lesson')))

The code looks fine, but when I swap the < and > round on lines 633 and 634 of src/Plugin/views/style/CalendarViewBase.php it works

Interesting, I may have to experiment with that on my end.

I've been testing the following patch to at least get this going for my specific use case, which seems to be working.

-      $and->condition($alias, $start->getTimestamp(), '>');
-      $and->condition($alias, $end->getTimestamp(), '<');
+      $field_storage_config = FieldStorageConfig::loadByName('node', $field->field);
+      if (!empty($field_storage_config) && $field_storage_config->getType() == 'datetime') {
+        $and->condition($alias, $start->format("Y-m-d\TH:i:s"), '>');
+        $and->condition($alias, $end->format("Y-m-d\TH:i:s"), '<');
+      }
+      else {
+        $and->condition($alias, $start->getTimestamp(), '>');
+        $and->condition($alias, $end->getTimestamp(), '<');
+      }

I have the same problem. Thank you for all your work here!

Not sure I followed... which patch fix the issue?

Is it #23 or #24 or both 🤷?

@matthieuscarset #24 is nothing official, I was just noting the workaround I used to proceed on how I needed to use the module.

@jamesgeldart I looked at the function that seems to create the sql.

I suppose it is the function public function getCalendarTimestamp() in line 174

Maybe the dataset in the background is not in the correct order. That could be the cause of the swapping? Just an inspiration.

// Get first result's timestamp.
$first_timestamp = NULL;
if (empty($this->options['calendar_timestamp'])) {
if ($first_result = $this->view->result[0] ?? NULL) {
$available_date_fields = $this->getDateFields();
$rows = $this->processResult($first_result, reset($available_date_fields));
$timestamps = array_keys($rows);
$first_timestamp = reset($timestamps) ?? NULL;
}
}

Trying to summarize, i think these are issues to be addressed in order to fix calendar results when SQL query filter is enabled:

1. Wrong date value format for datetime fields
2. Wrong alias for end value for datetime_range field (e.g. shoukd be `fieldblabla_end_value`)
3. Incorrect Calendar timestamp sometimes after navigating to previous/next

Marking issue as active. I am working on it.

While I was working on fixing the query filtering in the Calendar View style plugin, I realized there are too many unknown about date fields and their values and results expected to be displayed too, depending on the date, the duration of events...etc.

I think we should remove the query() method from the Calendar style plugin itself and leave editors in charge of properly configuring the View in order to avoid performance issues - such as restricting results in the future when you have many unlimited recurrent events.

Editors should be able to the use View filters to restrict the results of their calendars.

There is only one blocker I am trying to find the correct way of altering the value of filters to be able to use a custom Token (e.g. see this Slack thread + attached screenshot).

TL;DR

IMHO:

• Calendar View plugin should not interfere with the results from the View
• Thus, we should remove the query filtering
• Implement a custom token to use the Calendar's timestamp in View's filters
• Test the filtering with all possible type of date fields
• ..take a break and enjoy life!

I like the idea a lot to leaving the filtering to the site builder / view configurator. With regard to the date filtering following the pager, you could probably provide your own filter plugin, which extends the existing date filter from core and overrides the value field with the value that you can internally grab from the pager. So, you don't have to introduce a token, you can do that with a plugin that contains all the required logic.

Rework of Calendar plugin done in this commit.

Changelog:

• No more automatic query filtering (e.g. site builders should use the default View filters)
• Sort order is always ASC inside calendar days (e.g. in order to keep multiday events always at the top)
• Replaced custom processResult() method by populateCalendar() (e.g. former method was convoluted and could produce duplicates/unwanted results)
• Some fix/improvements to the multiday.js library for multiday events spanning on days in the past (e.g. start day not shown on the current calendar table)

Any help testing the module again will be much appreciated.

Code is on the dev branch 2.0.x

To complete this rework, we need to have a solution to filter dates in the past and future but this causes heavy loading time for large set of results (e.g. recurring events with no limits in time).

We need to make all date filters' values relative to the current Calendar timestamp

I think I have found a fix in this commit.

Date filters should now to follow the month/week navigation.

For instance:

• Create a Calendar Week display
• Add a filter for a Date range field
• Select "Greater or equal than" as the operator
• Select "Offset" and enter the value your want (e.g. `-2 weeks` for instance`)
• Save the View
• Now create a content with a date range starting 3 weeks ago

Results: The content won't be displayed on the current week.

Solution: Change the offset to `-3 weeks` on the filter.

To limit results in the future, repeat the steps above but using the "Date range end field" and the "Less or equal than" operator.

Using date filters like this allow site builders to configure the View as usual, with the possibility to reduce the query in the past/future.

I´m not sure I understand the current solution - but it doesn´t work for us.

We can´t set an offset for for instance "-1 year", because our users have to be able to see events from 5 years ago in the calendar.

But the calendar as it is now is far too slow because it has to load thousands of events.

So a "dynamic" page-filter - one that loads each month´s event every time you change to a new month - would be ideal.

Thanks for the feedback @robotjox.

I understand the issue - and we made a few attempts to find a sustainable solution to this heavy loading.

The latest solution is on the latest release: 2.1.0 and the choice was to leave the View results as-is, no query alter from the Calendar plugin. So, to answer your issue:

...the calendar as it is now is far too slow because it has to load thousands of events.

Are you using 2.1.0?
Can you test with a regular View (i.e. unformatted list)?

The View loading time and the list of results are not altered by the Calendar table.

Therefore you would need to configure the View correctly to fit your needs and then, select the Calendar display with the date filter.

Happy to help on Slack too because it is hard for me to debug things via comments on d.o.

2.1 did the trick for me. Thank you!
I can jump through weeks and through months.

Marking this issue as fixed now that 2.1.0 is released.

I've updated the module main page on d.o to reflect latest changes (i.e. how to configure date filters with offset value).

Thanks everyone for your help on this issue!

@matthieuscarset - thank you so much - new version seems to work perfectly with our many events :)

Automatically closed - issue fixed for 2 weeks with no activity.