You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current notes implementation may not scale well when there are many (hundreds or thousands) notes (or comment replies) on a post.
The comment REST API endpoint only returns 100 records at a time so fetching many will require multiple requests - my expectation is the current UI will only display comments when all comments have loaded.
Note that for the initial display we only show the top level comments (plus a message about the number of replies). Clicking a comment threat shows the replies.
What is your proposed solution?
Only load top level comments in the initial request
In the background load all of the (remaining) data
Ensure data fetching properly paginates thru >100 records
Possibly/future: display comment placeholders until first request request completes to avoid layout shift (we already know which blocks have comments). this applies more once we have comments positioned next to their related block in popovers.
related (see especially recent discussion): #10169
That proposed solution sounds good to me, agreeing that the "possibly/future" item isn't needed in the base handling here (and if necessary could be a future release thing and not needed for the core block commenting functionality but definitely a better UX).
@adamsilverstein I see you added this to the "Design priorities" board, is there a status there we should set and someone to ping to get things moving along for what's needed?
@adamsilverstein I see you added this to the "Design priorities" board, is there a status there we should set and someone to ping to get things moving along for what's needed?
Good question @jeffpaul - I think that was set automatically during the issue creation flow. I just moved it to "Needs Dev". I'm a bit new to how this projects are being used so I'm trying to follow what I see others doing. Please correct me if I do something strange!
I've not noticed many other Block Commenting-related issues or PRs getting assigned to the "Design priorities" board so unless there's a need for some sort of Design team/Designer input I think we can remove this issue from that board and leave this as-is on the "WordPress 6.9 Editor Tasks" board where the totality of the WP 6.9 editor-related issues are being tracked.
Activity
jeffpaul commentedon Sep 19, 2025
That proposed solution sounds good to me, agreeing that the "possibly/future" item isn't needed in the base handling here (and if necessary could be a future release thing and not needed for the core block commenting functionality but definitely a better UX).
jeffpaul commentedon Sep 19, 2025
@adamsilverstein I see you added this to the "Design priorities" board, is there a status there we should set and someone to ping to get things moving along for what's needed?
adamsilverstein commentedon Sep 19, 2025
Good question @jeffpaul - I think that was set automatically during the issue creation flow. I just moved it to "Needs Dev". I'm a bit new to how this projects are being used so I'm trying to follow what I see others doing. Please correct me if I do something strange!
jeffpaul commentedon Sep 19, 2025
I've not noticed many other Block Commenting-related issues or PRs getting assigned to the "Design priorities" board so unless there's a need for some sort of Design team/Designer input I think we can remove this issue from that board and leave this as-is on the "WordPress 6.9 Editor Tasks" board where the totality of the WP 6.9 editor-related issues are being tracked.
32 remaining items
adamsilverstein commentedon Jul 17, 2026
Related PRs:
adamsilverstein commentedon Aug 5, 2026
Removing this from the 7.1 board since we didn't land on the right solution yet; we can revisit for 7.2.
Mamaduka commentedon Sep 21, 2026
I've closed associated PRs; let's focus on #81599 as a performance improvement effort.