🇲🇦Morocco @b.khouy

I've opened an MR to fix this conflict with the Paragraphs widget. Until it's merged, you can use it as a patch: https://git.drupalcode.org/project/ultimate_table_field/-/merge_requests/9.patch

@smustgrave
I see, I've updated the issue description to match the default template.

I've updated the selectors as recommended.

Got it! Now I have enough information, thanks @sandeep.
I'm changing the issue type to "Needs Work."

@ressinel

Thanks for reporting this.

I recommend updating to the latest version of the module using the following command:: composer require 'drupal/ultimate_table_field:^1.0'

If the issue persists after updating, could you provide more details on how you're using the table field with Layout Builder?

As you know, the core Layout Builder module allows referencing content as blocks in the Manage Display section. How did you integrate the table widget into the layout?

Are you using the table form element as a block configuration field via Form API?

Are you leveraging a contributed module like Inline Entity Form or Layout Builder Widget to manage content within Layout Builder?

To help us better understand and troubleshoot the issue, please share detailed reproduction steps along with screenshots.

Thanks in advance!

Hello all,

The opened MR didn’t resolve all CKEditor cases—for instance, the issue persists when the source mode is selected. I’ve updated the MR with a fix that covers all scenarios.

I've attached two screenshots showing the before and after.

Until the MR is merged, you can apply the MR patch as a workaround: https://git.drupalcode.org/project/drupal/-/merge_requests/10936.patch

This issue also occurs in Drupal 10, so you can continue using the MR patch until migrating to Drupal 11. Alternatively, we might need to open a dedicated MR for the 10.x branch.

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

Great to hear it's working!
Patch has been committed, please update to the latest version:
composer require 'drupal/ultimate_table_field:^1.0'

@justice4u Thank you for reporting this issue.
The problem occurs in Drupal 11 when using the replace method in #ajax.
The attached patch provides a fix.

The fix has been committed. Please update the module to the latest version:
composer require 'drupal/ultimate_table_field:^1.0'

Thanks, @dpi.

@etedal-abu-rajab, I truly appreciate your enthusiasm for contributing to the Taxonomy Bulk Actions module and your interest in becoming a co-maintainer. However, contributing to a project isn't limited to maintainership—you can also make a valuable impact by fixing issues, opening bug reports, or suggesting new features. Your contributions in any form are always welcome!

Duplicate issue reported: https://www.drupal.org/project/domain_entity_type/issues/3489939 🐛 Error on "/node/add" when the user only has access to one content type Active

Fix typo

b.khouy → created an issue.

I rewrite the path in #3 to also fix Undefined array key "default_formatter" warning.

The Drupal\Core\Render\Element\FormElementBase class is not available in your current Drupal version. However, the alternative class, Drupal\Core\Render\Element\FormElement, is deprecated in Drupal 10.3 and is scheduled for removal in Drupal 12. To address this, we will continue using the deprecated FormElement class for now, with plans for a Drupal 12-compatible release in the future.

In the meantime, here is a patch to resolve the issue until the next release containing the fix.

Update add column/row screenshot.

Update the page title

The issue generally occurs when you try to upload a file that exceeds the post_max_size setting in PHP configuration. Here’s a summary:

• If UploadedFileSize <= upload_max_filesize, the file will upload successfully.
• If upload_max_filesize < UploadedFileSize <= post_max_size, a validation error message will appear.
• If UploadedFileSize > post_max_size, nothing happens (which is the current issue being discussed).

The key distinction between the Table Field and Ultimate Table Field modules is that Table Field supports only text fields for cell values. In contrast, Ultimate Table Field introduces a new plugin type called "Cell Field Type," enabling developers to create plugins that define various cell data types. By default, the module includes four cell data types: Text, Text (Long), Link, and File.

We're currently developing documentation with examples, which will be published soon, along with enhancements to the module's Backoffice UI.

b.khouy → created an issue.

I've integrated PHPCS, PHPStan, and the necessary linters into the project's GitLab CI to ensure clean and consistent code for all future contributions. The fixes have been merged into the 1.0.x branch.

To apply these fixes in your projects before the next official release, you can run the following command:
composer require 'drupal/domain_entity_type:1.0.x-dev@dev'

Thank you, everyone!

b.khouy → created an issue.

