Plugin Directory: "Last updated: 2019 years ago"

[SergeyBiryukov]

Upon initial commit, this plugin displayed "Last updated: 2019 years ago" in the sidebar:
​https://wordpress.org/plugins/digthis-quick-view-for-woocommerce/

Looking at the ​SVN changelog, the author has set the stable tag in readme.txt before the tag was created. I think the recommended way is to create the tag first. The author did it in the correct order with version 1.0.3, and it appears to be displayed correctly now.

The initial issue still seems like a bug though.

[Otto42]

I think the recommended way is to create the tag first.

The recommended way is to do everything at the same time, in a single commit.

[digamberpradhan]

So tags, trunk everything should be committed in a single commit, rather than tag first, trunk later ?
In the initial commit I committed the trunk first and the created the tag later.

I was under the impression Trunk was the development are and i could do anything in the trunk and the plugin would only show up once I created the tag, I was wrong.

[Otto42]

The way it works is that we scan the /trunk and look at the Stable Tag, and then go to the /tags directory to find that stable tag. If it does not exist, then the plugin is created as whatever is in /trunk.

The last updated value is slightly buggy in that respect, granted.

[Ipstenu]

This has hit a few plugins since they're in the habit of submitting trunk, with the 'version to be tagged' intact, and then releasing the tag. Right or wrong, it's how it's been used, and given how hard it has been to educate them on using tags in the first place, we need to find a better way to scan for last updated :/

[SergeyBiryukov]

Replying to Otto42:

The recommended way is to do everything at the same time, in a single commit.

I see, thanks. Looks like TortoiseSVN's Branch/Tag feature doesn't support that though, it displays a warning when trying to create a tag with uncommitted changes in trunk: 2740.2.PNG​.

Creating the tag folder manually and copying the files there would work, but in that case commit history for the files is not preserved, so my current preference is to create the tag and then update stable tag in readme.

[Ipstenu]

The bigger issue with that is some plugins are rather large, and you (Otto) have actually told people (including me) to use the copy from the https url and NOT /trunk so the processing is done on the server directly :) So ... we're giving people mixed, complex, signals here.

Is this part of Dion's plan to reduce the load of how many times we rebuild zips? Which I fully approve of, but we may need to tweak the logic a bit....

[digamberpradhan]

Replying to SergeyBiryukov:

Replying to Otto42:

The recommended way is to do everything at the same time, in a single commit.

I see, thanks. Looks like TortoiseSVN's Branch/Tag feature doesn't support that though, it displays a warning when trying to create a tag with uncommitted changes in trunk: 2740.2.PNG​.

Creating the tag folder manually and copying the files there would work, but in that case commit history for the files is not preserved, so my current preference is to create the tag and then update stable tag in readme.

That was the problem i faced as well, and hence the multiple versions. In my haste i committed multiple versions without reading the warning.

On version 1.0.3 What i did was choose, working copy instead of HEAD revision and commited Tag first and then updated the trunk.

And unless specified otherwise, this will be my update process going forward

[TyB]

Remote Post Swap last updated 2019 years ago.

[TyB]

I had this same issue when I uploaded this plugin: ​https://wordpress.org/plugins/remote-post-swap/ last night. This morning I made some simple updates to the plugin, including updating the stable tag from "0.5.0" to "0.6.0" and it appears to have fixed the issue. Note I am not using tags or anything like that, just updating the trunk at this point in time.

[Ipstenu]

Note I am not using tags or anything like that

Please do. If you use a stable tag in your readme, the directory expects to see a tag folder :) weird things will happen if you don't and our first advice will be to use tags.

[Otto42]

Actually, on reflection, I don't think this has anything to do with the order of operations at all.

The last updated date is the post_modified time internally, and that is set to current_time( 'mysql' ); when the importer decides to update this information. So, no matter what, it shouldn't be setting it to 2019 years ago. That's not even unix zero.

So, you can probably stop arguing about tags and such, since I don't think that's the underlying problem here.

[Otto42]

On examination of a case of this occurring, the post_modified and post_modified_gmt data is set to 0000-00-00 00:00:00.

Additionally, the GUID is strangely set as ​https://en-gb.wordpress.org/plugins/remove-powered-by-wordpress/ which might indicate that this might have something to do with being submitted on one of the i18n views of the plugins directory.

[Otto42]

In 5338:

Plugin Directory: Import script should set post modified time if existing time is not set. This prevents a 2019 years ago condition which is caused by plugins being approved and having a version number set for them, but then having that same version be checked into SVN, thus not having a version difference to cause the initial update time to change. Fixes #2740

[Otto42]

The initial problem started from [5316]. Before this, the post_modified value was getting set when the plugin was published, and then the importer would change it whenever the version of the plugin changed.

Since the version is stored as postmeta, and it is in the initial submission of the plugin, if the plugin is published and then the same version is pushed to SVN, the importer would not detect the change.

[5338] adds a condition where it will always set the post_modified value if the value is not set, which will only happen on the first import of the plugin from SVN.

Any plugins that still have this issue can simply push any change to SVN and it will update the post_modified value, fixing the issue for that plugin. Any future plugins will get their post_modified updated correctly on the initial import regardless of the version check.