ideas
ideas copied to clipboard
wp-cli
Bundle runcommand/hook with WP-CLI core
It's a nifty tool for tracking down the callbacks on a hook:
$ wp hook wp_enqueue_scripts --fields=callback,location
+------------------------------------------------+---------------------------------------------+
| callback | location |
+------------------------------------------------+---------------------------------------------+
| wp_localize_jquery_ui_datepicker() | wp-includes/script-loader.php:928 |
| rest_register_scripts() | runcommand-theme/lib/rest-api/extras.php:22 |
| runcommand\Assets->action_wp_enqueue_scripts() | runcommand-theme/inc/class-assets.php:21 |
+------------------------------------------------+---------------------------------------------+
https://github.com/runcommand/hook
Yes, looks useful indeed.
wp hook does not fit into our noun verb scheme. We should think about how the hook noun could be used and what verb the above represents.
I can think of naming this wp hook get, with a wp hook list showing a filterable list of all hooks.
Do we need to make a distinction between actions and filters?
I can also see something like wp hook trigger <action> be very useful.
I think I'd prefer wp hook list <hook> solely, and that would list all callbacks registered to the hook.
Do we need to make a distinction between actions and filters?
No. They're functionally equivalent, only different in naming.
Wouldn't wp hook list rather list all actions/filters instead? If that is filterable, it would be pretty useful for development as well:
$ wp hook list plugin
activate_{$plugin} A Fires as a specific plugin is being activated.
all_plugins F Filters the full array of plugins to list in the Plugins list table.
muplugins_loaded A Fires once all must-use and network-activated plugins have loaded.
plugins_api F Filters the response for the current WordPress.org Plugin Installation API request.
plugins_loaded A After active plugins and pluggable functions are loaded.
plugins_url F Filters the URL to the plugins directory.
...
Wouldn't
wp hook listrather list all actions/filters instead?
The total known actions/filters are only known at runtime? There's no central registry of actions/filters to reference.
Yes, but given a URL, you could probably get the list of hooks that were triggered.
Yes, but given a URL, you could probably get the list of hooks that were triggered.
Right, and down the rabbit hole you go.
I still think it remains sensible to only list callbacks for a specified hook. Thus, the behavior of wp hook list is similar to wp config list
I think most of the code should match what you had written in profile-command.
wp config list lists all config entries (in a filterable manner), it doesn't provide details for one entry.
Hmm, I think we're just reading hook in different ways. You seem to read hook as "what a developer has hooked onto the WP lifecycle", whereas I read it as "the hooks WP provides to developers".
You seem to read
hookas "what a developer has hooked onto the WP lifecycle", whereas I read it as "the hooks WP provides to developers".
Oh, right. The latter is impossible to know, in my opinion. Even the former is difficult to know, because hooks can be context specific (e.g. only added upon execution of a specific code path). But, for the most part, I've found the existing implementation quite helpful.
Also, we have wp media image-size, which lists all image sizes, so I don't think wp noun verb is a hard and fast rule. More of a general guideline to follow, unless there's a reasonable alternative.
With this in mind, I'd still prefer wp hook.
FWIW, I'd love to see this in wp-cli. Always add this package to all my wp-cli instances.
