#Bug Smash Initiative

I have updated the previous patch for Drupal 10.5

I have now added a new Setting number for custom update hook → section, it would be great if someone could review it, and make sure it's not wrong? Thanks!

I tested this on 11.x today and confirmed this is still a bug.

Reroll Merge request !5773 for 11.2.3 without tests code.

https://git.drupalcode.org/project/drupal/-/merge_requests/5773.patch can't be applied to d11.2 any more after the update of #454 🐛 Use email verification when changing user email addresses Needs work

Does exactly what I needed on a D11 site. Did not find any unintended side effects so far.

Thank you, pablo_pukha!

smustgrave → credited lendude → .

@lendude for 🐛 After modifying the views queries in hook_views_query_alter() the pager is broken Postponed: needs info

This came up as the daily BSI target

On 11.x I can confirm this is still an issue

In the block.schema.yml I see

      type: machine_name
      label: 'ID'
      # Blocks have atypical machine names: they allow periods for historical reasons.
      # @see https://www.drupal.org/project/drupal/issues/2685917
      # @see https://www.drupal.org/project/drupal/issues/2043527
      constraints:
        Regex:
          pattern: '/^[a-z0-9_.]+$/'
          message: "The %value machine name is not valid."

And the issue this was committed on 📌 Add config validation for the allowed characters of machine names Fixed

I think the regex and schema should be updated so it can't start or end with a period.

Reworked the approach from #54 to consolidate the autocomplete attribute down to a single value.

Rebased to the latest 11.x

Those other list builders can be fixed in follow ups

Fair enough. Created 🐛 Capture access cacheability in getDefaultOption() methods for all relevant entity list builders Active . This otherwise lgtm.

Thanks @bohemier! Though, what if later on, an actual official Drupal core 10401 update is released, fixing something entirely different. Will it not then be blocked from getting executed, since that number has already been run?

Though I guess, if your Drupal version is for example 10.5.1, it should be safe to use 10401, since going forward, only updates in the range of 105xx and upwards will be run on a Drupal 10.5 installation? I guess I answered myself there:

• Drupal +10.5 can use 10401
  If on Drupal +10.5, all is well and you can use 10401.
• Drupal 10.4 should not use 10401
  Do not use 10401 if you are still on 10.4. Since Drupal 10.4 may still get updates (" Security release window for Drupal 11.1.x and 10.4.x → ")), using 10401 in a custom update hook might block an actual, later Drupal 10.4 update.

It's still an issue in D11.

Not sure if the way I'm doing things is why it's a problem, but this is the issue that's happening.

Drupal 11.2:
When I call FormState::setError multible times it only show the first message.
I call: $form_state->setError($form,$message);

Please let's not try to fix the cacheability of every list builder here, this is about granting the ability for operations to have cacheability in the first place. Those other list builders can be fixed in follow ups - the fixes may cause other issues and will balloon this MR. This is a 10 year old major bug that would be really good to get fixed.

I've added the commented out param to the subclasses.

@ressa, here's what worked for me. There is no need to reset any hook update number, unless you had applied a previous patch or have any other patch adding the same hook number.

You can patch Drupal 10 with these steps:

Download the patch from #79
Run database update

Back to NW to look at whether cacheability needs to be handled in below bc of access checking per #160.

core/modules/field_ui/src/FieldConfigListBuilder.php
core/modules/taxonomy/src/VocabularyListBuilder.php
core/modules/workspaces/src/WorkspaceListBuilder.php

Also, to add the comment out parameter to all getDefaultOptions() implementations per #158.

The steps to reproduce the issue are complete. I was able to follow them with no problem. I'm adding more info to the proposed resolution in the IS.

I'm restoring the RTBC status. I checked the changes since @smustgrave RTBCed it in December. They include rebases and changes to view config that have been happening due to updates. It looks good to me.

Unpostponed finally.

📌 Investigate preprocess_field in the comment module Active was dealing with this problem, and we can tidy up that preprocess implementation here probably.

I created a merge request as the patch was still creating the revision table even if its not revisionable. Also removed the comments as suggested. Don't know how to test this one off the top of my head but manually testing of both a non revisionable and revisionable entity successfully added + deleted the indexes.

Leaving as needs work for tests.

This is major. Most core entities are revisionable so it doesn't come up often, but the API should work and fatal errors on non-existent tables isn't working.

Added some more detail to the Proposed Resolution section of the Issue Summary.

If we aren’t concerned with #49 can add to my review list for tomorrow

I ran into this logic recently on another issue and the current behaviour is very confusing as #48 demonstrates. We can't assume that everything rendered via block module is never rendered in any other context - especially with layout builder / experience builder and etc.

