New Breadcrumbs Block

[paaljoachim]

It would be nice to have a breadcrumbs block that we can add to the any area of the content.

EDIT:
I am cleaning up the proposal.

Here is a screenshot that uses the paragraph block to exemplify breadcrumbs.

One could add a breadcrumbs block to a post/page template, and style it directly in the template, and/or the block could become a dynamic reusable block.
Some styling options could be font color, font size, background color, icon between each level and width(if the breadcrumbs block is to stretch all the way across the post/page). Showing the path hierarchy with page/post title names.

This would be one of the Full Site Editing blocks which would be dynamic in nature, showing the relevant information based on the page/post one is currently on.

---

Initial post:

Here is an example from @aristath 's Gridd theme: https://github.com/wplemon/gridd

Here we need to be able to change the text and background color.
Rename/relink breadcrumbs in relation to @karmatosed 's below question. (Reason why I mentioned renaming is that some sites will automatically add a title called Home to the front page. It would be good to have the home page name used instead of the name Home.)

[karmatosed]

I like the idea of this block. I don't think it needs too many options. I am not sure about renaming or linking, that feels like heading into the territory of navigation for me, which there is already a block for. However, would you be able to tell me more what you were thinking there @paaljoachim?

[sybrew]

Breadcrumbs are fundamental to any website with more than one page, where they help visitors traverse pages easily. In essence, they must contain links all the way back to the homepage.

From Google: https://support.google.com/webmasters/answer/7451184?hl=en#hierarchy

A breadcrumb is a row of internal links at the top or bottom of the page that allows visitors to quickly navigate back to a previous section or the root page. Many breadcrumbs have the most general page (usually the root page) as the first, leftmost link and list the more specific sections out to the right. We recommend using breadcrumb structured data markup when showing breadcrumbs.

It'd be great to have this a block in Gutenberg/Core, as it'll push Phase 2's "Full Site editing" further towards completion.

[aristath]

Adding some thoughts here:

A breadcrumbs block will definitely be one the things that will be necessary for FSE... Breadcrumbs is one of the most basic things any theme adds, and it's always one of the messiest things to get right. Providing authors & users with a robust & clean solution would go a long way!

• On the editor side:
  • If used inside a template it would basically need to be a plain placeholder, since the actual breadcrumb will depend on the post the template is used on.
  • If used on a single post/page (basically anything other than a template or template-part), we could provide the option to customize the path. It would be nice, but not necessary for the initial implementation.
• On the front side:
  • Minimal styles would have to be implemented. Nothing fancy, just a display:flex on its wrapper, and separators between the items.

The block will need to be dynamic and not save the actual breadcrumbs HTML/path. Taxonomy hierarchies change, post categories & tags change, even the slugs can change. With that in mind, the breadcrumbs will need to be generated on post-render.

As for how the breadcrumbs themselves will be generated, there are lots of implementations out there. One of the most robust I've seen so far is the one in hybrid-breadcrumbs by @justintadlock, or the implementation from Yoast SEO. We could probably extract some of the logic from that and work on abstracting it, clean it up and remove the things that won't be necessary in the context of a block, strip it to its basics and make it into a block that can be used consistently.

[paaljoachim]

@andrewserong Andrew has made a WIP/Draft PR here: #32500
I noticed the progress has stopped up.

[andrewserong]

Thanks for the ping @paaljoachim! I had a bit of time a few weeks ago to explore the WIP draft PR, but then switched over to working on some other projects. I'm hoping to get back to it later on this week, and then chip away on it a bit in my spare time. If anyone gets the chance to take the PR for a spin / try it out, I'm very happy for feedback on the approach!

[paaljoachim]

I left some feedback directly in the PR. It would be helpful if others can also test out the Draft PR

One can use the Gutenberg PR build approach to test out the PR. Outlined here.

[BrunoAHVincent]

Any solution to this yet?

[paaljoachim]

Hopefully @andrewserong will bet able to get the first version in place by 20th September (beta 1).

[andrewserong]

Thanks for the ping! Yes, the draft is still in #32500 — it's a little lower in the priorities currently than design tooling consistency (#43241), which I've been helping out with (particularly spacing support #43243 and reviews), so not sure yet if I'll get enough time to dust it off before the beta cutoff. Will see how I go!

[syhussaini]

I got a similar request from a client recently. +1.

[rodolfomartinez]

Massive +1 here. With the recent advances in SEO and Accessibility in WordPress, I am surprised that we don't have this.

[justintadlock]

As for how the breadcrumbs themselves will be generated, there are lots of implementations out there. One of the most robust I've seen so far is the one in hybrid-breadcrumbs by @justintadlock, or the implementation from Yoast SEO. We could probably extract some of the logic from that and work on abstracting it, clean it up and remove the things that won't be necessary in the context of a block, strip it to its basics and make it into a block that can be used consistently.

I've also made that original script into a block on in the plugin directory (GitHub link), so feel free to use anything from the newer code for a core block too.

It'd definitely be a tough addition to core if we want something robust enough to handle any scenario. Most likely, we'd want to cover some base use cases and make it filterable enough for plugins to extend.

