Rename Custom Block terminology in the admin UI

Think the move block library is close to landing. Can we hammer out details of this one?

Down to one blocker now 📌 [PP1] Move "Block layout" from Structure to Appearance Postponed

Wondering if this is actually blocked by 📌 [PP1] Move "Block layout" from Structure to Appearance Postponed or if we can unblock this? This is primarily about renaming "custom blocks" which is not so relevant for block layout.

I've merged 10.1.x in to the MR and manually resolved all conflicts. We'll need to deprecate and redirect the old path /admin/content/block-content like we did for /admin/structure/block/block-content.

Should we re-title this issue to expand the scope outside of just the administration menu? I think we need to replace "custom block" everywhere it appears, in help topics, in code, etc. It's everywhere.

As /admin/content/block-content isn't in a tagged release, I don't think we'll have to worry

Comment #14 was in relation to #12

Re #13 I think that's a good idea, but let's see what @rkoller and the UX team think?

I vote changing everywhere. Could add to the change record in the meta that we changed it.

For new people may be confusing to see two titles referring to blocks.

For existing people the change record should cover that.

This issue would cross both block_content.module and block.module. I suspect we need to separate this into two issues, one for each sub-system.

in regards of #13 📌 Rename Custom Block terminology in the admin UI Fixed a +1 for changing everywhere. but for the renaming it would be good to have everything in place and untwined, meaning after "moving the block layout into appearance" also landed (ref #11 📌 Rename Custom Block terminology in the admin UI Fixed ). i think keeping this issue PP-1 might be the safer call?

and i had a conversation with @smustgrave already a few weeks back in the context of this issue in the #block-content channel (see https://drupal.slack.com/archives/C04AWT6FNEA/p1672344443803469 - i just forgot to post it in here). one suggestion that spun off in the thread was to change the title Block layout to Block Placement. Block placement is slightly longer but from my point of view a lot clearer.
the term layout in block layout one might associate with i am able to decide the actual layout of a block and its design. and if you take a look at the help text on the block layout page "Block placement is specific to each theme on your site. Changes will not be saved until you click Save blocks at the bottom of the page." the term block placement and what the user is actually able to do on the page is directly used at the beginning of the sentence. On that page the user actually decides were to place a block in the different regions. it is describing the actual activity way better than "layout" does. might be worth a thought? what do others think?

I agree that "block placement" is clearer.

I don't really follow the argument for blocking it on the move. Is there an example of a string usage that would be confusing if this got in first?

I don't really follow the argument for blocking it on the move. Is there an example of a string usage that would be confusing if this got in first?

I think it's just from a logistical perspective, when we were originally planning out all of the issues and the meta, it made sense to postpone the naming ones on the moving issues because it helps to focus the limited resource we have, rather than trying to do all of the issues at once and stretching the effort thereby meaning none actually get done. Also, because the MRs for the moving issues and the naming issues would touch the same code, trying to do them at the same time could get confusing and mean they need to be kept in step with each other.

Fair points. It seems to me this one is ready to go whereas the other one is still pending a decision on where to move it. IMHO this needs to go in before 10.1 so it should take priority. We shouldn't release it with the new "Custom blocks" link in Content only to rename that it in 10.2.

I reread the summary again, and actually there's nothing in the issue summary that blocks this issue on 📌 [PP1] Move "Block layout" from Structure to Appearance Postponed . All of the required changes to the Block Content module have been done. That issue is specific to the Block Layout page, which is provided by a different module. Yes you can access Content Blocks from there, but all the proposed changes in the summary can go ahead with or without that issue being committed.

Also re-titling to be cleared, as I think it's important we recognise that content_block and block are two separate modules, each with their own maintainers.

IMHO this needs to go in before 10.1 so it should take priority. We shouldn't release it with the new "Custom blocks" link in Content only to rename that it in 10.2.

