WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 5 years ago

#24205 closed enhancement (wontfix)

is_plugin_active() should return true for must-use/dropin plugins

Reported by: jrf Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.5.1
Component: Plugins Keywords: has-patch has-unit-tests
Focuses: Cc:

Description

As must-use plugins/dropins are automatically active, the expected behaviour for is_plugin_active() would be to return true. In reality it returns false.

Easy enough to reproduce and test - just add a plugin to the must-use directory and test with:

if( is_plugin_active( 'plugin-name.php' ) ) {
	echo 'plugin is active';
}
else {
	echo 'plugin does not seem to be active';
}

Hope this helps

Attachments (4)

24205.patch (1.0 KB) - added by rcoll 7 years ago.
add second arg and on true will search other locations
24205.2.patch (1.0 KB) - added by noam@… 7 years ago.
Sane default
0001-Patch-for-issue-24205-is_plugin_active-should-return.patch (9.4 KB) - added by jrf 5 years ago.
24205.diff (3.9 KB) - added by swissspidy 5 years ago.

Download all attachments as: .zip

Change History (22)

#1 @nacin
7 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

must-use plugins and drop-ins don't have a concept of "activation".

If you want to see if a plugin is active on a site, is_plugin_active() is a poor way to do it. The path can be anything. A plugin could be installed at test-plugin/test-plugin.php, test-plugin.php, or some-totally-different-name.php. You should look for a function, class, etc.

#2 follow-up: @jrf
7 years ago

Hi Nacin,

I totally agree that there are better ways to test for it, however that does *not* invalidate my report.
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.

Smile,
Juliette

#3 in reply to: ↑ 2 @MikeSchinkel
7 years ago

Replying to jrf:

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.

There's definitely some solid logic here...

#4 @knutsp
7 years ago

Because the must-use plugins and drop-ins can't be deactivated, once installed, the function should return true. It would make it more useful, telling that these extensions are installed, and therefore active.

But it isn't a bug. It's an enhancement. Suggest a new ticket.

#5 @SergeyBiryukov
7 years ago

  • Milestone set to Awaiting Review
  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Summary changed from is_plugin_active() returns false for must-use/dropin plugins to is_plugin_active() should return true for must-use/dropin plugins
  • Type changed from defect (bug) to enhancement

#6 @jrf
7 years ago

Call it whatever you like ;-) The re-open is much appreciated <3

@rcoll
7 years ago

add second arg and on true will search other locations

#7 @rcoll
7 years ago

  • Keywords has-patch added

Added patch will accept a second (optional) boolean argument and check mu-plugins and drop-ins on true. This way, we retain full backward-compatibility as well as accommodate the added functionality.

@noam@…
7 years ago

Sane default

#8 @noam@…
7 years ago

Added sane default.

$check_all now defaults to true.

#9 @jrf
6 years ago

Just realized... this of course also applies to is_plugin_active_for_network() for mu-plugins in a multi-site environment.

#10 @jrf
5 years ago

  • Keywords has-unit-tests added

Added a new patch based on @rcoll's patch for the same.

Improvements/Changes:

  • Use the more efficient wp_get_mu_plugins() function instead of get_mu_plugins()
  • Allow for bootstrapped MU plugins
  • Make it work too for is_plugin_active_for_network() and is_plugin_inactive()
  • Added relevant unit tests
  • Made the wp_get_mu_plugins() function slightly more efficient as reading directories is expensive and the function might now be called several times
  • Made the touched functions comply with code style guidelines
  • Checked all core uses of the touched functions (and kept the $check_all default set to false to prevent having to change nearly all uses in core)

What I didn't do:

  • Add unit tests for the network version as that would involve duplicating the _back_up_drop_ins(), _restore_drop_ins(), _back_up_mu_plugins() and _restore_mu_plugins() methods from the Tests_Admin_includesPlugin class to the Tests_Multisite_Network class or moving these methods elsewhere (to the WP_UnitTestCase class would seem a logical place)
Version 2, edited 5 years ago by jrf (previous) (next) (diff)

#11 @knutsp
5 years ago

  • Keywords dev-feedback added

#12 @dd32
5 years ago

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()).

#13 @DrewAPicture
5 years ago

  • Keywords needs-patch needs-unit-tests added; has-unit-tests has-patch dev-feedback removed

To move forward, this will need a new patch addressing feedback in comment:12 from @dd32.

@swissspidy
5 years ago

#14 @swissspidy
5 years ago

  • Keywords has-patch has-unit-tests added; needs-patch needs-unit-tests removed
  • Milestone changed from Awaiting Review to Future Release

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.

I agree with the first part, but not necessarily with the conclusion.

24205.diff is an updated patch without an additional $check_all parameter or bootstrap file check. It simply checks whether a plugin is active as a must-use plugin or drop-in as well.

#15 @swissspidy
5 years ago

  • Keywords 2nd-opinion added

#16 follow-up: @ericlewis
5 years ago

I tend to agree with wontfix, especially given dd32's response.

Say I want to use Gravity Forms as an mu-plugin. I drop the gravity-forms folder into the mu-plugins folder. Then I would need to write say an mu-plugins/index.php file to load gravity forms.

How would you know whether the Gravity Forms plugin bootstrap file is included? You would need to know it's being included by mu-plugins/index.php.

One actionable item is to make this explicit in the docs. I've opened up #35459 for that effort.

#17 in reply to: ↑ 16 @swissspidy
5 years ago

Replying to ericlewis:

How would you know whether the Gravity Forms plugin bootstrap file is included? You would need to know it's being included by mu-plugins/index.php.

You wouldn't know it, but that's not what my patch or the original suggestion is about. Simply put, if you have a drop-in called db.php or a mu-plugin called whatever.php, is_plugin_active() should return true for those as well. If you care about GF, then of course check for a function's existence.

I'm not 100% for this or against it as I can understand both sides.

Valid arguments against this:

must-use plugins and drop-ins don't have a concept of "activation".

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.

#18 @swissspidy
5 years ago

  • Keywords 2nd-opinion removed
  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

[36397] clarified the documentation of is_plugin_active()

Note: See TracTickets for help on using tickets.