[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 =>


 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

 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