This issue stems from the use of $this->getFrontPagePath() as the first parameter of the preg_quote() function in web/core/lib/Drupal/Core/Path/PathMatcher::matchPath method. We need to ensure that the first argument is always a string. In the attached patch, I’ve added a check to validate the returned value accordingly

@pdureau

I've revised the regex for attribute values to exclude forbidden characters. Typically, these forbidden characters include quotes (") and encoded HTML characters such as &, <, etc.
Here is the updated regex for attribute values:

$double_quoted_value = '"(?!.*&[a-zA-Z0-9]+\;)[^"]*"';

I took the time to reproduce this with the latest updates in 2.0.x but couldn't reproduce the issue.
It seems everything is working as expected, so I believe we can close this issue with the status "cannot reproduce"
@christian.wiedemann, you may want to test again with the latest 2.0.x and feel free to reopen in case the problem persists

Yes, because we know the specific list of allowed special characters in Tailwind, it's easier to define that list explicitly rather than managing all the other forbidden special characters.

Here is the related issue: [2.0.0-beta2] The regex for attribute (values) props should allow all Tailwind allowed special characters 🐛 [2.0.0-beta2] The regex for attribute (values) props should allow all Tailwind allowed special characters Needs work

b.khouy → created an issue.

@pdureau
Yes, this applies only to the regex for double-quoted values (the attribute name regex is fine). Here's a regex that includes only the allowed special characters:

$double_quoted_value = '"[\s\w\-_:&\[\]\/>\*]*"';

I will create another issue for that.

@pdureau

Can we reopen this issue ?
We need to account for all special characters used in Tailwind.
Here are some examples of Tailwind classes:

• bg-blue-500
• hover:bg-blue-500
• w-1/2
• w-1.5
• text-[16px]
• bg-[#ff5733]
• [&_img]:rounded
• [&_>p]:text-primary

b.khouy → created an issue.

@g4mbini
I encountered the same issue. As a temporary solution, I had to change my enum values to strings (e.g., use '1' instead of 1). In general, it seems that Drupal select widgets always return strings, so the UI Patterns module should account for this. I'll take some time to reproduce the issue and work on it.

b.khouy → created an issue.

@pdureau

If $this->context["bundle"] is expected to return either a string (the bundle), a boolean (for reasons that are unclear), or null, and the condition needs to be valid when the bundle is not null or when the bundle is false, the condition should be written like this:
if (!isset($this->context["bundle"]) && $this->context["bundle"] && isset($this->context["entity"])) {

Ultimately, the correct approach depends on your requirements. It looks like this issue has already been resolved in: 📌 [2.0.0-beta2] ContextHelper cleaning Fixed
:)

@christian.wiedemann
You're right, it would be better to handle this in PropTypePluginBase, ensuring a general fix for all prop types.

@pdureau I'll take care of it.

pdureau → credited b.khouy → .

b.khouy → created an issue.

I tested all existing prop types and found no serialization errors. This makes sense since, for example, the variant prop type uses enums, so fixing the issue with the enum prop type should also resolve it for the variant.

A merge request has been opened.

I'm not sure if this also affects other complex prop types, as I only have a few components in my project, and they all use primitive prop types (boolean, string, etc.) and enum prop type.
I will test with other prop types and create a merge request.

b.khouy → created an issue.

b.khouy → created an issue.

@Mav_fly Thank you for testing and confirming that the patch resolved your issue!
The patch has been committed and the related merge request has been successfully merged, a new release, version 1.0.5, has been created including this fix.

The problem here is that Readonly Html field type settings form build method ReadonlyHtmlFieldItem::fieldSettingsForm returns the complete form and this behavior has been changed recently in core parent method that returns the subform instead, so core is expecting a subform from ReadonlyHtmlFieldItem::fieldSettingsForm method, to fix this, first we retrieve the subform from the parent and then we use the retrieved subform to build Readonly Html field type settings form.
Please try out the attached patch and confirm if it resolves the issue. Thanks!

@Mav_fly thank you for details, now I can reproduce it.
Possible related issues: Using $form_state->getValue() in BlockBase's blockForm throws "subform and parent form must contain the #parents property" exception →

Issue status has been changed to Needs work.

@Mav_fly
We need more details to reproduce like the readonly HTML field has been added to which entity type form?