🇦🇺Australia @Mingsong

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'.

Thanks @Matthias for reporting it and the MR.

I identify another issue, maybe, with the following line in that commit.

https://git.drupalcode.org/project/fullcalendar_view/-/commit/91125f112d...

I think the comparison should be changed to

if ($start_field_option['type'] === $fieldtype) {
  $valid = TRUE;
  break;
}

Without those changes, those PHPUnit tests would fail.

Fullcalendar Block supports all kind of data source including a output from a Drupal view.

The patch for the MR can download from

https://git.drupalcode.org/project/entity_reference_tree/-/merge_request...

In case you need a patch for your own test.

I changed it to 'Needs review'. Hope any others can test and review this for us.

Any feedback and thoughts are welcome.

Thanks @Geoffrey for the MR.

Just one minor issue with it, which caused the PHPUnit test failed.

I corrected the data type for 'autocomplete_maxlength', then all tests passed.

Thanks @Geoffrey for the suggestion.

I am not sure if I fully understand the requirement. I link some relevant resource for everyone who interested in this feature, as the background of this discussion.

• Added configurable match limit to the entity autocomplete matcher →
• Hardcoded result size limit in the entity reference autocomplete widget. →
• How to display more than 10 items in link widget autocomplete?

Please feel free to correct me if the resources above is irrelevant or out of date.

I think it is a big issue for using Drupal as a big data (content) management system.

Thanks for the suggestion and the patch.

It sounds faire enough to me. But I would like to have the consistency with the TFA module.

So, let's wait until the TFA module has this move.

I close it for now since it has been fixed with 1.0.0-rc1 already.

Thanks @Aman for the patch (#3).

Actually, the bug should be fixed with RC1 version.

See the commit below.

https://git.drupalcode.org/project/docx_to_html/-/commit/e52f696cd92e66b...

Please make sure you clear the cache if you updated this module from previous version.

Ready for review.

Mingsong → created an issue.

Hi @Howard,

Yes, functionality-wise, those modules are similar. Technology-wise, they are different.

Merged into the develop branch.

Close it for now. Feel free to re-open it if there is any compatible issue with Drupal 11.

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

Thanks everyone.

Merged.

Feel free to re-open if there is any issue with Drupal 11.

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

Mingsong → created an issue.

Close this ticket for now as MR is merged.

Feel free to re-open it if there is any compatible issue with Drupal 11.

I close this ticket for now as it is out of scope of this module.

Thanks @mav_fly for the information.

This module (fullcalendar_view) module only supports the field types from Drupal core.

I am not familiar with the Bookable Calendar module ( https://www.drupal.org/project/bookable_calendar → ) and don't know if it uses a different field type apart from core.

The supported field types out of box can be found in the following lines.

https://git.drupalcode.org/project/fullcalendar_view/-/blob/5.x/src/Full...

Other modules can provide additional field type support by implementing the 'fullcalendar_view_processor' plugin.

Details see
https://git.drupalcode.org/project/fullcalendar_view/-/blob/5.x/fullcale...

Mingsong → created an issue.

What is the steps to reproduce this?
What is the settings? Start date field? Field type?

Have a look at this article.

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

Mingsong → created an issue.

Thanks @Stehpen for the review.

I correct those out of scope comments.

Regarding other changes, I believe they are necessary as they are part of the fix for this bug.

It is ready for review again.

Thanks @Stephen.

The summary has been updated as required.

Thank you @Alastair

Merge request is ready for review.

Is your site installed behind a reserve proxy or load balance?

If so, it might related to 🐛 Path settings is not working behind a reverse proxy Needs review

Merge request is ready for review.

Mingsong → created an issue.

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

Merge requests are ready for review.

10.2 branch is ready for review.

I believe this bug is caused by Drupal\ckeditor5\HTMLRestrictions::applyOperation() function.

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

As the function description suggested, it is supposed to support wildcard within an element name. Therefore, the wildcard $text-container should be resolved into a concrete tag, such as a P tag. But actually result is opposite.

Another example is

<h2 class="text-align-center">

which trigger another error message:

The following attribute(s) are already supported by available plugins and should not be added to the Source Editing "Manually editable HTML tags" field. Instead, enable the following plugins to support these attributes: .

In which, the plugin name is missing from the message.

#65 is different issue from this one.

Attribute name missing in the error message is another problem. More details see

https://www.drupal.org/project/drupal/issues/3445375 🐛 Supported attribute(s) not showing in CKEditor 5 Source Editing plugin error message Active

It seems that something related to <$text-container at line 455 in ckeditor5.ckeditor5.yml file.

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

The $text-container variable seems wan't replaced with the actual tag name, which is '

' tag in this case.

The test to reproduce this issue.

https://git.drupalcode.org/project/drupal/-/merge_requests/7924.patch

Mingsong → created an issue.