Tag Info

Hot answers tagged

17

Short answer: your name attribute values must use the schema option_name[array_key]. So, when you use … <input name="option_name[key1]"> <input name="option_name[key2]"> … you get an array as option value in your validation function: array ( 'key1' => 'some value', 'key2' => 'some other value' ) PHP does that for you, this is ...


15

if you look at the do_settings_sections function more specifically the line 1164 where the callback function is being executed : call_user_func($section['callback'], $section); you can see that the $section array is being passed to the callback function, so you can identify the callback by the $section['id'] hope this make since. Update here is an ...


12

The premise of the question is flawed. The Customizer API is not an options API, but rather an options preview API. The Customizer API relies on either the Settings API or the Theme Mods API to register controls for existing settings added via either of the two APIs. The Customizer does not - and cannot - define/register new settings that have not already ...


8

WordPress will not do any data sanitization for you. It does do sanitization/validation of the default options. You have to pass in the third argument of register_setting and either role your own validation callback or or use one of the builtins. If your options is only going to contain a string, you could do something like this, for instance. <?php ...


7

There are several components to error/notice creation and display process: add_settings_error() call to add item to stack (global $wp_settings_errors variable). settings_errors transient that keeps the errors so they survive move from page to page. settings_errors() function get_settings_errors() to retrieve errors from memory or transient and then ...


7

You're absolutely right that you can pass reusable form field markup to add_settings_field(). The trick is to define the data type for each setting, and then pass the same callback to each call to add_settings_field(). Within that callback, you simply add a switch that includes cases for each data type. Here's how I do it in Oenology: First, I dynamically ...


6

That's because your options are stored as a serialised array, in one row with name XX_theme_settings. To update one option, you would still need to retrieve the existing settings, ammend the appropriate value and update all options in your array together. For example: $my_options= get_option('XX_theme_settings');//retrieve all options ...


6

My point of view is that main purpose and benefit of Settings API is structure. It helps to keep complex settings setups: orderly (logic of registration and sections); secure (nonces, validation callbacks); extensible (hooking into another page or allowing to be hooked into). As with any such structural overhead it benefits more complex use cases and ...


6

If you wrote your code correctly, then delete_option would be the correct way. The question isn't how to clear the option; the question is how to structure your code such that the "option does not exist" case is a valid case. Think about it. The first time you start this code, that option isn't going to exist at all, right? Your code should be perfectly ...


6

The page content for custom backgrounds is created in wp-admin/custom-background.php. There is no action available where the fields are printed. To add new fields we have to print JavaScript into the page footer. The action is 'admin_footer-appearance_page_custom-background'. To save those field values we have to hook into ...


6

