Plugin updating

[kprovance]

First, if this has been reported already, I apologize for reporting.

I noticed - using the version here in the git which I pulled yesterday, if I have a plugin set to force_activation => true, and an update is available, the update fails, citing the plugin could not be removed. Is this a known thing?

Thanks!

[jrfnl]

@kprovance Thanks for reporting this. This is a new one indeed. I've been able to reproduce the issue and am looking into it now.

[jrfnl]

@kprovance Interestingly enough, the bug only seems to occur when doing a single plugin update via the link. Doing it in a bulk update - even with just the one plugin selected - does seem to work, so that could be considered a work-around for now.

[jrfnl]

Hmm... strangely enough, I can't consistently reproduce it. I've seen it happen a few times, but taking the same steps, more often than not, it just works.

@kprovance Would you mind doing some more testing ? and if you find a way to consistently get the error, please provide me with the config function to recreate the situation.

It might just be an incidental case of directory permissions on a specific system.

[kprovance]

I was able to reproduce on my local and live site. Here are the particulars:

The initial call to my config is inside the theme's functions.php, a simple require to the config

require_once( 'theme/plugins/install-plugins.php' );

If you need the entire config, I can gist it, but the array in question is this one

                array(
                    'name'                  => 'Theme Extreme Core',
                    'slug'                  => 'extreme-core',
                    'source'                => get_template_directory() . '/theme/plugins/extreme-core.zip',
                    'required'              => true,
                    'version'               => '1.0.0',
                    'force_activation'      => true,
                    'force_deactivation'    => false,
                    'external_url'          => '',
                ),

It's the core plugin for the theme (since Envato makes us put shortcodes and the like in there). Obviously, this install from a ZIP is for the benefit of new users. What actually happened up to the problem began when I ran a test on updating the core, using wp-updates. When the updates were available, I didn;t use the TGM interface to update them, I used the WP admin, which updates my core and three others (WooCommerce, MailChimp, and Redux Framework (I'm one of the devs there). So, I then checked 'Select All" and clicked "Update Plugins". During the updating process is when I noticed it (thinking to myself, this is going to be support hell) ;-)

That was local. I did the same thing on my live site. I went ahead and set force_activation to false, and everything was fine. In the larger picture, I can leave that set to false and prevent the front end from loading to avoid index errors and the like. Redux - at the time - wasn't set to force_activation, but I set it to try and the same thing happened. In all fairness, I haven't tried updating through the TGM interface yet. I was doing what I thought most non technical users would do, that is, see the icon at the top of the WP admin bar, see updates, and work from there.

I haven't gone through the TGM code to see why, I thought I'd ask first if it was it or me. Does the code put a lock on forced plugins that isn't released during an update outside of the TGM UI? I know that if one attempts to disable a plugin that has force_activate ticked, it reactivates itself without notice, which I figured was by design, but wonder if the same thing is occuring when the update WP process is occurring.

Anyways, if I left something out, or you need more data, let me know. :)

Cheers.

[jrfnl]

@kprovance Thanks, that info is helpful and as far as I can see, it actually identifies that this is not a TGMPA issue.

Am I correct in saying that this is a premium plugin, as in: a plugin which is not in the wp.org repo ?

TGMPA does not "inject" info into the WP update array (yet). As the plugin is a bundled plugin, you would normally only see an update if you included a new version with a new release of the theme, indicated this in the $plugins array and you would only see it on the TGMPA page, not on the normal WP update page.

The fact that you do see it on the normal WP update page, makes me suspect that the plugin contains code which does an update check (to an external site) and injects that info into the WP update array/page.

As I don't have access to the plugin, I can't verify this.
I suspect the actual problem is related to how the plugin is served from the external site as in: incorrectly packaged.

All the same, the force activation should not interfere with the normal update page as it does not hook into the upgrade routine. I've just tested with a wp.org registered plugin & force_activation set to true and have repeatedly been able to upgrade it without any issues whatsoever.

What surprises me is that you indicated that plugin is the core of your theme as that gives me the impression that you are also the author of that plugin. If so... what gives ? Am I missing something ?

[dovy]

