Opened 11 years ago
Closed 8 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)
Change History (22)
#1
@
11 years ago
- Milestone Awaiting Review deleted
- Resolution set to wontfix
- Status changed from new to closed
#2
follow-up:
↓ 3
@
11 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
@
11 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
@
11 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
@
11 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
#7
@
11 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.
#9
@
10 years ago
Just realized... this of course also applies to is_plugin_active_for_network()
for mu-plugins in a multi-site environment.
#10
@
9 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()
andis_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 tofalse
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 theTests_Admin_includesPlugin
class to theTests_Multisite_Network
class or moving these methods elsewhere (to theWP_UnitTestCase
class would seem a logical place)
#12
@
9 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
whenplugin-name/plugin-name.php
is selected feels too magical, and is bound to break. For example,wporg-plugins-loader.php
might loadsomething-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
@
8 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.
#14
@
8 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 amu-plugin
is designed to be more of a server/system-level configuration, as such, I wouldn't expectis_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.
#16
follow-up:
↓ 17
@
8 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
@
8 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.
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.