Category breadcrumbs path lost on posts in 23.1

[richardbuff]

trafficstars

• [x ] I've read and understood the contribution guidelines.
• [ x] I've searched for any related issues and avoided creating a duplicate issue.

Please give us a description of what happened

With version 23.1, if you create a new post and assign it a category, the proper category breadcrumbs trail will not show.

To Reproduce

Step-by-step reproduction instructions

1. I used a blank WordPress install in Local, running version WP version 6.6.1 and Yoast version 23.1 as the only plugin.
2. Turn on Yoast with Breadcrumbs for post types > Posts > Categories
3. Using 2024 default theme, I created a post, assigned it a category, and inserted the [wpseo_breadcrumb] shortcode and the category breadcrumb trail is missing. The same behavior is present using yoast_breadcrumb()
4. With version 23.1, commenting out the early return in the build function here makes the trail reappear: https://github.com/Yoast/wordpress-seo/blob/trunk/src/builders/indexable-hierarchy-builder.php#L120-L122
5. I believe that when testing this on a blank install, if you want to see the breadcrumbs break, you need to start with an older version of Yoast that is at least 22.9 and then upgrade. It appears that that if you start with 23.1 or 23.0 and then try to downgrade it still won’t show the breadcrumbs path. But on existing sites, rolling back to an older version of Yoast makes the trail appear.

Technical info

• Which browser is affected (or browsers): All

Used versions

• Device you are using: Macbook Pro
• Operating system: macOS
• PHP version: 8.2.10
• WordPress version: 6.6.1
• WordPress Theme: 2024
• Yoast SEO version: 23.1
• Relevant plugins in case of a bug: No other plugins installed

[josevarghese]

Hi @richardbuff

Thanks for using the Yoast SEO plugin and for creating the issue. I tested it on my lab site by installing the Yoast SEO 22.9 version and added the breadcrumb shortcode to a post. Then I checked the post and noticed that the category was outputted with the trailing slash (based on my permalink settings) without any issue.

After that, I updated the plugin to 23.2, which is the latest version that was released on the last day, and noticed that the category breadcrumb is still outputted with the trailing slash without any issues. You can find the screencast here for your reference: https://www.loom.com/share/12f7de7f59f045fc86e32b37b9b127ae. Did I missed any step while replicating the issue you have mentioned, please let me know.

[richardbuff]

@josevarghese Thanks for the response. Watch these two screencasts I made. In the first one, you can see on the second test post the breadcrumbs no longer work. In the second video, you can see me rollback and they suddenly start working.

• https://share.zight.com/5zuoZEGR
• https://share.zight.com/E0uO5pjE

[josevarghese]

Hi @richardbuff

Thanks for the video. When I tested with another site, I could confirm this issue with the category missing from the breadcrumbs on the post. I escalated it to our development team internally to take a closer look at this; we will keep you posted.

Thanks for your patience.

[josevarghese]

The issue only occurs on non-production websites (like websites generated using WP Local) or when the indexable is disabled, and it does not happen on live sites. That's why I could not replicate it during the initial testing, but it can now be replicated when tested using the Local WP.

[wittich]

I spent several hours debugging kind of the same issue with Yoast breadcrumbs that only occurs in local or staging environments. But it took me a while to understand that. It seems that Yoast breadcrumbs rely heavily on the indexables and hierarchy tables, which are typically only generated/updated in production environments.

To reproduce, I used the Yoast Test Helper plugin and clicked "Reset Indexables tables & migrations," which emptied the yoast_indexable and yoast_indexable_hierarchy tables. In a non-productive environment, these tables don't repopulate, leading to incomplete breadcrumbs. For example, instead of showing Home > Parent > Child, it only showed Home > Child. See #21539.

For consistency, breadcrumbs should not produce different results depending on the environment.

[aaronware]

I can confirm that this issue has impacted a production environment at least on Pantheon

[josevarghese]

@aaronware, can you check whether the wp-config.php is set with the value as the environment variable as development or not? This issue only occurs on websites set as development or local, where the SEO Data Optimization is disabled.

[n-dawson]

We've noticed that posts (or in our case, WooCommerce products) that already have categories assigned to them continue to show the category. If you recategorise the post (product) however, the old category continues to be shown in the breadcrumbs.

[bojuwhee]

Hi,

I ended up here because i got a similar issue : breadcrumb settings were not applied on local env but were functional live. in my local env, i got define('WP_ENVIRONMENT_TYPE', 'local'); in wp-config.php. commenting this line solved the issue.

Don't know why but hoping this will help

[richardbuff]

@josevarghese Just wanted to note that this Issue is flagged as "can't reproduce" and "needs more info" even though those two things were resolved, it was reproduced by your team and info was provided.

[josevarghese]

Hi @richardbuff

Thanks for the ping, and I now updated the tags.

[mrwweb]

Just ran into this issue. I don't have a perfect set of instructions to reproduce, but I can clearly describe the before state, the fix, and the after state.

This is on a site running local with an imported database from an old site but running Yoast SEO for the first time in a while.

Before (bug)

Incorrect breadcrumb path: Home > Grandchild

After (expected behavior)

Correct breadcrumb path: Home > Parent > Grandchild

"Fix"

As hinted at by others, this had to do with Yoast indexing the site correctly. The "fix" was to:

1. Edit wp-config.php to set WP_ENVIRONMENT_TYPE to production
2. Run the Yoast indexing tool on Yoast > Tools
3. Restore WP_ENVIRONMENT_TYPE to local

[itsViney]

I just ran into this bug and it had me stumped for a while before I found this issue report. Can confirm that setting the WP_ENVIRONMENT_TYPE to production does correct the breadcrumbs but I wouldn't call this a "fix" since we shouldn't really have this kind of inconsistency between local/dev environments and production.

[tyrann0us]

Hi @josevarghese, we encountered the same issue. Our QA team reported breadcrumb problems, and it took us some time to realize it was environment-related. Do you know if there are plans to "decouple" the breadcrumb creation from the indexables? Or, if you are reconsidering turning off indexable generation in non-production environments? I understand that many WordPress maintainers regularly push content/databases from non-production to production, which was the reason generation of indexables in non-production environments was disabled (reference), but this is actually considered bad practice; see https://docs.wpvip.com/guidebooks/develop-on-wpvip/applications-and-environments/#1-code-moves-up-content-moves-down.

For others who come across this, you can enable indexables in non-production environments with the Yoast\WP\SEO\should_index_indexables filter, i.e, add_filter('Yoast\WP\SEO\should_index_indexables', '__return_true'); This should allow breadcrumbs to function correctly in non-production environments.

Thank you!

[josevarghese]

Hi @tyrann0us

The reason we have disabled indexables in non-production environments is that we received numerous support tickets from users who ran the SEO Data Optimization process on their staging sites. Since staging environments use different URLs, the indexables were not reset after the site was moved to production, resulting in SEO issues, such as incorrect canonical URLs (as it's generated in the indexable) due to the change in domain. However, the decision regarding the decoupling of breadcrumbs and other related features for non-production sites should be made by the project team. Our product team will assess the severity of this problem in relation to other open reports and new features. Based on their assessment, the report will be given a priority level. Our developers address the highest-priority issues first. Unfortunately, this means we cannot give you an estimate of when they'll start working on your report.

However, if you would like to contribute to our code, you can do so by submitting a PR for it based on our contribution guidelines.