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).
Thanks for the explanation. I was using this filter in our themes to simply modify the breadcrumbs separator and replace the site title with the word Home. I wonder how to achieve it now? Should I use native update_option to achieve it?
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.
