🇦🇺Australia @Mingsong

Ok, first the selected nodes tip is required by others, we can't remove this feature. And second, I don't think hard-code the hight would fit all size of screen.

There is an error with the automated PHPUnit test.

1) Drupal\Tests\entity_reference_tree\FunctionalJavascript\BasicJavascriptTest::testEntityReferenceTreeJavascript
Behat\Mink\Exception\ResponseTextException: The text "Selected (3 of unlimited): Node 1 (1), Node 2 (2), Node 3 (3)" was not found anywhere in the text of the current page.

https://git.drupalcode.org/issue/entity_reference_tree-3197987/-/jobs/26...

Is there anyone know why? We can merge a MR that is failed from test.

IMO just having a new branch with the latest version of the fullcal library as a public branch

The answer from #7

The 6.x branch was created for catching up the latest major version of the Fullcalendar.js. It will be open and remain as long as anyone want it or contribute to it.

Again, like any other Drupal module, anyone is more than welcome to contribute. In this case, the 6.x branch is open to anyone who want to contribute to that version which is compatible with the latest Fullcalendar.js. It is totally free to use 6.x.

The premium version of this module is not based on 6.x branch, which is totally refactored from 5.x.

To those whom is interested in Fullcalendar.js 6, there are many other Drupal modules that have already supported it. Please give those modules a go before you considered the premium version here.

Sorry for commenting on a postponed issue.

I think the reason why the message rendered looks different between anonymous user and authenticated user is that there is another big-pipe placeholder callback was called prior to the call of Drupal\Core\Render\Element\StatusMessages::renderMessages(). That causes all messages were deleted in line 529 before the messages were rendered.

https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/big_p...

Since the anonymous user won't have toolbar, the big-pipe placeholder for the message is the only one in that page, so that the renderMessages() is called before the messages were delete in line 529.

I've also just found some very strange behaviour where the new JS themed messages are not being used for anonymous users. Both for webform submissions and even password reset submissions they're unthemed.

We're using the same method as Olivero so I'm not sure what's going on here.

When logged in everything works fine.

@acbramley, If you turn on the Twig debug information, can you see what template is used for the status message?

According to my test with Drupal 11, the message showing to authenticated user is rendered from the core/modules/system/templates/block--system-messages-block.html.twig template.

Meamwhile, the message showing to anonymouse users is rendered from the core/themes/olivero/templates/misc/status-messages.html.twig template, which is the front theme in my test site. In your case, it might be from your custom theme.

I think that is why the result are diffferent between anonymouse and authenticated users.

@Sourojeet Paul, beautiful work.

Thank you.

I can't see which field is used for the 'Start date' from your setting above.

Without knowing the answers to the questions asked on #2 🐛 FullCalendar View not showing events (but list,grid,table view is showing) Postponed: needs info , there is no way to help you figure out what happened to your view.

Given that there are 5,361 sites using 5.1.14 and 2,389 sites using 5.2.1 till August 18, 2024, I don't think this is a common issue.

I change it to 'Support request' until we know what went wrong, because this issue sounds more like 'How to use it'.

Here is a help document on how to use this module.

https://fivejars.com/blog/all-you-need-know-about-fullcalendar-view-module

Hope it help.

Please provide more information to help the troubleshooting. Such as is there any error the logs? In the browser console(JavaScript error)? What is the field type of the 'start date' field? What is the view settings?

Thank you.

- I use the full page view to add an event and not required fields are also not appearing.

If the new event was created by double clicking on a date in the calendar, this module just simply open a new page with the populated start date.
https://git.drupalcode.org/project/fullcalendar_view/-/blob/5.x/fullcale...

In this case, the page URL is something like '/node/add/article?start=2024-08-01&start_field=field_start&destination=/calendar', and there should be no field hidden. I would suggest have a look at other module or theme that hide the fields from your node edit page.

- Do you have more info how to override a class? A link where to find an example?

https://www.drupal.org/docs/drupal-apis/routing-system/altering-existing... →
https://drupal.stackexchange.com/questions/81362/how-do-i-alter-the-rout...

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

Thanks for reporting.

I can't reproduce this issue with a brand new installation of Drupal 10.3.2.

One possible reason is that there is some leftover user data in your database, due to the user's TOTP was enabled before.

The switching TFA method form is created and controlled by the TFA module, not this plugin.

The code where the switching links are created is in line 269 /Form/EntryForm.php. See the source code below.

https://git.drupalcode.org/project/tfa/-/blob/8.x-1.x/src/Form/EntryForm...

If you still come across this issue with a brand new install, please create a PHPUnit test to reproduce this issue.

Thanks for the suggest.

It is a common design not to disclose user's register email address before successfully authenticated.

So this feature won't be consider.

Thanks for reporting this issue.

I wonder if it is an issue with the Fullcalendar.js. Because this module doesn't provide additional logic to daylight saving, it relies on the Fullcalendar.js to deal with the time change.

If anyone came across this issue or have any clue to fix this issue, please help.

