WordPress.org

Making WordPress.org

Opened 3 years ago

Closed 3 years ago

#2133 closed defect (worksforme)

“Last updated” time not updated when updating “Tested up to” in repo

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

Description

Look at the “Last updated” time on:
https://wordpress.org/plugins-wp/cache-control/
https://wordpress.org/plugins/cache-control/

Last updated was updated on the old version when I committed rev. 1513554 where I increased the version number in the “Tested up to” field. So the old plugin directory right now shows last updated 10 minutes ago, and the new directory design says it was 3 months ago. Both show the updated “Tested up to” version number.

Change History (11)

#1 @tellyworth
3 years ago

  • Milestone set to Plugin Directory v3 - M9

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


3 years ago

#3 @dd32
3 years ago

  • Milestone Plugin Directory v3 - M9 deleted
  • Resolution set to worksforme
  • Status changed from new to closed

Not sure what the problem was here, but it's fixed.

I suspect it was a cache that didn't clear correctly, as I saw it incorrect earlier, but is now correct.
I haven't been able to duplicate a bad cache either though.

#4 @geekysoft
3 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

It’s not fixed.

The post-archival plugin was updated a week ago. The new page shows “Tested up to: 4.6.1” and yet “Last updated: 5 months ago”. The old page shows “Tested up to: 4.6.1” and “Last updated: 1 week ago”.

#5 @dd32
3 years ago

Yeah.. not sure what happened here.

The import a week ago succeeded, but post_modified and last_updated meta didn't update.
Re-running the import command from logs also succeeded, but they updated this time.

We're not checking the return value from wp_update_post() or the other update_post_meta() / wp_set_post_terms() calls, so it's entirely possible that they've failed.

I've improved some of the logging and will see if anything pops up. If anyone spots other plugins which don't update with a commit after now then let me know.

#6 @tellyworth
3 years ago

  • Milestone set to Plugin Directory v3 - M9

#7 @dd32
3 years ago

We're not checking the return value from wp_update_post() or the other update_post_meta() / wp_set_post_terms() calls, so it's entirely possible that they've failed.

FTR I don't think we should/need to do anything with these.

Unless there's further reports with recent plugins, I'm not investigating anything here.
(Note: The last_updated dates for a lot of plugins are more recent than they should be, but nothing should be older than it should be)

#8 @tellyworth
3 years ago

  • Milestone Plugin Directory v3 - M9 deleted
  • Resolution set to worksforme
  • Status changed from reopened to closed

#9 @geekysoft
3 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

Same problem.

https://wordpress.org/plugins/minor-edits/ (Last updated 9 hours ago, version 0.9.2)
https://wordpress.org/plugins-wp/minor-edits/ (Last updated 4 weeks ago, version 0.9)

However, this time the version number wasn’t updated either.

Last edited 3 years ago by geekysoft (previous) (diff)

#10 @geekysoft
3 years ago

Here is another case:

https://wordpress.org/plugins/post-archival/ (Last updated 5 minutes ago, version 1.2.1)
https://wordpress.org/plugins-wp/post-archival/ (Last updated 2 months ago, version 1.1)

Last edited 3 years ago by geekysoft (previous) (diff)

#11 @dd32
3 years ago

  • Resolution set to worksforme
  • Status changed from reopened to closed

I noticed this morning after getting off a plane that the sync process had stopped after encountering an error. As it's not yet "in production" it's not monitored as closely.

The process has been restarted and the above plugins were updated, it's high on my list to shift the process to running via a cron task so that it's kept running.

As a small footnote - It's a known issue that the last updated date for plugins is currently set to the time it's imported (imports happen as commits happen, but also manual, and also 'after the fact'), rather than the time of when the plugin release was made. That'll get fixed with a move towards a reliable cron.

Note: See TracTickets for help on using tickets.