WordPress.org

Making WordPress.org

Opened 8 months ago

Closed 8 months ago

Last modified 8 months ago

#2740 closed defect (fixed)

Plugin Directory: "Last updated: 2019 years ago"

Reported by: SergeyBiryukov Owned by: Otto42
Milestone: Priority: normal
Component: Plugin Directory Keywords:
Cc:

Description

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.

Attachments (3)

2740.PNG (5.5 KB) - added by SergeyBiryukov 8 months ago.
2740.2.PNG (23.7 KB) - added by SergeyBiryukov 8 months ago.
Screen Shot 2017-04-13 at 9.23.53 PM.png (112.8 KB) - added by TyB 8 months ago.
Remote Post Swap last updated 2019 years ago.

Download all attachments as: .zip

Change History (18)

@SergeyBiryukov
8 months ago

#1 follow-up: @Otto42
8 months ago

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.

#2 @digamberpradhan
8 months ago

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.

Last edited 8 months ago by digamberpradhan (previous) (diff)

#3 @Otto42
8 months ago

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.

This ticket was mentioned in Slack in #forums by sterndata. View the logs.


8 months ago

#5 @Ipstenu
8 months ago

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 :/

#6 in reply to: ↑ 1 ; follow-up: @SergeyBiryukov
8 months ago

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.

#7 @Ipstenu
8 months ago

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....

#8 in reply to: ↑ 6 @digamberpradhan
8 months ago

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
8 months ago

Remote Post Swap last updated 2019 years ago.

#9 @TyB
8 months ago

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.

#10 @Ipstenu
8 months ago

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.

#11 @Otto42
8 months ago

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.

#12 @Otto42
8 months ago

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.

This ticket was mentioned in Slack in #meta by otto42. View the logs.


8 months ago

#14 @Otto42
8 months ago

  • Owner set to Otto42
  • Resolution set to fixed
  • Status changed from new to closed

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

#15 @Otto42
8 months ago

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.

Note: See TracTickets for help on using tickets.