Git-updater: Current selected branch not updating on Plugins page list?

[rob]

I updated the Pods plugin to the release/2.7 branch, and it did update fine, but the Plugins list page always says the current branch is master.

This happens even on the develop branch of GitHub Updater.

I tried the "Refresh Cache" button in GitHub Updater's settings as well, but nothing happens.

[afragen]

You will need to use the branch switcher to reinstall the branch to correctly set the branch name. This was a new change for v7.0.0.

After doing this, the correct branch name will show in the branch switch row of the plugins page.

[rob]

Do you mean click 'another version' and select the same branch (e.g., release/2.7)?

Or do I have to re-install the plugin from Settings > GitHub Updater > Install Plugin?

[afragen]

First choice. Reinstall Pods branch release/2.7

[afragen]

I cannot replicate what is in your video. Can you give details about your environment?

[idpaterson]

I am having the same issue with switching to the develop branch for my Bitbucket repositories. There is no current_branch_* value in my github_updater options value.

[afragen]

Can this be replicated in a standard WP installation with default theme and only GitHub Updater and your plugin active?

[rob]

I tested this locally with Local by Flywheel and it works fine switching between branches with just GitHub Updater and Pods installed. I'll have to clone the production site tomorrow and test it out by disabling all plugins. Maybe there's a conflict somewhere.

(Thought maybe it's because we have InfiniteWP installed, but I deactivated that and it's still happening.)

[afragen]

Thanks @rob

Please let me know what plugin is causing the conflict and hopefully I’ll be able to figure out what’s causing it.

[idpaterson]

@rob maybe start with any overlap with my plugins? I'll try Local as well.

[idpaterson]

This may not be related to plugins; a fresh install works fine but has a slightly different format for the github_updater option value. After upgrading from earlier versions without reconfiguring the plugin my database entry looks like this:

Array
(
    [bitbucket_password] => xx
    [bitbucket_server_password] => 
    [bitbucket_server_username] => 
    [bitbucket_username] => xx
    [branch_switch] => 1
    [db_version] => 7000
    [github_access_token] => 
    [xx-wordpress-plugin] => 1
)

However, on the clean local install I get two new keys, github-updater and current_branch_*:

Array
(
    [bitbucket_password] => xx
    [bitbucket_server_password] => 
    [bitbucket_server_username] => 
    [bitbucket_username] => xx
    [branch_switch] => 1
    [current_branch_xx-wordpress-plugin] => master
    [db_version] => 7000
    [github_access_token] => 
    [github-updater] => 
    [xx-wordpress-plugin] => 1
)

Does this seem to be a possible cause of the problem or just a symptom of it? Is this a case of needing to remove and re-add the repositories when upgrading from old versions, or was the old data supposed to be updated automatically?

[idpaterson]

Tested a bit more on a staging site where the branch switch was not persisting: Deleting and reinstalling my Bitbucket plugins did not work, nor did deleting and reinstalling GitHub Updater, nor did mirroring the github_updater preference from the working install. Rob, is there any overlap in our installed plugins?

[rob]

@idpaterson, here's my list:

https://gist.github.com/rob/f4135064abf8d8fe29a2a692b601bd94

The only two I see overlapping are Akismet and User Switching. I disabled both, and still have the issue, so I don't think it's those.

I'll try to disable all of the plugins later today and see if it still happens.

[afragen]

I use both of those plugins on my test sites.

[idpaterson]

A little bit of debug output made the problem very obvious. In my case, the set_branch_on_switch filter is getting called first by a different plugin that is doing an HTTP request to check a plugin license. The hook is triggered with that url rather than the one corresponding to the HTTP request from github-updater.

So I am seeing set_branch_on_switch called with $url = 'https://divilife.com/?wc-api=upgrade-api&request=pluginupdatecheck&slug=divi-overlays&...'. The url does not match any repository so the current_branch_* value is not updated. Furthermore, the set_branch_on_switch filter is removed after the first HTTP response so the response from the update check is never handled.

[idpaterson]

The updater for this plugin uses the pre_set_site_transient_update_plugins action to perform the HTTP request that is coming in before the one that github-updater expects if you're looking for a test case.

[afragen]

What plugin are you referring to? Is there a remove_filter call in it?

[idpaterson]

It does not seem to have a remove_filter call, this is the Divi Overlays plugin... I disabled it to see if anything else pops up: http://www.elegantthemes.com/api/api.php which is probably the Divi license check behaving in the same way.

So rather than disable plugins and themes one-by-one, I commented out the remove_filter from set_branch_on_switch to see exactly how many of these were coming through before the intended response. The above elegantthemes.com request was followed by https://api.wordpress.org/plugins/update-check/1.1/ then another elegantthemes.com then finally the bitbucket repository that I was updating. After all that, the branch was properly switched and persisted on the plugins page.

If there is no better way to handle the status change than this hook, it appears that it may need to be removed only when the URL matches a response you intended to handle.

[afragen]

The hook is just a mechanism to capture the URL and the branch switch. Nothing happens to the data from the hook. My remove_filter only should only remove my set_on_branch_switch. Which is only called from my add_action in Branch constructor.

Adding and removing filters is sorta a best practice and won’t find the root cause of this issue.

[afragen]

Does this seem to be a possible cause of the problem or just a symptom of it? Is this a case of needing to remove and re-add the repositories when upgrading from old versions, or was the old data supposed to be updated automatically?

This is expected behavior. My changelog for 7.0.0 clearly describes this breaking change, which is why reinstalling the branch of your plugin is needed to properly set that value.

[afragen]

There really isn’t any shortcut to finding a plugin conflict than by activating and deactivating groups of plugins.

[idpaterson]

I think there may have been a misunderstanding, here is what I am seeing:

1. Branch constructor sets up the filter to call set_on_branch_switch
2. http_response filter is triggered by a third-party plugin
3. set_on_branch_switch runs but cannot operate on the unexpected URL to update the database
4. set_on_branch_switch uses remove_filter to prevent being called again
5. The filter is triggered by github-updater but set_on_branch_switch is no longer handling the filter
6. The bitbucket plugin has switched to the new branch, but the change does not persist since set_on_branch_switch did not record the branch

When I disabled the remove_action call inside set_on_branch_switch I was able to see all of the third-party plugins that were triggering the http_response filter before the response that github-updater intended the filter for. Eventually the filter was triggered with the correct URL and the branch was persisted to the database.

[afragen]

Thanks, I think I understand now.

Rather than run passively wait for the hook, I may need specifically instantiate the Branch class. I’ll think about it but for now just comment out the remove_filter.

[rob]

I can confirm that commenting out the remove_filter for http_response fixes everything for me!

With that said, I'm not using the Divi plugin @idpaterson is using, but I am using Beaver Builder (another page builder plugin) as well as other paid plugins that do license checks, so I'm sure the same thing is happening here, just with another plugin.

Thanks for tracking this down, @idpaterson.

[afragen]

I have an idea on how to fix this without using a filter hook. I should have something by the end of the weekend to test as I'm traveling right now.

[afragen]

This should be fixed in latest update. I've moved the trigger from a filter hook to a direct call.

Let me know if it works for you both.

[idpaterson]

This looks like a great solution and works perfectly for me!

[afragen]

Excellent!

[afragen]

v7.1.0.8 should have the final changes. I messed up a conditional along the way. 🤦‍♂️

[rob]

Late to the party, but it works! Thanks again for your hard work. :-) Thanks @idpaterson for figuring it out!