Plugins only disabled when WPLT is an mu-plugin

[Steveorevo]

Doesn't seem to actually disable the plugin; testing with Hello Dolly. It does appear to inhibit the "Activate" link from the plugins menu; but if the plugin was activated prior it appears to still be executing even though the interface says it's deactivated. Can anyone else reproduce?

[joeguilmette]

Can you get it to work with any plugins?

I'll run some tests with Hello Dolly and others tomorrow.

Thanks Stephen!

[jb510]

I tested locally with hello dolly and it is disabling it properly for me.

my wp-config includes this:

define('WPLT_DISABLED_PLUGINS', serialize(
    array(
        'iwp-client/init.php',
        'wordpress-https/wordpress-https.php',
        'hello.php'
    )
));

[jb510]

Steve, also note. It doesn't permanently disable the plugin or change active plugin array the DB. It just disables it "at run time" while that global is set, remove that hello.php line and it'll be active again.

If the plugin is disabled (in wplt_disabled_plugins array) and not active (in the DB) and you then click the activate link on the plugin screen the plugin will be added to the array of active plugins in the DB, but will continue to be disabled. As soon as you remove it from the wplt_disabled_plugins array it'll appear as active.

[Steveorevo]

Ahh, I see it's an early binding problem. Tried it with Debug Bar as well. As an mu-plugin, no issues. But I can see the tracing issue in PHP 5.5 (DesktopServer beta), and on Hostgator PHP 5.4. Screenshot attached. Curious though, it does disable it in the UI, but one can toggle it on/off even though the UI continues to report it as "un"active. The disabled plugin still executes. "Issue" resolved though by not installing as a plugin but rather under mu-plugins.

[Steveorevo]

Should note that it appears to only effect the last activated plugin in the list. It does disable the other plugins.

[jb510]

@Steveorevo, this is a mu-plugin only. Definitely won't work as a regular plugin.

@joeguilmette - I thought the page/wiki said that but now I'm not seeing it. Maybe a fresh issue/task to update that is needed.

[joeguilmette]

Yea, it used to. Must've gotten lost in the shuffle. No need for a new issue, I'll get it up tomorrow and add some notes in the description and installation sections.

Am I correct that the plugin disabling is the only feature that requires mu-plugin status? On Mon, May 4, 2015 at 11:03 PM Jon Brown notifications@github.com wrote:

@Steveorevo https://github.com/Steveorevo, this is a mu-plugin only. Definitely won't work as a regular plugin.

@joeguilmette https://github.com/joeguilmette - I thought the page/wiki said that but now I'm not seeing it. Maybe a fresh issue/task to update that is needed.

— Reply to this email directly or view it on GitHub https://github.com/joeguilmette/wp-local-toolbox/issues/10#issuecomment-98766309 .

[jb510]

I think so.

[joeguilmette]

I think Airplane Mode might have issues now that I think about it. On Mon, May 4, 2015 at 11:23 PM Jon Brown notifications@github.com wrote:

I think so.

— Reply to this email directly or view it on GitHub https://github.com/joeguilmette/wp-local-toolbox/issues/10#issuecomment-98771532 .

[jb510]

I thought Airplane mode might too, but a quick scan of norcross' repo I didn't see anything about it.

I think we could wrap the disable plugin in something like this

if ( did_action('muplugins_loaded') ) { / * wplt_disable_plugin_failure_admin_notice();  */ } else {  /* do disabling */ }

[joeguilmette]

Awesome. Thanks for this, Jon. I'll take a peek at it tomorrow and see what I can do. On Mon, May 4, 2015 at 11:32 PM Jon Brown notifications@github.com wrote:

I thought Airplane mode might too, but a quick scan of norcross' repo I didn't see anything about it.

I think we could wrap the disable plugin in something like this

if ( ! did_action('muplugins_loaded') ) { / * wplt_disable_plugin_failure_adminnotice(); / } else { /_ do disabling */ }

— Reply to this email directly or view it on GitHub https://github.com/joeguilmette/wp-local-toolbox/issues/10#issuecomment-98773531 .

[jb510]

See: https://github.com/dannyvankooten/wp-plugin-profiler/blob/master/src/Admin/Manager.php#L28 (Danny posted it in AWP)

[jb510]

Not sure if it's possible, but it'd also be nifty if there were a way for the plugin to move itself into mu-plugins and then out of mu-plugins. Not automatically, but after prompting. Just a random idea, maybe not a good one.

[joeguilmette]

I was trying to think of some way to get this to work while keeping the benefits of running the plugin from /plugins. There must be a way... On Mon, May 4, 2015 at 11:36 PM Jon Brown notifications@github.com wrote:

Not sure if it's possible, but it'd also be nifty if there were a way for the plugin to move itself into mu-plugins and then out of mu-plugins. Not automatically, but after prompting. Just a random idea, maybe not a good one.

— Reply to this email directly or view it on GitHub https://github.com/joeguilmette/wp-local-toolbox/issues/10#issuecomment-98774384 .

[Steveorevo]

Filter on pre_option_active_plugins. That occurs after muplugins_loaded and just before include_once( $plugin ); in wp-settings.php

[joeguilmette]

Just poked around for 20 minutes and got lost in the woods.

Want to have a crack at it @Steveorevo?

[Steveorevo]

I can have a look this afternoon.

[joeguilmette]

That would be awesome! Thanks Stephen! On Tue, May 5, 2015 at 4:42 PM Stephen Carnam notifications@github.com wrote:

I can have a look this afternoon.

— Reply to this email directly or view it on GitHub https://github.com/joeguilmette/wp-local-toolbox/issues/10#issuecomment-99011959 .

[Steveorevo]

:-(

Chicken/Egg Error. There is no way to have the plugin reside in plugins and get loaded to prevent others from loading simply because it would be too late; after all, the list has to be loaded in order for wp local toolbox can even alter the list. Technically impossible unless moved up in stack; moving to mu-plugins is the only way. I would have said it would be feasible if plugin loading was alpha sorted and WP Local Toolbox was renamed "AAA WP Local Toolbox", but it appears that WP gathers the list first, then tightly executes include_once on the list. Interesting exercise.

[joeguilmette]

That's what I thought... Now, what if we can find someway to slip an include into /mu-plugins? Do you think that would work?

[Steveorevo]

You'd have to leverage WP_Filesystem. Otto wrote a curious guide, but it's necessary to follow in order to write the file system with the correct permissions (execute, ownership, etc). Some hosting providers support WP's File System Direct, which allow PHP code to write PHP code (another dot PHP file to execute). However, many do not (i.e. Dreamhost, WPEngine, etc.). In these cases, they support SSH and/or FTP. Otto's work in WP core (http://ottopress.com/2011/tutorial-using-the-wp_filesystem/) uses some sort of finagling that allows writing the file with proper permissions via having WordPress FTP or SSH back into itself to write the file or update the permissions accordingly. Personally I think it's messy, requires that users know FTP/SSH credentials, etc. But it's a necessary feature for security purposes, and I probably couldn't have come up with better.

In short, it is possible; but it sure sounds like a pain in the ass. :-/

[joeguilmette]

Ok... What about simply detecting if the plugin is installed in /mu-plugins? If the user has enabled any features of WPLT that require it to be installed in /mu-plugins we can display an admin notice that they won't work.

[joeguilmette]

Note for me after reviewing this issue:

if ( did_action('muplugins_loaded') ) { / * wplt_disable_plugin_failure_adminnotice(); / } else { /_ do disabling */ }

[Surgeonito]

Or - KISS method - include the plugin into the theme as a library and load it on 'muplugins_loaded' hook??? Didn't test it, just shared it.