Since the layout names are dynamic, perhaps it’s better to store them in a numerically indexed nested array? Something like: wpv_settings[layouts][0][name] = $key wpv_settings[layouts][0][markup] = $value wpv_settings[layouts][1][name] = $key wpv_settings[layouts][1][markup] = $value …etc?
Here you go my friend: add_filter( ‘admin_init’ , ‘register_fields’ ); function register_fields() { register_setting( ‘general’, ‘msp_duration’, ‘esc_attr’ ); add_settings_field( ‘msp_duration’, __(‘Cache Duration’) ,’fields_html’, ‘general’ ); } function fields_html() { $value = get_option( ‘msp_duration’ ); $fields = array( array( “name” => __(‘Every 6 hours’), “value” => 60 * 60 * 6, ), array( “name” => __(‘Every … Read more
The issue, as determined by Chip Bennett in our conversation above, was related to the settings_errors() call. The problem was that I didn’t specify a setting for which I wanted to display either errors or update notices mostly because the tutorial from which I was working didn’t either. By specifying that setting, I see one … Read more
It depends on what the fields do. If they are all of the same type – a label and a text input for example – then, yes, that’s a good approach. You can just use the sixth parameter to create a different output. But if these fields are different, need different escaping methods (esc_textarea() versus … Read more
Given that you are dealing with email, I’d run wp_kses() with a very limited $allowed_html array similar to this sample from the Codex: array( ‘a’ => array( ‘href’ => array(), ‘title’ => array() ), ‘br’ => array(), ’em’ => array(), ‘strong’ => array(), ); HTML rendering is even more squirrelly in email readers than browsers … Read more
Because you mentioned the Settings API I assume you want to do AJAX from the admin area of wordpress. You have some research to do, so my answer is to check out these: http://dobsondev.com/2015/06/12/wordpress-ajax-example/ https://pippinsplugins.com/custom-database-api-reasons-for-custom-tables-and-an-api/ That should get you where you need to go. Happy WordPressing!
I’ve just run across this same issue myself on a project I am currently working on. Basically, what I did was break my settings into groups so they can then be displayed as a separate section(s): <?php class MyPluginSettings { /** * Constructor. * * @return void * @access public */ public function __construct() { … Read more
If you check the checkbox and save the plugin options it will add option to the {prefix}_options table in the database. To make a checkbox checked you need to update_option(‘option_id’, ‘value’ ) for that checkbox on plugin activation. to do that you need to register plugin activation hook. Place the below code in the main … Read more
You can hide it using jQuery which will be inserted in the wp-admin header: add_action( ‘admin_head’, ‘wpse_239421_hide_section’ ); function wpse_239421_hide_section() { ?> <script type=”text/javascript”> jQuery(document).ready(function($) { $(‘[scope=row]’).closest(‘tr’).hide(); } ); </script> <?php } This will remove the closet tr bases on the scope=row.
https://make.wordpress.org/core/2016/10/26/registering-your-settings-in-wordpress-4-7/ The register_setting() function signature changed in v4.7 allowing an array for the third option in place of a callback function in prior versions. Passing an array to register_setting() in WordPress v4.6.x and earlier will result in the errors above. WordPress v4.6.8 function definition: https://github.com/WordPress/WordPress/blob/1aa173010736085a921beb10fd420d6d863419a5/wp-admin/includes/plugin.php#L1767-L1795 /** * Register a setting and its sanitization callback * … Read more