[wp-hackers] Data recovery (post_status?)

[David Chait]

right, or have something like a dot-prefix to denote hidden classes of 
objects that the normal interface should ignore...

yes, definitely will need a code sweep.

-d

----- Original Message ----- 
From: "Mark Jaquith" <mark.wordpress at txfx.net>
To: <wp-hackers at lists.automattic.com>
Sent: Saturday, February 11, 2006 5:13 PM
Subject: Re: [wp-hackers] Data recovery (post_status?)


| On Feb 11, 2006, at 5:07 PM, David Chait wrote:
|
| > Agreed.  And, with the move to make more things varchar for
| > extensibility,
| > here's a vote to move post_status away from being an enum.
| > post_status=='trash' would probably do fine for this.  or
| > ".trash" (would be
| > nice to have a convention for hiding certain status 'classes' from the
| > normal view queries without explicitly listing the states to
| > exclude...).
|
| +1 on all counts, including making comment_approved a varchar.  Note
| (important one!): we're going to have to sweep through the code and
| make sure that all WP comparisons on post_status or comment_approved
| do == comparisons and not != comparisons.  That is, you should be
| able to add a new status and have WP just ignore it.  WordPress
| should name the statuses it wants to be seeing, not the ones it
| doesn't, because that might accidentally include new "custom" statuses.