Deleting a parent comment causes the child to move up a level

[oglekler]

Use case: Imagine that someone wrote something bad and it was published, another person replied that "Buddy, you are completely wrong," and then the admin removed the parent comment. And now the reply appears as related to the post or comment on a higher level comment that makes no sense.

There can be several approaches:

1. Prevent deleting if a comment has children, and only delete with children.
2. Keep the comment in the database empty with a placeholder that it was deleted, and keep children related to it. It can also be shown as deleted on the front end. I believe that social networks do this way.
3. Move children to pending, also marking that they were related to the deleted comment.

I count this as a bug, but the fix needs enhancement.

[SirLouen]

It's a bug or not, depending on the code, maybe it even has a unit test to expect this behavior.

But I agree with you, its not correct that a child comment is promoted to parent. I think that the right way to proceed is like in Reddit:

If there is a child, mark the parent as deleted and put a placeholder like: This message was deleted.

Would like to hear more opinions, @yashjawale, what do you think?

[peterwilsoncc]

This was introduced version 2.7.2, see commit [10762] for ticket #9003. The change didn't arrive with any unit tests and I can't see any that have been added since.

Reviewing the original ticket, the issue was caused by comments displaying in the wrong order when a parent was deleted. The misparented comments where displayed at the end of the list.

If not already the case, an alert could be displayed in the dashboard when a parent comment is trashed/deleted warning of the re-parenting.

I don't mind the idea of displaying a message to the effect the message was deleted but it would need to be done in such a way that the original comment can be restored if the admin restores the comment from trash.

[yashjawale]

The current code intentionally moves up the child comments if parent is deleted.

https://core.trac.wordpress.org/ticket/9003#comment:1 also brought up the approach of having placeholders but looks like the discussion never progressed

I think it would be better to show placeholder message for deleted parent comments like @SirLouen suggested.

One approach I could think of is to let the comment go to trash as usual & modify the display query to also fetch trashed comments, if its a parent to child comments then display placeholder else ignore rendering it.

This way the comment can be restored by admin.

[SirLouen]

Ok, so if the current behavior in code was the expected behavior, this seems to be an enhancement then.

And I think we all agree that a placeholder with the possibility of restoring is the best patch here.
I think that this ticket is set for a patch now.

[peterwilsoncc]

There are two things to consider re trashing:

1. the EMPTY_TRASH_DAYS constant can be used to disable trash and delete the comment immediately
2. wp_scheduled_delete will delete any comments that have been in the trash for EMPTY_TRASH_DAYS days. The default value is 30.

[peterwilsoncc]

I've been considering this over the last few days and come to the view that replacing deleted comments with a placeholder message is best left to a plugin.

My concern is that such a change would mean that WordPress no longer respects the site owner's decision to delete objects from the database. Once a comment has been published, even if accidentally, the comment would need to stay in the database in order for WordPress to know that the comment has been moderated.

If a site owner installs a plugin to enable such a feature, they've demonstrated a clear intent to retain the objects in the database in some form. Without the plugin, WordPress can not be sure of their intent.

I've added the close keyword to allow for a second opinion.

[SirLouen]

@peterwilsoncc I can agree that the advanced proposal to have placeholders, could be part of a plugin.

The problem, though, is still there: you delete a comment, and the child becomes the parent.

Another option could be simply trashing all the parent tree under the parent removed… Maybe adding a double check when removing a parent with children.

But definitely converting a child into a parent is not acceptable, it is a clear defect.

I have not reviewed the code, but even a hook action to override the behaviour could be also an option. What do you say @yashjawale ?

[peterwilsoncc]

Replying to SirLouen:

@peterwilsoncc I can agree that the advanced proposal to have placeholders, could be part of a plugin.

The problem, though, is still there: you delete a comment, and the child becomes the parent.

Another option could be simply trashing all the parent tree under the parent removed… Maybe adding a double check when removing a parent with children.

But definitely converting a child into a parent is not acceptable, it is a clear defect.

I have not reviewed the code, but even a hook action to override the behaviour could be also an option. What do you say @yashjawale ?

I'm happy to add preflight hooks to the various trashing, deleting and related functions if required.

My reading of the intention behind the reparenting commit is that it maintains the comment thread as well as possible. If a child comment is deleted, any grandchildren should remain descendants of the original comment.

