Hummingbird > Advanced Tools > Database Cleanup : The “Delete All” option deletes drafts. That’s brutal. I recommend moving to Trash.
I just spent a couple hours recovering draft posts from a SQL backup in a new site that has nothing but drafts. OK, mea culpa, there is a count of entries for draft posts, the Delete All button shows the total count. I didn’t realize that this also deletes the drafts that we enter into the dashboard widget. It’s just too easy to wipe out a lot of drafts that might have been created by several people.
I recommend that the Delete function first clears the Trash, and then uses Delete to Trash to remove drafts. This gives the admin an opportunity to recover. Clicking that button a second time will clear the trash.
Personally I’d prefer to see a checkbox on drafts, unchecked by default, to ensure the admin really wants to delete them. When scheduling database cleanup, there is a checkbox for all data types. Cool!
There are different kinds of drafts.
There are drafts of post-type ‘post’ that we write. I don’t think these should be touched at all really. I have drafts in an old site going back years – like projects in the garage that I’ll finish “one of these days when I have time”. Manual recovery of all of those would take a Long time, after an accidental Database Cleanup.
There are also post records of different post-types, some related to user profile changes, some are log entries, some are generated email items. Many of these come from WPMU DEV plugins like Defender and Branda. I don’t understand why these are left as drafts. If the data is of any use, shouldn’t it be moved to published? And if it’s not necessary after first use (admin email notifications), shouldn’t this junk be deleted?
The Database Cleanup deletes our ‘post’ post-types in post-status ‘draft’, but it doesn’t delete other post types in post-status ‘draft’ …. actual trash that’s no longer of use (unless it’s reported in a log somewhere).
I’m suggesting this one feature is a chainsaw, where a scalpel should be used – re-using a metaphor I applied recently to Hummingbird Asset Optimization. I wouldn’t want this feature to blindly delete draft items for any post-type, without knowing what the items are, how old they are, where they might be used, or other context-sensitive facts. That goes especially for ‘post’ types. Where WPMU DEV creates draft items and then leaves them there to collect dust – I’m hoping they’ll use their own tooling here to delete them.
In summary, I appreciate the functionality but I think this first implementation is overly aggressive, and I’m hoping DEV will (to use another metaphor) make this trigger a little more difficult to pull given that it’s so easy to shoot ourselves in the foot with it.
Thanks.