Exposed Filters params cause invaild date on load

After this change if no start date in query param it does not default back to Dec 1969

without a valid date parameter

First of all, any issue caused by an invalid parameter is not a bug.

Secondly, the Initial date parameter is optional, which mean if the client don't want to change the default initial date, which is the current day, no need to have the parameter in the URL. If the client does want to change the default initial date, then a valid date must be provided. If an unexpected initial date presented, please check the URL that you are visiting.

After all, this module doesn't provide any Drupal view. The view mentioned in the description of this issue is an example attached to the tutorial article.

I have the same situation as @nicholass. It doesn't make sense from a UI perspective to have an exposed start date field for a calendar display like this since we are relying on FullCalendar to provide the calendar navigation.

Is the best solution to add the exposed start date filter to the filters on the Page display and then hide it with CSS? I suppose the alternative would be to add a hook or something that will add &start= to the end of the URL parameters when ever the filter is applied.

I think there is a misunderstanding here.

The “start” parameter sent to the data source endpoint by the FullCalendar.js is the beginning of the date range of the dataset required by the FullCalendar.js. For example,when switching weeks or months, the FullCalendar.js will send out a HTTP request to the data source endpoint with the start date of that week, in your case, it is a request to the Drupal view built by you, not this module. This module has nothing to do with any Drupal view.

The “start” parameter in the URL to where the calendar block is placed is actually the “initial date” when the calendar should display at the beginning. Which is optional custom parameter.

Again, this module does not include any Drupal view, that is saying no patch to this module can help you to solve the problem with the view created by you.

If you are using a Drupal view to provide the data to the calendar, I think you might want to try other module,

For example, https://www.drupal.org/project/fullcalendar →

Which is straightforward and simpler.

Hi @mingsong, this is a legitimate bug. We have an instance of a fullcalendar_block that has this problem immediately after login.

On initial login, the system appends ?check_logged_in=1 to the query string. When this happens, and there is no start parameter in the query string, the initialDate gets set to Dec 1969.

The MR fixes the problem for me.

Hi @Paul, Thanks for confirming the patch work for you.

Please provide your Drupal core version and the steps and conditions (only authenticated user?) to reproduce this issue.

I will try to test it in your situation. Once I can confirm this issue, I’ll be more than happy to have it fixed.

Ok, I did a quick test with Drupal 11.1.

Here is the steps I took.

1. Install a brand new Drupal 11.1 website.
2. Install this module by using composer.
3. Place a Fullcalendar block in the Content region.
4. Config that block to use a event data source (Event source URL) as https://fullcalendar.io/api/demo-feeds/events.json
5. Leave other setting as default value.
6. Save the block.
7. Go to any page where the block would appear as an authenticated user.
8. Logout and visit the page again as anonymous.

According to my test, I couldn't reproduce this issue under any circumstance. The initial day is the default current day.

Month view

Week view

After all, if this issue requires a Drupal view to trigger, then it is out of scope as this module doesn't provider any Drupal view integration.

Ok, I think this issue does not only happen to Drupal view but any data source hosed on the same domain. Further more, it doesn't only affect authenticated user but all users if there any parameter in the URL. For example, /?hi=1

This issue is worse than my thought previously. Sorry for not looking at it closely.

I create a new patch with a clearer logic and clarify the difference between the 'start' parameter in the query parameter and the one fed to data source endpoint.

You can get the patch from https://git.drupalcode.org/project/fullcalendar_block/-/merge_requests/1...

According to my own test, I believe it is fixed by the patch. So I am going to release a new version shortly for this fix.

Fixed with 1.1.2

codebymikey → closed merge request !18

The original issue was caused because the new code I implemented not accounting for if the query.get(startParam) was empty (I assumed passing a null into Date would've lead to an invalid date, but I guess not, so my bad guys!).

I believe exposing the initialDate property as a configuration is useful since a site installation might use the start query string for something else, and for most use cases the startParam is usually also the initialDate. I've created a new MR adding the functionality.

Thanks @mikey,

Looks good to me.

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