For network option pages the correct form action URL is: wp-admin/network/edit.php?action=your_option_name Then you have to register a callback: add_action( 'network_admin_edit_your_option_name', 'your_save_network_options_function' ); In that callback function inspect the $_POST data, prepare the values, then save them: update_site_option( ...


6

If there is problem only with html markup you should check example from official jQuery UI site here: http://jqueryui.com/tabs/ It looks like yours, but for work you must check if your site include stuff like jquery and jquery ui script, jquery css is important too. After that you should have script with: $( "#tabs" ).tabs(); And everything should work ...


5

You have to call add_settings_section() first, pass a unique ID and assign it to the page (poor name) discussion: add_settings_section( 'ads_id', 'Extra Settings', 'ads_description', 'discussion' ); Then register a callback to save your field(s) … // Register a callback register_setting( 'discussion', 'ads', 'trim' ); … and then register ...


5

What you need to do is build your own data validation function. Ozh wrote a great tutorial about this earlier, but here's the gist of it ... Assume your options array is called $my_options and it contains three fields, 'text', 'age', and 'isauthorized'. You would still register it the same way: register_setting( 'my_setting', 'my_options', ...


5

You need to add a name attribute to your editors. The name attribute needs to be set to the value of of your option, so like this: function us_partners_cb() { $us_partners_desc = get_option( 'us_partners_desc' ); echo wp_editor( $us_partners_desc, 'uspartnersdesc', array('textarea_name' => 'us_partners_desc') ); }


5

Why does the Settings API send those parameters when submitting the settings form? Quite frankly, it doesn't. As you already mentioned, your form simply POST's to options.php, which in turn handles the request, updates the database, and then redirects back to the referer. How the referer is fetched is down to the function wp_get_referer(); function ...


5

If you use callbacks properly, there's no need for all the redundant code. Here's how I implement the Settings API, in a way that is completely scalable. Advantages (among other things): The Settings API forces sanitization of untrusted user data. The Settings API forces options to be registered as an options array, resulting in a single wp_options DB ...


4

The reason is that if you are on page 1, the data that is posted to be saved is an array of the form: XX_theme_settings=array('XX_Option1' =>'input1','XX_Option2'=>'input2',...) and contains no data from page 2. This is because the input from page 2 is not posted with it (since it wasn't in the same <form> - it's not on the page). Thus when ...


4

You need to pass last parameter $args, if you want add_settings_field to output <label> use `label_for' argument, see code snippet below <?php add_settings_field( 'my-id', 'Test Filed', 'mamaduka_test_field', 'general', 'my-section', array( 'label_for' => 'my-test-field' ) ); ?>


4

Using $_POST is too low level. Simply give it the same name as your other options. When you options are displayed they should have the names of the form: my_settings[a_particular_option]. For instance: <input name="my_settings[some_input_option]"/> Then for your hidden input and submit button: <input type="hiddden" name="my_settings[foo]" ...


4

As simple as things can sometimes be: The Settings API is not the Theme Customizer. Both are different things for different tasks. Settings API You're either writing a plugin or have a theme that doesn't have options that won't need any visual feedback? Go with this option. Theme Customizer You need to have options that have a visual impact that the user ...


3

I know this is an old question but I'll throw my two cents in, just in case someone else comes along; a simpler way to do so would be do write you own modification of the add_settings_section() function, which would only add a callback args parameter at the end of it. This would look like this ( or something like it ) function my_add_settings_section($id, ...


3

You need a second form with admin_url('admin-post.php') as form action. Then you can hook into admin_post_custom_action to execute your action. Sample code: add_action( 'admin_post_wpse_79898', 'wpse_79898_test' ); function wpse_79898_test() { if ( isset ( $_GET['test'] ) ) echo esc_html( $_GET['test'] ); die( __FUNCTION__ ); } In your ...


3

If you want to do this with options, save the routes as an array rather than individual options, or save the number of routes in an option so you can dynamically create and fetch them by building the option names based on the number you save. However, rather than saving this stuff in options, I would make a route custom post type. Route data would be post ...


3

When in doubt, look at the source code. Digging in to get_option(), you'll see (abbreviated): $value = wp_cache_get( $option, 'options' ); if ( false === $value ) { $row = $wpdb->get_row( $wpdb->prepare( "SELECT option_value FROM $wpdb->options WHERE option_name = %s LIMIT 1", $option ) ); // Has to be get_row instead of get_var because ...


3

Yes, you can and it's easier using a Class. In the admin_init hook (where the Settings API is being registered and defined) set a class property based on the user ID: $this->prefix = 'uid_' . get_current_user_id() . '_'; Then, in the rest of the code, refer to your option name as $this->prefix . 'option_name'. The result in the table wp_options ...


3

Fetch current options, and be sure to return an array if empty: $current_options = get_option( 'option_name', array() ); Ensure desired options are in an array: $desired_options = array( /* whatever you need goes here */ ); Merge them, using [wp_parse_args()]1: $merged_options = wp_parse_args( $current_options, $desired_options ); Update ...


3

Use the filter update_option_{$option}. It runs after a successful saving. $option is the name of your option, and you get the old and the new value as parameters. From wp-includes/option.php: do_action( "update_option_{$option}", $oldvalue, $_newvalue ); Use it like this for an option wpse_themesettings: add_action( ...


3

If the setting in question is $setting, and is a checkbox type, you validate it like so: <?php $valid_input[$setting] = ( isset( $input[$setting] ) && true == $input[$setting] ? true : false ); ?> In this case, $input is the form data passed to the validation callback, where $input is an array-of-arrays. The validation method is known as ...


3

If you have an options page (which should be inside one form), then all data is sent from that form, regardless of whether or not the option has been changed. The array received for validation is the data received from (your part of) the form. If the data is 'empty' it is because the data wasn't sent. Normally this would be because the user has deliberately ...



Only top voted, non community-wiki answers of a minimum length are eligible