Reproducible with at least:
- Drupal 8.2.6
- Drupal 8.3.0-beta1 via simplytest.me
Not reproducible with:
- Drupal 7.54 via simplytest.me
Steps to reproduce:
- Structure -> Content types -> Add content type, or /admin/structure/types/add
- Enter "Rock & Roll" as name (note: machine name is rock_roll) and save
- Check the breadcrumbs at the manage fields page: /admin/structure/types/manage/rock_roll/fields
Actual result:
The breadcrumbs are shown as:
Home » Administration » Structure » Content types » Rock roll
The real human-readable name isn't being used, instead the machine name is being converted into the wrong human-readable name.
This could be very misleading: if the original name was "My content type" (machine name: my_content_type), and it is renamed to "My content type (legacy, do not use)", it will still display "My content type", possibly causing confusion with a new "My content type".
Expected result:
The breadcrumbs are shown as:
Home » Administration » Structure » Content types » Rock & Roll
Drupal 7.54 does not have this problem, it shows:
Home » Administration » Structure » Content types » Rock & Roll
Cause:
Looks like the problem is somewhere in here, getTitle isn't returning a value and the fallback creates the misleading name:
core/modules/system/src/PathBasedBreadcrumbBuilder.php:123
build()
$title = $this->titleResolver->getTitle($route_request, $route_match->getRouteObject());
if (!isset($title)) {
// Fallback to using the raw path component as the title if the
// route is missing a _title or _title_callback attribute.
$title = str_replace(array('-', '_'), ' ', Unicode::ucfirst(end($path_elements)));
}
Proposed resolution
Implement a title callback to the Node type edit form, similar to the implementation for Taxonomy vocabularies:
_title_callback: '\Drupal\Core\Entity\Controller\EntityContoller::title'
| Comment | File | Size | Author |
|---|---|---|---|
| #19 | 2855636-19.patch | 5.02 KB | idebr |
| #19 | 2855636-19-tests-only.patch | 3.96 KB | idebr |
| #16 | 2855636-16.patch | 4.71 KB | idebr |
| #16 | 2855636-16-tests-only.patch | 3.64 KB | idebr |
| #13 | After applying patch - On taxonomy.jpg | 70.35 KB | NikitaJain |
Comments
Comment #2
hugovk commentedComment #3
krknth commentedI can confirm this issue exists with Drupal 8.3. And it looks fine with latest D7 version.
Comment #4
krknth commentedThe issue is there is no title callback for those routes in Drupal 8. But Drupal 7 implementing title callback in hook_menu.
File node.module, node_menu()
Comment #5
chiranjeeb2410 commented@hugovk,
What should be done regarding this issue as of now ?
Comment #6
hugovk commentedIdeally I'd like to see the Drupal 7 implementation ported to Drupal 8, or a new one implemented if that makes more sense. But I'm not familiar enough with it to create a patch.
Would someone else be able to look into this, or give some pointers?
Comment #7
chiranjeeb2410 commentedI think '_title_callback' => '\Drupal\Core\Entity\Controller\EntityController::title' should do the trick.
Comment #8
nikunjkotechaI confirm the fix shared in #7 works. Attached patch to fix in nodes as well as custom block types. It seems working fine in Taxonomy terms.
Comment #9
chiranjeeb2410 commentedUploading patch with required changes. Should work.
Comment #10
hugovk commentedThank you chiranjeeb2410 and nikunjkotecha!
I've partially tested patches #8 and #9 and that part I've tested is working:
I manually applied the patch changes to Drupal 8.2.6 and ran
drush cr, then edited a content type. The breadcrumb shows the correct human-readable title.However, I haven't tested the fix for custom block types. How can this be tested?
Note there's a probable typo for custom block types in patch #9:
+ _title_callback: '\Drupal\Core\Entity\Controller\EntityContoller::title'Patch #8 is identical except for:
+ _title_callback: '\Drupal\Core\Entity\Controller\EntityController::title'Comment #11
Pavan B S commentedMade changes as per the suggestion in comment #10.Applying the patch please review.
Comment #12
hugovk commentedThe patch in #11 is the same as the patch in #8 and does not have the typo.
But how can it be tested?
Comment #13
NikitaJain commentedVerified the patch https://www.drupal.org/files/issues/2855636-8.patch for nodes, custom block types and taxonomy terms. Its working fine for all.
Steps to check for custom blocks:
1. Navigate to /admin/structure/block/block-content/types
2. Click on 'Add custom block type'
3. Enter 'Rock & Roll' into the label field and save it.
4. You can able to see the new custom block type 'Rock & Roll'.
5. Click on 'Rock & Roll' on edit /admin/structure/block/block-content/manage/rock_roll
6. And then click on 'manage fields'.
7. You can able to see the breadcrumbs like this Home > Administration> Structure >Block layout >Custom block library > Rock & Roll
cc https://www.drupal.org/u/hugovk
Screen-shots attached
Comment #14
xjmThanks @NikitaJain for the manual testing!
We should add an automated test for this as well as per the core testing gate.
Comment #15
hugovk commentedHello! Thanks NikitaJain and xjm for reviewing!
nikunjkotecha, chiranjeeb2410 or Pavan B S, please could you create an automated test to go with your patch?
It'd be great to get this fix merged.
Thank you!
Comment #16
idebr commentedI have updated the existing BlockContentTypeTest and NodeTypeTest with a breadcrumb assertion based on the approach by tim.plunkett in the related issue #2513570-3: Changing name (label) of content type is not reflected in breadcrumb link text
Comment #19
idebr commentedAdded the Novice tag since there is a clear problem, test case and proposed resolutation available
Comment #21
chiranjeeb2410 commented@idebr,
Patch applies cleanly. Thanks for the related tests. Changing to RTBC.
Comment #22
alexpottCommitted and pushed 4d80891 to 8.4.x and 5d6ea2c to 8.3.x. Thanks!
I've credited @hugovk for raising the issue and providing feedback on patches. I've credited @krknth since their comments on the issue correctly identified what was missing from the route definitions. I've also credited @xjm for reviewing and noting the missing test coverage.
As this is a bug fix and a small change to the routing definitions with no API implications I've backported this bugfix to 8.3.x