Introduce subcommands to list/delete orphaned entities

[tfrommen]

Hi, again! 👋

As discussed in the #cli Slack channel, I hereby propose orphan subcommands for all entities that can be orphaned.

What Is This About?

WordPress offers dedicated APIs that are to be used for CRUD operations on the various core data structures. When deleting a comment via wp_delete_comment( $some_id_here, true ), WordPress takes care that all metadata for that comment gets automatically deleted as well. Great!

However, as we all know, people not always do what is right, and so it's not a rare situation that you have to face a database that is full of orphaned entries. Comment metadata for comments that no longer exist, comments for non-existing posts, or posts with parents that don't exist anymore.

With the new subcommands, you can easily spot orphans, and even delete them, if you want.

We would end up with the following:

• wp comment orphan: comments for non-existing posts and/or with non-existing parents 🌟;
• wp comment meta orphan: comment metadata for non-existing comments;
• wp post orphan: posts with non-existing parents;
• wp post meta orphan: post metadata for non-existing posts;
• wp term meta orphan: term metadata for non-existing terms;
• wp user meta orphan: user metadata for non-existing users.

🌟: Regarding comments, I don't know exactly what is the right definition of an orphan. A comment that has a non-existing parent? A comment that references a non-existing post? A comment with either?

Users don't have any reference, so they are no option.

Also, terms are not an option, for at least two reasons:

• due to their bad special table structure, both finding and deleting orphaned terms is more complex than anything above;
• it makes total sense to have terms that are not yet (or not anymore) in use (i.e., no post has that term assigned so far/any longer).

How to Use It

By default, wp %ENTITY% [meta] orphan will only list the IDs, one at a line, and don't do anything to these orphans:

$ wp comment orphan
4
8
15
16
23
42

By specifiying the count flag, the command informs about the number of found orphans, instead of listing their IDs:

$ wp post orphan --count
Entries found: 42

By specifying the delete flag, all orphans get removed from the database:

$ wp term meta orphan --delete
1
2
3
5
7
Entries deleted: 5

You can even combine the two flags:

$ wp user meta orphan --count --delete
Entries found: 123
Entries deleted: 123

How Does It Work?

Please have a look at #28 (db-command) to see my initial take on this.

The idea is now to split this up to include the individual parts in their respective entity command.

---

So, what do you say? 😃

Looking forward to feedback.

Cheers,
Thorsten

[schlessera]

For the post versions, it might make sense to have the ability to filter based on custom post type.

Something like:

wp post orphan --type=page --delete

[tfrommen]

For the post versions, it might make sense to have the ability to filter based on custom post type.

Yes, that is true. But there are also different kinds of comments.

wp post orphan --type=page --delete

wp comment orphan --type=vote --delete

[danielbachhuber]

The --delete flag would violate our philosophy of composability. Deleting orphans would be better implemented as an example like:

# Delete all orphaned posts
$ wp post delete $(wp post orphan --format=ids)
Deleted post 1.
Deleted post 2.
Success: Deleted 2 of 2 posts.

By specifiying the count flag, the command informs about the number of found orphans, instead of listing their IDs:

This can and should be implemented with --format=count. The WP_CLI\Utils\format_items() function conveniently handles a variety of formats.

---

Given the uncertainty around what constitutes an "orphan", it might make sense to implement this feature as a standalone wp-cli/orphan-command to start.

[tfrommen]

Got it, deletion should not happen based on a flag, but due to calling the the actual (sub)command delete.

Choosing between listing the according IDs or listing the number of entries found should happen via --format.

I am happy to create a new standalone command, wp orphan, if that's what it should be now.
Should we then talk about the API (i.e., the full set of possible commands)?

Since the metadata has really nothing to do with the according reference objects (or even their individual type), I want to suggest to not have something like $ wp orphan post meta delete, but rather use postmeta. It's only about the metadata, and not about posts.

Consequently, I see the following API:

# Delete all orphaned entities of the given optional type
$ wp orphan %ENTITY% delete --type=%TYPE%

# List all orphaned entities of the given optional type and in the given optional format
$ wp orphan %ENTITY% list --type=%TYPE% --format=(ids|count)

with %ENTITIY% being one of the following:

• comment
• commentmeta
• post
• postmeta
• termmeta
• usermeta

and %TYPE% being the comment type for comments, and the post type for posts, respectively.

Does that make sense so far?

[danielbachhuber]

@tfrommen Sorry — I've just realized that I dropped the ball on the conversation. Is this still something you'd like to work on?

[tfrommen]

@danielbachhuber Absolutely. I just didn't want to spend any more time without a clear direction. ...and I lost track of the issue.

[danielbachhuber]

Cool. I like the idea of a wp orphan * package. If you'd like to create a orphan-command repository in your GitHub account and get it to a working prototype, then we can discuss moving it into the WP-CLI GitHub organization.

[danielbachhuber]

Closing in favor of wp-cli/ideas#72