Make WordPress Core

Opened 7 years ago

Closed 20 months ago

#41494 closed defect (bug) (maybelater)

Quick Edit update functionality is inconsistent.

Reported by: umangvaghela123's profile umangvaghela123 Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Quick/Bulk Edit Keywords: needs-patch
Focuses: administration Cc:

Description

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

screenshot 1 :

http://i.imgur.com/F813yzf.png

screenshot:2

http://i.imgur.com/Zhp9VCS.png

screenshot:3
http://i.imgur.com/L9yvjDx.png

Change History (14)

#1 @SergeyBiryukov
7 years ago

  • Component changed from General to Quick/Bulk Edit

#2 @subrataemfluence
7 years ago

  • Focuses administration added
  • Keywords needs-patch added

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.

#3 @subrataemfluence
7 years ago

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.

#4 follow-up: @umangvaghela123
7 years ago

@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.

#5 in reply to: ↑ 4 @subrataemfluence
7 years ago

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.

This ticket was mentioned in Slack in #core by abhanonstopnews. View the logs.


2 years ago

#7 @webcommsat
2 years ago

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.

#8 @marybaum
21 months ago

Just tried, and cannot replicate the behavior.

#9 @webcommsat
21 months ago

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

Last edited 21 months ago by webcommsat (previous) (diff)

#10 @oglekler
21 months ago

I can't reproduce this on WordPress 6.0

This ticket was mentioned in Slack in #core by abhanonstopnews. View the logs.


21 months ago

#12 @SergeyBiryukov
21 months ago

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.

#13 follow-up: @oglekler
21 months ago

@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.

Last edited 21 months ago by oglekler (previous) (diff)

#14 in reply to: ↑ 13 @SergeyBiryukov
20 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to maybelater
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.