I don't think WordPress can delete/trash the entire comment tree because that is very unlikely to meet the user's intent when removing a single comment. A plugin may wish to do so using the existing trash_comment or delete_comment actions.

If it's not already the case, then an alert in the admin of the effects of deleting a parent comment should be shown to the user.

[SirLouen]

Replying to peterwilsoncc:

I don't think WordPress can delete/trash the entire comment tree because that is very unlikely to meet the user's intent when removing a single comment. A plugin may wish to do so using the existing trash_comment or delete_comment actions.

I don't really know each single expected behavior in WP, but its funny because I always thought it worked this way. The reality is that generally I lock comments (And I was thinking on integrating bbPress with comments in some of my sites in the future, which can has this all-or-nothing parent-child structure).

Leaving childs without a parent, means, leaving comments without a context, which can't make any sense for anyone. I wonder who could say: "Yeah, leave the comments without context". Like the example in the OP. Someone says something, someone answers to it, parent is removed, and the answer without the context, can make the author look stupid for having wrote that. Webmasters will not be accounting for this disorder because they cannot really see it. So we cannot really fully see what is the intent of an administrator, removing a single comment without having the whole context.

In a hierarchized structure like the parent-child comment relationship, a child is always a reply to a comment. I used Reddit because is the most famous parent-child comment system in the planet, something like a placeholder is an expected behaviour and they use the placeholder system. With youtube is different: if you remove the parent comment all childs are automatically removed, also a potential expected behaviour.

But leaving childs without parent is a defective behaviour. There should be some degree of accounting for this in core by default, not entirely relying in plugins to fixed (specially if we really plan to fully support a quality comments component, obviously), and maybe write a dev-note with the conclusion on how this will be “officially” handled for the version that is planned to be released.

Personally, I think, that how it's being handled is not a real design decision but just mere chance by how currently other hierarchical post types are handling the parent-child relationship (like Pages). But pages are not of the same nature of comments. Comments hierarchy is always a dependency, not an exception. Pages hierarchy can be of multiple uses. There can be a massive relationship, like some sort of inheritance or a fragile relationship, like just an organizational structure (for example, all the items starting with A). In the case of comments, again, the relationship is always, indistinctly, massively correlated (answer-reply).

[kimjiwoon]

Currently, when a post is moved to the trash in WordPress, all connected comments are deleted along with it. Likewise, when the post is restored, all comments are restored together.

However, in ActivityPub, every comment (reply) is an independent object with its own inReplyTo property. This does not align with the traditional WordPress behavior.

In a federated environment, replies received from a remote actor are fundamentally objects originating from another instance. They cannot simply be deleted locally. The only options for moderation are to hide them or block the actor.

In a federated WordPress context, comments should not be bound exclusively to a local wp_post. Much like email, they should be capable of being sent outward or attached to a remote URL. This means that even if the original post does not exist locally, it should still be possible to post a reply based on the URL.

Hashtags and mentions should be supported in comments. In other words, taxonomy needs to be enabled there.

---

​https://github.com/Automattic/wordpress-activitypub/pull/1996
Add image attachment support to federated comments

​https://github.com/Automattic/wordpress-activitypub/pull/2066
Implement a proper Tombstone handling

​https://github.com/Automattic/wordpress-activitypub/pull/1857
Only replace comment_link for remote comments

​https://github.com/Automattic/wordpress-activitypub/issues/2091
Idea to Completely Deprecate the WordPress Comments Field

​https://github.com/Automattic/wordpress-activitypub/issues/2065
Federated comments become orphans when the original post is deleted

​https://github.com/Automattic/wordpress-activitypub/issues/2073
Proposal: Comment-to-Comment Federation in WordPress ActivityPub

​https://github.com/Automattic/wordpress-activitypub/issues/1833
Edge Case Test: Federated Reply Block Does Not Sync as Comment

​https://github.com/Automattic/wordpress-activitypub/issues/2130
A Proposed Database Schema for WordPress ActivityPub Integration

wp_comments & wp_commentmeta: These would no longer be used for federated replies, as inReplyTo is an object property and should be managed in the ap_objects table.

[peterwilsoncc]

