[development] Moderation bit behavior

[Dries Buytaert]

On 05 Jul 2006, at 17:43, Khalid B wrote:
>> status  - remove. Let a module like workflow control the state of the
>> node. Or, don't have a state. Let the admin decide. Node_access is a
>> better solution than an all or nothing published state, in my  
>> opinion.
>
> Worth exploring further.

Worth exploring indeed.

>> promote - remove. Let's move nodequeue into core and make a default
>> "front page" queue. This more extensible.
>
> This is an interesting way of doing it and allows many flexible things
> to be done.

>> sticky - remove. Again, let the nodequeue system decide what is first
>> in the order.

Worth exploring indeed.

I suggest we tackle one or two fields at a time though.  Let's start  
with the moderate field.  We all agree to remove the moderate-check  
from the SQL queries so we can start working on that.  Chris offered  
to work on that.

The one thing we don't agree on is whether we should remove the  
moderate-flag from the node table, or whether we should leave it in  
place for other modules to use.  I'd prefer to remove it, but I don't  
mind leaving it in place if there are good reasons for.  Let's move  
that discussion to the patch queue, as soon Chris comes up with a patch.

So if Chris is going to work on the moderate-check, maybe someone  
else can focus on either:

a. the status-flag (as well as figure out how we can offer a 'save as  
draft'-feature).

b. exploring the benefits of caching frequently accessed fields in  
the node table.  This thread (http://drupal.org/node/47702) makes for  
a good starting point to evaluate the usefulness of this approach, as  
well as to figure out what fields are worth caching.

--
Dries Buytaert  ::  http://www.buytaert.net/