There are couple main considerations with options performance. How many options there are Every option with unique key is a row in options database. More rows makes table messier, but primarily for humans to work with. You’ll need to have crazy amounts of options to start making serious difference in performance. Are they autoloaded Options … Read more
I can’t see where the $option_name is declared, and don’t know what it contains. You are using that variable ($option_name) in the name attribute of the checkbox. You need to give to the name attribute of that checkbox field the name of your option. That is the second argument in the register_setting function. So if … Read more
I fixed it by: 1) checking wordpress version in: /home/myusername/public_html/version.php 2) downloading this version package from wordpress website 3) addingwp-includes/session.php file from downloaded package into /home/myusername/public_html/wp-includes/session.php (that file was empty or not existing)
I have tested your code and it is working fine. I hope you are checking the field on the right place. It should be and it is under Settings > General in your WordPress admin Just used the given code
The error message is actually misleading here. WP isn’t checking if the settings are registered — e.g., if ( isset( $GLOBALS[‘wp_registered_settings’][‘foo’] ) ) — it’s checking if the form was posted to the default options page (options.php), rather than a custom one (options-general.php?page=foo). So, it’s entirely possible to get this warning after calling register_setting(), if … Read more
take a look at https://tommcfarlin.com/multiple-sections-on-wordpress-options-pages/ You can… add_settings_section(“owlish_license”, “SECTION NAME”, null, “theme-options”); add_settings_section(“owlish_settings_group”, “SECTION NAME 2”, null, “theme-options”); add_settings_field(“owlish_display_notes”, “Display Notes”, “callback1”, “theme-options”, “owlish_license”); register_setting(‘owlish_settings_all’,’owlish_display_notes’); add_settings_field(“owlish_display_notes2”, “Display Notes 2”, “callback2”, “theme-options”, “owlish_settings_group”); register_setting(‘owlish_settings_all’,’owlish_display_notes2′); after you can use this wrapper on page settings_fields(“owlish_settings_all”); do_settings_sections(“theme-options”); Have a nice day.
Considering WordPress Codex flush_rewrite_rules This function is useful when used with custom post types as it allows for automatic flushing of the WordPress rewrite rules (usually needs to be done manually for new custom post types). However, this is an expensive operation so it should only be used when absolutely necessary.… I’d recommend you to … Read more
Nevermind, figured it out. Made the following changes: add_settings_section( ‘cp_required_info’, null, array($this, ‘cp_required_info’), ‘cp-settings-group’ ); add_settings_section( ‘cp_sync_info’, null, array($this, ‘cp_sync_info’), ‘cp-settings-group’ ); register_setting( ‘cp-settings-group’, ‘cp_admin_options’, array( $this, ‘sanitize’ ) ); <?php settings_fields( ‘cp-settings-group’ ); do_settings_sections( ‘cp-settings-group’ ); do_settings_fields( ‘cp-settings’, ‘cp_required_info’ );?> <!–Some HTML goes here–> <?php do_settings_fields( ‘cp-settings’, ‘cp_sync_info’ );?> ?>
Most likely your $options is a string and not an array. It is always better to validate that the $options are in the format you are expecting especially in development time when you are likely to switch formats and too lazy to clean the DB when doing that. something like if (!isset($options[‘hide_avatar’])) $options[‘hide_avatar’] = 0; … Read more
Settings API is (also) about the modularity of the settings, settings can be removed (never heard of anyone do it but it is possible) or amended (my favorite technique right now). When you separate the HTML and PHP you are breaking the modularity so maybe the setting API should just not be used by you. … Read more