Prefix optionsframework_option_name() and optionsframework_options()

[grappler]

Why are optionsframework_option_name() and optionsframework_options() not prefixed in options.php?

Won't they clash if a plugin is using the Options Framework?

[devinsays]

Those functions are called directly from the plugin/framework, so they can't be prefixed without some changes in architecture. An add_action or filter hook (or passing params to a class) would be preferable, but I think need to be addressed in the next major update.

When I have some time, I'd really like to look at Custom Metaboxes (https://github.com/WebDevStudios/Custom-Metaboxes-and-Fields-for-WordPress) and see if it might make sense (and be possible) to transition this framework to their codebase. That would improve a lot of things (more option types, extensible options, multiple option screens).

[grappler]

Would it be ok to use these two filters?

apply_filters( 'options_framework_option_name', $name )
apply_filters( 'of_options', $options )

I would prefer if you did not move to "CMB2". The first reason being that custom fields are normally plugin territory in themes. Secondly this increases the amount of code a theme reviewer needs to review before a theme is approved.

It was asked today in the #themereview channel today if "CMB2" is allowed and Tammie was against it.