When using protected content the admin may show outdated information under some scenarios

Open
  • Is something wrong?
#1,415 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
elasticsearch, php, wordpress
Domain
backend, search

Research direction

Start by tracing the admin post-trash request to the Elasticsearch index request, then reproduce the stale listing on a minimal WordPress site. Verify how waiting for Elasticsearch refresh affects the next listing load and whether the behavior should be limited to admin changes. Done means trashed posts are absent immediately after the listing reloads without unnecessary manual refreshes.

Written by the indexing model from the issue text.

Description

confirmed bug low priority module:protected-content

Describe the bug
With protected content enabled interactions in the admin can result in inconsistent information.

Steps to Reproduce

  1. On a small site with minimal plugins
  2. Create a post and save it
  3. In the post listing, click on trash to put the item in the trash
  4. Note that when the page refreshes the item is still shown in the listing
  5. Refresh the listing, note that the item has now no longer in the list

Expected behavior
Clicking trash would result in the post no longer being listed

Environment information

  • Plugins and version: I tested using 2.8 through 3.1
  • Theme and version: default WP theme on 5.2.2
  • Other installed plugin(s) and version(s): no other plugins

Cause and potential solution
This issue occurs because the request to update the post in Elasticsearch doesn't wait for Elasticsearch to commit the change, that is Elasticsearch returns immediately. The change isn't reflected in search results until the next refresh interval has fired which defaults to 1 second. When the WordPress admin loads again it does a search against an old copy of the index and gets outdated results back.

The potential solution is to add ?refresh=wait_for to the index request for the affected document(s). For performance I wouldn't recommend issuing a refresh command manually after indexing the document, only when making the index request. Manually issuing a refresh will just result in a doubled up refresh (because ES is already doing scheduled refreshes anyway) potentially causing more delay than necessary.

I also wouldn't use wait_for unless the command came from the admin page while users are making changes they would expect to be fresh on the next page load.

It maybe useful to allow for disable waiting in the event ES is configured with a longer than usual refresh interval.

Dominant language
PHP
Stars
1.3k
Forks
325
Avg merge
2d 11h
Merged PRs (30d)
24

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from 10up/ElasticPress

All issues in 10up/ElasticPress

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.