🇦🇺Australia @mingsong

The reason why a version number is attached to the library path is that other modules might also require a different version of JS assets.

This allows a website to have multiple versions of a library.

For example, module A requires jsframe 2.0 meanwhile, this module only supports 1.5.

In this example, there are two sub folders,

libraries/JSFrame/1.5.16/
libraries/JSFrame/2.0/

Again, those paths names won’t give any convenience for a hacker since the actual version could be any version you downloaded to local.

No, the primary reason is that it's security through obscurity: hiding version numbers achieves nothing. Almost all attacks are automated, most attackers won't even check the version number and will blindly try anyway, and those that do check will fingerprint the file, rather than interpreting the query string.

I close this issue as the version number will be disclosed by the Drupal core. And a local hosted asset can be any version regardless of the folder name.

using the local jsframe.js and only fall back to CDN version if the local file does not exist.

That is exactly how this module loads those required JS assets.

Regarding the concern of disclosing the version number of JavaScript assets, this is the way how Drupal core load a library. More specifically, a query parameter 'v' which is the version number will be added to the asset URL, no matter where the asset is hosted. Even if you change the folder name to 'hide' the version number from the path. More explanation see:
✨ Javascript Version Disclosure Active

As long as Drupal core still behave in this way, I don't think that you can hide the version number by changing the folder's name.

As suggested in the core issue, you can try the contrib module https://www.drupal.org/project/prevent_version_disclosure → which will remove the 'v' parameter from the asset URL.

In terms of your local folder's name, it doesn't matter, it is just a name. You can host any version you like on your local.
For example, you can put the version 2.30.1 of moment.js into the following folder:
libraries/moment/2.29.4

The folder name is 2.29.4, but the actually version of moment.js is 2.30.1, or whatever version you want to use.

PHPUnit tests failed.

FYI, a relevant discussion to the core.
🐛 Hide version number Active

It is not a bug and the 5.3.x branch is the current active develop branch.

Could you create a merge request for it? So that we can have the automated test to check those code.

Thank you.

Thanks for the merge request.

It looks good to me by reviewing the code.

I just created a module to implement a client plugin to validate the IDP's signature if desired.

https://www.drupal.org/project/openid_client_advanced →

I just created a module to implement a client plugin that provides the 'nonce' parameter if desired.

https://www.drupal.org/project/openid_client_advanced →

Thank you!

Thanks @Sascha for looking into it.

It is a fair point that a stable release can not depend on a develop branch which is not an official release version.

The backward compatibility is important too since the Drupal 10 will be supported for a while.

To those who wonder how to help, There are some outstanding tasks with the SimpleSAMLphp need to work on.

Again, the MR is a starting point to provide an easy way for those who want to test if this module will work with the coming version of SimpleSAMLphp in a D11 site.

mingsong → created an issue.

mingsong → created an issue.

Patched with 5.3.x.

In terms of date clicking (navigation), the FullCalendar has a setting for that.
See https://fullcalendar.io/docs/v5/navLinks

This module provides a block configuration to modify those settings.

navLinks: true

Go to 'Configure block' and add that setting as the screenshot below.

be able to pass url to a page to reveal a list of the day's events.

I am not sure about this feature.
You can have a look at all settings(options) supported by the FullCalendar out of box.
https://fullcalendar.io/docs#toc

Or if you need to customise the clicking behaviour, you can get help from
https://fullcalendar.io/docs/dateClick

And the hooks supported by this module.
https://git.drupalcode.org/project/fullcalendar_block#development

Update view settings.

Hi @Kevin Reynen, appreciate your support and the time you spent on this issue and other issues as a volunteer to help the Drupal community.

@Elin Yordanov, What are you talking about here is totally irrelevant to a license breach.

It seems your concern is essentially that a maintainer has chosen not to consider a new feature request. Implementing this feature would require significant refactoring of the module and retesting across two major versions of a third-party library.

