Strange update behavior since the 5.0 update

  • Resolved Eusebiu Oprinoiu

    (@eusebiuoprinoiu)


    1 year, 6 months ago

    Hello, Sybre!

    I’ve been trying to debug some strange behavior since the 5.0 update. Specifically, I noticed that:

    1. The folder name was changed from “autodescription” to “the-seo-framework,” and as a consequence, the plugin was deactivated, and future updates from WordPress were disabled.
    2. Between versions 5.0.0 and 5.0.1, the update menu started showing development versions like 5.0.1-dev-rc2.
    3. Trying to update to a development version led to an infinite update loop. Instead of downloading the actual archive for the development version, the 5.0.0 version archive was received. (and until the stable 5.0.1 version was released, the update notification would not go away)

    So my questions are:

    1. Did you implement a mechanism that renames the plugin folder? I searched your code but couldn’t find anything explaining this behavior.
    2. Did you make any changes that could lead to the strange update behavior?

    If you did not make any changes, I suspect the issues might be caused by Git Updater. I noticed you recently added “GitHub Plugin URI” in the plugin header, which might be why all this is happening.

    Normally, Git Updater should prioritize updates from WordPress, which is why I suspect the infinite update loop is happening. (the update details are most likely read from GitHub, but the actual update is pulled from WordPress)

    As for the folder name change, this might be explained by Git Updater as well. The slug in the WordPress repository is “autodescription”, but your GitHub repository is named “the-seo-framework”. It is likely that Git Updater renames the folder to the value pulled from GitHub and not the one from WordPress.

Viewing 9 replies - 1 through 9 (of 9 total)
  • Thread Starter Eusebiu Oprinoiu

    (@eusebiuoprinoiu)

    1 year, 6 months ago

    After additional testing I can confirm the issues are caused by Git Updater.
    Apparently this has been a problem for a long time for plugins hosted in the WordPress repo with a different slug than on GitHub.

    Plugin Author Sybre Waaijer

    (@cybr)

    1 year, 6 months ago

    Hi Eusebiu,

    Thank you for reporting this elusive issue and narrowing it down so diligently.

    I indeed added GitHub Plugin Updater support in v5.0 by adding that line to the plugin header. I haven’t tested this feature but only followed their implementation guide.

    Still, updaters shouldn’t get stuck in loops and should have fail-safes in place, so at least that part of the issue should be escalated to the GitHub Plugin Updater team.

    I’m going to test this behavior myself and narrow it down; please allow me some time to process this. Their KB has articles about renaming plugin files, which I may need to incorporate: https://git-updater.com/knowledge-base/how-to-ignore-repositories-in-git-updater/. Still, that’s for me to figure out.

    Does its interface allow excluding TSF from the updater? If so, that may be a practical temporary workaround.

    Thread Starter Eusebiu Oprinoiu

    (@eusebiuoprinoiu)

    1 year, 6 months ago

    Hello, Sybre!

    The interface of Git Updater does not provide a way to exclude plugins. It can only be done with code, like in the KB article you linked. (which is good enough for me)

    The problem is Git Updater works on the assumption that both the WordPress and the GitHub slugs are the same. (as stated here in the official documentation)

    Why did you add this header? Do you really need it?
    Plugins in the WordPress repo already have a reliable update mechanism. This header is meant to be used with plugins hosted on GitHub that have no other means to provide seamless updates.

    Plugin Author Sybre Waaijer

    (@cybr)

    1 year, 6 months ago

    Hi Eusebiu,

    Thanks for the feedback.

    A user requested the header. It seemed simple enough, and especially with GitHub Updater coming from a Core Team member, I had my hopes up and implemented it without a second thought.

    I’ll remove the header from the plugin in TSF v5.0.2, which is slated for next Tuesday. I will add it back in a future update; I’ll have it tested by then, considering its quirks.

    Thread Starter Eusebiu Oprinoiu

    (@eusebiuoprinoiu)

    1 year, 6 months ago

    Hello, Sybre!

    Git Updater is a great plugin. It’s one of the easiest solutions to provide seamless updates.

    Unfortunately, I don’t think you will be able to use it unless you change your GitHub slug to “autodescription”. I found two old tickets relevant to the issues above, and this is the fix suggested by Andy:

    https://github.com/afragen/git-updater/issues/746
    https://github.com/afragen/git-updater/issues/779

    Maybe one day, WordPress will allow developers to change the slug of their plugins.

    Plugin Author Sybre Waaijer

    (@cybr)

    1 year, 6 months ago

    Yeah, being unable to change the slug did a number on the % non-English users. Our reach has been dramatically outskewed compared to plugins that have “SEO” in their slug. One might say it’s been detrimental. But all my requests for change have been denied.

    In any case, I’d love to dig into the code of GitHub Updater; perhaps I can find a workaround that Andy might implement. I see value in having it available to everyone.

    For now, I work in the master branch, and although I rarely commit broken stuff to it, finding yourself with an untagged dev/RC version on your site wasn’t intentional. But because you have, please check your Schema.org settings — it might have been unintentionally disabled. One of the dev versions had a broken migration for Schema.org settings.

    Maybe I am using GitHub wrong, or maybe only tags should be considered stable by GitHub Updater. I’m going to do my research.

    Thanks again for guiding me through this issue.

    Thread Starter Eusebiu Oprinoiu

    (@eusebiuoprinoiu)

    1 year, 6 months ago

    Thanks for letting me know about the Schema bug. The settings have been lost, and I will have to recreate them.

    As for how Git Updater works, you need to be aware of a few things:

    While checking for updates, Git Updater reads the version from the Primary Branch. If the repo has tagged releases, it will pull the zip archive from the latest tagged release. If it doesn’t, it pulls the zip archive of the Primary Branch.

    As a consequence, the plugin version in the Primary Branch needs to be the same as the one in the latest tagged release. You will get an infinite update loop if they are not in sync.

    Andy Fragen recommends the use of a separate development branch.
    Personally, I push everything to master, but I don’t increase the plugin version until I am ready to publish a new release.

    You can read more about the update behavior here:
    https://git-updater.com/knowledge-base/versions-branches/

    Plugin Author Sybre Waaijer

    (@cybr)

    1 year, 6 months ago

    Incrementing the plugin version numbers lets me quickly identify states in my testing environments. I don’t think adhering to GitHub Updater’s rules should make developing harder.

    I’d love to see a way to disable taking from the primary branch and relying only on tags.
    e.g., by using Primary Branch: false.

    It seems that GitHub Updater treats Git as WordPress.org does SVN. Given the developer’s background in WordPress, I understand that, but it creates this predicament. I’ve just removed the updater header in the last commit.

    I’m sorry for the inconvenience. I should’ve tested this feature.

    Thread Starter Eusebiu Oprinoiu

    (@eusebiuoprinoiu)

    1 year, 6 months ago

    That’s OK. Thank you for taking the time to inspect this.

Viewing 9 replies - 1 through 9 (of 9 total)
  • The topic ‘Strange update behavior since the 5.0 update’ is closed to new replies.