Move block content edit and delete routes under admin/content/block to improve IA for editors and fix breadcrumbs

@benjifisher: Would it not still be "[PP-1]" though, since this issue is only postponed on one issue. If the "[PP-N]" in issue titles started tracking all the issues postponing the issues that the issue is postponed on, I could see that getting confusing fast. (I realise that was probably a bit hard to parse, hopefully you get what I mean)

I think we can action this now

Updated remaining tasks now that this is no longer postponed.

Actually think this could be closed. Appears to already be fixed.

for the revisions tab it seems fixed by this issue 🐛 Breadcrumb for local tasks of Custom Blocks should contain the name of the custom block not the entity ID Fixed but the edit tab of a block still only contains the home link in the breadcrumb - the current page of the custom block is missing.

FYI the solution should probably be generic as I see the same behavior for media items.

The proposed solution is less about making changes to the breadcrumb, and more about changing the path of block content entities to sit under the block content library, thereby also making the breadcrumb more useful.

That would also have to be generic I think. We don't do that for media or content.

If we changed the URL to be /block/1/edit though vs just /block/1 when editing that may fix the breakcrumbs but think the issue is we don't have a view route like we do for nodes.

I am assigning this issue to myself and working on it today. After 3 days, feel free to re-assign it if I forget to.

At first I considered updating paths like /block/add as part of this issue. I still like the idea, but it is out of scope for this issue and should be done at the same time as other entity types. Maybe someone already said as much.

I was also a little worried about using the path /admin/content/block-content/{block_content} because there is no fixed part after /admin/content/block-content. What if we do eventually change the path of the block-add form, and someone uses add for {block_content}? Then I noticed the condition block_content: \d+ and I stopped worrying.

3772 is ready to review.

Surprisingly, I updated only one line in the tests. It helps to search for /block/ that is not preceded by admin/structure and to ignore fixtures.

I am worried that we should add a redirect for /block/{block_content}/translations. This may also be a problem for 📌 [PP1] Move "Block layout" from Structure to Appearance Postponed .

Since ✨ Add Block Content revision UI Fixed was already fixed, I update the revision paths in the entity annotations and the update function. I think it is OK to update the update function because it is not yet part of a release. It might cause a little trouble for those of us who work with 10.1.x regularly. We might also update the screenshots in the change record for that issue → . I do not see any reference to the path, but the breadcrumbs are visible in the screenshots.

I notice that the block ID, not the title, shows up in the breadcrumb for the delete form and the translations page. In order to manage scope, I do not plan to do anything about it for this issue.

I’m not sure how this works, can’t see the code, and I’m on my phone, but just wanted to add that /admin/structure is not a guaranteed path since there are modules that can rename the admin path → . I maintain a site where the previous developer used it to rename it from /admin/ to /backend/ presumably because the previous non-Drupal site used that path.

@dalemoore:

Thanks for pointing that out.

I had a quick look at that module. From the description (project page and README) and the event subscriber, it looks as though it works by altering routes. I am pretty sure that the changes here will "play well" with that module.

Example: assume that module is configured to change admin to backend

Before this issue, the entity.block_content.edit_form route has the path /block/{block_content} (for example, /block/17). The module would not change it.

After this issue, the entity.block_content.edit_form route has the path /admin/content/block-content/{block_content}. The module would change it to /backend/content/block-content/{block_content}.

Sounds great! I wasn’t worried since this (D7) site will be merged into our new D10 site but figured I’d pop in and advocate for those who do use it just in case. Thanks!

Can the issue summary be updated as well? Seems to be changing the route to something else from the proposed solution.

After hacking the tests to figure out why they were failing, I rebased and force-pushed to simplify the git log.

I am updating the issue summary. I think that I implemented what was intended, but the proposed resolution was not very explicit.

I am making some further changes to the issue summary. The first line of the "Proposed resolution" section was

The Custom Block Entity Route paths will be changed from /block/ to /admin/content/block/.

Before ✨ Move Custom block library to Content Fixed , the "Custom block" list at /admin/content/block-custom was the "Custom block library" at /admin/structure/block/block-content. The line here was either a mistake or a guess as to where the page would end up.

I am fixing that line and changing "Custom block library" to "Custom block" list. The parts in quotation marks are the page titles.

We also have the renaming ticket where I think we are changing the page to Block Content

I added 🐛 Create BC redirects for children of changed paths Fixed . In order to manage scope, I would like to handle redirects for child pages in that issue, not this one. (If that issue is fixed first, then it should be easy enough to handle the redirects in this issue.)

I would like to get this issue done in time for 10.1.0-alpha1 because the path changes are disruptive and because this issue updates an update function. I think it is all right if the redirects for child paths are added later. Another reason to handle these redirects in a separate issue is that we already have child paths that need redirects after 📌 Move custom block types admin link to admin/structure Fixed .

I am adding screenshots to this issue, and I will add them to the change record. I already updated the text part of the change record.

The MR already includes new tests and fixes old ones. I am removing the tag for needing tests.

Applied the MR locally.

Couldn’t get the update hook to run without changing the number to 10201.

After the update ran, cleared cached and all the breadcrumbs appear to match the screenshots in the issue summary.

The update hook does not have to work from one version of 10.1.x to the next, until we get to the alpha release of 10.1.0. In fact, we might not guarantee an upgrade path until the beta release.

That is why I have been saying that the update-update is a reason to get this issue done before the alpha release.

If you want to test the upgrade path, then

1. Check out some version of Drupal 10.0 (such as 10.0.x or 10.0.7).
2. composer install
3. Install Drupal.
4. Check out the branch for this issue from the issue fork.
5. composer install
6. Execute update functions (drush updatedb or visit update.php in a browser).

As brought up in the slack channel #block-content with you, me, and @larowlan this should be able to run on 10.1.x also.

Re comment #60:

The Custom Block Entity Route paths will be changed from /block/ to /admin/content/block/.

Before ✨ Move Custom block library to Content Fixed , the "Custom block" list at /admin/content/block-custom was the "Custom block library" at /admin/structure/block/block-content. The line here was either a mistake or a guess as to where the page would end up.

When I originally wrote the issue summary, I wrote it with the assumption that by the time we got to this issue, the path would end up being /admin/content/block, the change from /admin/content/block-custom to /admin/content/block looks like it is being done as part of 📌 Rename Custom Block terminology in the admin UI Fixed . So if that gets committed first, we can then update the IS again.

Looking at the MR here, I think we should postpone this issue on 📌 Rename Custom Block terminology in the admin UI Fixed , given that issue is changing the block content overview path, I think it makes more sense to get that one committed, then update this issue with the updated path.

Now that 📌 Rename Custom Block terminology in the admin UI Fixed is fixed, I have updated the MR, so this issue is again ready for review.

Re Comment #67: #3318549 already updated the update function, so I think it is OK to do it again in this issue, as long as we get this issue fixed before 10.1.0-alpha1.

Going to mark this as I did a fresh install with the changes already applied and the breadcrumbs are working much better then before.

One minor question regarding the duplicate route.

Tagging as a 10.1 should have. Not the end of the world, but ideally.

Adjusting title to reflect the resolution

Test appear green so assuming the duplicate just wasn't needed.

Committed to 10.1.x and updated the change record

I updated the release notes for this (but neglected to mention above)

Awesome to see this get committed!

But also because it now opens up the possibility of looking at this for other entity types (taxonomy, media, etc) where there's a strong case for making the path and breadcrumb work in the admin UI, while also not breaking the breadcrumb for other accessing those entity types on the front-end. That's a much harder problem to crack, this was definitely the low hanging fruit one!

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