John Havlik

The challenge with taxonomies is establishing the relationship between the to taxonomy terms. If in your example New York has dog set as the parent term, Breadcrumb NavXT should be able to pick up on that. However, if that relationship isn’t set, while it’s possible to make it work when on a advert post, it is much more difficult on an archive page for the taxonomy terms (e.g. if you had an archive page that was the query result for adverts that are of category dog and location new york).

Since root pages for CPTs are not built into WordPress, WPML doesn’t translate them. You will need extra code to translate the root page. There are a few ways of doing this, the most straight forward is write the code that hooks into the bcn_breadcrumb_url filter. If you don’t want to write any code, there is an extension plugin to Breadcrumb NavXT that does this (and a few other things for improved WPML compatibility).

Thanks for digging into this to identify the plugin that caused the problem. I took a look at said plugin, and it looks like that plugin is registering the fv_player_encoding_category taxonomy at the incorrect time. It registers this taxonomy in the create_encoding_categories function that hooks into the admin_init action. The problem with this is not only is this after all of the init filters, but it makes the taxonomy unavailable outside the dashboard/admin area (which may be the intent, but if that is the intent, the taxonomy should be registered as a private taxonomy as well, which it currently is not).

I’m adding a check/message in the next version of Breadcrumb NavXT that lets the user know in the settings page if a CPT or taxonomy was detected to be registered too late (a dismiss-able message as in some cases, such as with FV Flowplayer it seems to be intentional) and to not include settings form elements for said CPTs and taxonomies (aims to prevent PHP error messages).

Based on the specific setting that caused the issue, it appears you have taxonomies that are getting added after the priority level of 8999 on the init action. By default hooks into the init action are at priority 10, and Breadcrumb NavXT runs at 9000, which should be much later than anything else. It is highly suggested that whatever adds the taxonomy so late is changed to add it earlier (smaller priority number, my guess is someone used priority 9999, which for adding CPTs or taxonomies makes it difficult to play nice with other plugins/code).

Just a heads up, the provided instructions don’t seem to apply to Breadcrumb NavXT itself. Based on the description, the interface appears to be theme specific/theme related.

Unfortunately, from the description, I’m not sure where to even start looking. My first guess is it isn’t actually Breadcrumb NavXT related. Especially since the problem persisted after deleting the plugin with FTP (there really isn’t a way for it to continue to run after it has been removed). That said, did your webhost have anything in your HTTP or PHP logs (error logs, or PHP slow log) that points to any of the Breadcrumb NavXT files?

So, I think I’ve come to a conclusion on how this will have to work. It really isn’t a good thing to let others override the actual setting object instantiation. So, instead, the input is still strings in the array, and then we instantiate the setting with that value within the plugin itself. I’m tracking this in the following GitHub issue: https://github.com/mtekk/Breadcrumb-NavXT/issues/270 I have pushed a change that makes a first cut at this implementation. The good news is for the select settings that are supported, it is compatible with how pre-7.0 worked. When you get a chance, please try out the master branch on GitHub and let me know if it meets your needs for programmatically adjusting the setting default values.

As part of the under the hood updates in Breadcrumb NavXT 7.0, the meaning of the filter changed slightly. It now expects the settings array (an array populated with objects compliant with the mtekk\adminKit\setting interface), where prior to 7.0 it contained the opts array (array of ‘raw’ options). This necessitated all 3rd party code to be updated that used this filter especially if it added items, or used the filter to override default values. Unfortunately, a bunch of 3rd party code was not updated, causing PHP warnings/errors (and a deluge of support requests). As part of the mitigation of the warnings/errors, the filter was moved to the top of the function, providing the ability of 3rd party code to add settings (e.g. for plugins that extend Breadcrumb NavXT), but removing the ability to affect the default settings.

I’m contemplating adding a bcn_setup_setting_defaults filter to the end of the the setup_setting_defaults() function to restore the ability to override the default settings. However, I’m trying to devise a way to ensure that bad things don’t happen when that is opened up again (potentially the filter won’t be added and the code after bcn_settings_init checks if a ‘good’ value exists before setting allowing the overriding of default values but in a safer way).