Alert when an admin screen goes stale due to another user's save#22
Alert when an admin screen goes stale due to another user's save#22josephfusco wants to merge 4 commits into
Conversation
8313b82 to
6ee2edf
Compare
6ee2edf to
22f8b78
Compare
▶ Preview in WordPress PlaygroundBoots a fresh WordPress with this PR's presence-api build, seeds 5 demo users, and drops you on the dashboard. Stress-test variant: 40 demo users · Built from |
2d92f9b to
3548f47
Compare
fd6434e to
69a9f1c
Compare
There was a problem hiding this comment.
Pull request overview
Adds “stale admin screen” detection to Presence API by tracking per-screen revision counters that bump on classic admin save flows and are surfaced to viewers via Heartbeat, enabling a client-side banner prompting a reload (including attribution to the saving user).
Changes:
- Introduces a new screen-revisions module that bumps per-screen revisions on Settings/post/user/term/comment saves and returns the current revision + actor metadata via Heartbeat.
- Enqueues a new admin JS/CSS banner client that detects when the viewer’s baseline revision is behind and renders a dismissible reload notice.
- Adds a comprehensive PHPUnit test suite for screen-revision bumping, Heartbeat payloads, and screen-key derivation; updates demo helper copy and uninstall cleanup.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| uninstall.php | Deletes the new wp_presence_screen_revisions option on uninstall. |
| presence-api.php | Registers the new module and hooks (enqueue + save/heartbeat handlers). |
| includes/screen-revisions.php | Implements revision storage/bumping, screen key derivation, Heartbeat payload, and banner enqueue. |
| assets/js/stale-screen.js | Heartbeat client that shows a stale-screen warning banner and reload button. |
| assets/css/stale-screen.css | Styling for the injected stale-screen notice layout. |
| tests/test-screen-revisions.php | New unit tests covering bump logic, Heartbeat responses, and screen key behavior. |
| tests/e2e/screen-stale-demo-helper.php | Updates demo helper notice wording. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
wp-env's Docker build runs `composer global require --dev phpunit/phpunit` which pulls the Sebastian Bergmann package tree from `api.github.com/repos/.../zipball/...`. Unauthenticated, that endpoint is throttled to 60/hour per IP — easily exhausted by GitHub Actions runners sharing NAT'd IPs — and starts 504-ing partway through the build. `GITHUB_TOKEN`-authenticated requests are bumped to 5000/hour, which our CI volume doesn't come anywhere near. Uses `composer config --global --auth` (the documented composer pattern) instead of hand-writing `~/.composer/auth.json`. Adds a `shivammathur/setup-php` step to each workflow so composer is on the host. Net change: +1 step, -2 heredoc lines, identical end-result file that wp-env's Dockerfile mounts into its `cli` build stage. Applies to `phpunit.yml` and `multisite.yml`; both build wp-env the same way and have the same failure mode on PRs like #22 where the runner happens to hit a depleted rate-limit bucket.
wp-env's Docker build runs `composer global require --dev phpunit/phpunit` which pulls the Sebastian Bergmann package tree from `api.github.com/repos/.../zipball/...`. Unauthenticated, that endpoint is throttled to 60/hour per IP — easily exhausted by GitHub Actions runners sharing NAT'd IPs — and starts 504-ing partway through the build. `GITHUB_TOKEN`-authenticated requests are bumped to 5000/hour, which our CI volume doesn't come anywhere near. Uses `composer config --global --auth` (the documented composer pattern) instead of hand-writing `~/.composer/auth.json`. Adds a `shivammathur/setup-php` step to each workflow so composer is on the host. Net change: +1 step, -2 heredoc lines, identical end-result file that wp-env's Dockerfile mounts into its `cli` build stage. Applies to `phpunit.yml` and `multisite.yml`; both build wp-env the same way and have the same failure mode on PRs like #22 where the runner happens to hit a depleted rate-limit bucket.
Each covered admin screen tracks a revision that increments on save and is broadcast over Heartbeat. When a viewer's page-load baseline falls behind, a dismissible notice prompts them to reload and names the user who saved. Coverage: Settings (options.php), post.php, user-edit / profile.php, edit-tags.php, comment.php. The wp_presence_current_screen_key filter lets custom and JS-driven screens opt in. Refs #12
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
c94a8a3 to
bf6beb4
Compare
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Each covered admin screen tracks a revision that increments on save and is broadcast over Heartbeat; when a viewer's page-load baseline falls behind, a dismissible notice prompts them to reload and names the user who saved.
Related: #12
How to test
Follow-ups
Use of AI Tools
AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 4.7
Used for: Implementation of the screen-revisions module, the JS banner client, the test suite, and the Playground demo helper. All changes were reviewed and verified by me.