[paaljoachim]

Breadcrumbs was brought up in the FSE Outreach Experiment Slack channel.
https://wordpress.slack.com/archives/C015GUFFC00/p1705592363506389

With this question by Alex.
"Although I am still diving into the recently released updates, I was curious about the projected timeline for incorporating Breadcrumbs functionality. As a theme developer, integrating ready-made Breadcrumbs patterns would be exceptionally beneficial and aligns with one of the most frequent header-related requests we receive."

I want to add @andrewserong 's comment he made to the Slack thread.
"I’d love to see us get a Breadcrumbs block into core. It’s been tricky to figure out the desired scope for a minimal block in core that still does everything that everyone would like it to. In my old WIP PR we didn’t manage to come to a consensus about whether or not the core block should include the schema.org microdata. It’d certainly be worth revisiting the idea, though, and seeing which features make sense for core, and which are better left to plugins."

It would be very helpful to get some movement here. Let's get to a consensus about the next step.
Thank you!

[jarekmorawski]

Interesting discussion! There's a clear interest in a Breadcrumbs block. I'm not sure it should be part of the core suite, but there's a chance it could be added when someone browses patterns or blocks in the Inserter (related: #61504).

After some internal discussion, I put together a design that I hope balances customizability and simplicity. It's based on @andrewserong's PR (#32500). I imagine the block would be extensible, meaning third parties could add custom settings and options (like icons or a new toggle to display the home link as an icon).

The block would consist of links to pages, navigation levels, taxonomies, etc. Using the toolbar, users could set the justification, alignment, and width—same as with the Group block and its variants.

The same settings would also be available in the Inspector. There'd be a new option for Width to allow users to enter a custom width in pixels or other units.

Users would go to Inspector to customize the block's appearance and behavior. When they enable "Show home link", the block will display a link to the home page and users will see an input field in the Inspector. It will allow them to customize the name of the home link. It'd default to the site name but users could enter anything, e.g., Home or Store.

Users could click the ellipsis menu to access more settings, like the current page toggle and a navigation level slider.

When the current page toggle is on, the block will display the name of the currently viewed page as the last breadcrumb level. It will not be active, so it wouldn't have the underline like other breadcrumbs. Users could change its appearance under Color in the Style tab.

The Max. navigation level slider would let users decide when breadcrumbs should be truncated. If moved to the left, the block would display ... in place of the truncated links. Note that the slider would define the maximum number of levels to show, so if there are fewer links, we'd show them all.

Users could change the separator in the Styles tab. Of all the dozens of websites I checked, all used one of the three options I included in the design. It could be a good starting point and if users ever need something else, they'd install a plugin that extends the block.

I also included a toggle for displaying the leading separator and reworded the copy a bit, though I'd argue the pattern isn't common enough to be part of the block's default setup. Happy to keep it in the design if you feel it's valuable.

Once again, users could change the separator color in the Color section.

Let me know if you have any thoughts!

[LukaszJaro]

Was there any more discussion about the adding some structured data to the breadcrumbs via microdata(schema.org)?

[justintadlock]

The Max. navigation level slider would let users decide when breadcrumbs should be truncated. If moved to the left, the block would display ... in place of the truncated links. Note that the slider would define the maximum number of levels to show, so if there are fewer links, we'd show them all.

Is there a "no max" option here in the slider, which should be the default?

Users could change the separator in the Styles tab. Of all the dozens of websites I checked, all used one of the three options I included in the design. It could be a good starting point and if users ever need something else, they'd install a plugin that extends the block.

Just noting that this list should be filterable by theme/plugin authors and the default separator should be something that can be set via theme.json.

I also included a toggle for displaying the leading separator and reworded the copy a bit, though I'd argue the pattern isn't common enough to be part of the block's default setup. Happy to keep it in the design if you feel it's valuable.

After 15 years of maintaining a breadcrumbs plugin, I've never once had someone ask to add a leading separator.

Once again, users could change the separator color in the Color section.

I'm not a big fan of adding non-standard colors to block options because theme authors cannot control them via theme.json at the moment. I'd avoid extra color options, at least until Core supports this.

[jarekmorawski]

Is there a "no max" option here in the slider, which should be the default?

Moving the slider all the way to the right would show all levels, no matter how many are there.

Just noting that this list should be filterable by theme/plugin authors and the default separator should be something that can be set via theme.json.

I agree. Every style-specific setting in the block should be extendable and modifiable by themes. We should, however, offer some options out of the box for users who use the default theme or one that doesn't provide extra customization settings.

After 15 years of maintaining a breadcrumbs plugin, I've never once had someone ask to add a leading separator.

Me neither, but it exists in the current block, so I've kept it for backward compatibility. I wouldn't mind removing it to reduce complexity.

I'm not a big fan of adding non-standard colors to block options because theme authors cannot control them via theme.json at the moment. I'd avoid extra color options, at least until Core supports this.

I think we'll need that anyway because well-defined active vs. inactive link styles are crucial for breadcrumbs. As for the separator, perhaps we'd automatically associate its color with the text color and display a slider to change its opacity, similar to the overlay in the Cover block?