shubham_pareek_19 → made their first commit to this issue’s fork.
shubham_pareek_19 → made their first commit to this issue’s fork.
shubham_pareek_19 → made their first commit to this issue’s fork.
shubham_pareek_19 → made their first commit to this issue’s fork.
shubham_pareek_19 → made their first commit to this issue’s fork.
shubham_pareek_19 → made their first commit to this issue’s fork.
I tested this on a clean setup but couldn’t reproduce the issue. With a Details field group and “Mark group as required if it contains required fields” unchecked, the group label does not show a required asterisk. It seems to be working as expected.
shubham_pareek_19 → made their first commit to this issue’s fork.
shubham_pareek_19 → changed the visibility of the branch 3569751-workspace-ajax-query to hidden.
shubham_pareek_19 → made their first commit to this issue’s fork.
shubham_pareek_19 → made their first commit to this issue’s fork.
I tested this on a clean Drupal site with AJAX Comments (8.x-1.x-dev) enabled but was unable to reproduce the issue. In my setup, the comment Edit and Delete links are AJAX-based but not dialog-based, so no nested dialog occurs and the grey overlay does not appear. This suggests the issue may depend on a configuration or custom code that forces comment actions to open via dialog.ajax. Leaving the issue in Active for further clarification.
shubham_pareek_19 → made their first commit to this issue’s fork.
The merge request fixes the incorrect @DataType annotation namespace. I’ve reviewed the change and it looks correct. Marking this as RTBC.
@joachim namyslo Could you please test the MR and confirm if everything looks good on your side?
If it works as expected, we can move this forward and get it fixed.
shubham_pareek_19 → made their first commit to this issue’s fork.
The attached patch (3566016.patch) could not be applied cleanly using git apply or patch -p1. Both commands failed with errors indicating a malformed/corrupt patch, likely due to formatting or line-ending issues,Because of this, I applied the changes manually.
While testing, I noticed that HTML entered in slider fields (for example test) was still shown as plain text on the frontend.This happens because Drupal textfields store values with HTML entities encoded. Even though Markup::create() was used, the content was still encoded, so the tags were not rendered.To fix this, I decoded the HTML entities before passing the values to Markup::create().
shubham_pareek_19 → made their first commit to this issue’s fork.
I've reviewed the fix working fine for me moving this to RTBC.
shubham_pareek_19 → made their first commit to this issue’s fork.
The patch no longer applies cleanly because the code has changed since it was created.
I applied the changes manually on the current branch and created a merge request.
shubham_pareek_19 → made their first commit to this issue’s fork.
I’ve tested the current MR and the issue is not fully resolved yet.
While testing NBSP cases, I also noticed the same behavior with multiple regular spaces.
with a trim length of 10 characters still causes the “Read more” link to appear, even though the visible text length does not exceed the limit.
This shows the problem is not limited to handling.
The trim detection logic is still counting collapsed or normalized whitespace differently from what is actually rendered.
To fully fix this, whitespace normalization (including NBSP and multiple spaces) needs to happen before the trim-length comparison that determines whether content is considered trimmed.
I was able to reproduce this locally. When the module is enabled and a valid node ID is used (for example /mjml_preview/render/1), the route is resolved correctly, but if the MJML API credentials are not configured yet, the request results in “The website encountered an unexpected error.”
This is not a 404 or routing issue—the controller is reached and fails due to missing configuration. Handling this case more gracefully (for example by hiding local tasks or returning a clean response when MJML is not configured) would improve the user experience on fresh installs.
please update issue summary.
Moving this issue to RTBC.I reviewed the changes and they correctly enforce the PHP requirement in both places.
1.ai_provider_litellm.info.yml now declares php: 8.2
2. composer.json requires php >= 8.2
Reviewed the merge request. CI configuration aligns with Mercury and Drupal standards, pipelines are passing, and related cleanup is appropriate. No remaining issues found. Marking RTBC.
i have added back theme settings schema.
Moving to needs review.
I’ve attached a patch that updates the Media entity label when a referenced
File is renamed via the File Rename module. The label is updated only when it
matches the old filename, so custom media titles are not affected. Cache
invalidation is included so the Media Library reflects the change immediately.
Tested locally on Drupal 10/11 with the default Document media type.
Moving this issue to Needs review.
shubham_pareek_19 → made their first commit to this issue’s fork.
shubham_pareek_19 → made their first commit to this issue’s fork.
shubham_pareek_19 → made their first commit to this issue’s fork.
To address the PHP 8.5 deprecation warning “Using null as an array offset is deprecated”, we updated the code to replace any NULL values returned by getBaseTable() with an empty string ''.
This change ensures that array keys are always valid strings, preventing the warning from appearing. The underlying functionality is unchanged; this is purely a compatibility fix for PHP 8.5.
it looks good to me moving it to RTBC.
I’ve gone through the merge request and checked all the updated comments. Everything looks correct now the patterns follow the format.I didn’t see any functional changes.
Overall, looks good to me and ready to move forward.
@geek-merlin i have tested this MR this works fine for me. Waiting for your input.
thankyou.
I’m really sorry that I wasn’t able to complete the task I had taken up.
I’m really sorry that I wasn’t able to complete the task I had taken up.
The changes looks good to me, thus created a MR since patches are deprecated.
Please review
Working on it.
working on it.
Working on it.
shubham_pareek_19 → made their first commit to this issue’s fork.
I applied the patch and the issue fixed for me, also the changes looks good to me,
Thus moving this to RTBC!
Added back the modules to test files.
Please review!!
shubham_pareek_19 → made their first commit to this issue’s fork.
reviewing it.
The current logic works, but it doesn't fully prevent deprecation warning. We should add an is_string() check to ensure $baseFormId is a string before calling str_ends_with():
$baseFormId = $form_object->getBaseFormId();
if (is_string($baseFormId) && str_ends_with($baseFormId, '_layout_builder_form')) {
return FALSE;
}
Reviewing it.
I had mistakenly assigned this issue to myself. Unassigning now apologies for the confusion.
Working on it.
Added the change record please review!!
@suryabhi
i have also follow these new steps but still i am uable to reproduce this issue , i have created new role and a new user of that role. Then with that new user I tried to edit the content created by the admin and also tried to edit the sitewide created by that new user with the admin's role. In both the cases I did't get ay error, pls tell me if I am missing somethig here.
Thanks,
The logic works with both Drupal 11 and 12.
I have tested this issue as per the provided steps:
Created a Sitewide Alert.
Edited the alert via /admin/content/sitewide_alert/{id}.
Also tried deleting the user who created the alert (with “Delete the account and make its content belong to the Anonymous user” option).
However, I was not able to reproduce the TypeError mentioned in the issue summary. The alert edit page loads without any errors, and I do not see any related entries in the Watchdog logs (/admin/reports/dblog).
To ensure I'm not missing something, could you please elaborate on the exact conditions required to trigger the error (e.g., should the owner field be manually unset or reference a missing UID)?
It would also be helpful if you could re-test this on your end and confirm whether it is still reproducible with the current codebase.
Thanks!
Everything looks good to me,Hence moving it to RTBC.
summary updated.
As fix is already committed on 1.x can we move this issue to Fixed!!