#Bug Smash Initiative

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

I think #24 is a valid concern (see 🌱 [policy] Treat username enumerations as security bugs that require Security Advisories Active ).

prudloff → changed the visibility of the branch 2842858-basic-auth-module to hidden.

prudloff → changed the visibility of the branch 10.4.x to hidden.

prudloff → changed the visibility of the branch 10.3.x to hidden.

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

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

The Ideas project is being deprecated. This issue is moved to the Drupal project. Check that the selected component is correct. Also, add the relevant tags, especially any 'needs manager review' tags.

Changing to the standard issue template → would also help other contributors.

For some ideas

I haven't reviewed this since my earlier comment.

Hook implementations are not covered strictly under BC. I know core sometimes still provides it.

I'm not sure either how we would do it in this case.

@smustgrave, I guess I'm not sure how to best go about implementing a deprecation since the current functionality is built into the user module (in a hook_ENTITY_TYPE_insert() implementation that gets triggered any time a user role entity is created) and not part of any API code that would be invoked directly by contrib extensions.

We could add something to trigger a deprecation warning inside the hook implementation but there wouldn't really be anything contrib extension maintainers could do to address the deprecation until functionality contained in the hook implementation is removed or moved elsewhere.

I'm also not sure whether this constitutes a major change or not. @alexpott mentioned in #18 🐛 user_user_role_insert should not exist Needs work that what user_user_role_insert() currently does isn't strictly needed:

user_user_role_insert() is doing something that does not have to happen at all. It's a UI niceness but from an API point-of-view just gets in the way.

Was perviously tagged for IS update so moving NW for that. Believe there is 1 question on the MR too.

Automatically closed - issue fixed for 2 weeks with no activity.

This seems like it could be an immediate breaking change if I had css written for before.

smustgrave → credited lendude → .

