Plugin not updating without InfiniteWP checked, not in WordPress admin even with InfiniteWP checked

[ethanclevenger91]

Scenario:

• Plugin that utilizes GitHub Updated (Plugin A) installed at version 1.0.1 with 1.0.2 available
• InfiniteWP plugin installed
• GitHub Updater v5.2.0 installed
• Site set up in InfiniteWP
• InfiniteWP option not checked in Remote Management tab

Result:

• Updating Plugin A from the WordPress admin spins forever, does not update (unexpected?)
• Plugin A update does not appear in InfiniteWP (expected)

---

Scenario:

• Plugin that utilizes GitHub Updated (Plugin A) installed at version 1.0.1 with 1.0.2 available
• InfiniteWP plugin installed
• GitHub Updater v5.2.0 installed
• Site set up in InfiniteWP
• InfiniteWP option is checked in Remote Management Tab

Result:

• Updating Plugin A from the Wordpress admin spins forever, does not update (unexpected)
• Plugin A update does appear in InfiniteWP and update is successful (expected)

[afragen]

You will get better information if you update from the update-core.php page and not the plugins.php page. That information would be helpful.

[ethanclevenger91]

Good call. Here's the error:

An error occurred while updating Webspec SMTP: Could not remove the old plugin.

Permissions maybe? I've replicated this on local and live, two different sites.

[afragen]

Definitely a permissions issue. Try adding define( 'FS_METHOD', 'direct' ); to wp-config.php file.

[ethanclevenger91]

Hrm. So I added that and was able to update from the "Updates" screen, but not the "Plugins" screen. Then I removed it and was still able to update from the "Updates" screen, but still got infinite spinning on "Plugins".

[afragen]

Weird. I don't have any updating code in the plugin, it uses WordPress core updating methods.

[afragen]

@ethanclevenger91 are you still having issues?

[ethanclevenger91]

I can update from the "Updates" page, but not the AJAX update from the Plugins page. That's with no plugins active other than mine that I'm updating and yours.

FWIW, if I have Toolset's Types plugin installed and active, it runs a file called admin.js when the AJAX update happens with the following code (this isn't the whole file, just a snippet):

if( typeof pagenow != 'undefined' && pagenow == 'plugins'){

            jQuery(document).ajaxSuccess(function(event, xhr, settings) {
                var data = otgs_wp_installer.getQueryParameters(settings.data);
                if(typeof data.action != 'undefined' && data.action == 'update-plugin'){
                    response = xhr.responseJSON.data;
                    console.log(typeof response.error);
                    if(typeof response.error != 'undefined'){
                        var default_error = jQuery('#' + response.slug + '-update .update-message').html();
                        jQuery('#' + response.slug + '-update .update-message').html(default_error + ' &raquo;<span class="installer-red-text"> ' + response.error + '</span>');
                    }
                }
                return false;
            });

        }

Scenario 1:

Given:

• Types is active
• GitHub Updater is active
• My plugin using GitHub updater (BitBucket style) is active
• I attempt to update my plugin via AJAX

Result:

• Console error: Uncaught TypeError: Cannot read property 'data' of undefined on the line response = xhr.responseJSON.data;

Scenario 2:

Given:

• Types is active
• GitHub Updater is active
• My plugin using GitHub updater (BitBucket style) is active
• I attempt to update a regular WP plugin via AJAX (active or not, doesn't have to be Types)

Result:

• console log of undefined from the noted admin.js file

Then:

• Without navigating away
• I attempt to update my plugin via AJAX

Result:

• console log of undefined again
• Update actually fails instead of spinning forever with the error Update Failed: undefined

Don't know if that's useful at all for debugging, and like I said, even with Types deactivated, the update fails.

[afragen]

Still very strange. I don't have any custom updating code in the plugin. All I do is add the plugin to be updated to the appropriate array.

I'll keep testing here. Could you report your environment? WordPress version, PHP version, etc?

Not that it should matter but, there is a cosmetic bug when AJAX updating where the version number vanishes.

[ethanclevenger91]

Sure. So it's happening both on the server and locally.

Local:

WAMP
WP 4.3.1
PHP 5.5.12

Server:

CentOS
WP 4.3.1
PHP 5.5.25

I'll try a WP install without any other plugins even there (not just deactivated), see what happens, though I don't see how that could be an issue.

[afragen]

Can you update .org plugins from the plugins page?

[afragen]

Can you send the URI for your plugin or add afragen as read access?

[ethanclevenger91]

.org plugins update just fine. Just shared a plugin with you. There are more than that one, but the two I've tested, including that one, behave the same way.

[afragen]

Thanks. I'll be able to test a bit more this evening after work.

[afragen]

Ok, some quick testing shows that public Bitbucket plugins update and private Bitbucket plugins fail using shiny updates. This gives me a starting point to test.

[afragen]

I think the issue has to to with AJAX updates and the fact that the Bitbucket Basic Auth is sent via an HTTP header. As there is no page load I'm guessing that no headers are sent and therefore no authorization can be done.

I'll have to confirm this, but if this is accurate the eventual solution may only come when Bitbucket allows for application specific tokens like GitHub.

[afragen]

Let me know if 45d1772 fixes this issue. Please update to latest develop branch.

[ethanclevenger91]

Success. Small UX bug - the Version: x.x.x disappeared after the AJAX update. Came back when I refreshed. But anyway. All good.

[afragen]

I know about that cosmetic bug and it may take a change to core to fix it.

[afragen]

Cosmetic bug should now be fixed. It only took another rewrite of the renaming code. 😝