Skip to content

fix: resolve stale cache causing incorrect display in custom status Quick Edit#849

Merged
GaryJones merged 1 commit intodevelopfrom
fix/657-custom-status-quick-edit-cache
Dec 21, 2025
Merged

fix: resolve stale cache causing incorrect display in custom status Quick Edit#849
GaryJones merged 1 commit intodevelopfrom
fix/657-custom-status-quick-edit-cache

Conversation

@GaryJones
Copy link
Copy Markdown
Contributor

This change addresses a visual update bug in the Custom Status Quick Edit functionality where the status row would display stale data after updates, requiring a manual page refresh to see the correct name.

The Problem

When editing a custom status name through Quick Edit, the update operation would save correctly to the database (verified by page refresh), but the table row rendered from the AJAX response would display the old name rather than the newly updated one. This created a confusing user experience where changes appeared not to take effect until the page was manually refreshed.

The underlying issue was a timing problem in the cache management within update_custom_status(). The function cleared the internal custom_statuses_cache at the start of its execution. However, during the update logic—specifically when the slug needed to be updated as part of a name change—calls to get_default_custom_status() would repopulate this cache with stale data from the database. This repopulation occurred before wp_update_term() had written the new values. Consequently, when the function returned the updated status via get_custom_status_by(), it was serving cached data that reflected the pre-update state.

The Solution

The fix moves the cache reset to occur after wp_update_term() has completed but before fetching the updated term data. This ensures that when get_custom_status_by() retrieves the status object to return in the AJAX response, it's working with fresh data that reflects the update that was just written to the database.

This approach mirrors the pattern already successfully employed in the Editorial Metadata module, which handles similar update operations without cache-related issues.

Testing

To verify the fix:

  1. Navigate to Edit Flow → Custom Statuses
  2. Click "Quick Edit" on any custom status (except Draft, which has special handling)
  3. Change the status name and click "Update Status"
  4. Observe that the table row immediately displays the updated name without requiring a page refresh

Fixes #657

The Quick Edit feature for custom statuses was displaying stale data
after updates. Whilst the update persisted correctly to the database,
the AJAX response returned outdated information, requiring a page
refresh to see the changes.

The root cause was premature cache invalidation. The internal cache
was being cleared at the start of update_custom_status(), but
subsequent calls to get_default_custom_status() during slug validation
repopulated it with stale data before wp_update_term() executed. This
meant get_custom_status_by() returned cached data instead of the
freshly updated term.

Moving the cache reset to immediately after wp_update_term() ensures
the cache contains only fresh data when retrieving the updated status.
This matches the pattern used successfully in the Editorial Metadata
module.

Fixes #657
@GaryJones GaryJones requested a review from a team as a code owner December 21, 2025 13:13
@GaryJones GaryJones self-assigned this Dec 21, 2025
@GaryJones GaryJones added this to the Next (minor) milestone Dec 21, 2025
@GaryJones GaryJones merged commit 32e6417 into develop Dec 21, 2025
13 of 14 checks passed
@GaryJones GaryJones deleted the fix/657-custom-status-quick-edit-cache branch December 21, 2025 13:25
@GaryJones GaryJones mentioned this pull request Jan 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bug: Custom Statuses Name not changed on update

1 participant