🇲🇦Morocco @b.khouy

Hi @jesss,
Thanks for reporting this. We're planning to include this feature in the next release and are currently working on it.

@orkut murat yılmaz
The current release is secure as it only handles mathematical formulas. In the next release, we’ll introduce a plugin system allowing custom logic beyond math, which will require advanced security checks. This will enable users to define their own computed field logic through plugins.

It’s been handled, thanks for the heads-up.

greggles → credited b.khouy → .

b.khouy → created an issue.

@quietone

I can confirm that the issue doesn’t occur with the Claro admin theme on Drupal 11. It only affects alternative admin themes like Gin in this case.

Since CKEditor theming is part of Drupal core, I believe it would be beneficial for CKEditor to enforce proper word-breaking in the editing area by default. This would help prevent similar issues from being reported in the future.

@krakenbite

Apologies for the delay! If something seems stuck, feel free to bump the relevant issue—chances are we’ll see it and respond accordingly.

We’ve just published a new release with Drupal 11 support. I’ve also credited you on the compatibility issue—thanks for raising it!

Don’t hesitate to stay involved—reporting bugs, sharing suggestions, or opening feature requests in the issue queue is always welcome and appreciated!

@krakenbite
Thank you for your interest in the Taxonomy Bulk Actions module and for expressing a desire to become a co-maintainer. I truly appreciate your enthusiasm for contributing to the project.

That said, maintainership is typically granted to contributors who have demonstrated sustained involvement—such as reporting issues, submitting patches, or suggesting enhancements. These contributions help build trust and show commitment to the project's long-term success.

I encourage you to start by engaging through the issue queue: propose ideas, help triage existing issues, or contribute code. Once there’s a history of meaningful contributions, we can absolutely revisit the discussion of co-maintainership.

Looking forward to your input and collaboration!

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.