@SirLouen I think this all goes back the suggestion that if a comment with a child is trashed, then a warning can be shown in the dashboard if that is not already the case.

@kimjiwoon The ActivityPub plugin is written by a third party so you will need to follow up any issues in the repository you've linked to.

[yashjawale]

From my testing, no warning is shown currently while deleting a comment with children.

Also, I can see two different behaviors...

If we are just sending the parent comment to trash, its children too are not shown in frontend (although the comments screen in dashboard shows the child comments normally).

But if I clear the trashed comments (i.e. delete permanently), THEN the child comments get moved up, which contradicts the behavior shown by trash action.

imo user might expect child comments to get deleted too, as that is what trash option implied on the frontend before deleting the comment permanently.

[kimjiwoon]

While the ActivityPub plugin is currently maintained as a third-party project, there is a strong possibility that federation will eventually become part of WordPress core.
For this reason, I believe it is important to raise compatibility concerns in Trac as well. If the philosophical gap between WordPress comments and federated replies grows wider, it will become increasingly difficult to align them in the future.
On the contrary, if WordPress core evolves toward more modern and interoperable structures — for example, handling deleted objects with placeholders, supporting taxonomy in comments, or considering external object references — it will make future integration smoother and prevent WordPress from drifting into a “Galapagos” model that ignores broader web standards.

[SirLouen]

Replying to peterwilsoncc:

@SirLouen I think this all goes back the suggestion that if a comment with a child is trashed, then a warning can be shown in the dashboard if that is not already the case.

