[wp-trac] [WordPress Trac] #24205: is_plugin_active() should return true for must-use/dropin plugins

WordPress Trac noreply at wordpress.org
Thu Sep 3 22:09:17 UTC 2015


#24205: is_plugin_active() should return true for must-use/dropin plugins
-------------------------------------------------+-------------------------
 Reporter:  jrf                                  |       Owner:
     Type:  enhancement                          |      Status:  reopened
 Priority:  normal                               |   Milestone:  Awaiting
Component:  Plugins                              |  Review
 Severity:  normal                               |     Version:  3.5.1
 Keywords:  has-unit-tests has-patch dev-        |  Resolution:
  feedback                                       |     Focuses:
-------------------------------------------------+-------------------------

Comment (by dd32):

 I still feel like this is probably a wontfix, although I agree with the
 logic of this:
 > When someone uses the is_plugin_active() function, one would expect
 must-use plugins to report true as - like you say - they don't need
 activation, they are *always* active when loaded that way.

 Where I differ however, is that `is_plugin_active()` is based upon the
 'plugin slug' in the plugins directory, which for most plugins is `plugin-
 name/plugin-name.php`. `mu-plugins` however have no idea of directories,
 supporting only `plugin-name.php`.

 Of course `plugin-name.php` is also a valid plugin in both `mu-plugins`
 and `plugins` though.

 I feel as if, `is_plugin_active()` is designed more to be a site option,
 where as a `mu-plugin` is designed to be more of a server/system-level
 configuration, as such, I wouldn't expect `is_plugin_active()` to be true
 for those cases.

 Based on the patch above, I have a few concerns
  * Adding a `$check_all` parameter makes it not a drop-in enhancement,
 effectively making it require opt-in from every plugin limiting it's
 usefulness
  * Checking for bootstrap functions, ie. `plugin-name.php` when `plugin-
 name/plugin-name.php` is selected feels too magical, and is bound to
 break. For example, `wporg-plugins-loader.php` might load `something-
 special/special.php` and other such things
  * If a plugin has to opt-in, it can, and should, just go ahead and use a
 proper feature detection (such as `file_exists()`).

--
Ticket URL: <https://core.trac.wordpress.org/ticket/24205#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list