#Bug Smash Initiative

This is an issue as reported by 2 of our clients. I haven't been able to determine the exact process / steps to reproduce based on the information received. I'll update here once I'm able to reproduce.

$whitelist was changed to $pathPrefixes in Drupal 11.1.0

https://git.drupalcode.org/project/drupal/-/commit/27948b069b1be0be6062b...

Here is an updated patch for Drupal 11.1+.

When updating to Drupal 11.1.3 while this patch is installed, clearing cache for the first time (the first of our post-deployment steps), the following error happens. Removing the patch allows cache to be cleared, and it can be added back. I think a check for an empty or unset whitelist will fix this. If so, I'll update the patch.

Error: Call to a member function get() on null in /var/www/html/docroot/core/modules/path_alias/src/AliasManager.php on line 149 #0 /var/www/html/docroot/core/modules/path_alias/src/PathProcessor/AliasPathProcessor.php(47): Drupal\path_alias\AliasManager->getAliasByPath()
#1 /var/www/html/docroot/core/lib/Drupal/Core/PathProcessor/PathProcessorManager.php(108): Drupal\path_alias\PathProcessor\AliasPathProcessor->processOutbound()
#2 /var/www/html/docroot/core/lib/Drupal/Core/Routing/UrlGenerator.php(392): Drupal\Core\PathProcessor\PathProcessorManager->processOutbound()
#3 /var/www/html/docroot/core/lib/Drupal/Core/Routing/UrlGenerator.php(294): Drupal\Core\Routing\UrlGenerator->processPath()
#4 /var/www/html/docroot/core/lib/Drupal/Core/Render/MetadataBubblingUrlGenerator.php(105): Drupal\Core\Routing\UrlGenerator->generateFromRoute()
#5 /var/www/html/docroot/core/lib/Drupal/Core/Url.php(769): Drupal\Core\Render\MetadataBubblingUrlGenerator->generateFromRoute()
#6 /var/www/html/docroot/modules/contrib/webform/src/WebformHelpManager.php(1613): Drupal\Core\Url->toString()
#7 /var/www/html/docroot/modules/contrib/webform/src/WebformHelpManager.php(146): Drupal\webform\WebformHelpManager->initHelp()
#8 /var/www/html/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php(259): Drupal\webform\WebformHelpManager->__construct()
#9 /var/www/html/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php(177): Drupal\Component\DependencyInjection\Container->createService()
#10 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(289): Drupal\Component\DependencyInjection\Container->get()
#11 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(253): Drush\Runtime\LegacyServiceInstantiator->resolveFromContainer()
#12 [internal function]: Drush\Runtime\LegacyServiceInstantiator->resolveArgument()
#13 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(223): array_map()
#14 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(193): Drush\Runtime\LegacyServiceInstantiator->resolveArguments()
#15 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(167): Drush\Runtime\LegacyServiceInstantiator->instantiateObject()
#16 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(117): Drush\Runtime\LegacyServiceInstantiator->create()
#17 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(54): Drush\Runtime\LegacyServiceInstantiator->instantiateServices()
#18 /var/www/html/vendor/drush/drush/src/Boot/DrupalBoot8.php(242): Drush\Runtime\LegacyServiceInstantiator->loadServiceFiles()
#19 /var/www/html/vendor/drush/drush/src/Boot/DrupalBoot8.php(218): Drush\Boot\DrupalBoot8->addDrupalModuleDrushCommands()
#20 /var/www/html/vendor/drush/drush/src/Boot/BootstrapManager.php(211): Drush\Boot\DrupalBoot8->bootstrapDrupalFull()
#21 /var/www/html/vendor/drush/drush/src/Boot/BootstrapManager.php(397): Drush\Boot\BootstrapManager->doBootstrap()
#22 /var/www/html/vendor/drush/drush/src/Application.php(219): Drush\Boot\BootstrapManager->bootstrapMax()
#23 /var/www/html/vendor/drush/drush/src/Application.php(185): Drush\Application->bootstrapAndFind()
#24 /var/www/html/vendor/symfony/console/Application.php(284): Drush\Application->find()
#25 /var/www/html/vendor/symfony/console/Application.php(193): Symfony\Component\Console\Application->doRun()
#26 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run()
#27 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun()
#28 /var/www/html/vendor/drush/drush/drush.php(140): Drush\Runtime\Runtime->run()
#29 /var/www/html/vendor/bin/drush.php(119): include('...')
#30 {main}
Error: Call to a member function get() on null in Drupal\path_alias\AliasManager->getAliasByPath() (line 149 of /var/www/html/docroot/core/modules/path_alias/src/AliasManager.php).
 [warning] Drush command terminated abnormally.
