Move custom block types admin link to admin/structure

I'm working on it. I think it's a good idea for novice users of Drupal.

Made and reviewed.

I wish it's what you wanted, @Chris2

The block_content module also different custom block types. So the menu item should be moved there.

I am glad found this issue!!

In #2957425: Allow the inline creation of non-reusable Custom Blocks in the layout builder we will be using custom blocks directly in the layout builder. They will not be part of the "library" in a sense that you won't

+++ b/core/modules/block/block.links.menu.yml
@@ -3,3 +3,9 @@ block.admin_display:
+  route_name: block_types.admin_display

+++ b/core/modules/block/block.routing.yml
@@ -84,3 +84,13 @@ block.category_autocomplete:
+
+block_types.admin_display:
+  path: '/admin/structure/block/block-content/types'
+  defaults:
+    _controller: '\Drupal\block\Controller\BlockListController::listing'
+    _title: 'Block types'
+  requirements:
+    _permission: 'administer blocks'
+
+

It we don't need a new route but just can point menu item to the existing route...

Hmm that route is create dynamically because \Drupal\block_content\Entity\BlockContentType in it's annotation sets the path for collection for links.
But I think can still point to that route once we figure out what it is.

See also #2862564: Move Custom block library to Content

I will be working on this.

I've addressed #2 and #6 by fixing typo, moving the new link to block content module and using the existing route. There is no interdiff because it differs to much from the first patch.

The menu item name from my last patch was not suitable so I've changed it.

Reviewing the issue for DrupalEurope

Did a manual test, looks exactly as in the proposed resolution.

Patch looks good. Link tekst and description are according to issue summary and consistent with content type link.

Adding screenshot of the new link.

This means that there are two ways to get to the same place within the same hierarchy.
And it's a different place than proposed in #2862564: Move Custom block library to Content.

Perhaps that part needs more discussion?

#15 makes me think we need more review before committing.

Custom blocks are "now" content entities with types similar to node types. As a newbie I would expect menu links for creation of custom block types next to node, comment and media types.

The current link as a tab under block layout is quiet hard to find and also suggests, that custom blocks are only usable for block layout. But this is not true. E.g. the new layout builder also allows you to use custom blocks based on those types. For me this wasn't obvious although layout builder also uses the term "block".

I agree, that there should be only one way to get to the same place within the same hierarchy. This way should be the short and content type consistent one via "Structure" > "Block types". The problem is, that users are used to the current circuitous way. If we remove that one, users might think that custom block types are gone or at least will be surprised by this UI change. That's why I vote for two ways to get to custom block types (kind of backward compatibility) till #2862564: Move Custom block library to Content is resolved.

1. Removed the no longer necessary local tasks and added the new admin menu link under site structure as done at #11
2. Changed the block types base admin path from "admin/structure/block/block-content/types" to "admin/structure/block-content"
3. Module help reviewed
4. Tests updated, but no new tests added

Wrong path prefix on previous patch.

