Opened 8 years ago
Closed 8 years ago
#2133 closed defect (bug) (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)
This ticket was mentioned in Slack in #meta by tellyworth. View the logs.
8 years ago
#3
@
8 years ago
- Milestone Plugin Directory v3 - M9 deleted
- Resolution set to worksforme
- Status changed from new to closed
#4
@
8 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
@
8 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.
#7
@
8 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
@
8 years ago
- Milestone Plugin Directory v3 - M9 deleted
- Resolution set to worksforme
- Status changed from reopened to closed
#9
@
8 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.
#10
@
8 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)
#11
@
8 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.
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.