[wp-trac] [WordPress Trac] #41346: Introduce a hook for individual plugin loaded
WordPress Trac
noreply at wordpress.org
Tue Jan 22 17:06:21 UTC 2019
#41346: Introduce a hook for individual plugin loaded
--------------------------------------+-----------------------------
Reporter: Rarst | Owner: SergeyBiryukov
Type: feature request | Status: reopened
Priority: normal | Milestone: 5.1
Component: Plugins | Version:
Severity: normal | Resolution:
Keywords: has-patch needs-dev-note | Focuses: performance
--------------------------------------+-----------------------------
Changes (by desrosj):
* keywords: has-patch => has-patch needs-dev-note
* status: closed => reopened
* resolution: fixed =>
Comment:
I am working on a dev note for these new action hooks and came across
something we should fix.
The inline documentation for the three new hooks says that the plugin
''basename'' is passed. In the current state of the code, this is not
correct. The full path to the plugin is actually passed instead. At a
minimum, the inline docs should be updated to accurately reflect that the
full path is passed.
While I don't necessarily think that passing the full path is bad, I don't
know that it is the most useful value to pass to this action. In writing
code examples for the dev note, I realized that targeting a specific
plugin in that action hook is not as straightforward as it could be.
For example, if I wanted to target code to only run when "myplugin" was
loaded, I believe that the best way to really write a conditional to
target that plugin in the current state would be as follows:
{{{
if ( false !== strpos( $plugin, 'myplugin/myplugin.php ) )
}}}
While not terrible, it is not ideal. The full path could be any number of
variations baed on server configuration and file structure and the plugin
directories can be changed by defining constants before core to name a few
of the issues that could come up. The following would be a much better
approach:
{{{
if ( 'myplugin/myplugin.php' === $plugin )
}}}
Thinking this through, there are a few options. First is to update
`wp_get_mu_plugins()`, `wp_get_active_network_plugins()`, and
`wp_get_active_and_valid_plugins()`, to accept an optional parameter to
return both the full path and the shorter plugin name. This seems too
risky, though. Especially this late in the release cycle, as these
functions have been around for quite a while.
The second option is to just reverse the string concatenation performed in
those functions before passing the value to the hook. Attaching a patch
with that approach for feedback.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/41346#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list