Quick Edit update functionality is inconsistent.

[umangvaghela123]

When we change the post status by quick edit then the status is not changed in all section.

screenshot 1 :

screenshot:2

screenshot:3

[subrataemfluence]

I could reproduce the bug.

AJAX is not updating the count panel even post status gets changed. Reloading the page however shows correct counts under each status.

[subrataemfluence]

It should be fine if the DOM is updated for counts at client side only once a post / page status is updated via Quick Edit.

I don't feel we need to run a query to update counts for Quick Edit. Because next time the page will load, it will bring up the real counts from the database.

Client side DOM update is working OK for me, though a few tweaking are still required. And when I reload page the counts come up right. Hoping to upload the patch soon.

[umangvaghela123]

@subrataemfluence

we know WordPress counting functionality is working fine with a refresh but it is fine If we do some stuff

and make proper with ajax.

[subrataemfluence]

That's what I am trying to accomplish.

Replying to umangvaghela123:

@subrataemfluence

we know WordPress counting functionality is working fine with a refresh but it is fine If we do some stuff

and make proper with ajax.

[webcommsat]

Component bug scrub 14 March 2022 - Ticket requested for advice on how best to take this forward to @costdev and @audrasjb

There is currently no patch for this, nor update during the last five years. There is a suggestion for a tweak in Ajax.

[marybaum]

Just tried, and cannot replicate the behavior.

[webcommsat]

On various tests, I can not replicate this. It looks like this may have been fixed in subsequent releases.

@umangvaghela123 appreciate it has been a long time since you raised this. Can you still replicate this issue? Thank you

[oglekler]

I can't reproduce this on WordPress 6.0

[SergeyBiryukov]

I can still reproduce on WordPress 6.0.1 exactly as described:

1. Change a published post to a draft via Quick Edit.
2. The post numbers above the table do not reflect the status change.
3. The correct numbers are only displayed after a page refresh.

So the issue still seems valid. I think we have several options here:

• Fix this with some Ajax to update the counts, similar to the existing wp.updates.refreshCount function.
• Close as maybelater if there is currently no interest in working on this, and reopen if someone creates a patch.
• Close as wontfix if there is consensus that this is an acceptable edge case.

[oglekler]

@SergeyBiryukov It isn't obvious that the reporter wanted to see the update without page refresh. There is 'click update…' caption with arrow on the screenshot №3 which is misleading. So, if expect to see this update after Quick edit, the whole submenu needs to be rebuilt, because in case where there was no Draft pages previously, it needs to be added and Published (1) be removed. With current logic when we're usually handling updates with page refresh it ins't very convenient to do. Possibly, when the whole page will be built with React with data from theserver, it will be much more convenient to dynamically update such things as counters, rebuild menus, add buttons etc.

I've reported other minor problems with an interface: #51496 and #54799 and there should be more.
It is possible that the whole experience in managing posts, pages, themes etc. needs to be rebuilt and there is no point to fix small things but to create a big roadmap for improving users (editors) experience in general.

[SergeyBiryukov]

Replying to oglekler:

It isn't obvious that the reporter wanted to see the update without page refresh. There is 'click update…' caption with arrow on the screenshot №3 which is misleading.

Yeah, the Update button label refers to the second screenshot, but the arrow points to where the expected change would be after clicking the Update button. I agree the description could be better :)

So, if expect to see this update after Quick edit, the whole submenu needs to be rebuilt, because in case where there was no Draft pages previously, it needs to be added and Published (1) be removed.

Correct, that is my understanding too.

It is possible that the whole experience in managing posts, pages, themes etc. needs to be rebuilt and there is no point to fix small things but to create a big roadmap for improving users (editors) experience in general.

I tend to agree. Going to close as maybelater for now, this can be reopened later if someone is interested in working on a patch.