Can't update plugin listings in the new directory

[Kelson]

I have two plugins in the directory that are still showing old versions. I’ve updated both on GitHub with release tags and attached zip file.

When I click on “Update Download Link” on either plugin while logged in, the directory pops up this error message:

Oops! Something went wrong. Please try again. If you continue to experience an error contact us.

And the URL updates with a query string of “notification=github-api-wrong-126”

I registered them with the staging version of the directory back in 2022, in case that’s relevant.

I may be missing a step in the listing update process, but the “Something went wrong” error isn’t helping me figure out what it might be.

[Simone]

Sorry for the delay, but we had to fix something in ClassicPress Directory to see what was wrong.
Seems that the plugins are not updating as we check for description in (case-sensitive)

• README.md
• readme.txt

Can you please rename readme.md to README.md in your plugins and try again?

[Kelson]

That seems to have been it. I updated one of them in GitHub to use the capitalized README.md, and the ClassicPress directory is able to pick up the newer version now. GitHub and Codeberg seem to be case-insensitive, so as long as WordPress itself doesn’t do a case sensitive match on readme.md, I should still be able to use a single file for all repositories.

Is there a reason it’s doing a case-sensitive match, though? It just seems stricter than necessary.

[Simone]

GitHub is not case-insensitive:

https://github.com/kvibber/unwrap-shortlinks/blob/d981b729674648d4cec5ce9e473c350f1c728b65/readme.md

We get the description from README.md inside the ZIP file and as a fallback readme.txt.

As *nix filesystems are also case-sensitive we limited the number of fallback files.

But if you feel that is useful we can discuss the change.

[Kelson]

I don’t mean GItHub’s filesystem or retrieval URLs, I mean the logic GitHub uses to decide which file to populate the readme section of the project’s home page: GitHub - kvibber/unwrap-shortlinks: Plugin for WordPress and ClassicPress to follow shortened links (t.co, bit.ly, etc) and expand them so that your blog post will point directly to the destination.

It found the file when it was readme.md, and it still finds the file now that it’s README.md

That appears to be true for Codeberg as well (where I host my primary git repo), and for WordPress’ plugin directory (it finds the stable tag whether the copy in trunk is readme.md or README.md, and if it finds that in both cases, I expect it should find the content in the tagged copy of the file next time I update it).

Maybe it’s not worth checking every variation, but it seems like just adding fallbacks for Readme.md and readme.md (the most likely variations) and maybe ReadMe.md (potentially more screen-reader-friendly camel case) wouldn’t add too much overhead. And if you prefer to stick with the more traditional case, a better error message would certainly be helpful.