@cilefen for [#3415142

@lendude for 🐛 Comment module uninstallation leaves key_value table with entity.definitions.bundle_field_map entry Postponed: needs info

@jurgenhaas your last 2 patches barely have any code in them, are you sure they work?

Rebased as this MR was 800 commits back

Feedback appears to be addressed on this one.

Think we will have to trigger some deprecation to warn people

Then think this needs to go back to NW for backwards compatibility can’t just break things for people immediately

• Addressed @smustgrave's MR comments
• Added the actions as exported config yml files to config/install in the standard and demo_umami install profiles
• Added the actions as exported config yml files in the administrator_role and content_editor_role recipes

@smustgrave, yes, I think if contrib module tests involve the creation of user roles, they could be affected by these changes. I think maintainers of profiles and recipes that include custom roles are even more likely to be affected.

There may be some cross-over with 🐛 Details elements have incorrect aria-describedby attributes Needs work , which is RTBC.

This came up as daily BSI target

Issue summary could use some love but #129 may be worth exploring?

What's wrong with the original MR that tries to pop off the extra request?

Thanks to cptX (#58), I have no more "page not found" errors. My site is multilingual but comments translation is not enabled. It was a disaster for SEO as every permalink was giving a "page not found" when not in the default interface language. I don't see a solution for this in the last patch (#62).

Hi guys

As the last feedback review was given by #41, i made another up-to-date check after all last commits and the changes seems to address the requests.
The advanced column "is gone" as the collapsible behavior.

Checked with Drupal 11.2.x-dev

I think this belongs in the extension system component, since ModuleInstaller is in the Drupal\Core\Extension namespace.

Rerolled latest patch to an MR

Rerolled the 11.1.x MR changes against 11.1.7.

Automatically closed - issue fixed for 2 weeks with no activity.

This was previously fixed in #1211668: Special characters are encoded twice for feed icon attribute title → and we have \Drupal\Tests\system\Kernel\Common\AddFeedTest::testFeedIconEscaping testing for it. Is this not working correctly? Does this only affect feeds from views?

CR will need some work as believe we missed 11.2

Left some comments on the MR.

If the test changes were needed to make them pass then wouldn't this change potentially break contrib tests.

Thanks @mstrelan for digging into that! Agree with your findings.

Automatically closed - issue fixed for 2 weeks with no activity.

#57 feedback was addressed.

Automatically closed - issue fixed for 2 weeks with no activity.

I got the same error on Drupal 10.4.7
It happened after deleting some nodes meanwhile ECA was analyzing the nodes and setting their moderation states etc. Maybe this was not the reason.

Anyway like before someone instructed I managed to fix it and deleted the corrupted node like this:

1. Go to mysql console
2. use databasename;
3. SELECT nid FROM node_field_data WHERE nid NOT IN (SELECT n.nid from node n);
4. 	DELETE FROM node_revision WHERE nid = 12553;
4.1	DELETE FROM node_field_revision WHERE nid = 12553;
4.2   DELETE FROM node_field_data WHERE nid = 12553;
4.3   DELETE FROM node WHERE nid = 12553;

The change record should explicitly reference the config key that's being removed. There will be some cases like distributions with a full set of exported config that could end up with stale config after this change and will need to remove the key manually.

I'm confused by the update number here - left a comment on the MR.

I have reviewed and tested the patch against Drupal 11.x-dev, and it works as expected. The patch successfully removes the incorrect access denied messages that appeared in the Site Branding block when users lacked permission to edit certain elements. Specifically, users without the appropriate permissions no longer see misleading references such as "You do not have the appropriate permissions to change the site logo" when they only lack access to the site name or slogan.

I've tested with D10.4.5 and D11.1.6 ,checked with adding new language also checked with already added language edit page but not reproduced this error.

Thank you!

I don't think there should be any access checks on the paths. When combined with a module like r4032login it absolutely makes sense to allow an access restricted page to be the front page. Even admin paths, e.g. for a decoupled Drupal site that might only be used for administering content, it would make sense to put /admin/content as the front page.

Applied the latest patch and converted to a merge request. Fixed the test coverage and found a bug with the active theme and fixed that too.

Attaching rerolled patch against 11.1.7

Came up as a daily BSI target

This still appears to be the case, example

* "delete-multiple-confirm" = "Drupal\Core\Entity\Form\DeleteMultipleForm"

But is it still a problem?

Will say if this still happening lets put back into NW, but no follow up in 3 months could close out.

To make progress here the policy changes should to be defined. I have changed the proposed resolution with a template where the actual changes can given and made available for review.

I did some more digging. We can use 'system.entity_autocomplete' in the test like so:

$this->drupalLogin($this->account);
$selection_settings_key = Crypt::hmacBase64(serialize([]) . 'userdefault', Settings::getHashSalt());;
\Drupal::keyValue('entity_autocomplete')->set($selection_settings_key, []);
$this->drupalGet('/entity_reference_autocomplete/user/default/' . $selection_settings_key, [
  'query' => [
    'q' => $this->account->getAccountName(),
  ],
]);

However we never enter ThemeTestSubscriber::onView so the exception is never thrown anyway.

I think we can just remove the test.

#22 - The other reference to user/autocomplete was removed in 🐛 NodeCreationtest::testAuthorAutocomplete has incorrect selector for falsey check Active

I've created an MR to remove the test. But kind of agree with #17:

What was this originally testing? Should we still test that?

Good question. The test was meant to ensure that the theme registry was not initialized when making a request to the autocomplete route. The theme_test module has an event subscriber that throws a "registry initialized" exception if the theme registry is initialized. This currently only applies to the 'system.entity_autocomplete' route but previously applied to 'user.autocomplete' and 'user.autocomplete_anonymous', before #2434697: Remove UserAutocompleteController → . I'm not sure if there is any test that's checking for that exception, so perhaps that should be removed too? Or we refactor FastTest to use the 'system.entity_autocomplete' route instead.

Merged the latest 11.x.

prudloff → changed the visibility of the branch 2118743-twig-debug-output-d10 to hidden.

My use case: I wanted to create a view reporting the number of users for each role. However, when I enable aggregation I cannot see the Roles field available to be added.

To discuss the feedback on #50, also was tagged for a follow up but don't see the issue for that.

Left comments.

smustgrave → credited saschaeggi → .

Myself for 🐛 keep dropbutton intact with autobutton setting on modal Postponed: needs info

@saschaeggi for 🐛 Restore two-colour focus indicator Postponed: needs info

Since there's been no follow up going to close out, but if still an issue please re-open.

This issue was originally created because when the node wasn't loaded, the batch failed and the user was presented with "could not be rebuilt" and "need to be rebuilt" messages simultaneously.

Now that 🐛 Node Access Rebuild never finishes (infinite loop) Fixed fixed the bug when a node couldn't be loaded, I'm not really sure what relevant information we could provide in this log message and why it would be the job of this batch process to call out a faulty node? A node has to exist in the database and then produce an error on load to even hit this issue (since $nids come from an entity query).

What information could we actually provide here that would help a user in any way? They'd still see a successful batch operation afaict.

We might as well wait until 📌 {% trans %} does not support render array and MarkupInterface valued placeholders Needs work is merged before fixing up the conflicts here too since that changes the rendering of $username as well.