Repository navigation
Users query: Return the registration date as registered.site and registered.gmt - #1237
Conversation
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. Props Bot commandsYou can trigger Props Bot actions by commenting on this PR:
|
✅ WordPress Plugin Check Report
📊 ReportAll checks passed! No errors or warnings found. 🤖 Generated by WordPress Plugin Check Action • Learn more about Plugin Check |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #1237 +/- ##
=============================================
+ Coverage 85.33% 85.34% +0.01%
- Complexity 4424 4431 +7
=============================================
Files 173 173
Lines 16408 16435 +27
=============================================
+ Hits 14001 14027 +26
- Misses 2407 2408 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
gziolo
left a comment
There was a problem hiding this comment.
Thank you for bringing it over from WP core 💯
dkotter
left a comment
There was a problem hiding this comment.
Changes look fine to me.
Noting it came up on the AI call today that these schema changes (there's been a few PRs now with them) technically break backwards compat, if anyone happened to be using these abilities with the old schema.
I'm personally okay with that, as these are gated behind an experiment and we don't claim to support experiments in a backward compat manner but curious if anyone else has differing thoughts here? At the very least, need to make it clear in the changelog that any schema changes to existing abilities (introduced in v1.4.0 or less) will need downstream updates if being used directly.
|
Let's make it clear in the changelog and release notes that all 3 core abilities have now identical shape like these shipping in WordPress 7.2, which required breaking changes to support all feedback shared during development and testing. |
What?
Follow up to #1207. Port of WordPress/wordpress-develop#15001.
This PR syncs
core/users-querywith the core changes made after the last sync:registered_dateis replaced by aregisteredobject with{ site, gmt }: the registration date in the site's timezone and in GMT. Each is null when the stored date is not a valid date.fieldsinput acceptsregistered.siteandregistered.gmtto select a single date.registered_dateis rejected as an unknown field.user_registeredis now always read as UTC, whatever the PHP default timezone is.tearDown().Why?
The plugin should keep behaving like core, and
registereduses the same{ site, gmt }shape as thecore/content-querydates in #1235. The core PR is approved but not committed yet.How?
includes/Abilities/Users/Users.php: the core changes, with theaitext domain and aDateTimeZoneimport.UsersTest.php: the core test changes.Use of AI Tools
AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5.5
Used for: porting the core change and tests; reviewed by me.
Testing Instructions
Verify unit tests are passing:
Or run the ability in the editor console:
Each item should have a
registeredobject withsiteandgmtkeys.Changelog Entry