Failed to run drush cr: exit status 1

Seems like this should be moved out of PNMI.

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

Will try to find time next week to test this. If someone wants to have a crack at this in the meantime, go ahead.

Closing this as outdated for now. The other referenced issue from the IS isn't in either I'm not too sure where this would stand regardless.

If this is still an issue, please feel free to reopen it.

Triaged as part of BSI.

Is this still relevant? I've never used the field_layout module, but when testing it there is at least 1 thing that changes when swapping layouts - the layout icon. Even with no settings this does change so I think this should maybe be closed as outdated?

Just got again the error today and a bot crash my drupal website.

I've managed to fix the test, but it's not a regression test—it only verifies the specific use case reported by the original poster. However, it should trigger the error, yet I haven't been able to reproduce it by undoing the fix and running the test.

Could it be that this is no longer an issue?

I should have been more clear. It is the Events Registration recipe that is blocked.

https://www.drupal.org/project/events_registration →

Retagging.

Putting in needs work because the passage of time has caused the MR to become stale and have an error.

Wonder if the IS could get some love. Using the standard template please

Good to see the tests still pass but believe will still need test coverage

Thanks.

Since there hasn't been a follow up in 4+ months going to close out. If still an issue please reopen.

They're tagged services, which I think means they fall under this rule of not being covered by BC.
https://www.drupal.org/about/core/policies/core-change-policies/bc-polic... →

This has broken several contrib modules that inherit from PathBasedBreadcrumbBuilder --

- 🐛 BusinessRulesBreadcrumb must be compatible with PathBasedBreadcrumbBuilder on Drupal 10.4.0 and above Active
- 🐛 Fatal error: Declaration of Drupal\entity_ui\Breadcrumb\AdminBreadcrumbBuilder::applies Active

Meh added it to the baseline. The alternative was asinine:

    if ($this->rendererConfig['debug'] === TRUE) {
      $render_start = microtime(TRUE);
    }

    // Had to become (also further down):
    $debug_mode = $this->rendererConfig['debug'];
    if ($debug_mode) {
      $render_start = microtime(TRUE);
    }

To hell with that :)

I am adding the patch file instead of using a PR in the composer.json file for PR #11146 in Drupal 10.4.3 with PHP 8.3.

Why is phpstan choking on this on an unrelated variable that it should know how to inspect.

Needs tests and we need to update https://www.drupal.org/docs/drupal-apis/render-api/auto-placeholdering#s... →

Also we should check if we want to load defaults for pre_render and post_render. But there we need to also check if defaults were already loaded and someone changed the type.

From reading the issue where we created a Stable9 theme - #3050374: Create Drupal 9 stable theme → - I can't see any reason given for why we moved items from /misc to /media-library.

My feeling is that someone decided that "misc" is too general, and each template should live somewhere specific. But I don't know why media-library was chosen. It's interesting that we do not have any "misc" folder in Stable9.

I have a suspicion that we can either:

1. Leave it as is, or
2. Decide where we think those templates should go - with the requisite release notes/change record.

If we choose option 2, do we want to (re)create a "misc" directory in the Stable9 theme, or is there somewhere more appropriate to place these templates? Would they all be better placed in the /admin directory? Or maybe feed-icon.html.twig could go in the /views directory?

@smustgrave, I've applied your two suggestions and left a reply to your third MR comment of what I think @rlmumford pretended to do.

Thanks!

Checked in drupal 11 claro theme in chrome and microsoft edge browsers, not able to reproduce the issue. Below is the screen shot of working display terms.