I'm a friend of @kprovance and the lead dev behind Redux. I'm sorry, but I don't think that is the case here.

The plugin he is using does not have any custom updater information inside it. I have a copy of it here. It doesn't even have a GitHub repo URL.

Probably he's got a lower version specified the installed plugin, and a higher version outlined in the TGM declaration, which causes an update, correct? This previously worked. ;) I know because I tested with it all the time.

[jrfnl]

@dovy Could you mail me the relevant copies of the plugin (older + newer version) to test with ? ... at adviesenzo.nl

[jrfnl]

@dovy

Probably he's got a lower version specified the installed plugin, and a higher version outlined in the TGM declaration, which causes an update, correct? This previously worked. ;)

Not sure exactly what you mean here, but until version 2.5.0 updating was not included in TGMPA at all. Updating bundled plugins now works based on the version you specify in the $plugins array passed.

[kprovance]

Eh, maybe I didn't explain myself properly, there seems to be some confusion about the actual issue. I'll try again:

So, yes, I'm including and activating my core plugin (not premium per se, there is no licensing involved, it's just a support plugin Envato requires for shortcodes, posts types, etc. I use TGM to install it via a ZIP file, but I wanted to use the force_activation arg to switch it on right off. So far so good, everything works peachy.

I'm using wp-updates for new versions, so if a new one is available, it can be updated via the standard WP updater.

The actual problem is because the force_activation is set, the plugin doesn;t fully disable during the WP updating process, when WP enabled maintenance mode and does it updating thing. It appears (and I'm only speculating) that because the plugin is always activated, during the update process, it's never fully removed and replaced with the new version (as appears to be the way WP does it, by removing the old plugin and installing the new one). My guess - FWIW - is that because the plugin is always force activated, it cannot be removed, and then the updating process barks with the 'Unable to remove plugin folder, cannot update, etc, etc" Then, I have an empty plugin folder with no files that cannot be updated through any means because the actual folder will not delete.

Set force_activate to false, the problem goes away completely. I can send you my core, but the same issue occurs with any plugin with force_activate set, including ours (https://wordpress.org/plugins/redux-framework/). The array for that is:

                array(
                    'name'                  => 'Redux Framework',
                    'slug'                  => 'redux-framework',
                    'required'              => true,
                    'force_activation'      => true,
                ), 

You might have to go into redux-framework.php and set the version number lower to trigger an update notice.

The other thing I failed to mention - and I apologize profusely for forgetting to mention it - is this occurs on multi-site. Usually, I don't use MS, but has no choice during the dev process. I fear that might be part of the issue, upon reflection.

[jrfnl]

@kprovance Thanks for the further clarification. I'll try to reproduce it again later today, this time using WP-MS.

[jrfnl]

@kprovance @dovy To start, I should mention that TGMPA currently is not set up for multi-site use. There are a lot of issues to get that working properly and solving those is part of the v3.0 roadmap #394.

All the same, I've spend yet another couple of hours trying to reproduce this issue and I still cannot do so, let alone do so consistently.

Tested with the latest TGMPA (2.5.2 to be released today or tomorrow).

Tested on both WP 3.9 as well as 4.2.2
Tested both on WP single site as well as multi-site.

Ran the tests with Debug Bar Constants on v1.3.1 (to update to 1.4) and Redux Framework 3.5.0 (to update to 3.5.5.5). Both repo plugins. Both with 'force_activation' => true.

Have run all the following tests numerous times and only saw the issue once.

• TGMPA screen - single plugin update via link
• TGMPA screen - single/multi plugin update via bulk dropdown
• WP plugins screen - single plugin update via link
• WP plugins screen - single/multi plugin update via bulk dropdown
• WP update screen - single plugin update via bulk update
• WP update screen - multi plugin update via bulk update

The only time I saw the issue - non-reproducable on consecutive runs - was on WP MS, WP update screen, multi-plugin update via bulk update and the result was that the first plugin (DBC) had the issue, the second one (Redux) updated fine.

So, I'm going to close this issue for now.
If either of you can find a way to consistently reproduce this issue on a clean WP install, please outline the steps in detail and add the TGMPA registration function and I might try again, but as things stand, there is nothing to debug for me.