Tag Info

Hot answers tagged

21

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 ...


16

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 ...


16

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 ...


9

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

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', ...


7

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 ...


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

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 ...


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 ...


7

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( ...


6

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 ...


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 ...


6

No, it is not. Use esc_html__( 'string', 'text_domain' ) instead (two underscores). Translated strings are unknown input. Unknown input is per default malicious. You don’t know where the language file comes from. It doesn’t even have to be the one you provided, because the path can be filtered or changed with a symlink. Even if it is your file: do you ...


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

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

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( ...


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 ...


5

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 ...


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 ...


4

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 ...


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

There are no hooks to modify the output of do_settings_sections(). Hence the only option you have is to write custom versions of the functions do_settings_sections() and do_settings_fields(). They are located in /wp-admin/includes/template.php, lines 1159-1174 and 1190-1207 (wordpress version 3.2.1), respectively (do not modify them there). You could (not ...


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

Look at your validation function (the one referenced by your register_setting call). Whatever it returns replaces the entire setting in the database. So if it's not getting the setting and then altering it and returning the entire setting, you'll lose the data that you didn't have it return.


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 ...


3

Instead of using add_settings_section() and add_settings_field() every time, create a function that returns an array of options for example: function my_theme_options() { $options = array(); $options[] = array( 'id' => 'ID', 'title' => 'Title', 'type' => 'text_field', // use this value to ...



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