Unable to check version

[Xavier]

Hi,
Thanks for your plugin that I used since several years now. But today, I have a problem.
I use Gitlab integration and I don't manage to update my plugin : I use tags.
I've installed Debug Bar and here's the result :
From the metadata URL :

Successfully retrieved plugin info from the metadata URL:

YahnisElsts\PluginUpdateChecker\v5p2\Plugin\PluginInfo Object
(
    [extraProperties:protected] => Array
        (
        )

    [name] => Art Com Sites
    [slug] => art-com-sites
    [version] => 1.1.4
    [homepage] => https://artcombureautique.fr

And from the cached update :

Checked version | 1.1.20
-- | --
YahnisElsts\PluginUpdateChecker\v5p2\Plugin\Update Object (     [extraProperties:protected] => Array         (         )      [slug] => art-com-sites     [version] => 1.1.4

I don't understand why it's always checking from the version 1.1.4 because my last tag is v1.2.0.
Do you have an idea, please?
Thanks for your help
Regards
Xavier

[Yahnis Elsts]

It's hard to figure this out without actually looking at the repository, but here are some suggestions:

• Does the version tagged 1.2.0 also have 1.2.0 in the plugin header? If the actual plugin version doesn't match the tag name (aside from the v prefix), that can sometimes cause strange problems.
• Is the update checker actually looking at the tags? There's no built-in logging for that, but you could set up a proxy or a WP plugin that logs outgoing HTTP requests and see what API requests it sends.
• On a related note, does the 1.1.4 version number come from a tag or maybe a branch? If the debug output includes a download URL, you might be able to figure out the answer based on that.
• Could you be hitting the API rate limit? In cases where only some of the requests get rate-limited, it could cause the update checker to use the wrong version.

[Xavier]

Hi Yahnis,
Based on your 4 suggestions, yes all my tagged versions have the version number in the plugin header and yes, the update checker is looking at tags. What I didn't mention is that I've been using your plugin update checker the same way on several sites without any problem until today on the websites using THAT plugin.

The 1.1.4 version number comes from an old tag. It seems like the update checker "finds" a cached value but I don't have cache plugin and the server cache is disabled. That's why I don't understand what's occurring.

The only thing I change in my process is that my gitlab repository used groups and I transferred the project to my namespace. But I don't think it's the problem since in gitlab when I check for updates my personal access token is used.

I don't manage to find a solution at the moment and I hoped you could have encountered the same problem before. But I will look forward: if I find an answer I will come back to tell what the problem was.

Thanks

[Yahnis Elsts]

The only thing I change in my process is that my gitlab repository used groups and I transferred the project to my namespace. But I don't think it's the problem since in gitlab when I check for updates my personal access token is used.

This part stood out to me. I'm not very familiar with GitLab, but could this mean that the repository URL changed, or that GitLab is serving an outdated copy at the old URL, or anything like that?

[Jake]

The only thing I change in my process is that my gitlab repository used groups and I transferred the project to my namespace. But I don't think it's the problem since in gitlab when I check for updates my personal access token is used.

This part stood out to me. I'm not very familiar with GitLab, but could this mean that the repository URL changed, or that GitLab is serving an outdated copy at the old URL, or anything like that?

Yes, transferring a project from a group to a personal namespace means the repository url is going to change.

[Yahnis Elsts]

I see. It does seem like it might be useful to check if PUC is sending the requests to the correct URL and getting the expected responses from the API. For example, you could log them with this plugin.

The more popular Query Monitor plugin also logs HTTP requests, but I don't think it's going to work in this case since it only shows requests sent during the current page load. As far as I know, requests sent from AJAX and Cron handlers don't show up, and if an admin page triggers a redirect, the target page doesn't "see" requests sent on the previous page.

[Xavier]

Thanks for your answer. @jakeparis : I did change the URL
@YahnisElsts I installed the plugin you told me. And I don't have any error : the request is done and the URL is ok. The plugin sees all my tags from version 1.1.4 to the last one (1.2.0).
As I'm quite limited with that issue. I will try to make a new repository for my plugin to have a really "clean" starting point and I will see. Will come back here soon to give you the results. Thanks for your advices.

[Xavier]

Hi! It's been a while but I solved my problem. I just re-create another repo from the top with a new access token and the difference is that in the new repo I didn't use the group. I don't really know what was my problem but with the new repo, everything is ok.
Thanks for your help anyway!
Xavier