Removing tag 3.0.1 from WordPress SVN

[menno-ll]

Dear developer,

We're stumbeling on a small inconvenience, caused by an accidental tag created for a version 3.0.1 in the WordPress SVN repository.

We over here at our company use WPackagist to install plugins. This allows us to install plugins using Composer for our WordPress websites.

Because the tag for version 3.0.1 still exists in WordPress SVN, this is seen as the latest version by WPackagist, as it uses semantic versioning to determine the latest version. Therefore, when we run composer outdated in our terminal, it shows that the plugin is outdated, even though it's on the latest version 2.1.3.

$ composer outdated --direct

Color legend:
- patch or minor release available - update recommended
- major release available - update possible
wpackagist-plugin/jwt-auth                        2.1.3   3.0.1

Multiple colleagues have now accidentally installed version 3.0.1 in multiple projects, which is unfortunately broken.

The request I have is relatively simple (at least, I hope so). Is there a possibility to remove the tag 3.0.1 from the WordPress SVN?

Thank you in advance! Kind regards, Menno

[wavedeck]

@menno-ll since this plugin has issues functioning properly in the most recent version of WordPress (6.4.x) and the last update was a little over 9 months ago, i decided to take the matter into my own hands and fork it.

I also plan to strictly follow SemVer conventions, making this fork compatible with WPackagist and Composer. The source tag 3.0.1 is already available in my repository and fixes for WP 6.4 follow in the next few days as release 3.1.0 (added a new parser method to fix issues in 6.4.x)

The fork is available here

[sun]

Hey there, thanks for creating this issue.

Can you clarify what problems you're having with version 3.0.1 with latest WordPress Core? Ideally link to existing issues, so we don't duplicate their discussion here.

We were actually about to publish the new major version v3 on wordpress.org – finally, one must say, as it has been privately tested with the code here on GitHub in RC state for more than one year and we didn't hear about major issues.

[sun]

Oh and we're following SemVer here. The major bump is indeed caused by potentially breaking changes that could affect custom integration code on existing sites.

[wavedeck]

@sun take a look at my issue created in #111 I‘ve tried to use this plugin, configured it as per readme and set up my .htaccess accordingly (although on a private vps shouldn’t be disabled)

I always received a 403 Username wrong because $request->get_param(„username“); is always null. Same with the password. Take a look at my issue, to see how I approached fixing it.

I‘ve tested both on a completely blank install as well as my testing site, and it didn’t work without manually parsing the authorization header

[sun]

@wavedeck Yeah, as pointed out in https://github.com/usefulteam/jwt-auth/issues/111#issuecomment-1905691509, that is caused by not sending the username and password parameters in the POST request body.

@menno-ll Could you clarify what you originally meant with the following?

Multiple colleagues have now accidentally installed version 3.0.1 in multiple projects, which is unfortunately broken.

To clarify, v3 has a major new feature (refresh tokens) but with regard to the main/existing functionality, there are only a marginal changes compared to v2 – if you're not using the API in too advanced ways, then your existing code should work identically with v3.

[wavedeck]

@sun I've clarified my issue #111 now since, it actually was unclear what was meant with "params" in the README.md. Sending the credentials in the POST body works, however i'd like to request, that the plugin adds a feature to fallback to Basic Authorization if the credentials were not submitted in the body.

In regards to @menno-ll's issue, he meant that there's a commit in the Wordpress Plugin SVN Repo, that references v3.0.1 as a tag and it's causing issues for him trying to use it, when installed with WPackagist / Composer as an alternative way (preferred by the roots.io stack) to wordpress.org

https://wpackagist.org/search?q=jwt-auth shows a v3.0.1 already available and would be automatically selected if the developer chooses to install the latest version via WPackagist (3.0.1 > 2.1.6)

I cannot speak for him, what issues he encounters in v3.0.1 compared to v2.1.6 (latest version on wordpress.org) but this sums up what he is requesting.

A tag does make sense in regards of the planned major version bump, so you have a fixed starting commit, but maybe reconsider, if git flow (main, develop, feat/xyz...) would make more sense for further development, as this prevents a premature launch on sites like WPackagist and with a major version bump, there is always the opportunity to consider changes in the workflow

[menno-ll]

@wavedeck Thank you for clarifying my issue, that saves me a lot of typing!

@sun In regards to the following

Multiple colleagues have now accidentally installed version 3.0.1 in multiple projects, which is unfortunately broken.

The error I get when i download the version tagged as 3.0.1 from wpackagist is the following

Warning: require(/path/to/project/wp-content/plugins/jwt-auth/vendor/autoload.php): Failed to open stream: No such file or directory in /path/to/project/wp-content/plugins/jwt-auth/jwt-auth.php on line 25
Fatal error: Uncaught Error: Failed opening required '/path/to/project/wp-content/plugins/jwt-auth/vendor/autoload.php' (include_path='.:/usr/local/Cellar/php@8.0/8.0.30/share/php@8.0/pear') in /path/to/project/wp-content/plugins/jwt-auth/jwt-auth.php on line 25

It seems like either

• The vender/autoload.php file should only be loaded when present, when you are developing on the project
• The vendor/autoload.php file (and other composer files) are not included in the tagged code while it should have been there

[dominic-ks]

Yeah I can't remember how that version ended up in there, it can presumably just be removed. I think it's likely that it was added to SVN incorrectly or in error and doesn't reflect the state of V3.0.1 which is the latest version on the master branch here.

My plan is that this version will be released properly once it's been merged with the latest wp-org-master branch which will clear everything up.

[menno-ll]

Let's hope! If you could keep an eye out for it when releasing v3.0.0 that would be great. Do you have an estimate for when you expect v3 to be released?

[dominic-ks]

I don't I'm afraid, It's very near the top of my things to do list, it'll just be when I get the time.

[menno-ll]

Understandable, unfortunately maintaining a plugin next to other work isn't an easy job.

[sun]

The tag has been removed: https://github.com/usefulteam/jwt-auth/tags

[menno-ll]

Thank you. I'll assume that the WP tag will then also dissapear soon.

[dominic-ks]

@sun The tag they're referring to is on the wordpress.org SVN repo rather than the github one.

[sun]

Indeed, that requires a manual operation with svn. This post suggests using svn delete.

[dominic-ks]

@sun @menno-ll Yep that's easy enough, it's done now.