[development] Moderation bit behavior

Earl Miles merlin at logrus.com
Wed Jul 5 16:13:48 UTC 2006

Gerhard Killesreiter wrote:
> Mark Fredrickson wrote:
>> On the subject of bits on nodes, I would advocate for the least 
>> number of hard wired fields as possible. Hardwired data conflicts 
>> with user configurable systems and makes administration harder and 
>> more confusing for end users. Instead, I would advocate for 
>> dynamically added data (from modules) where needed.
>> In more specific terms, let me argue for removing a large portion of 
>> the current node object (feel free to disagree):
>>  From the node table:
>> nid  - keep
>> vid  - keep
>> type  - keep
>> title  - remove. Titles should be set by node modules (and stored 
>> where the body and teaser are), not stored in the node table.
> This was a design decision. We often only need the title of a node 
> (for link lists for example). If we do a join on the node_revisions 
> table, we lose a lot of time. We are contemplating to add the author's 
> name for the same reason (save join on user table).
>> uid   - keep
>> 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.
>> created - keep.
>> changed - keep
>> comment - remove. Why would I want this data if I don't allow 
>> comments? Spareness should be avoided if we can help it.
>> promote - remove. Let's move nodequeue into core and make a default 
>> "front page" queue. This more extensible.
>> moderate - remove. As this thread shows, no one is sure exactly what 
>> moderate should do. Let a moderation system control node moderation.
>> sticky - remove. Again, let the nodequeue system decide what is first 
>> in the order.
> I'd be in favour of a more flexible bitfield instead of all the single 
> fields.
I'd be in favor of something along these lines:

node_flag('moderate') -- returns the name of the flag used for 
'moderate' or NULL if there isn't one.
node_flag_register('moderate') -- register the flag during .install, 
returns the real fieldname. Returns NULL if no flags are available.
node_flag_list() -- return an array of all existing flags

Modules can then register their flags which are directly put in the node 
table. We can pick some number of these; we could add a method to add 
more flags;

Queries simply use node_flag('moderate') instead of 'moderate' if they 
care about it. They never need to know the field's true name.

Cons: database names won't be transparent because it will just be 
'flag1', 'flag2' or whatever, and some kind of translation may need to 
be done for things that look at a node as a whole. Also, 'flag1' on one 
Drupal install will have a completely different meaning from 'flag1' on 
another. I think both of these cons are quite minor; they allow us to 
kind of do away with the moderate flag without actually doing away with 
it. Modules which need to set flags can.

More information about the development mailing list