First, it’s important to note that maintainers are not responsible for testing or validating patches on their own—especially for new features that they do not intend to support.

Second, no one has yet tested or confirmed that patch that you are talking about. Even if thorough testing were completed, the decision of whether to accept and apply it ultimately rests with the maintainer.

Finally, there are many constructive ways to support a module maintainer. However, saying “you must do this for me” is not one of them.

Given that there are so many alternative modules out there, why don't you just give another modules a try?

Hi @Elin Yordanov, I think we have some misunderstanding here. Let me clarify them.

mingsong, sells the newer version of the module

Let me clarify that, there is no 'newer' version than 5.2.5 → , which is hosted on Drupal.org and fully comply with the GPL-2.0 or GPL-3.0.
The fact is that I have been contributing a lots of efforts and keep releasing new versions for that module. Here is the release records.
https://www.drupal.org/project/fullcalendar_view/releases →

rejects community patches to update the module to work with the newer version of the library

This is not true. The dedicated branch 6.x is still open and will open for every to anyone who need to fork or patch. That feature request issue was marked as 'Close', because it won't be considered and leaving that issue open will mislead the expectations. Even the issue is closed, anyone still can keep patching it. There is no way to reject or block patching at all. Frankly, I don't think close a 'Feature request' will breach any license.

Thank @Christopher, great catch.

I changed the code in line 366

When you have a chance, could you please confirm whether the issue is solved by that change?

mingsong → made their first commit to this issue’s fork.

It will be patched with the new release.

Thanks @Sviatoslav.

It is a brilliant ideal to introduce the excluded tags, which make it more flexible.

Thanks @Christopher for the suggestion on Comment #4 💬 skip headings Active . In a situation where a bold tag for a taxonomy term still need, we can use the CSS to prevent unwanted style inherited from the parent element.

So I take those two solutions together.

I think we can confidently release this change.

Appreciate all your works on this module.

Sorry, my bad. I forgot to add the '' into the allowed tag for the text format setting.

After adding it, it works as exptected.

Thanks @Sviatoslav.

I manually tested the feature branch with Drupal 11.2.4.

Here are the result:
The original content.

<p>
    I use <strong>Drupal</strong> a lots.&nbsp;
</p>
<p>
    Drupal is my favourite CMS.
</p>
<p>
    &nbsp;
</p>

The rendered result after applying the tooltip.

<div class="text-content clearfix field field--name-body field--type-text-with-summary field--label-hidden field__item"><p>I use <strong>
  Drupal
  
     Drupal is a very popular 
  CMS
  
     CMS stands for content management system.
  

.
  

</strong> a lots.&nbsp;</p><p>
  Drupal
  
     Drupal is a very popular 
  CMS
  
     CMS stands for content management system.
  

.
  

 is my favourite 
  CMS
  
     CMS stands for content management system.
  

.</p><p>&nbsp;</p></div>

The tooltip taxonomy terms:
1. CMS

2. Drupal

FYI, The 5.3.x branch is the currently active develop branch.

I will change the default branch to 5.3.x shortly.

Since the D11 version is in progress and automated tests passed, I change it to review.

All automated tests for !45 mergeable have been passed. Now the D11 compatible branch is ready for your local test.

