One problem with the way WordPress handles hooks is that to remove a specific hook with an OOP callback, you must have access to the exact same instance of the class as when the callback was added. This is generally easy enough to handle in your own plugins/themes. However, it makes it nearly impossible to … Read more
From Codex: Plugin API – Action Reference – profile_update: Note: This hook is not used on user edit/profile pages. To hook into the admin’s user edit pages, use the hook edit_user_profile_update which is located in /wp-includes/user-edit.php instead. From Codex: Plugin API – Action Reference – edit_user_profile_update: This hook only triggers when a user is viewing … Read more
Hi @Jonathan Sampson: While this is not exactly what you asked for it might actually be a viable solution and it comes for free from WordPress.com thanks to @yoast‘s tweet this morning when he referenced this blog post: An Automated Way to Take Screenshots of any Website – Free Basically you can use WordPress.com’ screenshot … Read more
I wonder if you’re looking for this one: /** * Fires after the user’s password is reset. * * @since 4.4.0 * * @param object $user The user. * @param string $new_pass New user password. */ do_action( ‘after_password_reset’, $user, $new_pass ); It was introduced in WordPress 4.4 and lives within the reset_password() function. The after_password_reset … Read more
The wp_trash_post hook might be what you’re looking for: Fires before a post is sent to the trash. Also, there’s the trashed_post hook: Fires after a post is sent to the trash. Here’s some untested code to get you started: function my_wp_trash_post( $post_id ) { $post_type = get_post_type( $post_id ); $post_status = get_post_status( $post_id ); … Read more
The problem is that your actions are being run in the order you perceive but the styles are just being collected by WordPress and included in a random order. The order of your add_actions will not be important. I would do this: function add_all_stylesheets() { // you omitted this from your question, see below } … Read more
They were both introduced in version 2.9, but were done so in different files. update_postmeta went into /wp-admin/includes/post.php While… update_{$meta_type}_meta went into /wp-includes/meta.php It was only later that update_postmeta was shifted into /wp-includes/meta.php. So I believe it was for backward compatability, where by because the update_postmeta hook was always receiving the value of maybe_serialize() then … Read more
In my projects I do it like that PHP function foo() { echo ‘bar’; } add_action(‘wp_ajax_foo’, ‘foo’ ); // executed when logged in add_action(‘wp_ajax_nopriv_foo’, ‘foo’ ); // executed when logged out Javascript data = { action: ‘foo’, avalue: ‘some value’, ‘anothervalue’: ‘another value’ }; jQuery.post(ajaxurl, data, function(response){ alert(response); });
There is the filter ‘pre_update_option_’ . $option. You have to know the option name. Options can be updated from front-end too, so WordPress doesn’t make a difference here. Then there is an action: ‘update_option’, you get the arguments $option, $oldvalue and $_newvalue. Finally, if the update went successful, you get two further actions: do_action( “update_option_{$option}”, … Read more
If you look at the code for wp-login.php both the login case and the default case run wp_signon(). The reason, so it seems to me, is to manage cases where a user already has a valid cookie for the site. So I don’t think there is a hook that fires only upon login, but it … Read more