I am confused… What does this accomplish?
Couldn’t your plugin simply hook the init action directly? What would you do differently in a db-table-editor_init action than you would in an init action? I certainly don’t mind adding actions if they are useful, but since this plugin doesn’t actually do anything at init time, I don’t see what a sub action is accomplishing.
Actually, you could launch your plugin initialization and code here, but even if this method is empty, it allows other plugins to work once yours is loaded. Plugins that allows extensions do it this way, as woocommerce for example. There is a lot of extensions for it.
The constructor launch this :
add_action( ‘init’, array( $this, ‘init’ ), 0 );
And in the init method :
public function init() {
// Initialization code here
do_action( ‘woocommerce_init’ );
}
So other plugins that are extensions launch this in the constructor :
add_action( ‘woocommerce_init’, array( $this, ‘load’ ) );
In this way, extensions are sure to have the plugin loaded before executing their own code that depends on the plugin.
With our plugins : mine needs your plugin’s method add_db_table_editor to be loaded. This is the only way to get certain of that. Otherwise, the function does not exist, not yet…
I hope it’s clearer this time, as english is not my native language…
Regards.
No worries, your english is very good 🙂 I think I understand what you are saying.
All plugins are already loaded at init time so for the current case, there is not a great need for a db_table_editor_init action. If my plugin *had* something it needed to do at initialization, then your plugin might need to wait till mine is initialized.
That said, it is arguably clearer for your code to have a direct action for this, rather than hooking init and checking for add_db_table_editor, so I am adding that hook and updating the documentation.
Thank you for the suggestion, look for version 1.3.2 soon