FYI, SimpleSamlPHP official version supported Symfony 7 is in progress and aiming for the end of the year 2025. (https://github.com/simplesamlphp/simplesamlphp/blob/simplesamlphp-2.5/co...).

If anyone could help us on testing or troubleshooting on the SimpleSAMLphp 2.5, that would be very helpful.

Please give your feedback and finding to the issue on Github.

Patched with 2.x-dev →

Thanks @Konstantin

The latest fix makes sense to me by reading the code.

// Triggering dialogResize event on node expansion
            treeContainer.on('after_open.jstree after_close.jstree', function (e, data) {
              $(window).trigger('resize.dialogResize');
            });

Thank you.

Patched with 2.x-dev →

This fix has been patched with the 5.3.x branch → .

If this issue still exists with 5.3.x or any regression defect caused by this fix, please feel free to re-open this issue here.

Thanks.
I experienced the same problem. Don’t worry about the test on the Gitlab CI for now. As long as our local test are passed, we can be confident about it.

Thanks @jmoreira, good catch.

This fix will target 5.3.x branch. I just modify the MR for that.

mingsong → created an issue.

Please try the 5.3.x →

This issue has been tested with that branch, it looks good to me.

mingsong → created an issue.

The automated test failed.

Back to need work.

Try version 5.x-dev

If the issue remains with the latest dev version. Please provide more details.

The user base for this module has been growing steadily, and its usage has now exceeded 200 installations.
The latest version has undergone thorough testing, giving us confidence in its stability.

I have released the first release candidate which is compatible with D11 in preparation for the initial stable version.

Hi @Andrew,

Thanks for your trust.

This module is used by more websites because it was the first module that integrated the FullCalendar.js with Drupal 8 in 2018.

These days, there are many options.

What you need to do is to migrate or update the configurations of your view, or simply create a new view with the other module. It shouldn't take too long.

There are some alternatives to this module, for example the Fullcalendar module → .

There are some alternatives to this module, for example the Fullcalendar module → .

FYI,

Fullcalendar rending inside of a tab (not ui tabs)

https://fullcalendar.io/docs/v3/render

fullCalendar doesn't render inside a bootstrap tab

Patched with the develop version.

Since Drupal 11.2.0-alpha1, the validation behaviour for validating a datetime element has been changed.
Details see 💬 Support to use the datetime-local element Active

I believe that the fix is to add the following line to those datetime element.

'#date_date_format' => 'none',

I did a quick test with Drupal 11.2.0 and 5.2.4. I couldn't reproduce the error mentioned.

Here is my test case.

Drupal version: 11.2.0
Module version: 5.2.4

Content type: event
Start date field: field_event_start
Start date field type: Date and Time
End date field: not specified.

I use the following Drush command to generate the view provided by the Fullcalendar View Generator module

drush fcvg "Test Calendar" "event" "field_event_start" "test" --title_field=title --end_date_field="" --enable

The view was created successfully and the calendar display as expected.

In order to help you on the problem you are facing, please provider more details, such as

Content type: event
Start date field: field_event_start
Start date field type: Date and Time
End date field type:
View settings:

mingsong → created an issue.

Thank you.

Thank you.

mingsong → made their first commit to this issue’s fork.

Close it as I think all questions related to this module have been answered.

I am not sure if I understand your question correctly.

Flood control?

Yes, this module comes with the flood control measure to prevent brute-force attack.

Is there anything that would stop someone from creating an account with someone else's email

This is a question to Drupal core. Since Drupal will set the password reset link to user's email, if this happen, then that is a security question to core. As Drupal security policy, I won't discuss this question here.

I tried it out leaving the code field empty and eventually I got "Failed validation limit reached." I don't know if there's a way around that.

Bypass the flood control is a security breach, so the short answer is no, you can't.

Just wondering if this is a topic that has come up, either for this module or for the TFA plugins generally.

I don't understand what you want to ask here.

greggles → credited mingsong → .

Thanks and welcome @Sviatoslav Smovdyr.

The dev version is already compatible with D11.

https://www.drupal.org/project/tfa_email_otp/releases/1.0.x-dev →

You can download or composer require 'drupal/tfa_email_otp:1.0.x-dev@dev'

Thanks for the patch.

The changes make sense to me by reading the code.

Once the CI is passed, it will be merged into the 3.x branch.

mingsong → made their first commit to this issue’s fork.

poker10 → credited mingsong → .

Thanks @mikey,

Looks good to me.

Update field output settings.

Fixed with 1.1.2

Fixed with 1.1.2

Sorry for misunderstanding this issue.

This issue should be fixed with the new version coming shortly.

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.

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

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.