[wp-hackers] Data recovery (post_status?)
davebytes at comcast.net
Sat Feb 11 23:08:10 GMT 2006
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.
----- 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.
More information about the wp-hackers