The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: ntsekouras <[email protected]>
Co-authored-by: mcsf <[email protected]>
Co-authored-by: jasmussen <[email protected]>
Co-authored-by: justintadlock <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Size Change: -122 B (-0.01%)

Total Size: 2.27 MB

_{compressed-size-action}

Looks good at a quick glance. I think it's the segmented control we need a tweak to. "With ancestors" doesn't read clearly. How about something like:

Page path (for anything hierarchical), with this contextual help text:

Show the page’s parent and ancestor hierarchy in the breadcrumb path.

Archive path (for terms, authors, cpts, anything non hierarchical) with contextual help:

Show parent archive links, such as category or tag archives.

I think it's the segmented control we need a tweak to. "With ancestors" doesn't read clearly. How about something like:

The tricky part with this control is that is very specific to the case where we have hierarchical post types with taxonomies. Every other use case is handled (or it will be in follow ups) automatically by the block.

That's why I think there should be a single help message that describes how specific this option is (with my initial suggestion For hierarchical post types with taxonomies, the breadcrumbs trail can consist of either the post ancestors or its assigned terms.).

So, @jasmussen your suggested copy is not accurate because nothing else is impacted by the value of this attribute, like any archive pages.

I even considered not having a UI for this, but some PHP filter that will probably be needed for some other specific more advanced settings, like selecting main taxonomy and term per post type. I plan to explore this after landing this one.

Thanks for the clarification. I still think there's a way to provide more easily understood terminology for these. I realize it may be an exotic feature, but it seems like it should be possible to use simpler language. We can be verbose. I wonder, who can we ping with good instincts for what might be good verbiage here? Pinging at random, perhaps @mcsf ?

Woo category
Justin's block also shows the products archive - is this special handling for Woo @justintadlock ? 🤔

Not for Woo. It's general handling for all post types, which would first run through the Post assembler class: https://github.com/x3p0-dev/x3p0-breadcrumbs/blob/f772863c9b732fb53562b26290bfc989c7363d6c/src/Assembler/Type/Post.php

Then it'd run through the PostHierarchy class: https://github.com/x3p0-dev/x3p0-breadcrumbs/blob/f772863c9b732fb53562b26290bfc989c7363d6c/src/Assembler/Type/PostHierarchy.php

@justintadlock do you think we can move forward with this iteration? Is there something in your opinion that should be handled better here? There will be follow ups and I don't want to add too many things at once.

Flaky tests detected in 4bd4ac0.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/18786465105
📝 Reported issues:

• [Flaky Test] ensures List View global shortcut works properly #51533 in /test/e2e/specs/editor/various/list-view.spec.js

It took me a while to wrap my head around this.

Here's my takeaway: @ntsekouras's proposed messaging is on the right track, but our choice of type of control and form layout could make a big difference. I agree with @jasmussen that the "With ancestors" / "With terms" labelling is confusing. Ultimately, isn't this setting an advanced setting that most users don't have to be bothered with (until they do)? With that in mind, I'm thinking we should frame this as an option, possibly with a checkbox:

# Advanced

The exact type of breadcrumbs shown will
vary automatically depending on the page
in which this block is displayed.

In the specific case of a hierarchical
post type with taxonomies, the
breadcrumbs can either reflect its post
hierarchy (default) or the hierarchy of
its assigned taxonomy terms.

[ ] Prefer taxonomy terms

Yeah, it's still a mouthful. Balancing clarity and accuracy is tricky here. Hence the motivation to demote this setting to an opt-in preference that most users can ignore, and hence the suggestion to consider making it an advanced setting.

Is this helpful at all?

@justintadlock do you think we can move forward with this iteration? Is there something in your opinion that should be handled better here? There will be follow ups and I don't want to add too many things at once.

It should be fine to move forward.

I also think it'd be helpful to have a general/tracking ticket for the block itself to discuss items like what @mcsf mentioned above, which are not necessarily directly related to to the addition of archives support. We don't want to lose track of good feedback and architectural discussion.

I created an initial tracking issue for the block here.

Is this helpful at all?

@mcsf of course it is. I updated per your suggestion with the difference that the help message in controls is below and I think we shouldn't be blocked much by this here, as it should be handled and designed better with the rest similar settings. I have this as a task in the tracking issue:

Some settings are template related and a bit more advanced in order to handle the case of adding the block once in a header and set it for the whole site. One would be to show on homepage and the other is about the case of a hierarchical post type with taxonomies (the breadcrumbs can either reflect its post hierarchy (default) or the hierarchy of its assigned taxonomy terms). We'll have a first iteration that adds the latter under advanced panel, but we might want to display them somehow differently (example Modal, etc..).

I like that verbose description, and making it a checkbox. It's completely fine to be extremely elaborate and clear in contexts like these, where you have already found your way to the block itself and are choosing to configure arcana.