Also, 100% agree with @mstrelan in comment #21, especially since we literally just changed Custom Block Library path to /admin/content/block-content in 10.1.x, and setup the redirect, if we change it again in 10.2.x and add another redirect and BC layer that's just going to get confusing for users. In addition to changing the title of the page and local task, so yes we really should get this done in 10.1.x.

smustgrave → closed merge request !3179

There is one detail relevant to this issue that came up in the aftermath of the feedback sessions i've had at the weekly lean coffee table at the Drupal user group Munich the Tuesday before the last #3318112-25: Move "Block layout" from Structure to Appearance → via a slack conversation with @jurgenhaas. We've also touched the matter during the feedback session but Jürgen phrased and argued the problem more thoroughly in the follow-up:

What is currently called Block layout is being called Layout in the mockups @larowlan provided in #3318112-22: Move "Block layout" from Structure to Appearance → and #3318112-23: Move "Block layout" from Structure to Appearance → . The additional alternatives that were voiced and discussed during the coffee table were Block placement and Placement. But @jurgenhaas suggests to go with Regions as the label for this page for following reasons instead:

• Block should not be in the name. It is ambiguous as blocks are placed in regions as well as in layout builder.
• Layout should not be in the name. It implies that layout could be changed and adjust whereas it is fixed by the theme's geometry, i.e. the regions.
• Placement doesn't catch it either, as placing blocks can be in various places, i.e. in regions as well as in layout builder.

The label should be a clear indicator, such as layout builder is labeled "Layout Builder" regions should be named "Regions".