Short answer to you question is no, there won't be new feature to load events by week.

With the latest version this module, in order to reduce the loading time, I would suggest checking the following.

1. Are you using another module to manage the recurring date field? such as the Smart date module → ? If so, try not to use other module but use a long plain text field to present the RRULE string for recurring logic of an event. You can get more information how to do that in this module page under how to use section.
2. Try another alternative module, such as https://www.drupal.org/project/fullcalendar_block →

Sorry I couldn't be more helpful.

Drupal provides a way to override a controller class. You can try that via a custom module.

When adding a new event via the Drupal Off-Canvas or a pop up model dialogue, the space of the form is limited. If displayed all fields, particular the long text field, the form would overlay.

Adding an event in a new page should not be affected.

So, this new feature won’t be considered.

@Michael O'Hara, free feel to report this module or me as the maintainer to the Drupal Association or wherever you want.

This module has been put into 'Minimally maintained' for a while. That means non-commitment to any major version in the future at all. I have no idea what you are talking about. You can keep complaining no future major version release of a 'Maintenance fixes only' module.

As the point I made at #4, I bring in this discussion is about to discuss in what way that is a sustainable for a Drupal module moving forward. What I am looking at is beyond this Drupal module.

No worries.

Close it as merged.

The 6.x branch was created for catching up the latest major version of the Fullcalendar.js. It will be open and remain as long as anyone want it or contribute to it.

But a release of it which is covered by the Drupal security policy won't happen. Making it clear here is to inform anyone who use 6.x branch for their own projects that they need to make their own plan based on the fact.

@Nick Perkins, I don't know how many contribute module has you every maintained or contributed to the community. Let me tell you what I have done for this module, excluding other modules I have contribute to the community where I have spent thousands unpaid hours.
1. Review the patch provided by others. This work includes security review and functionality review. When a maintainer release a version that is covered by Drupal security policy, the maintainer is responsible for making sure that version is safe. The most of users of a Drupal contribute module don''t have that knowledge. They simply rely on and trust the module maintainer.

2. Investigate and fix the bugs caused by a patch or new feature provided by others after releasing. Accept a new feature, particularly the one is fundamental changed from the bottom, is not the end of the story, but is a begin of a new journey. Accept a new feature without knowing how it works and no plan to maintain it. That is not the way how I maintain a Drupal contribute module.

Back to your suggestion. Yes, I would like to have someone join to help this module as a co-maintainer. In order to have a good hand to help to make the job easier, not the opposite, I need a person who has the knowledge and experience on maintaining a popular Drupal module which has large feature request queue. I need to know the person's plan on this module. I need to know how many hours that person will contribute to this module regularly.

True, there is a merge request right there. If you are interested in maintaining this module or V6 version. How about starting from reviewing the merge request. I put the link here.
Please let me know how you are going to review this merge request. What things are you going to check? What test are you going to conduct?
If you just want that feature, but not interested in reviewing and testing it. That is totally fine. Then the questions above are given to those who is willing to do it.

Again, if you just want that patch for your own custom version of this module, you can patch it in your own project. But put it into next release version of a contribute module, there are a lots work behind that.

I can't reproduce this issue with a brand new installation, neither with Drupal 11 nor 10.3,

Can someone create a PHPUnit test to reproduce this issue?

The bug is patched with 3.4.1.

I will leave this issue open as the recipe task has not been done yet.

Thanks for reporting this issue.

It is a compatibility issue many modules facing after upgrading to Drupal 11.

The change log for reference.

https://www.drupal.org/node/3404140 →

I will fix this issue for this module first. Then we can have the recipe after that.

This issue will be patched with 5.2.1

Thanks.

According my local test and the CI test on Gitlab, I believe this issue is fixed by the merge request.

Thanks, @Michael, for your honest feedback.

I am bringing up this idea as a survey for the Drupal community, specifically targeting the users of this module.

First, a contributed Drupal module is the result of the collective efforts of many community members, including coding, testing, and idea contributions. Generally speaking, I don’t think only the module maintainers deserve financial support, as many open-source projects rely on broader community contributions. This is why the current version will continue to use the MIT license.

Secondly, this raises a significant question for the community: what is the sustainable way to ensure the continued success of a Drupal module? This involves not only keeping up with security updates but also adding new features. This issue isn’t unique to this module; many popular Drupal modules have been in minimal maintenance mode for years. Some modules may appear active, but if you closely examine their issue queues, you’ll realise they need more engineering hours to be properly maintained.

It is a Fullcalendar.js issue.

https://github.com/fullcalendar/fullcalendar/issues/2919#issuecomment-30...

Should be something we can do from the Drupal backend.

Thanks @ James for reporting.

I test it with Drupal 11.

Drupal version: 11.0.0

Fullcalendar View version: 5.2.0

Here is the result from my test.

Month view:

Week view:

Day view:

List view:

The evnet title present correctly except the list view. Is it the same as what you see on your end?

It is good hear that a patch is enough to help someone already.

