Closed maath0712 closed 9 months ago
It's hard to figure this out without actually looking at the repository, but here are some suggestions:
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.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
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?
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.
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.
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.
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
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 :
And from the cached update :
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