Does wordpress clean up your action hooks? - wordpress

I've written a Wordpress plugin. I hook to some actions from another plugin and everything works, but I want to know, when I deactivate my plugin, do these actions still get called and executed, or does Wordpress remove them automatically?
I tried removing actions on deactivate hook, but something doesn't make much sense to me. I'm using OOP.
When adding an action, I add the callable with an array like this in a registerActions function:
add_action('gform_validation_' . $form_id, array($this, 'formValidate'));
and remove it in unregisterActions function:
remove_action('gform_validation_' . $form_id, array($this, 'formValidate'));
My problem:
The registerActions and unregisterActions functions are called to different instances of the same class. Is remove_action actually removing the same action I've created?
I couldn't find anything discussing this on the internet and it really left me wondering.
Edit: I guess I could store the instances and actually call the registerActions and unregisterActions functions on the same instance. But how do I do it properly? I could also make action functions static.

Related

add_action in different location - Wordpress

I have a function that when it comes to calling from another plugin I call it this way
add_action( 'du_postSaveEvent', [ 'Lever\Api\Providers\ShareService', 'postSaveEvent' ], 10, 3 );
This works while in a plugin path.
/public_html/wp-content/plugins/
But if I call it from a page that is in
/public_html/wp-content/themes/
the thing changes and I can not execute said action
How should the action change?
The function to call is inside a plugin and has this structure.
public static function postSaveEvent ( $new_status, $old_status, $post ) {
}
Note:
That is, if I call that function from another plugin that is inside the plugins/ folder works.
But if I call it from a page that is in themes/ it doesn't work.
This is most likely because in the WordPress lifecycle, plugins are loaded before the themes and can therefore execute code earlier and access more lifecylce hooks which are not available for themes.
Depending on when the hook "du_postSaveEvent" is executed, you will not be able to access it via theme, because when the theme is loaded the code already ran.
You find the lifecyle docs here:
https://codex.wordpress.org/Plugin_API/Action_Reference
If you develope a plugin that runs hooks with "do_action", it is best to implement them in a hook that is run after the "after_setup_theme".
(e.g. 'init')
If you don't have access to when "du_postSaveEvent" is ran, you best use a plugin to add more functions to it. Since there is no way for your theme to access it.

add_action() in wordpress uses php file name as first parameter. What does it mean?

Recently I am trying to understand the codebase of a custom wordpress plugin.
Some syntax of add_action() looks confusing to me.
add_action( 'after_plugin_row_wc-smart-cod/wc-smart-cod.php', array( $this, 'add_warning' ) );
I know the first parameter of add_action() is the name of the action to which the function 'add_warning' of $this object is hooked.
But in the above example the first parameter is the name of a php file, instead of an action name.
What does it mean ?
Thanks.
The first parameter to an action is a string. Generally it is something like wp_footer or before_send_email but there really isn't any restrictions on it. For instance, in my company's code, we often use slashes to give the action a (fake) namespace such as company/plugin-name/class/action but this is 100% arbitrary from WordPress's perspective.
Back to your example, however, there actually is a specific pattern from WordPress for that specific hook which you can see here. Every plugin in WordPress has an "entrance" or "plugin" file that boots up the entire plugin. Because most plugins live in a sub-folder, it is often plugin-name/plugin-name.php or plugin-name/index.php but it is ultimately up to the plugin author.
Most people use that specific action to add special messages to their own plugin's row in the general listing of plugins. The plugin you mentioned is using it to give a warning to users with a very specific version of the plugin installed.

Restoring 'post' post-type via a child theme

I am working with a client who has chosen a theme which looks nice but actual removes a lot of WordPress functionality. Whether or not it is deliberate, it has removed the post type of 'post'. I found the hook they used to do this but unfortunately, they added it via a closure not a callback.
Below is a sample piece from the theme:
add_action('admin_menu', function () {
remove_menu_page("edit.php");
remove_menu_page("edit-comments.php");
}
});
The scenario is that I am creating a child theme to add back the WP functionality. The only way I can think to restore this is by adding another action that uses add_menu_page. I just don't really know how to restore it.
I may have to switch themes but they really like this one aesthetically. Guess the downside is that it reinvents the wp-admin backend. It wants us to add data through it's interface and not through the traditional 'post' and 'page' post types.
Anybody have any solutions?
I see only one solution - absolutely remove hook admin_menu and after do full restore (without closure). Of course, need more read and learn about hook admin_menu before operating. You can start from remove_all_actions
Solution No.2:
If closure callback is one in parent theme you can to use simple 'closure' remover :)
//remove closure callback
$hooks = $wp_filter['admin_menu'][10];
foreach ($hooks as $key => $value) {
if (preg_match('|^\d|', $key))
//closure's always started from 00000....(??)
remove_action('admin_menu', $key);
}

WordPress functions.php: how to apply update_option()?

I'm trying to set the default Image Link URL for my WP users so that it doesn't include the url link as a default. I've done some research, and I know the function is in the wp-admin/options.php:
update_option('image_default_link_type','file');
Rather than mess with the core files, I'd like to put this into the functions.php, but never know the proper way to implement stuff like this! This is what I have so far in my functions.php:
<?php
update_option('image_default_link_type','none');
?>
This obviously doesn't work: it needs the proper setup! What is the correct way to implement this in functions.php?
Also: I'd like to know the strategy for figuring out how to implement functions like this in the future by myself? For example, I never know whether or not I'm supposed to use add_filter or do_action, and how I need to pass the parameters. I've yet to find a book or post out there that explains this very well, and can show me by example. Any good leads on this would be awesome too!
Start with the Wordpress codex. Visit the plugin API (which is really what you are doing) that explains Hooks, Actions and Filters. Then see the Action Reference which provides your list of hooks.
Here you will find the hook update_option_OPTIONNAME. Description from codex:
Runs after a WordPress option has been update by the update_option
function. Action function arguments: old option value, new option
value. You must add an action for the specific options that you want
to respond to, such as update_option_foo to respond when option "foo"
has been updated.
Adding code from asker's comment:
function inventory_linkurl_setting() {
update_option('image_default_link_type','none');
}
add_action('admin_init', 'inventory_linkurl_setting'); ?>

finding do_action function

I've got this.
do_action( 'bp_before_directory_groups_list' );
and I cant find the corresponding add action to trace the function that is called. Anyone know what im doing wrong?
Mark
Maybe there isn't one, as it may be just there so as to enable other plugins to hook into it But to check, run this code after loading all the plugins, like in a theme file:
print_r($wp_filter['bp_before_directory_groups_list']);
$wp_filter is a global variable that stores all the action hooks and filters added by plugins.

Resources