I have to admit i like the idea of the term regions in combination with approach 2 ( #3318112-23: Move "Block layout" from Structure to Appearance → )for theme cards. i always disliked the term block layout and considered it imprecise/unclear and therefore was an advocate for block placement or placement - that term is used in help texts as well as when people are discussing block layouts in conversations. But Jürgen has a point. Even though going with just regions it lacks somehow the detail what the user is able to do in/with regions?

Think the block layout changes should be moved to a separate ticket. We already moved block types and block library so 100% should tackle those renaming. But block layout hasn't been moved yet and even though it would be nice for 10.1 it's not top of the list of changes needed.

As I said in comment #22, I think changes to Block Layout are out of scope for this issue because this issue is specifically for the Block Content module and Block Layout is provided by a separate Core module.

To quote myself from #3318112-27: Move "Block layout" from Structure to Appearance → :

As a final thought, I wonder if the Layout local task tab should be called "Block layout", rather than just "Layout", my thinking here is inspired by something that was said at the recent usability meeting about how we could better guide users to the new locations of pages after they are moved. Keeping the page/tab title as "Block layout" helps with that because it provides consistency, in that the user is looking for the block layout page, so by keeping the name of the tab consistent with what the menu link under Structure is currently named, we make it easier for users to find it.

I think I was one of the people who originally proposed naming it simply "Layout", because in the future Layout Builder could replace the current region/block layout interface; But if/when that happens it might then make sense to shorten the name of the tab to "Layout", until then I think "Block layout" is better.

So I think Block Layout should not be renamed, yet.

This is ready for review now

Question if we will need an update path for the view

Manual testing

1. When I visit admin/content we seem to have two local tasks - Blocks and Custom Blocks
   
   One of them looks to be coming from a view, the other from a list builder.
2. The views one doesn't have a local action to add a new block
   
3. The list builder one probably should be hidden when views exists, which I think means they both need the same path
4. It occurred to me that this could have been because there's no update path, so I tried a re-install. Did that and confirmed the duplicates are gone. So we will need an update path.
5. Confirmed the module name is updated in the help overview
6. The help topic at http://127.0.0.1:8080/en/admin/help/topic/block.overview calls it 'Content Block module' whereas the help overview calls it 'Block Content' - I think they should use the later when referring to the module, and the former when referring to the entity. So we need to update the help topic
7. The block category at admin/structure/block is still 'Custom' when we place a block content block, however I think we should leave that as is and address in ✨ Set Block Category to Bundle in block_content module Postponed
8. Tagging as Drupal 10.1 target because the update hook scenario is made much harder if we have to do it again in 10.2 (After alreading moving it once in 10.1) - discussed with @xjm
9. We will need to update the change record for ✨ Add more granular block content permissions Fixed , as the permission names have changed, tagging for that
10. We need to update the permission titles too

Here's the remaining places I found custom block or custom_block in core

Key

✅ Leave as is
❌ We should fix

• ❌core/profiles/demo_umami/themes/umami/umami.theme: // Add a class indicating the custom block bundle.
• ❌core/profiles/demo_umami/themes/umami/umami.theme: // Block suggestions for custom block bundles.
• ✅core/profiles/demo_umami/config/install/user.role.author.yml: - 'create and edit custom blocks'
• ✅core/profiles/demo_umami/config/install/user.role.editor.yml: - 'create and edit custom blocks'
• ❌core/tests/Drupal/KernelTests/Core/Entity/FieldableEntityDefinitionUpdateTest.php: ->setDescription(t('The time that
  the custom block was last edited.'))
• ❌core/themes/claro/templates/block-content-add-list.html.twig: * Claro's theme implementation to display a list of
  custom block types.
• ❌core/themes/claro/templates/block-content-add-list.html.twig: * - description: A description of this custom block
  type.
• ❌core/themes/stable9/templates/admin/block-content-add-list.html.twig: * Theme override to present a list of custom
  block types.
• ❌core/themes/stable9/templates/admin/block-content-add-list.html.twig: * - types: A collection of all the available
  custom block types.
• ❌core/themes/stable9/templates/admin/block-content-add-list.html.twig: * - description: A description of this custom
  block type.
• ✅core/modules/block/tests/src/Kernel/Migrate/d6/MigrateBlockContentTranslationTest.php: 'd6_custom_block',
• ✅core/modules/block/tests/src/Kernel/Migrate/d6/MigrateBlockTest.php: 'd6_custom_block',
• ✅core/modules/block/tests/src/Kernel/Migrate/d7/MigrateBlockContentTranslationTest.php: 'd7_custom_block',
• ✅core/modules/block/tests/src/Kernel/Migrate/d7/MigrateBlockTest.php: 'd7_custom_block',
• ✅core/modules/block/tests/src/Kernel/Migrate/d7/MigrateBlockTest.php: // The d7_custom_block migration should have
  migrated a block containing a
• ✅core/modules/block/migrations/d7_block.yml:# This configuration migration depends on the d7_custom_block content
  migration.
• ✅core/modules/block/migrations/d7_block.yml: - d7_custom_block
• ✅core/modules/block/migrations/d6_block.yml:# This configuration migration depends on the d6_custom_block content
  migration.
• ✅core/modules/block/migrations/d6_block.yml: - d6_custom_block
• ✅core/modules/block/src/Plugin/migrate/process/BlockPluginId.php: $lookup_result =
  $this->migrateLookup->lookup(['d6_custom_block', 'd7_custom_block'], [$delta]);
• ✅core/modules/forum/tests/fixtures/drupal7.php: 'page_arguments' =>
  'a:3:{i:0;s:25:"block_custom_block_delete";i:1;i:4;i:2;i:5;}',
• ✅core/modules/layout_builder/tests/src/FunctionalJavascript/LayoutBuilderUiTest.php: 'create and edit custom
  blocks',
• ✅core/modules/layout_builder/tests/src/FunctionalJavascript/InlineBlockTest.php: 'create and edit custom blocks',
• ✅core/modules/layout_builder/tests/src/FunctionalJavascript/InlineBlockTest.php: 'create and edit custom blocks',
• ✅core/modules/layout_builder/tests/src/FunctionalJavascript/InlineBlockTest.php: 'create and edit custom blocks',
• ✅core/modules/layout_builder/tests/src/FunctionalJavascript/InlineBlockTest.php: 'create and edit custom blocks',
• ✅core/modules/layout_builder/tests/src/FunctionalJavascript/InlineBlockTest.php: 'create and edit custom blocks',
• ✅core/modules/layout_builder/tests/src/FunctionalJavascript/InlineBlockTest.php: 'create and edit custom blocks',
• ✅core/modules/layout_builder/tests/src/FunctionalJavascript/InlineBlockTest.php: 'create and edit custom blocks',
• ✅core/modules/layout_builder/tests/src/FunctionalJavascript/InlineBlockTest.php: 'create and edit custom blocks',
• ✅core/modules/layout_builder/tests/src/FunctionalJavascript/InlineBlockTest.php: $permissions[] = 'create and edit
  custom blocks';
• ✅core/modules/layout_builder/tests/src/FunctionalJavascript/InlineBlockTest.php: * Tests 'create and edit custom
  blocks' permission to edit an existing block.
• ✅core/modules/layout_builder/tests/src/FunctionalJavascript/InlineBlockTest.php: 'create and edit custom blocks',
• ✅core/modules/layout_builder/tests/src/FunctionalJavascript/InlineBlockTest.php: $permissions[] = 'create and edit
  custom blocks';
• ✅core/modules/layout_builder/tests/src/FunctionalJavascript/InlineBlockTest.php: 'create and edit custom blocks',
• ✅core/modules/layout_builder/tests/src/FunctionalJavascript/InlineBlockPrivateFilesTest.php: 'create and edit custom
  blocks',
• ✅core/modules/layout_builder/layout_builder.module: if ($account->hasPermission('create and edit custom blocks'))
  {
• ✅core/modules/layout_builder/src/Plugin/Block/InlineBlock.php: '#access' => $this->currentUser->hasPermission('create
  and edit custom blocks'),
• ✅core/modules/layout_builder/src/Controller/ChooseBlockController.php: '#access' =>
  $this->currentUser->hasPermission('create and edit custom blocks'),
• ✅core/modules/layout_builder/layout_builder.permissions.yml:create and edit custom blocks:
• ✅core/modules/block_content/block_content.post_update.php: * Moves the custom block library to Content.
• ✅core/modules/block_content/block_content.post_update.php:function
  block_content_post_update_move_custom_block_library() {
• ❌core/modules/block_content/tests/src/Functional/BlockContentListViewsTest.php: * Tests the custom block listing
  page.
• ❌core/modules/block_content/tests/src/Functional/BlockContentListTest.php: * Tests the custom block listing page with
  different permissions.
• ✅core/modules/block_content/tests/src/Functional/Update/BlockContentUpdateTest.php: * @see
  block_content_post_update_move_custom_block_library()
• ✅core/modules/block_content/tests/src/Functional/Update/BlockContentUpdateTest.php: * @see
  block_content_post_update_move_custom_block_library()
• ✅core/modules/block_content/tests/src/Kernel/Migrate/d6/MigrateCustomBlockContentTranslationTest.php:
  'd6_custom_block',
• ✅core/modules/block_content/tests/src/Kernel/Migrate/d6/MigrateCustomBlockContentTranslationTest.php:
  'd6_custom_block_translation',
• ✅core/modules/block_content/tests/src/Kernel/Migrate/d6/MigrateBlockContentTest.php: 'd6_custom_block',
• ✅core/modules/block_content/tests/src/Kernel/Migrate/d7/MigrateCustomBlockContentTranslationTest.php:
  'd7_custom_block',
• ✅core/modules/block_content/tests/src/Kernel/Migrate/d7/MigrateCustomBlockContentTranslationTest.php:
  'd7_custom_block_translation',
• ✅core/modules/block_content/tests/src/Kernel/Migrate/d7/MigrateCustomBlockTest.php: 'd7_custom_block',
• ❌core/modules/block_content/tests/src/Kernel/BlockContentPermissionsTest.php: 'A basic block
  type: Edit custom block',
• ❌core/modules/block_content/tests/src/Kernel/BlockContentPermissionsTest.php: 'A square block
  type: Edit custom block',
• ❌core/modules/block_content/block_content.permissions.yml: description: 'Get an overview of all custom blocks.'
• ✅core/modules/block_content/migrations/d7_custom_block.yml:id: d7_custom_block
• ✅core/modules/block_content/migrations/d6_custom_block.yml:id: d6_custom_block
• ✅core/modules/block_content/src/Plugin/migrate/source/d6/BoxTranslation.php: const CUSTOM_BLOCK_TABLE = 'boxes';
• ✅core/modules/block_content/src/Plugin/migrate/source/d7/BlockCustomTranslation.php: const CUSTOM_BLOCK_TABLE =
  'block_custom';
• ✅core/modules/block_content/src/Plugin/migrate/source/d7/BlockCustomTranslation.php: $query =
  $this->select(static::CUSTOM_BLOCK_TABLE, 'b')
• ❌core/modules/block_content/src/BlockContentPermissions.php: 'title' => $this->t('%type_name: Create new custom
  block', $type_params),
• ❌core/modules/block_content/src/BlockContentPermissions.php: 'title' => $this->t('%type_name: Edit custom block',
  $type_params),
• ❌core/modules/block_content/src/BlockContentPermissions.php: 'title' => $this->t('%type_name: Delete custom block',
  $type_params),
• ❌core/modules/block_content/src/BlockContentPermissions.php: 'title' => $this->t('%type_name: View custom block
  history pages', $type_params),
• ❌core/modules/block_content/src/BlockContentPermissions.php: 'title' => $this->t('%type_name: Revert custom block
  revisions', $type_params),
• ❌core/modules/block_content/src/BlockContentPermissions.php: 'title' => $this->t('%type_name: Delete custom block
  revisions', $type_params),
• ✅core/modules/content_translation/migrations/d6_custom_block_translation.yml:id: d6_custom_block_translation
• ✅core/modules/content_translation/migrations/d6_custom_block_translation.yml: migration: d6_custom_block
• ✅core/modules/content_translation/migrations/d6_custom_block_translation.yml: - d6_custom_block
• ✅core/modules/content_translation/migrations/d7_custom_block_translation.yml:id: d7_custom_block_translation
• ✅core/modules/content_translation/migrations/d7_custom_block_translation.yml: migration: d7_custom_block
• ✅core/modules/content_translation/migrations/d7_custom_block_translation.yml: - d7_custom_block
• ✅core/modules/content_moderation/tests/src/Functional/LayoutBuilderContentModerationIntegrationTest.php: 'create and
  edit custom blocks',
• ✅core/modules/migrate_drupal/tests/src/Kernel/d6/MigrateDrupal6AuditIdsTest.php: 'd6_custom_block',
• ✅core/modules/migrate_drupal/tests/src/Kernel/d7/MigrateDrupal7AuditIdsTest.php: 'd7_custom_block',

I think we should add a follow up to change the layout builder permission from 'create and edit custom blocks' to 'create and edit inline content blocks' - I think it's out of scope here

Huge work @smustgrave 🙌

This is our last must-have for D10.1 for block content, shaping up nicely

Added 📌 [PP-1] Change the machine name of the 'create and edit custom blocks' permission Postponed

Updating remaining tasks

Everything should be addressed and I updated change record.

Applied the latest patch to a fresh install of 10.1.x previous the site install without any other patches applied. and i've installed the help topics module. a few additional observations.

1. on admin/content/block i like the change on the tab from content block to just block. it is just a bit inconsistent that the content block section is the only under admin/content which has differing h1 and tab title. but i think it should be ok. aside that without any content block created There are no content blocks available.Add a content block. is missing a space after the first period.

2. on admin/help/topic/block.overview it is not clear what

Managing blocks overview
The Block module allows you to place blocks in regions of your installed themes, and configure block settings. The Block Content module allows you to manage block types and content blocks. See the related topics listed below for specific tasks.

is referring to. i suppose the blocks overview is referring to the block layout page?

and the link blocks chapter of the user guide ( https://www.drupal.org/docs/user_guide/en/blocks-chapter.html → ) is probably needing a follow up adjusting the terminology there as well?

3. on /admin/help/block the link online documentation for the block module ( https://www.drupal.org/docs/core-modules-and-themes/core-modules/block-m... → ) needs a follow up as well to adjust the terminology.

4. on admin/help/block_contentthe link online documentation for the block content module ( https://www.drupal.org/documentation/modules/block_content → ) needs a follow up as well to adjust the terminology.

5. on admin/people/permissions one permission title Access the Content block library page refers to the no longer existing title content block library. To be in line with the titles for the node permissions and the recommendation in #1975064-215: Add more granular block content permissions → the string should be changed to Access the Content blocks overview page.

Thanks I’ll work on this.

If I don’t get to it in 3 days anyone else can jump on and remove my name

Actually wasn't much to change.

#32
1 = being tackled in a separate ticket
2 = Changed to Overview for managing blocks
3 = Not sure where to place a follow up for https://www.drupal.org/docs/core-modules-and-themes/core-modules/block-m... →
4 = same for https://www.drupal.org/documentation/modules/block_content →
5 = updated
6 = sounds like a plan

uh that was fast thanks!

#34.1 do you have the link to the issue that is tackled in?

#34.2 hm also with "overview for managing blocks" i wouldn't be exactly sure to which page that part in the help topics section refers to. is it /admin/content/block or /admin/appearance/block. from a users perspective it would be helpful to use clear terminology. managing blocks is just a top level task in the help topics module. but for a user it would be helpful to know to which exact function or page that section is refering to. (and as i said even personally i am uncertain what it exactly refers to still)

#34.3 & #34.4 i am also not exactly sure. i just wanted to point out those shouldn't be a blocker for this issue. but both pages definitely need an update. probably best would be to wait until the move block layout issue is in and then create documentation issues or directly edit both pages . the first link uses custom block 8 times and also has a few paths like Administer > Structure > Block Layout that have to be updated. the second link uses custom block/custom block types 13 times. there is also the question when those changes should go live? with the release of 10.1?

Re #34.1 the issue is 🐛 Remove duplicate "add block" link from block content type view's "Results not found" message Postponed
Re #34.2 I agree, we should expand and fix that here - note also 🐛 Hook help for block content module is out of date after new permissions Needs work
Re #34.3 and #34.4 these can be edited post commit, tagged as such - I've also applied for smustgrave and I to be a maintainer of those pages

@smustgrave can you confirm you've resolved the ❌ We should fix items from #29?

We have 12 days until 10.1 alpha, this is the last piece we need for internal consistency with the other changes (and to avoid needing 2 BC layers for route name changes)

This is looking really good, thanks for all of the great work so far everyone!

Added a couple of comments to the merge request, one minor and one potential big one.

Left some comments and yes @larowlan believe everything has been addressed.

Reviewed all issue comments and remaining threads in the MR. It looks like the only outstanding issue is the description of the menu item for the view.

It's currently reading as Create and edit content block content., with a proposed change of Create and edit content blocks which I agree reads slightly better.

Otherwise amazing work as always :)

Just pushed up that change.

It looks like we're all happy with the wording. Marking as RTBC, great work :)

The discussion around whether to stay with Block types or go with Block content types has not yet concluded, and whichever we choose will result in updates to the merge request.

It’s already been changed to block content types

Usability review

We discussed this issue at 📌 Drupal Usability Meeting 2023-04-14 Fixed , that issue will have a link to the recording.

For the record the participants were: myself, @benjifisher, @rkoller, @BlackBamboo and @paulocs

The focus of the discussion was mostly centred around which term we should be using: Block types, Content block types or Block content types.

The recommendation is to stay with the shorter "block types". It was noted that for some users the words "content" and "types" seen together is strongly associated with content types, and so "content block types" or "block content types" could result in confusion, whereas simply "block types" ensures there is clear distinction between those and "content types".

We also noted that because the user is used to going to structure to create content or media types, which they can then use under the content area, simply referring to content block types as "block types" is enough context: as a user I can create blocks under Content therefor I can create "block types" under Structure.

"Block types" is also the shortest of the three options, and if the context is clear we can afford shorter terminology.

The group also noted that using the term "content block" on /admin/content/block is okay, as you are in the space of creating content and quite often blocks there will have a WYSIWYG text area.

We also discussed whether there could be any confusion between content blocks and blocks created by other modules (either in code or config). We observed that in the Block Layout area, when listing or placing a block, the term "Categories" is used and not "Types" to group the blocks there, and that content blocks are all grouped by a single category. We felt this created enough of a distinction between content blocks and blocks which are provided by code and config. We did note that in the Block Layout content blocks are still categories to as "custom", the group recommended changing the "custom" category to "content block".

Reverted back the changes. Changed category but they will also be using the block types when ✨ Set Block Category to Bundle in block_content module Postponed lands.

@smustgrave that's a really good flag, thanks for brining up that issue. I think it would be good, giving the context, to also bring that issue to the usability group, so I'll tag it for review. Hopefully we can prioritise it fro this coming meeting.

From what I can tell, the last piece of feedback has already been addressed in the reverts, therefore this is RTBC again.

Verified that remaining items from #29 have been addressed, removing that from remaining tasks

grep -iEr "custom( |_)block" core|grep -v node_modules|grep -vE "d6\_|d7\_"|grep -v 'create and edit custom blocks'
core/modules/forum/tests/fixtures/drupal7.php:  'page_arguments' => 'a:3:{i:0;s:25:"block_custom_block_delete";i:1;i:4;i:2;i:5;}',
core/modules/block_content/block_content.post_update.php: * Moves the custom block library to Content.
core/modules/block_content/block_content.post_update.php:function block_content_post_update_move_custom_block_library() {
core/modules/block_content/tests/src/Functional/Update/BlockContentUpdateTest.php:   * @see block_content_post_update_move_custom_block_library()
core/modules/block_content/tests/src/Functional/Update/BlockContentUpdateTest.php:    $this->assertSession()->pageTextContains('Custom blocks');
core/modules/block_content/tests/src/Functional/Update/BlockContentUpdateTest.php:    $this->assertSession()->pageTextContains('Custom block library');
core/modules/block_content/tests/src/Functional/Update/BlockContentUpdateTest.php:   * @see block_content_post_update_move_custom_block_library()
core/modules/block_content/src/Plugin/migrate/source/d6/BoxTranslation.php:  const CUSTOM_BLOCK_TABLE = 'boxes';
core/modules/block_content/src/Plugin/migrate/source/d7/BlockCustomTranslation.php:  const CUSTOM_BLOCK_TABLE = 'block_custom';
core/modules/block_content/src/Plugin/migrate/source/d7/BlockCustomTranslation.php:    $query = $this->select(static::CUSTOM_BLOCK_TABLE, 'b')
core/modules/migrate_drupal/tests/fixtures/drupal7.php:  'page_arguments' => 'a:3:{i:0;s:25:"block_custom_block_delete";i:1;i:4;i:2;i:5;}',
core/modules/tracker/tests/fixtures/drupal7.php:  'page_arguments' => 'a:3:{i:0;s:25:"block_custom_block_delete";i:1;i:4;i:2;i:5;}',

These are either migrate or update hooks, so all good.

All items resolved in the MR so removing that from IS too

Updating issue credits

Didn't mean to change status

Committed and pushed to 10.1.x, huge effort folks

See you in the other issues in the meta or 🐛 Hook help for block content module is out of date after new permissions Needs work

Updated change record.

We need to make documentation updates on Drupal.org, I'll go propose some now.

larowlan → closed merge request !3612

Updated the two docs pages on Drupal.org

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

benjifisher → credited BlackBamboo → .

benjifisher → credited paulocs → .

I am belatedly adding credit for the participants in the 2023-04-14 usability meeting. (See Comment #44.)