🇦🇺Australia @Mingsong

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.

Wildcard is handy in a situation where there are a lots of attributes needed to be allowed, that are not supported by enabled plugins.

Mingsong → created an issue.

Those two MRs are ready for review.

MR 7888 is aiming for 10.2.x branch.

The patch for 10.2.x

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

Mingsong → changed the visibility of the branch 10.2.x to hidden.

Mingsong → changed the visibility of the branch 3410100-10.2-regression-ckeditor to hidden.

Apart from the proposed resolutions from #53, another one could be:
4. Accept the wildcard in the class attribute name, such as 'class*', for example, in the 'Manually editable HTML tags' box, if you specify '' then all classes for an A tag will be allowed.

The MR 7887 introduces functionality to support wildcard characters '*' in the class attribute names within the 'Manually editable HTML tags' setting.

If you the patch to do a local test, you can get the patch from

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

This MR is aiming for 11.x branch.

Mingsong → created an issue.

MR is ready for review.

Mingsong → created an issue.

MR 9 is ready for review.

Mingsong → created an issue.

MR 8 is ready for review.

Mingsong → created an issue.

Thanks @Mark Fullmer for the suggested solutions in #53.

I would vote for option 1. For a better user experience, in the error message where said

The following @element_type(s) can optionally be supported by enabled plugins and should not be added to the Source Editing "Manually editable HTML tags" field: %overlapping_tags.'

In that message, If we could provide a link to where an admin user who has the permission to ignore the constraint conflicts without custom coding/hook required, that would give a better user experience.

Mingsong → created an issue.

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

I believe it was with the latest version.

Thanks @Sascha for your warm welcome.

Yes, I think some real integration tests are important.

I think we can learn something from samlauth module, regarding SMAL test integrating to a Drupal module.
For example,
https://git.drupalcode.org/project/samlauth/-/tree/8.x-3.x/test_resources

Once you are added as a maintainer, try to give other maintainers a chance to review changes and try to avoid committing your own non-trivial changes as much as possible.

Couldn't agree more. Yes, software development is a team work, communication is a key part for this job.

Thanks @Mohit for the fix.

The origin branch is based on the 10.2.x branch and there are some conflicts if targeting 11.x branch.

So I created a another branch based on the 11.x branch and a new MR targeting the 11.x branch.

https://git.drupalcode.org/project/drupal/-/merge_requests/7752

We need to fix this issue for all active branches(10.2.x, 10.3.x and 11.x)

Cheers,

A new test to reproduce this error in 10.2.x branch.

https://git.drupalcode.org/project/drupal/-/merge_requests/7660/diffs

Mingsong → created an issue.

I couldn't reproduce this error by the following steps on a Drupal 10.2.5 site:

1. Go to the media overview page (/admin/content/media).
2. Add a new media by clicking the link(button) 'Add media'.
3. In the 'New media' page(/media/add), add an Image media.
4. In the 'New image' page(/media/add/image), fill in all required fields, such as name, image file(uploaded).
5. Save this new image media.
6. Go to the file overview page(/admin/content/files)
7. Click the file link uploaded by that image media above
8. The image file open as expected. No error

Fixed an unit test error.

I am not sure which module you were referring to. But apparently, this module doesn’t have a D7 version.

And it has been in a minimum maintaining mode, which means no new features will be delivered.

The MR is ready for review.

Mingsong → created an issue.

Thanks @Sven

Thanks @Adam,

I just rebased the MR and will be working on test when I have a chance.

Mingsong → created an issue.

There is a drop down box to allow you to choose which content type’s content you want to create while double clicking. In that drop down box, the top option is ‘None’, that means‘Not to create’.

What content type you choose to create when doubling clicks?
Can you choose ‘none’ as the option of the drop down box?

Due to a bug in /tests/src/Functional/SimplesamlphpAuthTest.php line 91

https://git.drupalcode.org/issue/simplesamlphp_auth-3439861/-/blob/4.x/t...

The PHPunit test won't be passed.