Rename Custom Block terminology in the admin UI

This is still blocked but wanted to get what I could ready for when #2862564: Move Custom block library to Content lands

Replaced all occurrences of custom block type with block type
Replaced all admin/content/block-content routes with admin/content/block
Changed the name of the module.

Questions
Still need an update hook for the block view but should the title of the page match the tab?
Should we replace Custom blocks with blocks or content blocks?

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

Down to one blocker now #3318112: [PP1] Move "Block layout" from Structure to Appearance

Wondering if this is actually blocked by #3318112: [PP1] Move "Block layout" from Structure to Appearance 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.

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 #3318112: [PP1] Move "Block layout" from Structure to Appearance. 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 clearer, 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.

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: [PP1] 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 #3153092: Set Block Category to Bundle in block_content module
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 #1975064: Add more granular block content permissions, 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 #3352557: [PP-1] Change the machine name of the 'create and edit custom blocks' permission

Updating remaining tasks

Everything should be addressed and I updated change record.

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

Re #34.1 the issue is #3095893: Remove duplicate "add block" link from block content type view's "Results not found" message
Re #34.2 I agree, we should expand and fix that here - note also #3352550: Hook help for block content module is out of date after new permissions
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 #3352906: Drupal Usability Meeting 2023-04-14, 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 #3153092: Set Block Category to Bundle in block_content module 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 #3352550: Hook help for block content module is out of date after new permissions

Updated change record.

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

Updated the two docs pages on Drupal.org

Fantastic to see this get in, thanks for the great work everyone 🎉

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