I close this issue since this feature won't be considered as the free version of this module.

I am planing to develop a premium version of this module, which will support the FullCalendar 6.

Details see 🌱 Premium Version Active

Mingsong → created an issue.

Mingsong → created an issue.

According to the following conversions with simplesamlphp repository in Github:

https://github.com/simplesamlphp/simplesamlphp/issues/2008#issuecomment-...

https://github.com/simplesamlphp/simplesamlphp/issues/2164#issuecomment-...

Pretty much, the answer from them on Symfony 7 is no.

By the way, will the Drupal 10.4 stick with Symfony 6 to the end?

It is alright. Thanks for prompt response.

Thanks @Liam for reviewing my patch.

I wonder if you meant adding property promotion in the following line?

https://git.drupalcode.org/project/webform/-/blob/6c74b9d9347a61fda605b3...

Because the original didn't have that, so I am not sure which line you referred to in #14.

Open merge request !502 aiming for 6.3.x branch.

The merge requests are ready for review.

It seems that the CI test failure with 'phpunit (previous minor)' is related to 📌 Test Webform against upcoming 10.2.x on GitLab CI — and use concurrency to make tests 6x faster (on GitLab CI) Needs work .

I prefer having a unique icon for this module. Due to other FullCalendar relevant modules might use the official full calendar logo as well.

Thanks for the logo icon.

Could anyone open an merge request for this issue and commit the logo file to the merge request? please.

Thanks everyone.

I close this issue as it has been fixed with 3.4.0

Also I am aware that, in your screenshot, there was no 'Delete' button, which is different from a brand new D10 site.

I can't reproduce it with a brand new Drupal 10 site.

Drupal version: 10.3.1
Admin theme: Claro

Ready for review.

Mingsong → created an issue.

Th CI error is caused by 🐛 Ignore the new user.logout.confirm route in the PasswordPolicyEventSubscriber RTBC .

The patch from MR !87 for local test.

We came across this issue too.

I suggest another approach to avoid this error.

Since the password field is hidden, the password constraints table should not be render at all.

So I suggest the following change

$password_mutable = $form['account']['pass']['#access'] ?? TRUE;
  // Load form if relevant and password is mutable.
  if (\Drupal::service('password_policy.validation_manager')->tableShouldBeVisible() && $password_mutable) {

According to the error message, is it something from another module?

modules\contrib\recurring_events

The patch from #86 merge request. In case anyone need the patch for local test.

This subject has been discussing for years. It is not easy and requires a lots of security reviews and tests as well.

Anyone comes with a patch, it is more than welcome to re-open this issue.

Thanks everyone.

Merged into the develop branch.

The module is in minimally maintained mode. Any new feature like this one that requires refactoring won't be consider.

There are many alternative module available. Please consider using other module instead.

I close this issue as it won't be considered.

There is further plan for the feature with this module.

Here are some alternative to those who interested in this feature.

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

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

Ready for review.

Mingsong → created an issue.

Could you please provide the view configuration yml file? So that it is easy for others to reproduce this issue in a local test environment.

Also the PHP error stack trace is important for troubleshooting.

Need test with diff 2.x before we can update the dependency.

The composer.json has been removed.

Ready for review.

MR is ready for review.

Mingsong → created an issue.

You need to learn what “RRULE” means.

This is a free contribution module built and help by volunteers.

Any bug report and feature request is welcome, because they will help others in the Drupal community.

I am close this issue as it is obvious misunderstanding.

First of all, text field as a data field is not supported.

Have a look at the document below might help.

https://fivejars.com/blog/all-you-need-know-about-fullcalendar-view-module

Secondly, this is a support request issue.

MR is ready for review.

Mingsong → created an issue.

The CI test failure is irrelevant.

See the following issue for more details of that CI failure.

🐛 Ignore the new user.logout.confirm route in the PasswordPolicyEventSubscriber RTBC

Created a MR for the proposal.

For those need a patch to test, here is the patch from the MR.

https://git.drupalcode.org/project/password_policy/-/merge_requests/86.p...

It is common use case where a user need to login via Drupal authentication when SSO is not available as a backup. Particularly the IDP is managed by third party.

I would suggest a different way to decide whether the password policy should be applied for an external linking user.

Instead of checking if the user is an external linking user, we can depend on whether the password field is accessible. No matter for what reason, as long as the password field is hidden, the password policy should not be forced as user can not change it via a hidden password field.

Still an issue with 4.0.0.

If the 'Allow SAML users to set Drupal passwords' option is enabled, the user still can change their password according to my test with 4.0.0.

But it is still a problem, which will create an external authentication link for every new user even if 'authentication via SimpleSAMLphp' option is inactive.

Here is the patch for the MR.

https://git.drupalcode.org/project/fullcalendar_view/-/merge_requests/69...

We need someone has the Smart Date module or any other module that implements the fullcalendar_view_processor plugin installed on their site to test and confirm for us.

So I will leave it as 'Needs review'.