A notice will not do the cut for a reason: Imagine a big hierarchy, with multiple child comments. You will lose the track fast, and it is a massive hassle (imagine a newspaper with a microworking mod team that doesn't have much agency on the comment moderating system). Currently there is an unexpected behavior, but this is a fragile solution.

The placeholder thing is a super robust solution. Both for trashed (with the ability of restoring) and perma-deleted items (no restoring option obviously). Yes, it implies some extra code. If we cannot aim for this quality solution, then full hierarchy trashing is not an option.

Replying to yashjawale:

imo user might expect child comments to get deleted too, as that is what trash option implied on the frontend before deleting the comment permanently.

I suppose that auto-removed trashed items would also affect child hierarchy.

[kimjiwoon]

By using the /?comment_id=123 query string together with ActivityPub\Tombstone, it would be possible to implement a placeholder for deleted comments.

• ​https://developer.wordpress.org/reference/functions/comment_id/
• ​https://developer.wordpress.org/reference/functions/get_comment_id/

[peterwilsoncc]

@SirLouen As I've said, a place holder would require preventing users from deleting objects from the database. This is not something WordPress core can do.

@kimjiwoon As Iv'e said, the ActivityPub plugin is maintained by a third party. There is literally nothing any WordPress Contributors can do here on trac. Please refrain from postinf further comments on this ticket or trac regarding the plugin.

[SirLouen]

Replying to peterwilsoncc:

@SirLouen As I've said, a place holder would require preventing users from deleting objects from the database. This is not something WordPress core can do.

Not necessarily. Placeholder can be founded in pure logic.
Currently the comment creation and deletion logic is the following:

1. Childs get comment_parent ID
2. When you delete permanently, the child comment_parent is updated.

Remove this logic. Keep comment_parent ID forever even if parent doesn't exist anymore.
When writing the comments tree, if comment_parent does not exist, put a placeholder, if not, put the comment_parent.
This could place placeholders not only on the first parent but in any parent of the tree.

[peterwilsoncc]

Replying to SirLouen:

Not necessarily. Placeholder can be founded in pure logic.
Currently the comment creation and deletion logic is the following:

1. Childs get comment_parent ID
2. When you delete permanently, the child comment_parent is updated.

Remove this logic. Keep comment_parent ID forever even if parent doesn't exist anymore.
When writing the comments tree, if comment_parent does not exist, put a placeholder, if not, put the comment_parent.
This could place placeholders not only on the first parent but in any parent of the tree.

This logic would be incomplete.

If the deleted comment is a child, then the thread would be detacted without retaining an object

• Top level comment, ID 1
  • Deleted comment, parent 1, ID 2
    • Comment, parent 2, ID 3

Without a placeholder for the deleted comment the continuation of the thread would become detached from comment one. The only way to accurately record a deleted comment would be to prevent the deletion of objects from the database.

[SirLouen]

Replying to peterwilsoncc:

If the deleted comment is a child, then the thread would be detacted without retaining an object

• Top level comment, ID 1
  • Deleted comment, parent 1, ID 2
    • Comment, parent 2, ID 3

Without a placeholder for the deleted comment the continuation of the thread would become detached from comment one. The only way to accurately record a deleted comment would be to prevent the deletion of objects from the database.

True, "cutting" the tree in the middle directly from the database, will provoke a detachment of nodes. This means that it will generate a new tree, where deleted ID2 is the new main parent, with a placeholder, and ID 3 is the child of that placeholder.

If you mess with the database and you end with broken hierarchies.

And to avoid this from the logic on deletion (after trashing), we could introduce a comment_approved (or comment_type, not sure which will be better), called "placeholder" (to retain the hierarchy)

Let's evaluate current behaviour:
Parent ID 1
Child A ID 2 Parent ID 1
Child B ID 3 Parent ID 2

If you delete a Child from the database, the whole subtree disappears.

• Delete Child A from DB
• Only Parent ID 1 displays
• Child B ends detached but doesnt display anymore.

If you trash and delete permanently from UI

• Delete Child A from trash
• Tree updates new Parent for Child B (ID 3) is Parent (ID 1), still a weak behaviour.

Imagine this scenario:

Parent ID 1: "I like playing Mario Kart, one of the best games in history"
Child A ID 2 (Parent, ID 1): "This game has been one of the worst I've ever played"
Child B ID 3 (Parent: ID 2): "I totally agree with you"

A mod trashes Child A. And later in time, trash is cleaned, making Child B parent ID 1. It will end looking like this:
Parent ID 1: "I like playing Mario Kart, one of the best games in history"
Child B ID 3 (Parent: ID 1): "I totally agree with you"

Result: Unfortunate sequence of comments, isn't it?

With my algorithm it will look like:

• Deletion from Trash:

Parent ID 1: "I like playing Mario Kart, one of the best games in history"
Child A ID 2: (comment_approved = placeholder, Parent ID 1): "This comment has been deleted"
Child B ID 3 Parent ID 2: "I totally agree with you"

Result: Clutch

• Deletion from DB

Parent ID 1: "I like playing Mario Kart, one of the best games in history"

Parent ID N/A - "This comment has been deleted"
Child B ID 3 Parent ID 2 (nonexistent): "I totally agree with you"

Result: Looks a little unfortunate, but not as unfortunate as the current logic status.

Plus, something that is not being handled currently: trash comment_approved with childs can also display the Placeholder (currently all childs from the trashed comment simply disappear, which, in the worst scenarios, the best, but only while the comment is trashed; once it leaves trash, parents will be recalculated).

[kimjiwoon]

I prefer the logic that threads.net uses for deleted comment placeholders in WordPress.

Instead of linking every comment only to the original post, it allows the target of a comment to be stored as another comment. By explicitly using inReplyTo to define the reply target, the reply feed can show things like “Reply to [username]” or “Reply to an inaccessible post.”

This way, every comment retains information about its reply target. Even if the original post or parent comment is deleted, the relational structure between comments is preserved.

In fact, I even prefer when comments can function like microblogging notes on a user’s profile, independent of the original post.

[kimjiwoon]

Wouldn’t it be possible to handle comments from logged-in users through the wp_posts table, and only use the wp_comments table for anonymous users?
This could help enable more fine-grained control over comment permissions.

The idea is to add a “note” post type field to the wp_posts table, so that it can be used for both comments and microblogging.
On the author page, this could then be displayed in a separate archive tab.

[SirLouen]

Replying to kimjiwoon:

Wouldn’t it be possible to handle comments from logged-in users through the wp_posts table, and only use the wp_comments table for anonymous users?
This could help enable more fine-grained control over comment permissions.

I think your proposal are way too complicated to be a simple enhancement. They are a better fit for a ​Feature Plugin.

I'm trying to keep this as simple as possible to be a simple enhancement patch.

But if you want to dream big with all those syndicated comments and new post types for comments, consider applying for a Feature Plugin. Be aware, that regardless of the direction it takes, it could always be improvement.

But I think we should make a smaller fix first before dreaming big.