@manuel.adan Could you please provide an interdiff to the last patch (#11)? I don't understand why there are so many changes. On which comment/issue is your patch based on? #15 and #16 suggested some discussion about a possible solution of this ticket. Unfortunately this didn't happened yet (besides my 2cents in #17).

The 5 lines patch from #11 just adds a link to the structure menu, so I thought that an interdiff was not necessary in this case. I briefly explain the purposed changes at #19, but I go in more detail.

In addition to the new link, I propose two additional changes in attention to the following background:

1. From #15:

   ...there are two ways to get to the same place within the same hierarchy

   From #17:

   ...As a newbie I would expect menu links for creation of custom block types next to node, comment and media types

   So I removed it from its current location (Block layout -> Custom block library -> Block types) in favor of the new link at Structure -> Custom block types.

2. From the summary:

   ... the following admin links are easily accessible at /admin/structure:

   Comment types (/admin/structure/comment)
   Content types (/admin/structure/types)
   Media types (/admin/structure/media)

   If the Block content types admin page will be now at Admin -> Structure, its URL should follow the same schema as the other similar items, so I changed it from /admin/structure/block/block-content/types to /admin/structure/block-content

Only one thing remains:

...The problem is, that users are used to the current circuitous way. If we remove that one, users might think that custom block types are gone or at least will be surprised by this UI change

Totally agree. At the Block layout (/admin/structure/block) we can add some additional help text with an indication about the current location of the custom block library, that would be useful for new as well as existing Drupal users.

Finally, about #2862564: Move Custom block library to Content, it is tight connected to this, actually I was working on it as well. None of both block the other, but I thing both issues should go within the same Change Record.

The patch in #20 no longer applies cleanly to 8.9.13.

I think this is something that really should be done. With Layout Builder in core, I bet for most new sites, the primary use of Block Types has nothing at all to do with anything else you can access in the Block Layout menu. Hiding Block Types like this discourages new developers from using them and probably leads to inefficient architectural decisions. This is a real shame because they are so powerful when used in conjunction with Layout Builder.

The patch in #20 doesn't apply cleanly to 9.2.
Needs reroll.

Re-roll patch #20
please review.

Patch #29, added a Custom block type menu in the structure.

Adding screenshot for reference.

2987964-29.patch has been queued for custom testing.

Applied #29 patch working fine now we able to see custom block type in admin/structure sharing screenshot ....

Verified and tested patch #29.
The patch is not applied successfully and not working as expected.
Needs to be Re-roll.

Testing Steps:
# Goto: Appearance -> Apply Seven theme
# Goto: /admin/structure

Expected Results:
# User should see the default "Custom Block types" link.

Actual Results:
# Currently, the User is not able to see the default "Custom Block types" link.

Please refer attached screenshots for the same
Not working as expected.
Can be a move to Needs Work.

Rerolled 29
Fixed some broken test cases also.

Small tweak.

I've successfully applied the patch in #43 to a Drupal 10.1.0-dev install. Everything looks and works fine.

The only potential problem I see is the proximity of Block layout and Custom block types. I like the fact that Custom block types got moved to the same menu level like Content types, Comment types, and Media types. But due to the prepended word custom and the alphabetical sorting you have Block layout on top of the list then four other menu items and then Custom block types.

I wonder if it would make sense to rename it to just Block types? Cuz without the patch applied on /admin/structure/block/block-content/types the page title is Custom block library but the title of the tab is only Block types. That title admin_toolbar is using as well.

Block types would have a better readability. If a person is scanning for block the word custom has to be processed while with just Block types it would be easier to comprehend. I am not that long into Drupal so I am in lack of the evolution and historic background of the feature but are there also "regular" block types if there are custom block types?

And like #2862564: Move Custom block library to Content this issue might also need a follow up for admin_toolbar.

Fully agree with that. We don't call "Media bundles" "Custom Media Bundles"

Uploaded a new patch with those changes.

Test fix.

I am making this issue a child of #3318110: [meta] Reorganize Block items in the administration menu so that it will be grouped with #2862564: Move Custom block library to Content.

I've applied the patch in #47. In regards of the name change to Block types I've found a few more Custom block type occasions in the block type interface:

• The button label + Add custom block type at /admin/structure/block-content.
• On the edit page of a block type the h1 page title has custom block type appended.
• If multilingual modules are installed then you have the local task translate custom block type.

I've also searched for custom block type in vscode and that had a few more additional results. but sure if all of those would have to be adjusted as well :/

Replaced all Custom block type references with block type

Cool! thank you for the updated patch in #50. I can confirm that the three points I've listed in #49 got updated and fixed and the number of search results searching for Custom block type in VSCode got reduced dramatically as well.
The only two places I am still able to find the old string, are the project_data.json for project browser, which is currently in contrib, and the drupal-10.x.de.po file which is the translations file for the german localization, that got downloaded when the second language got added (before the patch got applied). So all occasions of Custom block type got catched now. looks good to me. i'll leave the status at needs review so others could do a code review.

When Body layout gets moved out of Structure in #3318112: [PP1] Move "Block layout" from Structure to Appearance, it might be worth to consider to change the route to the Block type page from https://drupal101.ddev.site/admin/structure/block-content to https://drupal101.ddev.site/admin/structure/block. That way it would be consistent with pages like content type or media type.

patch #43 is probably the one we want now as it doesn't rename.

@rkrolller can you confirm #43 is what we want now. It doesn't do any renaming.

sorry for the delayed reply. quickly applied #43 and can confirm that in there none of the renaming took place yet. so i agree that this should be the desired one.

#43 patch applied and working fine for me. Thanks for the patch @smustgrave

Reviewing patch in #43.

1. --- /dev/null
   +++ b/core/modules/block_content/block_content.links.menu.yml
   @@ -0,0 +1,5 @@
   +block_content.block_content_type.collection:
   +  title: 'Custom block types'
   +  parent: system.admin_structure
   +  description: 'Create and manage fields, forms, and display settings for your custom blocks.'
   +  route_name: entity.block_content_type.collection
   

   The link name should be entity.block_content_type.collection to match the route name.

2. Users with the <em>Administer blocks</em> permission can create and edit custom block types with fields and display settings, from the <a href=":types">Block types</a> page in the site Structure.

   I would change that last part to simply say under Structure or under the Structure menu, something about "in the Site structure" doesn't quite sound right.

3. Users with the <em>Administer blocks</em> permission can create, edit, and delete custom blocks of each defined custom block type, from the <a href=":block-library">Blocks</a> page in the Custom block library

   The end of this sentence can now be shortened as there is only one tab for the custom block library, something like from the <a href=":block-library">Custom block library</a>.

4. The Block types Collection has this text at the top of the page Each block type has its own fields and display settings. Create blocks of each type on the Blocks page in the custom block library.

   None of the other collection pages under structure have any text at the top, so in the interest of consistency, neither should this collection.

Also filed this issue about the add route #3319145: [PP-1] Provide a "add" link template for the block_content_type entity type

Fixed colon issue.

Looks good, also updated the issue summary.

Haven't reviewed the patch but a big +1 to this. Also happy we're dropping the word "custom".

I'm wondering if we should update the issue title and/or summary with that detail? Also should we consider a change record?

Yes, this issue needs a change record (CR). I just added a stub CR, and I would like to use it for this issue and its siblings (the children of #3318110: [meta] Reorganize Block items in the administration menu). I am also adding the tag for updating the CR.

I notice that the patch in #61 updates the text in block_content_help(), but I do not see any updates in the help_topics module. Maybe only block_content.type.html.twig needs to be updated. It should be pretty easy to enable help_topics and review all the topics related to blocks. It would be helpful to add notes to the sibling issues at the same time.

I would also like to see the required changes to help text summarized in the "Proposed resolution" section of the issue summary. I am adding the tag for a summary update.

I am adding tags for the required approvals.

Think this will be a great feature that will make blocks more usable for the user. So stamp of approval

Please take a look at the following Help Topics which I think will need to be updated with this change:

1. Defining a custom block type (the breadcrumbs) - core/modules/help_topics/help_topics/block_content.type.html.twig
2. Creating a custom block (step 1) - core/modules/help_topics/help_topics/block_content.add.html.twig

Thanks!

Updated based on #69

Updated CR but think it was agreed upon that all the issue in the meta will be included in that CR. So added a small note based on just this ticket

I took a look at the interdiff in #70 and I can see I was unclear in my comment.

What I meant is that:

1. In the Help Topic, "Defining a custom block type" (core/modules/help_topics/help_topics/block_content.type.html.twig), the breadcrumbs need to be updated to reflect the new location of the custom block types page.
2. In the Help Topic, "Creating a custom block" (core/modules/help_topics/help_topics/block_content.add.html.twig), step 1 needs to be updated to reflect the new location of the custom block types page.

Updated. Sorry case of the Mondays

I reviewed the patch in #72 as follows:

1. Installed Drupal 10 from a fresh clone of the 10.1.x branch
2. Applied the patch from #72
3. Installed Help Topics experimental core module
4. Cleared the cache for good measure
5. Using the Manage administrative menu, navigated to Structure (admin/structure)
6. Verified that the menu item "Custom block types" appears in the list of links+descriptions on this page
7. Clicked on the listed menu link, "Custom block types" and the page appears as normal
8. Created a test block with "create a new revision" unchecked -- this appears to work as normal
9. Created a test block with "create new revision" checked -- this appears to also work as normal
10. Using the Manage administrative menu, navigated to Help
11. Under the section, "Module Overviews", clicked on the link, "Custom Block"
12. Verified the instructions for adding and configuring a custom block accurately reflected the changes in this patch
13. Clicked on every link on the Custom Block module overview and verified they all work
14. Navigated to the main Help page
15. Under the section, "Help Topics", clicked on "Managing blocks"
16. On the help topic, "Managing blocks", under the heading, "Related topics", clicked on "Creating a custom block"
17. On the help topic, "Creating a custom block", verified the steps (specifically step 1) reflected the new location of the "Custom block layout" page
18. On this same page, under the heading, "Related topics", clicked on "Defining a custom block type"
19. [NEEDS WORK] On the help topic, "Defining a custom block type", step 1 is not correct.

2 changes needed on core/modules/help_topics/help_topics/block_content.type.html.twig:

1. Line 12 of core/modules/help_topics/help_topics/block_content.type.html.twig:

{% set types_link_text %}{% trans %}Block types{% endtrans %}{% endset %}

Change to:

{% set types_link_text %}{% trans %}Custom block types{% endtrans %}{% endset %}

2. Line 18 of core/modules/help_topics/help_topics/block_content.type.html.twig:

  <li>{% trans %}In the <em>Manage</em> administrative menu, navigate to <em>Structure</em> &gt; <em>Custom block library</em> &gt; <em>{{ types_link }}</em>.{% endtrans %}</li>

Change to:

  <li>{% trans %}In the <em>Manage</em> administrative menu, navigate to <em>Structure</em> &gt; <em>{{ types_link }}</em>.{% endtrans %}</li>

Note:: To see this change, you will need to clear/rebuild caches.

Addressed issues in #73

Update to my review in #73, line 9 in core/modules/help_topics/help_topics/block_content.add.html.twig needs to be changed so that the link title matches what is on Structure (admin/structure) with the patch applied.

Change to:

{% set library_link_text %}{% trans %}Custom block types{% endtrans %}{% endset %}

I'm sorry I missed this in my previous review.

Addressed #75

Thanks @smustgrave for the new patches and working with me here!

I've reviewed the patch in #76 as follows:

1. Installed Drupal 10 from a fresh clone of the 10.1.x branch
2. Un-applied/reverted previous patches
3. Cleared all caches
4. Applied the patch from #76
5. Ensured Help Topics experimental core module was installed
6. Requested re-index of search index
7. Ran cron
8. Checked that 100% of search index was completed
9. Navigated to Help and using the Help search field, searched for "custom block library" (the previous term) and there were no results
10. Using Help's Search, searched for "custom block types" and there were 4 results, including the 2 changes in the latest patches which updated the steps to change link titles from "Custom block library" to "Custom block types".
11. Using the Manage administrative menu, navigated to Structure (admin/structure)
12. Verified that the menu item "Custom block types" appears in the list of links+descriptions on this page
13. Clicked on the listed menu link, "Custom block types" and the page appears as normal
14. Created another test block with "create a new revision" unchecked -- this appears to work as normal
15. Created another test block with "create new revision" checked -- this appears to also work as normal
16. Using the Manage administrative menu, navigated to Help
17. Under the section, "Module Overviews", clicked on the link, "Custom Block"
18. Clicked on every link on the Custom Block module overview and verified they all work
19. Verified the instructions for adding and configuring a custom block accurately reflected the changes in this patch
20. [NEEDS WORK] On the Custom block library page (admin/structure/block/block-content), In the view of custom blocks, the no results text needs to be updated so that there is a grammatical space between the 2 sentences. Right now it displays There are no custom blocks available.Add a custom block.
21. Navigated to the main Help page
22. Under the section, "Help Topics", clicked on "Managing blocks"
23. On the help topic, "Managing blocks", under the heading, "Related topics", clicked on "Creating a custom block"
24. On the help topic, "Creating a custom block", verified the steps and link titles reflected the new location of "Custom block layout" and the correct menu link title
25. On this same page, under the heading, "Related topics", clicked on "Defining a custom block type", verified that the steps and link titles reflected the new location of "Custom block types" and the correct menu link title

So there is 1 thing that needs work still:

[NEEDS WORK] On the Custom block library page (admin/structure/block/block-content), In the list of custom blocks, the no results text needs to be updated so that there is a grammatical space between the 2 sentences. Right now it displays There are no custom blocks available.Add a custom block..

So just tested and I'm not seeing that?

Looking at this again, I think that nitpick of mine (in #77) is out of scope for this issue. It doesn't look like any of the code in the patch affects that view of custom blocks, just the routing of that page and the ripple effects of changing its location in various places. (So, I won't upload a screenshot for that reason.)

I think this is ready for a product manager to take a look.

For the reasons stated in #77 and #79, I think this is RTBC.

Re #77 and #79, those updates might be in scope for #2862564: Move Custom block library to Content.

For #77.20, I already opened #2965817: Missing space between sentences on the Custom Block page, which was closed as a duplicate of #3095893: Remove duplicate "add block" link from block content type view's "Results not found" message.

Either way, I agree that it is out of scope for this issue.

@AaronMcHale - Thank you for clarifying!

If I'm understanding correctly, this issue's changes affect just 1 help topic, "Defining a custom block type" (core/modules/help_topics/help_topics/block_content.type.html.twig).

Changes to core/modules/help_topics/help_topics/block_content.add.html.twig should not included in a patch for this issue. But should be included in #2862564: Move Custom block library to Content.
Edit: If the location of the Custom block library page changes in #2862564: Move Custom block library to Content, then this help topic's navigation instructions would need to be updated as well.
I've updated the issue summary.

Removed the change to block_content.add.html.twig

Applied the patch #84 and it is working fine.

Looks like the patch in #84 is the same as the RTBC patch in #61, with the only difference being the minor change to help topics to point to the new location for the Block Type Collection.

Given that, setting back to RTBC.

Hiding unnecessary screenshots.

Updating issue credits, removed @trackleft2 as their branch was empty

Added credits for reviews that changed the patch and those on the UX team who've played a big role behind the scenes here

1. +++ b/core/modules/block_content/block_content.module
   @@ -36,10 +36,6 @@ function block_content_help($route_name, RouteMatchInterface $route_match) {
   -    case 'entity.block_content_type.collection':
   -      $output = '<p>' . t('Each block type has its own fields and display settings. Create blocks of each type on the <a href=":block-library">Blocks</a> page in the custom block library.', [':block-library' => Url::fromRoute('entity.block_content.collection')->toString()]) . '</p>';
   -      return $output;
   

   I can't see anything above explaining why this was removed - was it intentional?

2. +++ b/core/modules/block_content/tests/src/Functional/BlockContentCreationTest.php
   @@ -111,10 +111,9 @@ public function testBlockContentCreationMultipleViewModes() {
        $this->clickLink('Manage display');
   -    $this->drupalGet('admin/structure/block/block-content/manage/basic/display');
   +    $this->drupalGet('admin/structure/block-content/manage/basic/display');
   

   I know we didn't introduce this here, but I think this effectively making two requests to the same url?

   One with ::clickLink and another with ::drupalGet - I think we can remove the ::clickLink one?

Setting to NR for the first item.

I've pinged product managers in slack to hopefully get their approval so we can remove that tag.

Thanks for all the work here everyone, excited this is close.

Do we have an existing issue for making the 'redirect to place block form when block content is added' optional - as that's another odd UX issue with block content

Addressed #89.2

For #89.1 please the reason it was removed was for consistency. The media types and content types pages don't have a description.

small tweak to the test. Saw it was 2 drupalGet() back to back.

Seems random unrelated failure

Applied patch #43 and working fine.

I think this is ready

I've pinged product managers but haven't had a response.

There's buy in here from the UX team.

Regarding the removal of the help text, I have filed #3325034: Providing additional methods of navigating the admin interface based on discussion at #3323771: Drupal Usability Meeting 2022-12-02, as it's clear we need a more holistic pattern for deep-linking between related parts of the admin UI.

random ckeditor failure.

Discussed this with @xjm in slack.

This already has UX team sign-off, the conditions for needing product manager sign-off are:

If the change represents a significant new feature, UI change, or change to the "user experience" of the project, the product managers must approve or refuse it.

(from https://www.drupal.org/contribute/core/maintainers)

Since the change is just bringing the menu item in line with patterns for other entity types, I don't think that's signfiicant enough to require product manager sign-off, so I am going to go ahead and untag this.

I haven't yet reviewed the issue to be able to commit it myself though so leaving RTBC.

I am updating the Proposed resolution in the issue description to be a little more complete: we are changing the path as well as the menu links. I am also being a little more generic, removing the specific Help Topics file that gets updated.

I have a couple of questions about the changes to BlockContentType.php:

- *   label_collection = @Translation("Custom block library"),
+ *   label_collection = @Translation("Custom block types"),

What page does that affect?

I think it is a good idea to update page titles as part of this issue and its siblings, unless we already decided to do that in separate issues. I do not have time to figure it out myself, but I think that the Block Types page is currently a tab on the Custom Block Library, so it has the same title, and this change fixes that. If that is correct, then let's add that to the issue summary.

+ *     "delete-form" = "/admin/structure/block-content/manage/{block_content_type}/delete",
+ *     "edit-form" = "/admin/structure/block-content/manage/{block_content_type}",
+ *     "entity-permissions-form" = "/admin/structure/block-content/manage/{block_content_type}/permissions",
+ *      "collection" = "/admin/structure/block-content",

That looks like an indentation error on the last line, so back to NW. I am adding the Novice tag for this change. Please remove the tag when you post an updated patch.

Setting back to NW per the previous comment.

It was agreed upon to address the renaming in separate tickets. https://www.drupal.org/project/drupal/issues/3318549 or https://www.drupal.org/project/drupal/issues/3318558

If that is what you are referring to?

Fixed indentation

@quietone, thanks for updating the issue status when I forgot to.

@smustgrave:

As we discussed on Slack, I was asking about the change I quoted in #100. I now have more time, and I have confirmed that it affects the page title (the title rendered as an H1 element) of the page now at /admin/structure/block-content. The sibling issue #3318549: Rename Custom Block terminology in the admin UI deals with the custom block library, not with this page.

I am updating the issue summary to mention the page title.

I am adding screenshots of the Custom block library before and after the patch, to show that the second-level tabs are removed.

I had a closer look at the patch, and it needs more work.

1.

+++ b/core/modules/block_content/block_content.module
@@ -26,9 +26,9 @@ function block_content_help($route_name, RouteMatchInterface $route_match) {
...
-      $output .= '<dd>' . t('Users with the <em>Administer blocks</em> permission can create, edit, and delete custom blocks of each defined custom block type, from the <a href=":block-library">Blocks</a> page in the Custom block library. After creating a block, place it in a region from the <a href=":blocks">Block layout</a> page; see the <a href=":block_help">Block module help</a> for more information about placing blocks.', [':blocks' => Url::fromRoute('block.admin_display')->toString(), ':block-library' => Url::fromRoute('entity.block_content.collection')->toString(), ':block_help' => Url::fromRoute('help.page', ['name' => 'block'])->toString()]) . '</dd>';
+      $output .= '<dd>' . t('Users with the <em>Administer blocks</em> permission can create, edit, and delete custom blocks of each defined custom block type, from the <a href=":block-library">Blocks</a> page in the Custom block library. After creating a block, place it in a region from the <a href=":block-library">Custom block library</a>.', [':blocks' => Url::fromRoute('block.admin_display')->toString(), ':block-library' => Url::fromRoute('entity.block_content.collection')->toString(), ':block_help' => Url::fromRoute('help.page', ['name' => 'block'])->toString()]) . '</dd>';

There are two links in that line, and the wrong one is updated. We want to change from "... the Blocks page in the Custom block library" to "... the Custom block library", since there is no longer a second-level tab labeled "Blocks". We do not want to change the link to the Block layout page. I do not think we want to remove the link to the Block module help.

This is hard because hook_help() requires us to paste together strings. That is one of the reasons we are switching to the Help Topics module.

2.

+++ b/core/modules/block_content/block_content.module
@@ -36,10 +36,6 @@ function block_content_help($route_name, RouteMatchInterface $route_match) {
...
-    case 'entity.block_content_type.collection':
-      $output = '<p>' . t('Each block type has its own fields and display settings. Create blocks of each type on the <a href=":block-library">Blocks</a> page in the custom block library.', [':block-library' => Url::fromRoute('entity.block_content.collection')->toString()]) . '</p>';
-      return $output;
-

Why are we removing this help text? Again, I think we should replace "Blocks page in the custom block library" with "Custom block library" since there is no longer a second-level tab labeled "Blocks".

3.

The first paragraph ("About") on /admin/help/block_content is unchanged:

The Custom Block module allows you to create and manage custom block types and content-containing blocks from the Custom block library page. Custom block types have fields; see the Field module help for more information. Once created, custom blocks can be placed in regions just like blocks provided by other modules; see the Block module help page for details. For more information, see the online documentation for the Custom Block module.

It used to be that both block types and "custom" blocks were managed by Custom block library and its descendant pages. Since that is no longer true, we should change the first sentence to something like this:

The Custom Block module allows you to create and manage custom block types from the Block types page and content-containing blocks from the Custom block library page.

Address points 1 and 3 from #104
2 please see comments #89, #90, and #96.

@smustgrave:

Thanks for the references to previous comments. I may not have been clear about the changes to the help text.

Keeping the numbering from #104,

1. On /admin/help/block_content, the line under "Creating custom blocks" now reads,
   

   Users with the Administer blocks permission can create, edit, and delete custom blocks of each defined custom block type, from the Custom block library. After creating a block, place it in a region from the Custom block library.

   The first "Custom block library" should be a link, and the second should be "Block layout page", linking to /admin/structure/block.

2. I added a note to the issue summary.
3. On /admin/help/block_content, the first link to "Block types" is broken.

Back to NW.

@smustgrave:

Thanks for fixing those.

I am sorry I did not notice this before, but I would like one more change. On the help page, under "Creating custom blocks", the current patch removes the phrase, "see the Block module help for more information about placing blocks." That is a good change, since it already says that under "About". But if we are removing that link, then we should also remove ':block_help' from the $arguments parameter to the t() function.

If you want, make a similar change to the "About" line: remove the unused ':block-content' parameter. It was already there and unused before this issue, so it is not really in scope, but as long as we are editing that line we might want to clean it up.

@smustgrave:

Thanks for fixing those last two points.

I reviewed the code changes, and I updated the issue summary to make sure that the proposed resolution matches what the patch does. There are a few changes that are not strictly in scope, but I think they are all good and have been discussed in the comments.

I tested manually, checking

• Changes to the admin menu
• New path
• Page title
• Breadcrumbs
• Help text (both hook_help() and Help Topics)

It all looks good to me, so back to RTBC.

Added patch against #109 in 10.1.x version

I've hidden the patch in #111, as I believe #109 is already queued against 10.1.x, unless there's something I missed where we needed an additional re-roll.

Nope you are correct 109 already applied for 10.1

Thank you for the interest gunjan-rao-naik but you can check if the previous patch already applies by clicking the test/retest button. Removing credit as it’s a duplicate patch.

@gunjan-rao-naik:

If you would like some guidance on how you can help with this issue (and the related ones) then you can join us in the #block-content channel in Drupal Slack.

This is a great change! I recently rebuilt my blog on D10, and noticed how awkward the navigation for custom blocks is. Also, the voice of webchick in my head is telling me that people who aren't already Drupal-indoctrinated just think of blocks as content, so this issue plus #2862564: Move Custom block library to Content will make Drupal easier to understand.

I did wonder why we were keeping the word "Custom" despite the sensible reasons in #44 and #45 to drop the word. @smustgrave pointed out that that will be changed in #3318549: Rename Custom Block terminology in the admin UI, which is good scope management. That way, the terminology for "Custom block library", "Custom block types", etc. won't get out of sync until we are ready to change it all together.

I applied the patch, clicked around in the user interface, and made sure all the changed elements made sense. I did find one place (well two places on the same page) that we missed reverting "Block types" back to "Custom block types", on the Help page:

We will change them eventually in #3318549: Rename Custom Block terminology in the admin UI, but just in case all three issues aren't done before 10.1.0-alpha1, we should make sure the link text is "Custom block types" for now, since that matches the menu link text.

I did check Help Topics to be sure, and the text does seem to be "Custom block types" everywhere there.

Fixed the 2 instances of Block types to Custom block types. Since it's such a small change I feel comfortable moving back to RTBC.

+1for the RTBC

I reviewed the patch with git diff --color-words to carefully review the changes to the help strings and paths.

I checked to ensure there were no references to the old path or route with:

[ayrton:maintainer | Fri 13:48:56] $ grep -r 'block/block-content/manage' *
[ayrton:maintainer | Fri 13:49:19] $ grep -r 'block_content.list_sub' *

Finally, I carefully read over all the results for "Custom block library" to confirm that they were referring to the list of content, and not the block types"
[ayrton:maintainer | Fri 13:49:31] $ grep -r 'Custom block library' *

Really glad to have this change in -- onto the next issue in the meta! Committed to 10.1.x as a minor-only user interface improvement, and published the change record.

Let's consider this improvement to the information architecture (along with its sibling issues) as something we can highlight about 10.1.

Awesome to see this get committed, thanks @xjm for going through it in such fine detail.

As a reminder, the next issue to work on in this series is #2862564: Move Custom block library to Content, which is now unblocked.

I am adding an updated screenshot. I notice that the one on the issue summary shows "Custom block library" instead of "Custom blocks". I am also adding it to the change record.

And here is a screenshot showing the Custom block types page: