[wp-hackers] Data recovery (post_status?)

[David Chait]

Owen Winkler wrote:
| David Chait wrote:
| > I'm happy with any solution that is reasonably quick to query, and takes
| > minimal-if-any resources to exclude from queries.  If you have to query 
a
| > secondary table, or test a character, that'll make it more difficult to
| > 'exclude'.  That's why I proposed post-status==trash, though I 
admittedly
| > didn't consider the 'how to put things back' for posts vs comments vs 
...  I
| > think the period-prefix thing is a potential query bottleneck...
| >
| > do we simply need a 'trash' flag on all major object tables?  that just
| > seems overkill in one sense, in another it simplifies stuff greatly.
|
| When did "delete" come to mean "possibly store it somewhere for
| convenient for later retrieval, just in case you didn't really want to
| actually, you know, delete it"?  I never saw any delete buttons labeled
| "Throw this away, but put it somewhere I can get it later if I made a
| mistake".  I can see the advantage of letting users recover from their
| mistakes, but geez.

Ummm, usability folks?  I think there was a recent link here to an article 
about the Scott Adams disaster, which noted that the usability of web apps 
just stinks when it comes to things like deleting items.  I mean, my OS has 
a trash can, my email app has a trash can... ;)

| In any case, using a separate trash table to hold all of this data seems
| silly when the affected tables have a status column that could be set to
| "deleted".  The only thing you lose is the status prior to deletion,
| which would be set to the status with the least impact, for example,
| "draft" or "0"/"moderate".  Everything else would already be set properly.

First, I never said use a separate table -- I said a separate flag/field. 
Second, I'm the one who suggested setting the status column to 'trash' in 
the first place! ;)

| Deletion dates (if you want to purge deleted things via cron) could be
| stored in postmeta.  For comments, that's a bit trickier.  Are we going
| to add the commentmeta table?  If so, there's the natural place for it.
|  If not, then the purge cron action can simply store (in options) the
| comment ids of all of the comments that it didn't purge during the last
| purge event.  It will only purge comments that are stored in this list.
|
| If you insist on a new column, then make it a NULL-capable date field.
| If the field is NULL, then it's not deleted.  If it is not null, then it
| contains the date the record was deleted.  Every query on those tables
| will then need to check whether that column is NULL to make sure it's
| not returning deleted items.  Since all queries should already be
| checking their status fields directly (post_status = 'publish' will
| automatically ignore rows using the status of 'deleted'), using a flag
| field will be more coding work, data storage, and query overhead for not
| much more gain.

I don't insist on new anything.  I floated an initial idea of status==trash, 
which got responded to by "how does it get restored", which led me to float 
the flag idea... :)

I'm all for storing deletion timestamp and original post_status in the 
post-meta.  Sounds great.  No need for a flag.  No need for another field or 
table for posts.  Comments are a separate topic -- though I agree, 
comment_approved (once made into a varchar) could ALSO be set to 'trash'.

I'd prefer the wp-cron-purge thing be an optional implementation, not the 
default.  How hard is it to click over to the "Trash" page, and click the 
"Yes, really nuke all of these" button, maybe once every two weeks?  I just 
dislike house-cleaning thingys running on their own (I'm a C++ programmer, 
not Java! ;) ;) ).

-d