Wonder if proposed solution can be cleaned up. It mentions just removing this function but looking at the MR not super clear why all the recipes and profiles had to be updated now.

I figured this one out. It happens when Account administration pages are activated and on top in "Interface text language detection". And it happens in Drupal 10 also. I don't know if this is a bug. But it is very confusing

I can confirm this in drupal 11

While I did have an installation which worked correctly, I had to reinstall, and now deleting ANY translation always wants to delete ALL translations.

Thanks for researching! Closing as outdated.

Test coverage already exists for this issue.

The functionality described here is already covered in the following test:

Function:
testDisableLanguageSwitcher()

File path:
language/tests/src/Functional/LanguageUILanguageNegotiationTest.php

What it verifies:

The language_block:content block can be placed

When language_content is disabled via form submission, the language switcher block is automatically removed.

This fulfills the goal of this issue, ensuring block derivative cleanup is tested.

This issue can be closed as already resolved.

Just to highlight why this was changed back to active, this should not be a new submodule in core.

You might want to read this before working on Core issues: https://www.drupal.org/community/contributor-guide/reference-information... →

Essentially the fix by wojtha in this issue 13 years ago and richthegeek and cvangysel in #873070: When an image button appears after another button in a form, the wrong triggering element and #submit handlers are detected → 14 years ago remains correct and needed.

When image buttons are clicked, browsers do not set NAME in the POST, instead setting NAME_x and NAME_y (with x and y the coordinates of the click). To get the clicked button we need to test for these parameters instead of the presence of value— that is, equally . (Damien's suggestion of using #value for image buttons also does not work, whether the button is pressed or not, whether it has a value or not, the value gets set anyway, and set to "true", presumably because of how image buttons are treated by the browser— the only thing that is safe to check are if coordinates were set.)

And yes (replying to 13 year old comments from another issue now, but the same feedback will come up) these changes make the alternative condition specific to image buttons, but i'm fairly certain that is because that is all there is— the only other element in core which uses #has_garbage_value is Radios, which aren't ever going to be triggering a form submission.

So, yeah, image buttons are ridiculous and Drupal core could totally deprecate them and not support them since basically nobody has cared for a decade (especially if we finally do 📌 Use form element type instead of Needs work ), but as long as we have ImageButton extending Submit we need to support it properly as an alternative to Submit, that works alongside Submit buttons.

The merge request is ready and works, but leaving Needs work as it needs a test showing that this fails even when value is not set in the initial form element definition. As my use case is altering an existing button there is some possibility that something about that is adding 'value' back, but definitely unsetting value is not enough.

Related: 🐛 TypeError: htmlspecialchars(): Argument #1 ($string) must be of type string, array given in htmlspecialchars() (line 432 of core\lib\Drupal\Component\Utility\Html.php) Active

A question is whether we should already validate and filter placeholder arguments in FormattableMarkup::__construct(), or wait for __toString() to be called as it is now.

Doing it in __construct() will provide a more useful backtrace.
However, if there is any code that relies on non-Drupal placeholders returned from FormattableMarkup->getArguments(), even if they won't be inserted in the string, that code would no longer work as designed.

So maybe we can validate in __construct() to call trigger_error(), but filter in ::placeholderFormat() which is called in __toString(), where we then don't call trigger_error() again.

Rebased for OOP hook conversion.

And it is not a duplicate with changing values client side; although that may be related, this is being caused with alteration in a Drupal form/widget alter.

From the IS:

Don't re-use user_mail_notify or mutate the email on a cloned version of the user in case someone calls ::save() on it

I think this would be straight forward to implement after 📌 Extract _user_mail_notify() into a user MailHandler Active .

This is absolutely still a bug in Drupal 11.

Button Field module documents:

Important note

Due to #1452894: Elements with #has_garbage_value and #value are always set as a triggering element you can not use image buttons on edit forms when there are any other buttons. Non-editable displays are unaffected.

And where i'm coming from, i confidently told Gin in 🐛 Image buttons cannot be kept in Gin's sticky form actions Active that core's image button form element is a valid alternative to a standard submit input form element:

As noted in ✨ UX when using gin with Contnet Moderation and Workflows Active , Workflow Buttons module pairs very well with Gin for improving the experience of using content moderation workflows, and the 2.0.x branch of Workflow Buttons' "Trash workflow" submodule switches to using the image button to have a trash icon for the soft-delete, similar to the trash icon Claro/Gin add to core's delete link. […]

But in short swapping the submit button out and substituting an image button for it works, and Gin should support this core form element when adding Gin attributes and looking for the #gin_action_item flag.

And i get it working perfectly and then discover that no matter which button i press, the image button (soft delete!) is the one that gets incorrectly identified as the trigger button.