The breadcrumb shows 'Edit <label>' on all entity routes, even canonical/delete routes

I'm having a similar problem with the node edit form. However, it shouldn't break the existing behavior for users who want it, so there should be a setting on the theme to choose if we want to override or not the breadcrumb. The default value of that setting should be the current behavior (override).

Added a new commit with a new setting to skip the breadcrumb override. We are conserving the change of the "Home page" label, but could be a new setting for that particular tweak.

I'm putting this on hold for now, as we have no plans to add more settings at this time, as we are prioritising a stable version.

Thanks for answering so quick! :)

For me it always prints "Edit [bundle]" text (not a link) as last breadcrumb fragment. I do not understand the reason why it's done this way.

// Add bundle info.
$variables['breadcrumb'][] = [
  'text' => t('Edit') . ' ' . $node->type->entity->label(),
  'url' => '',
];

Overall I think, it's out of scope for a theme to alter breadcrumbs links.

For me it always prints "Edit [bundle]" text (not a link) as last breadcrumb fragment. I do not understand the reason why it's done this way.

It shows which entity type you're editing. But it seems to be a bug to show "Edit" on the "Delete" action – which we should address.

Overall I think, it's out of scope for a theme to alter breadcrumbs links.

Definitely not for Gin. As we're testing/experimenting with new changes which we might consider to include for Core (Claro) in the future.

For me it always prints "Edit [bundle]" text (not a link) as last breadcrumb fragment.

I've just managed to reproduce the original issue. On canonical node view page the breadcrumbs consist of just one link ("Edit %title"). No link to the home page was provided. Isn't it a bug?

I think the problem here is that the issue title does not match the issue summary.
Issue title describes a feature
Issue summary describes a bug.

I created a new MR in which I fixed the issue, without introducing any new settings. That part should probably be moved to a separate issue.

DieterHolvoet → closed merge request !147

This needs a reroll

I guess we have a caching issue here, as it does not change within an entity. Only if you change to a different entity. And it stays on the one which you visit first.

Couldn't reproduce the caching issue but I added relevant cacheability metadata to the $variables array, should be fixed now.

Just for documentation: This MR does not fix the permission issue with Gin Toolbar in frontend themes (edit link is shown to users without update permission).

To fix the frontend permission issue use the patch from issue #3319445 🐛 Edit link in breadcrumb region shows even when user has no permission RTBC

hudri → closed merge request !213

Sorry for the noise, I somehow got lost in the Gitlab Web IDE. I wanted to update Dieter's MR with an entity access check for the edit link in the secondary toolbar

https://git.drupalcode.org/issue/gin-3281984/-/commit/f3c1c7700399ebed84...

but somehow lost some other commits on the way along. So I closes my MR213 again, but the fix is a simple one-line change. Hope someone with better Git-Fu skills than me can merge this properly.

I pushed your change!

Verified the MR177 changes and tested it on Drupal version 10.1.x and Gin Theme version 8.x-3.x. The patch works fine and it fixes the original issue mentioned in the ticket. I have added the before and after screenshots for reference.

This MR would need a manual rebase

Rebased.

@DieterHolvoet @saschaeggi I have applied MR!177 changes, And after adding MR changes entity label working fine. Attached screenshot before and after state. Moving to RTBC

Here is an immutable, stale patchfile of MR 177 for RC7, for hotlinking in composer.json.

Pipeline failed because of conflict in code so moving to NW.

Resolved conflict, moving NR.

Hi, I've tested MR- MR !177 mergeable on Drupal version- 10.1.9-dev. The patch was applied successfully and looks good to me.

Testing Steps:

• Download/install the Theme "Gin Admin theme"
• Go to Content> Create new or edit an existing node- Clienk on Delete. Attached before result.
• Download this patch and Apply.
• Go back to the Content/Delete- and re-verify this.

Testing Results:
After applying the patch, the Delete confirmation page breadcrumb label is changed now. RTBC++

Here is a stale patch file for RC9 for use inside composer.json.

The MR no longer applies beyond dev, the patch file cherry-picked all all of DieterHolvoet's work. Not intented for development!

This works great and fixes the "Edit [term name]" on taxonomy pages as well. Just tested the last patch file but didn't look at the MR.

Updated patch from #38 for rc10. I hope I didn't miss anything.
I don't have the capacities right now to look at the MR unfortunately.

Still setting to "Needs work" to check if the MR needs modifications to be applied to the current dev.

@djsagar if you give me push access to your forked repo I'll sort out the merge conflict. I have it fixed up on my local already.

Updated my last cherry-picked patch to apply to rc11

This is a longish issue, I tried following but different things were going on. I happened to work on a fix about url access and I wanted to share my work here.

My recommendation would be to maybe try to get the access bit first (which is easier) and then something more robust for the breadcrumbs in general?

In anyway, the two MR can co-exists and I will be using on a product of mind.

This is pretty much the same fix that the one #3319445-26: Edit link in breadcrumb region shows even when user has no permission → , and they likely should be applied together.

Updated my last cherry-picked patch to apply to rc14

Updated MR kindly review.

Updated the cherry-picked patch to rc15

The latest patch was applied successfully and the issue was resolved to my project.

Just to be sure: Were you testing MR !177? Thanks for a short feedback

The last cherry-picked patch is indeed based on MR!177

saschaeggi → changed the visibility of the branch 3281984-url-access to hidden.

Thanks y'all!

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