Issue Summary
Changing a staff user's slug in Settings → Staff does not invalidate Admin's client-side search index, so the editor's link toolbar keeps offering the author's old URL until the browser is fully reloaded.
Staff settings are React, and the React → Ember state bridge pushes the updated user into the Ember store but never calls search.expireContent(). The index behind the link toolbar (and the global Cmd/Ctrl+K search — same index) is only rebuilt after an explicit invalidation, so it keeps serving the URL captured when the admin app was loaded.
Post slug changes behave correctly, because post saves still run through Ember's post model, which does invalidate. That asymmetry is what made this look like a server-side caching bug when it was first reported.
The tag equivalent of this bug was fixed in #29698 by adding a TagsResponseType case to onInvalidate. Users were never given the same treatment when staff settings moved to React.
Steps to Reproduce
- Open Ghost Admin and open any post in the editor. This builds the admin search index.
- Without reloading the browser, go to Settings → Staff and open a staff user (e.g. "Jamie Larson", slug team-jamie).
- Change the slug to jamie-larson and hit Save. The URL preview under the field, the staff list and the route all show the new slug.
- Navigate back to the editor (still no browser reload). Select some text and press Cmd/Ctrl+K.
- Type part of the staff user's name and pick them from the STAFF group.
Expected: the link is inserted as /author/jamie-larson/.
Actual: the link is inserted as /author/team-jamie/ — the old slug. It stays wrong for the rest of the session. A full browser reload fixes it, and so does saving any post (that path does invalidate the index).
The server is not involved: GET /ghost/api/admin/search-index/users/ returns the new slug and URL immediately, with Cache-Control: no-store.
Related, same cause: deleting a staff user leaves them in the search index for the rest of the session (onDelete doesn't invalidate either).
Ghost Version
v6.64.0
Node.js Version
22 LTS
How did you install Ghost?
Docker on Magic Pages
Database type
MySQL 8
Browser & OS version
No response
Relevant log / error output
Code of Conduct
Issue Summary
Changing a staff user's slug in Settings → Staff does not invalidate Admin's client-side search index, so the editor's link toolbar keeps offering the author's old URL until the browser is fully reloaded.
Staff settings are React, and the React → Ember state bridge pushes the updated user into the Ember store but never calls search.expireContent(). The index behind the link toolbar (and the global Cmd/Ctrl+K search — same index) is only rebuilt after an explicit invalidation, so it keeps serving the URL captured when the admin app was loaded.
Post slug changes behave correctly, because post saves still run through Ember's post model, which does invalidate. That asymmetry is what made this look like a server-side caching bug when it was first reported.
The tag equivalent of this bug was fixed in #29698 by adding a TagsResponseType case to onInvalidate. Users were never given the same treatment when staff settings moved to React.
Steps to Reproduce
Expected: the link is inserted as
/author/jamie-larson/.Actual: the link is inserted as
/author/team-jamie/— the old slug. It stays wrong for the rest of the session. A full browser reload fixes it, and so does saving any post (that path does invalidate the index).The server is not involved:
GET /ghost/api/admin/search-index/users/returns the new slug and URL immediately, withCache-Control: no-store.Related, same cause: deleting a staff user leaves them in the search index for the rest of the session (onDelete doesn't invalidate either).
Ghost Version
v6.64.0
Node.js Version
22 LTS
How did you install Ghost?
Docker on Magic Pages
Database type
MySQL 8
Browser & OS version
No response
Relevant log / error output
Code of Conduct