Add status/promote/sticky to node_revisions table [#543294]

Given that any hope of #218755: Support revisions in different states being implemented in D7 is quickly dwindling as the code freeze approaches, and in light of conversations taking place in #282122: D7UX: "Save draft" and "Publish" buttons on node forms, I propose that we take the small but extremely significant step of adding status, draft, promote and sticky fields to the node_revision table.

These fields would remain in the node table as well, but be duplicated in the node_revisions table. This would be a HUGE boon for anyone working on modules dealing with content moderation and workflow. It would prevent the need for many complicated hacks and workarounds while greatly increasing the scope of what can be accomplished in contrib. Given that we're leaving the fields in the node table, I don't expect this will have any substantial downside, but the potential upside is tremendous!

Comment	File	Size	Author
#8	543294-add-bit-columns-to-node-revision.patch	5.74 KB	Damien Tournoud
#8
#7	543294-add-bit-columns-to-node-revision.patch	5.12 KB	Damien Tournoud
#7
#5	543294-add-bit-columns-to-node-revision.patch	5.12 KB	Damien Tournoud
#5
#4	543294-add-bit-columns-to-node-revision.patch	5.12 KB	Damien Tournoud
#4
#3	543294-add-bit-columns-to-node-revision.patch	4.24 KB	Damien Tournoud
#3

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

catch

he/him

English

CreditAttribution: catch commented 8 August 2009 at 09:33

I have a feeling that if we just add the fields in the schema, drupal_write_record() will handle writing to them for us, so this could be a very small change.

Comment #2

jstoller

he/him

CreditAttribution: jstoller commented 9 August 2009 at 00:11

Great! How do we make that happen?

Comment #3

Damien Tournoud CreditAttribution: Damien Tournoud commented 9 August 2009 at 00:54

Status:

Active

» Needs review

File	Size
543294-add-bit-columns-to-node-revision.patch	4.24 KB

Here is an (untested) patch.

Comment #4

Damien Tournoud CreditAttribution: Damien Tournoud commented 9 August 2009 at 01:06

File	Size
543294-add-bit-columns-to-node-revision.patch	5.12 KB

Moshe noted that we need to load those columns from the node_revision table now.

Comment #5

Damien Tournoud CreditAttribution: Damien Tournoud commented 9 August 2009 at 01:07

File	Size
543294-add-bit-columns-to-node-revision.patch	5.12 KB

And a less-broken patch.

Comment #6

yched CreditAttribution: yched commented 9 August 2009 at 01:08

I'm not sure sticking the update in the existing node_update_7005() for 'body as field' is a good idea. Saves duplicating the overall structure of the function, but those are two really unrelated updates...
At any rate, note that node_update_7005() only acts on node types with $info->has_body == TRUE, which is not what we want here.

Comment #7

Damien Tournoud CreditAttribution: Damien Tournoud commented 9 August 2009 at 01:10

File	Size
543294-add-bit-columns-to-node-revision.patch	5.12 KB

An even less broken one.

Comment #8

Damien Tournoud CreditAttribution: Damien Tournoud commented 9 August 2009 at 01:13

File	Size
543294-add-bit-columns-to-node-revision.patch	5.74 KB

This one should do it, and fix the issue raised by yched in #6. I do think it makes total sense to do both operations at the same time.

Comment #9

moshe weitzman CreditAttribution: moshe weitzman commented 9 August 2009 at 17:33

Status:

Needs review

» Needs work

+++ modules/node/node.install
@@ -488,6 +525,19 @@ function node_update_7005(&$context) {
+        // Migrate the status columns to the {node_revision} table.
+        db_update('node_revision')
+          ->fields(array(
+            'vid' => $revision->vid,
+            'status' => $revision->status,
+            'comment' => $revision->comment,
+            'promote' => $revision->promote,
+            'moderate' => $revision->moderate,
+            'sticky' => $revision->sticky,
+          ))
+          ->condition('vid', $revision->vid)
+          ->execute();

Can we not populate node_revision with a single SQL statement that features a subquery? If successful, it probably does make sense to separate the node_revision migration from body as field.

Comment #10

Damien Tournoud CreditAttribution: Damien Tournoud commented 9 August 2009 at 17:47

No, there is no such thing as UPDATE FROM SELECT (as there is INSERT FROM SELECT).

Comment #11

moshe weitzman CreditAttribution: moshe weitzman commented 9 August 2009 at 17:58

Status:

Needs work

» Needs review

Comment #12

RdeBoer

Melbourne

CreditAttribution: RdeBoer commented 10 August 2009 at 00:12

Agree with jstoller this was long overdue. Big thank you to all others in this thread for making this happen.
Rik

Comment #13

jstoller

he/him

CreditAttribution: jstoller commented 19 August 2009 at 00:55

This patch will likely need to be updated based on what's happening in #282122: D7UX: "Save draft" and "Publish" buttons on node forms.

Comment #14

moshe weitzman CreditAttribution: moshe weitzman commented 19 August 2009 at 02:56

Status:

Needs review

» Reviewed & tested by the community

Comment #15

Dries CreditAttribution: Dries commented 19 August 2009 at 12:38

Status:

Reviewed & tested by the community

» Fixed

This looks like a great first step. Thanks!

Comment #16

webchick

she/they

English

Vancouver 🇨🇦

CreditAttribution: webchick commented 19 August 2009 at 14:10

Oh, excellent!

This patch was off my radar, but would've made writing Revision Moderation module sooooo much easier!

Comment #17

RdeBoer

Melbourne

CreditAttribution: RdeBoer commented 20 August 2009 at 03:55

Errr.... marked as "fixed" ?

As jstoller mentions in #13. The patch is subject to change as a result of developments in #282122: D7UX: "Save draft" and "Publish" buttons on node forms, in particular comment #160, regarding the "(published) status" flag.

The published info is already covered by the "status" flag on node. Having this flag on the revision table as well is unnecessary and inefficient. Furthermore it will open the door to confusion and possible data inconsistencies. There can be at most one revision that is published. But with a status flag on revision it will be possible to create pathological cases where more than one draft/revision have their published flags set.

By contrast, again referring to #282122, comment #160, a more generic "state" field on revision would be brilliant!

So, in the patch just change the word "status" to "state" (or "workflow", as Dries prefers in comment #161 and we're done!

.....except maybe for the moderate flag...
As far as I know "moderate" is already obsolete on node, what is the idea behind reviving it for node-revision?

Comment #18

jstoller

he/him

CreditAttribution: jstoller commented 20 August 2009 at 22:49

Status:

Fixed

» Needs work

Based on the current standing of #282122: D7UX: "Save draft" and "Publish" buttons on node forms, the changes from the current patch here are:

'status' should be removed from {node_revisions}
In the {node} table, 'status' should be renamed 'published' to prevent confusion with our new 'state' field
'moderate' is a node property and should only appear in the {node} table
Add a 'state' field to {node_revisions}
Add a 'last_state' field to {node_revisions}
The 'timestamp' field in {node_revisions} should be replaced by 'created' and 'changed' fields, just like those in {node}

I think that's it, but please check #282122: D7UX: "Save draft" and "Publish" buttons on node forms for the details and any further changes. Alas, I will be out of town until code freeze.