How many plugins do you use that have a small number of config settings that you almost never need to go back to? These plugins might help prevent spam, add a widget, or shortcode; they have settings but, crucially, don’t need tweaking or changing very often, if at all. What a waste it is for these plugins to create new admin pages just for that. Well here’s an alternative.
Take a look at this entry from my plugin page:
This entry has an extra action: configure. Selecting configure opens panel beneath the entry containing the basic configuration options letting you change the settings from the plugin page itself, and without requiring the addition of another admin page.
You can download this sample plugin at the end of this post, but here is an explanation of how you achieve this in your own plugin.
There are four parts to this technique:
I’ll explain these in turn.
When the table loads that lists all the plugins an action (after_plugin_row) is triggered imediately after each row. This action passes three values: the filepath of the plugin, the basic details of the plugin, and the state of the plugin, so whether it is active, inactive, or recently active.
Adding the form means checking against these to ensure that the form is inserted at the right point and outputing the form itself:
[php]
add_action("after_plugin_row", array(&$this,"add_config_form"), 10, 3);
function add_config_form($pluginfile, $plugindata, $context){
if ( $plugindata['Name'] == 'Plugin Config Sample' && $context == 'active' ) {
?>
}
}
It is important to note that the plugin page is effectively one big form. This means that you can't use an actual form to make the update, which is why there are no form tags in the function above. You will need to Ajax to get the data and submit it.
The plugin also adds some CSS so that the form is hidden by default which means we need javascript to make it visible.
Using jQuery it is very easy to work back and insert the configure link, the javascript is included in the sample plugin below so I won't spit it out right here.
The final part is using Ajax to actually update the plugin.
Jquery includes some really easy functions for using ajax so the following is all I have used:
[js]
$('#pcsc_config_submit').click(function(){ pcsc_config_update()});
function pcsc_config_update(){
//get the important value
API_Val = $('#pcsc_config-API').val();
//set the url
url = '/wp-admin/admin-ajax.php';
//add the action and the actual value
$.post(url , { "action" : "pcsc_config-update" , "pcsc_config-API" : API_Val }, function(d){
if ( d == 'updated' ) {
//show the updated message
$('#pcsc_message').show();
}
});
}
The important point to note here is the URL and the action value. By sending the request to admin-ajax.php and including an action name (pcsc_config-update) you can use a hook to handle request.
The following code in the plugin handles the request:
[php]
add_action("wp_ajax_pcsc_config-update", array(&$this,"save_config"));
function save_config(){
if ( !update_option('pcsc_config-API' , $_POST['pcsc_config-API'])){
add_option('pcsc_config-API' , $_POST['pcsc_config-API']);
};
die('updated');
}
Note the hook that calls the save_config function is 'wp_ajax_' + the action specified in the ajax call. The function updates the option and then dies and echos 'updated'. Looking back at the javascript, it tests for the value updated in the return data and makes the success message visible if it is there.
Obviously a real world scenario would include validation, error handling, and nonces.
You can download the example plugin here, it is very basic, just enough to demonstrate the technique, but hopefully you will consider this method next time you make a plugin that doesn't require much configuration. This will help to make WordPress a little less cluttered for everyone.
The 2.7 version of my Fun with Plugins, plugin generator, will include this has an option.
Update:I've just been pointed toward a filter that I overlooked (odd as I looked for something that did this specifically) which means extra actions can be added to the action list without the use of Javascript which is excellent news. Details of the filter: plugin_action_links can be found at Nerdaphernalia.
Because of this I have updated the plugin to include an alternative options as well. Option 1 is the javascript link, the second option will link to the settings page, but doesn't add an admin menu, so there is still only one link to it.
(__)
`
Frank, I'm not quite sure which bit of it you don't know so I have tried to guess.
You need to add a new value in the jquery using
if ($('#secure_wp_index').is(':checked'))
{
SecureWP = 1;
} else {
SecureWP = 0;
}
Then add it to the post object right after “pcsc_config-API” : API_Val, so you change that to read:
“pcsc_config-API” : API_Val , “SecureWP” : SecureWP
you can then check what value is set in PHP using $_POST['SecureWP'] == 1
(__)
`
THanks for yout time. I use thsi in php/html
<input type="checkbox" name="secure_wp_index" id="secure_wp_index" value="1" <?php if ( $secure_wp_index == '1') { echo "checked='checked'"; } ?> />Wth this is it possible to save the value of the checkbox. How i make this in the form with wp_ajax?
(__)
`
Which part is it that you are have a problem with? Is it the javascript side, or the PHP side?
(__)
`
Nice workflow and i like this.
I have tested this code and i have a probelm, maybe you can help me?
How it is possible to use a input-field type checkbox for update the vaule in options?
I can't see the resoltion.
Thanks!
(__)
`
[...] the weekend, I happened to come across a post written by Andrew Rickmann which showcased an idea to create a configure link next next to the usual Activate/Deactivate Edit [...]
(__)
`
[...] Keith and I dissect the news of the week. Jacob Santos was cool enough to call in to confirm that Andrew Rickmanns idea of placing a configure link inside of the plugin management panel would be included in the [...]
(__)
`
[...] Keith and I dissect the news of the week. Jacob Santos was cool enough to call in to confirm that Andrew Rickmanns idea of placing a configure link inside of the plugin management panel would be included in the [...]
(__)
`
[...] Keith and I dissect the news of the week. Jacob Santos was cool enough to call in to confirm that Andrew Rickmanns idea of placing a configure link inside of the plugin management panel would be included in the [...]
(__)
`
[...] Keith and I dissect the news of the week. Jacob Santos was cool enough to call in to confirm that Andrew Rickmanns idea of placing a configure link inside of the plugin management panel would be included in the [...]
(__)
`
[...] Keith and I dissect the news of the week. Jacob Santos was cool enough to call in to confirm that Andrew Rickmanns idea of placing a configure link inside of the plugin management panel would be included in the [...]
(__)
`
[...] the weekend, I happened to come across a post written by Andrew Rickmann which showcased an idea to create a configure link next next to the usual Activate/Deactivate Edit [...]
(__)
`
[...] Keith and I dissect the news of the week. Jacob Santos was cool enough to call in to confirm that Andrew Rickmanns idea of placing a configure link inside of the plugin management panel would be included in the [...]
(__)
`
[...] Keith and I dissect the news of the week. Jacob Santos was cool enough to call in to confirm that Andrew Rickmanns idea of placing a configure link inside of the plugin management panel would be included in the [...]
(__)
`
[...] Keith and I dissect the news of the week. Jacob Santos was cool enough to call in to confirm that Andrew Rickmanns idea of placing a configure link inside of the plugin management panel would be included in the [...]
(__)
`
[...] few posts ago I wrote about the option to add a configuration form to the plugins page to avoid cluttering up the admin space. Jeffro picked up this post on Weblog Tools Collection and [...]
(__)
`
I doubt this debate will end any time soon Jeffro. It would be nice to be told to put config panels in place A (as distinct from adding extra capabilities which is fine to go wherever they should go) but that isn’t the WordPress way.
For sure there will be people who will think the plugin page is a stupid place to put config details as it takes it out of the menu system and others who think that is precisely why it is a good idea.
(__)
`
They may have the option, but what happens if this becomes yet another place I have to browse to, to see if the plugin settings link is there or not. I wish plugin authors would settle on a one stop shop where all configuration links are located.
Although I understand that because of how some of the administration panels are named, settings links sometimes don’t belong in a certain menu versus others. This is a usability issue. Still, I’d like to see some sort of unofficial standard to make the end users life a little less complicated.
(__)
`
I figured you had probably put that forward at some point given the way Habari works (i.e. very well) but given the newfound desire to make WordPress usable I thought it might be a welcome addition.
My prefered method of reducing the jumble is to require people to learn how to change variables at the top of plugins but I don’t think that would go down too well. :-)
It is quite simple to do so I’m not even sure it is necessary in the core. If people can see how to do it quickly and easily then they have the option.
(__)
`
See, there’s a good idea. I had it back in 2006. That WordPress doesn’t include such an obvious idea, even at the suggestion of its users (and developers), is one major reason why Habari exists.
I actually suggested several options for reducing the menu jumble that plugins inevitably produce. One alternate solution was a unified page of one-off options for small plugins. The trouble was, you had to install a plugin to display the unified options, and explicit plugin dependencies didn’t exist, so if you didn’t code an alternate way to display your plugin options, your plugin had no config!
Maybe you can get more traction for the concept and have it integrated into WordPress core code. It’s hard to get developers to universally use something that requires more code because the core software won’t support it for some reason.
Sorry to invade your WP with Habari, but reading your recent twitter exchange, I know where your ideas spawned from. ;)