Hi @lucspe,
The short answer is that you can’t. These settings use WordPress’s Settings API, and it only really takes a user capability argument on a per-page basis.
Furthermore, all of these settings are saved in a single serialized entry in the database. So even if you hooked into bpfwp_settings_page and removed those fields for users without a certain capability, they’d end up overwriting the data in the database.
I presume what you want to do is prevent a client or lower-level manager from making changes. I can see two possible solutions to this.
First, the simplest thing to do would be to just enqueue some CSS on that page in the admin which hides those settings. It wouldn’t be safe from a malicious user, who could still uncover and modify those settings. But if you just want to prevent accidental overriding or modification, that should work.
Alternatively, you can use the option_{$option_name} hook to force the value of the API key and multiple language options whenever they’re retrieved. In your wp-config.php you’d add some constants like this:
define('BP_GMAPS_API_KEY', 'your-api-key');
define('BP_MULTIPLE_LOCATIONS', true);
Then you’d hook in with something like this;
add_filter( 'option_bpfwp-settings', 'luscpe_override_bp_options' );
function luscpe_override_bp_options( $val, $option_name ) {
$val['google-maps-api-key'] = BP_GMAPS_API_KEY;
$val['multiple-locations'] = BP_MULTIPLE_LOCATIONS;
return $val;
}
That’s just an example. You may need to inspect $val and make sure you’re overriding these values correctly. But once done it should make the values match what’s in your config file, regardless of what someone has put into the fields in their Business Profile.
Thread Starter
lucspe
(@lucspe)
Hi,
To prevent a client or lower-level manager from making changes to the API key was exactly the case.
Hiding those settings via CSS was my first thought however the TR in the form on the admin page doesn’t have a class assigned so having to rely on nth-child is a bit risky in terms of future-proofing it.
I tried modifying the code in includes/class-settings.php to add CSS classes – as add_settings_field allows to pass that in the args array – however it seems that it is not supported by the framework used to add the settings. But I am not familiar with it so I might be missing something there.
The option to force values via constants seems like a good workaround functionally, however it would have been best to be able to “visually remove” those fields.
Thread Starter
lucspe
(@lucspe)
Sure.
I’ve sent you a pull request. I think that should be it.