Closing in favor of 🐛 Lazy builder broken (#type defaults not loaded) Needs work as the core team explained there that they do consider this a DX bug they want to see fixed.

This might have been a Drupal CMS blocker at one point but it no longer is, and certainly not for the Events recipe. Untagging!

Updated work around for 10.4.x:

use Drupal\Core\Access\AccessResult;
use Drupal\Core\Form\FormStateInterface;
use Drupal\media_library\MediaLibraryState;

/**
 * Implements hook_field_widget_single_element_WIDGET_TYPE_form_alter().
 * 
 * Add the plugin ID to the media library state when in layout builder.
 */
function MODULE_field_widget_single_element_media_library_widget_form_alter(array &$element, FormStateInterface $form_state, array $context) {
  $route_match = \Drupal::routeMatch();

  if (in_array($route_match->getRouteName(), ['layout_builder.add_block', 'layout_builder.update_block'])) {
    /** @var \Drupal\media_library\MediaLibraryState $state */
    $state = $element['open_button']['#media_library_state'];
    $openerParameters = $state->getOpenerParameters();
    $openerParameters['plugin_id'] = $form_state->getFormObject()->getCurrentComponent()->getPluginId();
    $new_state = MediaLibraryState::create($state->getOpenerId(), $state->getAllowedTypeIds(), $state->getSelectedTypeId(), $state->getAvailableSlots(), $openerParameters);
    $element['open_button']['#media_library_state'] = $new_state;
  }
}

/**
 * Implements hook_ENTITY_TYPE_create_access().
 * 
 * Allow editors with inline block permissions to insert from media library.
 */
function MODULE_block_content_create_access(AccountInterface $account, array $context, $entity_bundle) {
  $route_name = \Drupal::routeMatch()->getRouteName();

  if ($route_name === 'media_library.ui') {
    /** @var \Drupal\media_library\MediaLibraryState $state */
    $state = MediaLibraryState::fromRequest(\Drupal::request());
    $openerParameters = $state->getOpenerParameters();

    // If the plugin ID exists within the opener parameters, we know
    // the media library is being used on the layout builder form.
    if (isset($openerParameters['plugin_id']) && str_starts_with($openerParameters['plugin_id'], 'inline_block')) {

      if ($account->hasPermission('create and edit custom blocks')) {
        return AccessResult::allowed();
      }
    }
  }

  // No opinion.
  return AccessResult::neutral();
}

Left comments on MR for consistency

If you are another contributor eager to jump in, please allow the previous poster at least 48 hours to respond to feedback first, so they have the opportunity to finish what they started!

For anyone needing to apply this as a fix for Drupal 10, I've been able to go and create a patch file that can be used.

@acbramley - The latest updates done are making this MR diff (applying it as a patch) not work now with Drupal 10 environments. When trying to apply the diff as a patch on Drupal 10.4.1, Composer throws an error saying that the patch cannot be applied.

Came up again but hasn't been much change since. Does seem like a task to me also though.

🐛 ManagedFile::uploadAjaxCallback causes status messages to be unnecessarily filtered Needs work from acbramley

The MR is not supposed to be applied to 11.1.x but on 11.x branch. If this gets accepted to 11.x then we can create a MR for 11.1.x.

This came up in the Bug Smash PMNMI triage. It looks like we haven't had a response to why this issue is postponed. Is someone able to update this issue on whether it is still something that needs work?

Rebased, fixed tests and linting, added CR. This is ready for review.

This bug does actually affect Media library fields in Blocks as well, 🐛 The media library should perform access checks against the revision of the entity being edited Fixed did not fix it.

While the Block Content revision is now loaded in MediaLibraryFieldWidgetOpener, and ->access() is called on the revision, SetInlineBlockDependency::getInlineBlockDependency still just loads the default revision of the parent of the block (e.g the Node) and checks if that block revision exists in the Node, which it doesn't when you're editing a forward revision of the Node (because that'll have different block revision ids). In fact, 🐛 The media library should perform access checks against the revision of the entity being edited Fixed probably caused this regression with media library because it used to check the default revision of the block which would have been in the default revision of the node!

This came up as a daily bugsmash target.

From what I can tell the code is still the same. But I also wonder if this is a task or feature request vs a bug?

🐛 Language override save event not fired when config is renamed Postponed: needs info

Since it's been over a year and still can't reproduce going to close out for now. If still an issue please reopen.

For what it's worth: patch #86 also applies cleanly to 10.4.2 and seems to work correctly.

I can confirm what @yevko's saying: the MR does not apply on 11.1.x

This change is rejected on "modules/language/language.module", probably because the dev-version of 11 looks quite different there:

--- modules/language/language.module
+++ modules/language/language.module
@@ -19,6 +19,7 @@
 use Drupal\Core\Language\LanguageInterface;
 use Drupal\Core\Routing\RouteMatchInterface;
 use Drupal\Core\Session\AccountInterface;
+use Drupal\language\AdminLanguageRender;
 use Drupal\language\Entity\ContentLanguageSettings;
 use Drupal\language\Plugin\LanguageNegotiation\LanguageNegotiationUI;
 use Drupal\language\Plugin\LanguageNegotiation\LanguageNegotiationUrl;

acbramley → closed merge request !8919

I think this issue should be closed now since it is so old and the original report no longer applies.

I've split the change to checkPermissions out into 🐛 UserCreationTrait::checkPermissions contains unreachable code Active

Closing due to lack of steps to reproduce. Please reopen if you are able to reproduce this from a clean install.

smustgrave → credited vidorado → .

smustgrave → credited znerol → .

For triaging 🐛 PageCache caching uncacheable responses (violating HTTP/1.0 spec) + D8 intentionally disabling HTTP/1.0 proxies = WTF Needs work

This is still an issue and is because things like NodeRevisionRevertForm use % placeholders. We get around this with a custom formatter than formats strings as markup. Since the revision_log is a string field, I think the easiest approach here is to just change the placeholder used to remove the markup in the first place?

#106 missed the plugin itself.

Drupal 10.4.2 patch—working.

Duplicate? 🐛 Media Fails to Enforce oEmbed Allowed Providers Setting Active

catch → closed merge request !10110

Committed/pushed to 11.x and cherry-picked to 10.5.x, thanks!

With 2670798-50.patch I am getting

Path: /flag/unflag/like/11969/default?destination=/node/6%3Fpage%3D%252C%252C%252C%252C%252C%252C%252C%252C%252C%252C%252C%252C%252C1&token=awoKBYgqrejo2wsK3kmJH7iOzWluofZsoXUmcbeyv0E&_wrapper_format=drupal_ajax. Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException: 'csrf_token' URL query argument is invalid. in Drupal\Core\Routing\AccessAwareRouter->checkAccess() (line 120 of /var/www/html/test/web/core/lib/Drupal/Core/Routing/AccessAwareRouter.php).

This error comes with views and infinity scroll, and for some of those flags which the views infinity loads after user scrolls down enough that it initiates a load of new content. So the first nodes which have flags are working, but some of the new do not work.

#29 closed this as a duplicate, yet the referenced issue was merged into Drupal 10.1 in 2023, and this bug still remains on 10.1, 10.2, 10.3 etc. The google_tag module does not work without the patch from this issue if you use condition plugins.

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

Noted;
Thanks, Adam, for following up.
We're implementing a custom-coded solution for this:

Example: List of default ignored view modes.
This is being handled using multiple _form_alter() hooks in forms.

Maybe the allowed/ignored list could be stored within the same field-form config settings (for fields).

I can confirm that this still appears at 10.4.2.

Looking through how EntityReferenceEntityFormatter works and thinking about possible solutions I'm not sure this is actually achievable without some form of jankiness.

Entity reference fields can allow multiple bundles. If I allow 2 bundles with different "active" view modes, how do we determine what to show in the view mode options? EntityDisplayRepository does have getViewModeOptionsByBundle (the formatter currently uses getViewModeOptions which returns all view modes for the entity type), but again we'd have to combine them for each bundle that's configured for the field, etc.

Given configuring views is a site builder task, and the Views UI will show a preview, it's simple enough to swap the view mode if it doesn't look correct?

I'm going to close this as works as designed given the length of time since it was last commented on it doesn't seem like a highly desirable change.

Please feel free to reopen if you disagree.

Ran into this while working on Radios in a table.

I looked into the form processing a little bit, and confirmed #12 🐛 Radios and checkboxes not rendered correctly when nested inside other render arrays Active . \Drupal\Core\Render\Element\Radios::processRadios was not being run on radios elements within a table.

My temp solution was "whatever it takes" to get the radios working and I ended up with this method:

/**
 * Takes a normal render array for a radios element and makes it work within
 * a rendered table element. This solves a core Drupal bug where Radios are
 * not rendered at all within a table.
 *
 * @link https://www.drupal.org/project/drupal/issues/3246825
 *
 * @param array $radios
 *   Normal radios render array.
 *
 * @return array
 *   Fixed render array with child Radio (singular) elements.
 */
public function fixNestedRadios(array &$form, array $render_parents, string $render_name, array $radios): array {
  // First item in the parents array is the "tree name".
  $tree_name = reset($render_parents);


  // This container contains a hidden field that registers the $tree_name with
  // the $form_state. This trick allows our custom-rendered radios to be found
  // in $form_state->getValue($tree_name);
  if ($tree_name && !isset($form[$tree_name])) {
    $form[$tree_name] = [
      '#type' => 'hidden',
    ];
  }

  // Build the <input> element names and ids we'll need.
  $parent_names = $render_parents;
  $parent_name = array_shift($parent_names);
  if ($parent_name && $parent_names) {
    $parent_name .= '[' . implode('][', $parent_names) . ']';
  }

  $child_name = $parent_name ?
    $parent_name . "[$render_name]" :
    $render_name;

  $radios['#id'] = $radios['#id'] ?? Html::getUniqueId($child_name);
  $radios['#title_display'] = $radios['#title_display'] ?? 'visible';
  $radios['#description_display'] = $radios['#description_display'] ?? 'visible';
  $radios['#default_value'] = $radios['#default_value'] ?? FALSE;
  $radios['#attributes'] = $radios['#attributes'] ?? [];
  $radios['#parents'] = $render_parents;

  // Render each of the radios options as a single radio element. Neither
  // $form nor $form_state are actually used in this process, just required.
  $form_state = new FormState();
  $radios = Element\Radios::processRadios($radios, $form_state, $form);

  foreach (Element::children($radios) as $index) {
    // Radios::processRadios() doesn't set the #value field for the child radio
    // elements, but later the Radio::preRenderRadio() method will expect it. We
    // can set these values from the $radios #default_value if needed.
    // - '#return_value' is the "value='123'" attribute for the form element.
    // - '#value' is the over-all value of the radios group of elements.
    $radios[$index]['#value'] = $radios[$index]['#value'] ?? $radios['#default_value'];

    // Some other part of the rendering process isn't working, and this field
    // rendered as an <input> ends up not having a "name" attribute.
    $radios[$index]['#name'] = $child_name;
  }

  return $radios;
}

Maybe these things I had to do to make it work can be a clue for someone more familiar with the how forms -> render arrays -> forms work.

@freelock, thanks for providing the detailed steps to reproduce.
I'll update the tests and will update the PR.

Can we close the other one and keep continue working on this issue itself.
We can carry steps to reproduce.

See 🐛 Whitescreen in Layout Builder when a data feed icon with argument is attached to a block Active for an example case using Views Data Export. The patch in this issue fixes that for me.

Seems like more info is needed to move it forward

I did tried to reproduce the issue based on steps mentioned in issue summary.
It seems issue doesn't exist anymore.

I even tried to follow based on step #23 and it seems to be working fine.
I created the view added in patch #16 and added the block in the layout builder for user entity.
It worked fine.

@possibri, @laurentwh
If you noticed the issues, please provide a test view or something I can use to reproduce the issue.

We probably need updated steps to reproduce or see if it has been addressed in recent 11.x cycle.