When using Layout Builder, remove contextual links for blocks outside of the current layout

Views also using to suppress contextual #3039248: Deprecate views_ui_contextual_links_suppress(), views_ui_contextual_links_suppress_push(), views_ui_contextual_links_suppress_pop()

I think both issues needs common ability to control contextual additions to render element
Like

$build = [
  '#type' => whatever,
  '#contextual' = [
    ’filter' = [layout_builder, views],
  ],
];

Here's a quick fix you can place in a custom module to remove all contextual links that are not used by Layout Builder:

/**
 * Implements hook_contextual_links_plugins_alter().
 */
function HOOK_contextual_links_plugins_alter(array &$contextual_links) {
  // Remove all contextual link plugins except for the ones provided by layout
  // builder. The only reason we have contextual links module enabled is because
  // layout builder requires it for editing blocks. Having the contextual links
  // enabled for other things confuses site builders that assume the pencil icon
  // is used for editing layouts.
  foreach ($contextual_links as $key => $contextual_link) {
    if (strpos($key, 'layout_builder') === FALSE) {
      unset($contextual_links[$key]);
    }
  }
}

Rebased to run the test-only feature

1) Drupal\Tests\layout_builder\FunctionalJavascript\ContextualLinksTest::testContextualLinksOutsideLayout
Behat\Mink\Exception\ExpectationException: An element matching css "[data-contextual-id*='block:block=global_block:']" appears on this page, but it should not.
/builds/issue/drupal-3028191/vendor/behat/mink/src/WebAssert.php:794
/builds/issue/drupal-3028191/vendor/behat/mink/src/WebAssert.php:443
/builds/issue/drupal-3028191/core/modules/layout_builder/tests/src/FunctionalJavascript/ContextualLinksTest.php:201
/builds/issue/drupal-3028191/core/modules/layout_builder/tests/src/FunctionalJavascript/ContextualLinksTest.php:119
/builds/issue/drupal-3028191/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
ERRORS!
Tests: 2, Assertions: 32, Errors: 1.

Tested this manually on a Standard profile install with layout builder enabled
Checking the title block I see the contextual links
Applying the MR and refreshing my browser I can no longer see the contextual links for the title.

Did verify the contextual links within the layout are still functional.

Went to a random non layout builder page and verified contextual links are unaffected there too.

Test needs to be fixed

Tested this manually, It is working as expected and the test coverage is also thorough.

Committed 6959691 and pushed to 11.x. Also cherry-picked to 10.2.x. Thanks!

Took me a long road to come here. For everyone wondering where their contextual links went when using layout_builder translations with https://www.drupal.org/project/drupal/issues/2946333 or https://www.drupal.org/project/layout_builder_st, the newly introduced JS in this issue removes them.

I opened an issue for that in the layout_builder_st issue queue: https://www.drupal.org/project/layout_builder_st/issues/3411037
Not sure if this is the right place either...

Just wanted to let this comment here for others who are debugging this.

We have a custom module to create block groups in layout builder. The child blocks in the parent block group have their own contextual links defined by the module, and do not have the layout_builder_block: start to the contextual ID. This change removed the contextual links for the child blocks, and they can no longer be edited, removed, moved, etc.,

What is the best way to approach changes to the custom module to support this change? Adding the colon : to the end here seems a bit heavy handed. If it wasn't there, we could at least update our module to use the layout_builder_block_ prefix.

I'm tempted to patch this change out for now on our sites as it makes a lot of assumptions.

Our solution for this was to patch the one line and adjust the condition to allow our custom blocks as well:

if (contextualId && !(contextualId.startsWith('layout_builder_block:') || contextualId.startsWith('OUR_CUSTOM_BLOCKS:'))) {

I'd still like to see something more comprehensive to allow customizations like ours if possible. Again, this change makes a lot of assumptions about the desired user experience and the approach here is very heavy-handed.