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 Needs review

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.

Summary:


Gin interferes with BigMenu's breadcrumb by replacing the first item in the breadcrumb, disrupting the expected hierarchy.

Steps to Reproduce:

1. Install and enable the Gin theme.
2. Install and enable the BigMenu module → .
3. Create or edit a menu with a hierarchy (items that have child items).
4. Navigate to the child items' overview page.
5. Observe the breadcrumb trail.

Expected Behavior:

The breadcrumb should display all items set by BigMenu, including the first item, which is supposed to be "Back to @label top item" (as defined in BigMenuForm.php).

Actual Behavior:

Gin replaces the first item in the breadcrumb with "Back to site" which disrupts the breadcrumb hierarchy and removes the expected "Back to @label top item" link.

Observations:


The issue stems from Gin overriding the first breadcrumb item via:

1. gin_preprocess_breadcrumb: The refactor and changes in this commit removed the URL check before altering the first breadcrumb item’s label. This means the first item in the breadcrumb will always undergo the label change, regardless of its original url/value.
2. escape_admin.js: This commit introduced a check on the $url variable in the gin_preprocess_breadcrumb function. The $url variable is derived from $entity = _gin_get_route_entity(); (L18 in screenshot below) which is empty in my case. The JavaScript then adds a "data-gin-toolbar-escape-admin" attribute (L44 in screenshot below), overriding its URL and replacing it with the last page you visited in front.

Both changes ensure the first breadcrumb item is completely replaced. This makes it impossible to navigate back to the root/top menu overview from the child overviews.

Previous Feedback:


As noted in an earlier comment, introducing a theme setting to toggle this behaviour would resolve conflicts like this. While I understand if adding settings isn’t a priority, I strongly believe themes should avoid altering critical UX elements like breadcrumbs unless it’s explicitly configurable. Breadcrumb hierarchies are often module-defined (e.g., for admin workflows), and themes overriding them can break user expectations.

Proposed Solutions:

1. (Immediate/Easy Fix) Reinstate the URL Check before altering: (See patch attached) Disclaimer: For me, and the current site I am using BigMenu on, this check suffices.
2. (Future Enhancement) Add a Theme Setting: Allow users to disable Gin’s breadcrumb overrides (e.g., "Override breadcrumbs" checkbox in theme settings).

Additional Context:

• * Drupal Version: 10.3.9
• * Gin Theme Version: dev-3.x
• * BigMenu Version: 2.1.0

Closing Note

Thank you for all the work and effort you’ve put into developing and maintaining Gin. It’s a fantastic theme. This issue is a minor edge case, and I hope the proposed solutions can help improve compatibility with modules like BigMenu/other modules that adds their own overviews.