This is the second, and hopefully last, bug fix release of the 7.0 branch of Breadcrumb NavXT. In this release, the “Sorry, you are not allowed to access this page.” message when attempting to visit the Breadcrumb NavXT settings page has been fixed for the majority of users. Additionally, the behavior of the default setting instantiation was changed to allow bcn_settings_init to set the value of the following settings:
Hhome_template, Hhome_template_unlinked, hseparator, and hseparator_higher_dim.
The permissions bug was due to the introduction of namespacing in adminKit 3.0, which caused a check against WP_Role to always return false (since it was looking in the wrong namespace), resulting in the bcn_manage_options capability never getting assigned to the administrator role. Note that this primarily affected sites that never had Breadcrumb NavXT 6.5.0 or 6.6.0 installed (i.e. new installs or updating from a version prior to 6.5.0). If your WordPress install does not have an administrator role, you will need to add the bcn_manage_options capability to the appropriate role in your install.
This is the first, and hopefully only, bug fix release of the 7.0 branch of Breadcrumb NavXT. This release features fixes to 4 bugs and 2 behavior changes for better resiliency to non-supported environments. As part of this, two different settings errors have been fixed/handled more gracefully (the get_value on string error and the int required string given error). A few tweaks were made to hopefully support PHP5.6 without error (this is untested so the minimum listed PHP requirement stays at 7.0). Additionally, the run level for the default settings generation was moved from 11 to 9000, this should avoid errors in the settings page caused by other plugins registering post types at priorities other than the default 10.
Lastly, in order to work around issues with 3rd party code that is not 7.0 compatible, the location that the bcn_settings_init filter is applied has been moved to the top of the setup_setting_defaults function. With this new location, 3rd party code can still add settings, however the default settings can no longer be modified.
Holy under-the-hood improvements Batman! This release feature a heavy reworking of the code that powers the administrative interface. While there isn’t much to show for it right now, the ground work has been laid to revamp how the settings importing/exporting works. Additionally, the core breadcrumb trail class now supports multidimensional breadcrumb trails. Note that this doesn’t mean it generates them, internally, it allows non-hierarchical terms to be handled more gracefully. On top of the under-the-hood changes, several bugs were fixed in this release.
PHP8 compatibility has been improved (the REST controller no longer throws an error). Widget settings not saving/taking effect in WordPress 5.8+ has been fixed as well. Lastly, an error in how the position count worked was fixed for when the output order of the trail is set to reverse.
Internally, the way settings work has changed significantly. Rather than saving the entire set of setting values to the database, only non-default values are now saved. As part of this, a new filter, the bcn_opts_update_to_save filter was added to allow control of the non-default values before saving. The change in what is saved to the database helps with future updates, allowing sites that use the default value for a setting to keep up with the latest settings changes without having to manually make changes.
Lastly, a few notes on potential messages and behaviors that may be seen. Immediately after migrating settings on the Breadcrumb NavXT settings page, you may see a notice about unknown settings. Under normal circumstances, this will disappear after re-loading the page. It is a result of the settings updater removing old settings from the database (since only non-default values are now saved). Additionally, if the labels for the settings tabs are missing, it is likely that you are also running WP Lynx, or some other plugin that uses an old version of adminKit. At this point of time, you’ll have to either update those plugins, or deactivate them. Finally, if you use any of the Breadcrumb NavXT extension plugins, you should update these plugins prior to updating to Breadcrumb NavXT 7.0.
Since the last time the topic of Breadcrumb NavXT and bbPress Compatibility was investigated, almost 6 years ago, a little has changed in how both plugins operate. In fact, due to a change in how bbPress operates internally, Breadcrumb NavXT now supports post type jumping.
Out-of-the-box, forums and topics should work well. However, the settings recommendations have changed since the last visit of this topic. The current settings recommendations are:
Forum Root Page and Topic Root Page – Set these to be equal and to whatever page you have set as ‘Forum Root’ under Settings > Forums.
Forum Archive Display – Unchecked
Forum Hierarchy Display – Checked
Forum Hierarchy – Post Parent
Topic Archive Display – Checked
Topic Hierarchy Display – Checked
Topic Hierarchy – Post Parent
What Doesn’t Work
Out-of-the-box, topic tag archives still won’t work as expected. Additionally, the search page, search results page, and user pages do not work. These all require custom, bbPress specific code.
Recently, Breadcrumb NavXT bbPress Extensions was updated to include support for the search page, search results pages, and user pages (at least the landing page for user pages, the various sub-pages are not supported yet). This is in addition to fixing the how topic tag archives show up in the breadcrumb trail.
Holy post type jumping Batman! This second feature release of 2020 changes how post type archives are handled when following a post parent hierarchy. Additionally, a bug introduced in 6.5.0 was fixed where an error that would be thrown in the WordPress dashboard if the administrator role does not exist.
Previously, if the post type changed while following the post parent hierarchy, the post type of the current item was used for the post type archive. In 6.6.0, this behavior changed to use the post type of the highest level post in the post parent hierarchy. The old behavior just didn’t make sense and causes problems with plugins that use multiple custom post types in the same hierarchy. A side benefit of the change is improved bbPress and BuddyPress support.