Feature request: allow developers to extend or change the options

I’m currently checking in version 2.3.0 which introduces filters that address items #1 and #3 in your list. I’m also working today on documentation of these features, which will be available here:

https://nononsensewp.com/developer.php

Item #2 from your list doesn’t strictly need anything in the plugin itself. The way the plugin works is that anything that’s toggled “On” on the admin page gets saved in the wp_options table. To force any of the plugin’s options to be turned on, you just need to write those values to the options in your plugin or theme. (And in conjunction with that, you may want to use the new filters to prevent the option from displaying in admin… that will be explained on the documentation page.)

For example, if you want to hardcode the “Remove WP emoji” function, you’d put this in your code:

update_option('r34nono_remove_wp_emoji', true);

Of course, you don’t really need to update that option on every page load, so I would recommend putting this inside an activation hook. Another approach, if this is a one-off situation, would just be to go to the hidden admin page for managing all options — [your_site_url]/wp-admin/options.php — and plugging a value of 1 in for r34nono_remove_wp_emoji… or just applying the setting on the No Nonsense admin page first and then using the hook to hide the setting to prevent future changes.

• This reply was modified 2 years, 4 months ago by room34.

Just to clarify that last point a bit: if you are hardcoding a setting and you want to hide it in the admin, be sure not to remove it from the array of functions —?just set its show_in_admin value to false.

Wow, thanks a lot for your efforts!

I tried using the filters from inside a theme, but they don’t trigger.

### Functions.php

error_log('test');

add_filter('r34nono_define_utilities_array', function($utilities) {

	write_log('test nononsense 1');

	unset($utilities['r34nono_set_permalink_structure_to_postname']);
	return $utilities;
});

### debug.log

[15-Jul-2022 08:53:23 UTC] test

My theory: a theme runs later than plugins, so by default they can’t hook into plugin functions. But you might hook your plugin functions to a later hook, so themes can use them.

The first hook available for themes is after_setup_theme, that might work. Or use the init-hook. See https://codex.www.ads-software.com/Plugin_API/Action_Reference.

I’m already thinking of a nice solution for Item #2.

Like you say, I can easily update the options in the database. So with the new filters I could simply add a utility to set my prefered settings. ??

Maybe you could add the option names to the documentation:

r34nono_remove_posts_from_admin => BOOL
r34nono_remove_comments_from_admin => BOOL
r34nono_remove_dashboard_widgets => BOOL
r34nono_remove_dashboard_widgets_options => ARRAY
r34nono_remove_admin_color_scheme_picker => BOOL
r34nono_redirect_admin_to_homepage_for_logged_in_non_editors => BOOL
r34nono_redirect_admin_to_homepage_for_logged_in_non_editors_options => ARRAY
r34nono_limit_admin_elements_for_logged_in_non_editors => BOOL
r34nono_remove_edit_site => BOOL
r34nono_remove_duotone_svg_filters => BOOL
r34nono_remove_default_block_patterns => BOOL
r34nono_remove_widgets_block_editor => BOOL
r34nono_disallow_full_site_editing => BOOL
r34nono_disable_site_search => BOOL
r34nono_remove_wp_emoji => BOOL
r34nono_remove_front_end_edit_links => BOOL
r34nono_remove_head_tags => BOOL
r34nono_remove_head_tags_options => ARRAY
r34nono_remove_comments_from_front_end => BOOL
r34nono_login_replace_wp_logo_link => BOOL
r34nono_remove_admin_email_check_interval => BOOL
r34nono_remove_admin_wp_logo => BOOL
r34nono_admin_bar_logout_link => BOOL
r34nono_hide_admin_bar_for_logged_in_non_editors => BOOL
r34nono_remove_howdy => BOOL
r34nono_auto_core_update_send_email_only_on_error => BOOL
r34nono_xmlrpc_disabled => BOOL
r34nono_xmlrpc_disabled_options => ARRAY

I added a public gist for manipulating the settings through code.

https://gist.github.com/erikjoling/4eae6fe325db95e327a933e11cdad342

@ejoling Thanks for these follow-up notes. I’ll admit that when I tested this before rolling it out, I only tried it in a custom plugin, not in a theme. And my development work got interrupted for a couple of weeks. When I got back to it this week, I had forgotten what led me not to roll this out already (since the functionality was done)… but this was it.

I believe I could resolve this by putting the $this->add_hooks(); inside the 'after_setup_theme' action instead of running it immediately. I’ll test that and roll out an update as soon as I sort it out.

Thanks also for the suggestion to add the function names/option keys to the documentation page… I’ve just done that.

Two changes were necessary:

1. Moving the two new hooks into the R34NoNo::add_hooks() method.

2. Replacing the direct $this->add_hooks() call in R34NoNo::__construct() with add_action('after_setup_theme', array(&$this, 'add_hooks'));.

I did a few spot tests to make sure that the new filters work both within custom plugins and within the theme, and that existing built-in functionality still works as expected. It’s looking good, so I’ve gone ahead and rolled out version 2.3.2 with these changes.

I just tested the filters in my theme again, this time with No Nonsense v2.40. And it worked: I could disable utilities and settings.

But I ran into a problem adding a setting using the following code:

add_filter('r34nono_define_settings_array', function($settings) {

	// Adding a setting
	$settings['erik_nono_test'] = array(
		'title' => 'Erik Nono Test',
		'description' => 'This is what my function does.',
		'hook_type' => 'action',
		'hook' => 'init',
		'priority' => 10,
		'pn' => 0,
		'group' => 'My Custom Heading',
		'show_in_admin' => true,
	);

	return $settings;
});

function erik_nono_test() {
	error_log('erik_nono_test');
}

The setting was nicely added to the interface, but I couldn’t enable it. The setting wasn’t stored to the database.

I think this has to do with delaying calling those hooks until after_setup_theme… they’re not running before R34NoNo::admin_page_callback() is processing the form data.

It’s kind of a chicken-and-egg scenario here, but I think I should be able to sort it out.

Nope; that wasn’t it… the issue is that the code only writes options to the database if their key starts with r34nono_. That’s an entirely reasonable thing for me to do when I’m running everything, but I shouldn’t expect developers using these filters to prepend all of their function names that way.

I did this mainly as a shortcut way to loop through the entire $_POST array but prevent things like the nonce getting written to the wp_options table. I need to rethink it a bit. Should have a fix available shortly.

OK… this is fixed in version 2.4.0.1, available shortly.

The only fields in $_POST on the admin page form submission that shouldn’t be written to wp_options are the two nonce-related fields. So instead of checking for the field key beginning with r34nono_ I now just specifically check that the key is not either r34nono-nonce-settings or _wp_http_referer and write all of the other fields.

Any security considerations around writing $_POST values to the database are already handled by sanitization functions (htmlspecialchars(), filter_var_array() and filter_var()) built into the existing logic.