Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
BlockContentType entity has hard-coded routes in block_content.routing.yml
We can make use of a route provider that was added later on and remove the hard-coding
Proposed resolution
Use a route provider
Remaining tasks
Patch
Get tests green
Profit
User interface changes
Breadcrumb updated on child pages of 'admin/structure/block/block-content/manage/basic' to include the word Edit as per standard entities.
API changes
None
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#5 | interdiff.txt | 794 bytes | darvanen |
#5 | block-content-type-route-provider-2919890-5.patch | 3.31 KB | darvanen |
Comments
Comment #2
larowlanComment #3
tstoecklerThanks for getting the ball rolling on this effort again! Adding parent issue.
Comment #4
darvanenI'm expecting this patch might fail a Breadcrumb test the way #2919891: Make Vocabulary use a route provider instead of hard-coded routes did when "Edit " was added to the breadcrumb, hopefully that's the only one.
Comment #5
darvanenAs I suspected. This should fix it.
Comment #6
larowlanUnless bot disagrees, I think this is good to go.
Thanks @Darvanen
Comment #8
xjmSomething that makes me hesitate on issues like this is that it's getting harder and harder to figure out where a page is coming from. Previously I could grep for the path in routing files, find the route, and then grep for its callback or default or whatever.
The dynamic route generation is probably still much better DX because there's less boilerplate, but do we have a strategy for documenting this or helping people figure out what code in their codebase is providing the page they're looking at? There doesn't seem to be anything about route providers on the routing API documentation page which was probably missed docs gate for the issue that added
Drupal\Core\Entity\Routing\AdminHtmlRouteProvider
. That was #2578955: Implement auto route generation but DON'T use it for all core entities, just before release, and it looks like it updated the entity section of the handbook rather than the routing section.Leaving RTBC because this concern isn't in this issue's scope, but maybe we should file a followup that adds a brief paragraph to the routing page linking the entity page?
Comment #9
xjmAre the routes still the same with the new route provider?
Comment #10
darvanenYes, they're defined in the annotations.
* links = {
* "delete-form" = "/admin/structure/block/block-content/manage/{block_content_type}/delete",
* "edit-form" = "/admin/structure/block/block-content/manage/{block_content_type}",
* "collection" = "/admin/structure/block/block-content/types",
* },
I have also eyeballed them and they're definitely the same.
Odd how add-form isn't there though, and edit-form wasn't in the yaml file either.
I agree with you re documentation - I wouldn't have known where to start looking on this without a pointer from @larowlan
Comment #13
tstoecklerOpened #2939755: Expand routing.api.php to include route subscribers and entity route providers for the followup.
Re #9: Yes, the routes are the same but for minor changes in the title which we have decided in related issues that are actually positive as they lead to more consistency across the entity types.
Will send for a re-test as I don't think the test failure is related.
Comment #14
tstoecklerComment #15
larowlanAdding review credits for @tstoeckler and @xjm
Comment #17
larowlanThanks for creating the follow-up for documentation/discovery.
In training new staff, I've been directing them to the annotation for the documentation of the URIs.
The intent of this issue and others in the meta is to standardise on that.
At present we have a mix of routing.yml and annotations.
The later is better DX, so I believe standardising on that is the preferred approach.
Committed as 429d9c6 and pushed to 8.6.x.