You also raise some valid points about using current_user_can – I often forget that many WordPress users take advantage of roles – it’s important to make sure you’re not giving too much power to the underlings.

To make sure that the correct form is also getting submitted and the user actually was accessing the form, you can use a combination of ‘check_admin_referer’ and ‘current_user_can’. I initially left those out of my description because I didn’t really feel like bogging down my approach. You should be using those things anyways, though, regardless of how you check for submission.

I’m intrigued by your approach though – I definitely like the idea of using a $_GET variable to indicate an update, as it’s always helpful to tell the user what has been updated. I’m a little skeptical about running it on init though – since init runs on every page load, both front and back, we’re adding the extra overhead of checking for the $_POSTed variable on every page load – even ajax calls. Also – depending on what you’re doing, you’ll need to do some extra validation to make sure the call is coming from the right place, and whoever is making the call has the proper permissions to do so (again, because running from init, it could be accessible from the front end).

If I do need to do some extra data manipulation on posted variables from an admin page, I usually opt to put the code at the top of my admin panel display function, and post the form to itself with action=”". That way, I know the code is only going to be run from that particular admin page, and anybody trying to get to it from outside will have to deal with WordPress’ authentication functions.

I’d be interested to hear if I’m way off base with this though (heck, I’d be interested to hear if I’m even a little off base), and your thoughts about my concerns on running on init. New ideas always help, and you definitely seem to know what you’re talking about.

Either way, thanks for stopping by and commenting!