Trash the Note Replies

[karthick-murugan]

What?

Closes #72862

This PR fixes a bug where deleting a parent note did not delete its child replies. The deletion confirmation dialog promised to delete all replies, but only the parent note was actually deleted from the database, leaving orphaned replies.

Why?

Previously, when a user deleted a note that had replies, the confirmation dialog stated: "Are you sure you want to delete this note? This will also delete all of this note's replies." However, the implementation only deleted the parent note itself. Child replies remained in the database (they only disappeared from the UI because their parent relationship was lost).

This created data integrity issues and a mismatch between what the UI promised and what actually happened.

How?

The fix adds a new recursive helper function deleteCommentAndReplies that:

1. Checks if the comment has any replies in its reply array
2. Recursively deletes each reply (and their nested replies) before deleting the parent
3. Handles deeply nested reply structures

The onDelete function now calls this helper instead of directly deleting only the single comment. This ensures that when a parent note is deleted, all its replies (including nested ones) are properly removed from the database.

The recursive approach handles any depth of nesting:

• Parent Note → Reply 1 → Nested Reply → Deeply Nested Reply
• All children are deleted before their parent

Testing Instructions

1. Open a post or page in the editor.
2. Insert a block (e.g., a Heading block).
3. Add a note to the block by clicking the "Add note" button or using the Notes panel.
4. Add at least one reply to the note.
5. Optionally, add nested replies (replies to replies) to test deeper nesting.
6. Click the delete button (three dots menu → Delete) on the parent note.
7. Confirm the deletion when prompted.
8. Verify: Check the database (e.g., wp_comments table) or refresh the page - both the parent note and all child replies should be completely removed, not just marked as trashed.

Video

REC-20251103155213.mp4

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: karthick-murugan <karthickmurugan@git.wordpress.org>
Co-authored-by: desrosj <desrosj@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: adamsilverstein <adamsilverstein@git.wordpress.org>
Co-authored-by: jeffpaul <jeffpaul@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[desrosj]

Thanks @karthick-murugan!

Can you explain a bit why you chose to tackle this on the JavaScript side? When I mentioned this, I envisioned this being handled servers side in the wp_trash_comment() function. I believe that the problem will only be fixed if the editor itself with this approach, and it would result in many requests instead of just one.

I recognize that I opened this issue here when the server side code is managed in SVN trunk. But this felt like the best place to track considering most of the feature's bugs are being tracked here.

[Mamaduka]

I agree with @desrosj. The logic needs to be handled on server side.

[karthick-murugan]

@desrosj - Apologies - I missed the server-side approach mentioned in the issue. You're right that this should be handled server-side in wp_trash_comment() rather than in the JavaScript client code for better performance and universal coverage. Closing this PR in favor of a server-side implementation.

[desrosj]

No worries, @karthick-murugan! Thanks for creating this PR! It's always helpful to have multiple approaches to consider.