Default settings ignored in register_settings

  • I’m built a plugin, and set up its default settings with register_settings:

    
		register_setting(Add_Img_Maps::get_plugin_name() , Add_Img_Maps::get_plugin_name(), array(
			'default'=> array(
				'header' => 1,
				'content' => 1,
				'thumbnail' => 1,
				'imagemapresizer' => 1,
				'srcset' => 'off',
				)
		));

    (And yes, I’ve confirmed that the function is called.)

    The options page is displayed by a partial .php file which calls get_options. But when I installed the plugin on a fresh site, no options were set, srcset which is an either/or radio button setting.

    The options page works apart from this, which makes this a trivial-impact bug. Which is just as well, because I don’t have the kind of virtual machine setup which would let me instantiate new WordPress installations to test this out on. (Settings persist even when I uninstall the plugin, despite a proper uninstall script, which is another trivial-impact issue.)

    I’ve checked that the activate() function is called, the register_settings documentation, and that the key matches the get_options call. What else should I be checking?

    The zipfiles on the release page can be imported directly into WordPress.

    The page I need help with: [log in to see the link]

Viewing 4 replies - 1 through 4 (of 4 total)
  • Moderator bcworkz

    (@bcworkz)

    There’s more to adding and saving option settings than merely registering a setting. Please review the Settings Section in the Plugin Handbook. It has a complete example you can use for reference.

    You mention that you don’t have a virtual machine for testing. Maybe you should ?? Developing on a live site is problematic at best. Once you’ve started developing on a local installation, you’ll never go back. A lot of devs swear by Local by Flywheel. I’ve no experience with it myself, but that’s what I hear. This is unrelated to your options issue and it’s not my place to tell you how to work, but it pains me to hear that someone is struggling by working on a live installation. A local install is SO much better! It’s worth making the effort to set up. it’s not even that difficult.

    If nothing else, you could setup a separate installation in a sub-folder of the site you are currently using. But local will be much better.

    It has a complete example you can use for reference.

    Are you referring to this one? –> https://developer.www.ads-software.com/plugins/settings/using-settings-api/#example

    Because that one doesn’t register defaults.

    This one, however, does… –> https://developer.www.ads-software.com/reference/functions/register_setting/

    But that code is considerably different. I am confused about which is the proper example here. Thanks.

    Moderator bcworkz

    (@bcworkz)

    Hi kjodle = Yes, I was referring to the #example in the Plugins Handbook, and no it does not setup any defaults. It’s a basic example. Not all settings necessarily have defaults.

    I’m not sure which code you’re referring to on the register_setting() reference page. I think you mean this user note (currently the last one). It does register a default even if it’s just NULL. You could add that $args assignment to the Handbook’s #example before calling register_setting(), passing $args as the optional 3rd parameter.

    If you do use the user note code to declare a default, consider if sanitize_text_field() is the proper sanitation callback for your field. It may be appropriate, or it may be you need to write your own sanitation callback. It depends on the exact nature of your field. Not only should user values be escaped, but should be restricted and validated to any extent possible. For certain fields, perhaps limiting input length to a certain range might be appropriate. In other situations, maybe escaping is all you can do. Other restrictions may not be appropriate.

    Thread Starter Ian McDonald

    (@drianmcdonald)

    Thanks for your help. I tracked this down. A line of documentation had let me to confuse [un]register_setting (Settings API, runtime) with delete_option (Options API, persistent).

    Local by Flywheel looks interesting, though I don’t think I’ve got the hardware for it right now.

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Default settings ignored in register_settings’ is closed to new replies.