Drupal has a revisioning system based on nodes. Revisioning module http://drupal.org/project/revisioning works great on node revisions. However, as far as I know there is no revisioning system for fields. Fields in core will be realized in D7 and the task at http://drupal.org/node/367595 is giving translation feature to fields. I think it would also be nice to keep a revision history (like revision author, status [in moderation, current etc.], revision time etc.) feature for fields. For example, it would be very helpful for a database site like movie database. For example, assume that a user updates a field of a movie like publishing date, director, language etc. Instead of creating a revision for all node (meaning duplicating all fields), it would be nice to just to create revision for updated fields. Admins can easily notice which fields are updated and also see the revision history. Also they can revert forward and back between the revisions of a field, without changing the revision of a node, which would change other fields too. What do you think?

There are similar requests in the forums, like

http://drupal.org/node/495322
http://drupal.org/node/512144

Comments

mcload’s picture

mcload commented
Issue tags: +Fields in Core, +Fields API

Also like this http://drupal.org/node/384208

Bojhan’s picture

Bojhan commented

I think its definitely a feature we want to pursue, however it requires some hard work probally.

yched’s picture

yched commented

Hm. My brain crawls to the back of my skull thinking of the quagmire.

Call me pessimistic, but IMO there's no chance that this will happen before D8, if at all...

bjaspan’s picture

bjaspan commented

I do not think this suggestion is a good idea.

First, the Field API already supports revisions for any entity type that has them. You describe the ability to update some fields of an entity separate from the others, but that really is nothing more than an optimization to save disk space in the db. I do not think the additional conceptual complexity in the API, implementation effort, nor development effort would be worth this optimization, certainly not until there was a compelling use case.

Second, you suggest that Field API should store "revision author, status [in moderation, current etc.], revision time etc." I do not think so. A field stores a specific kind of data; a text field is a text field, a date field is a date field. The other things you mention (author, status, time, etc.) are not properties of a field, they are fields themselves; they are properties of an entity, e.g. properties of a node. Your suggestion boils down to (and I shudder even to coin this phrase) "make fields into nodes." Down that path lies... well, nothing, because we won't go there. :-)

I'll leave this open for a response but expect to mark it "won't fix."

mcload’s picture

mcload commented

Field API's revision support only shows the revision number of the node that field is attached to. It is not something new or novel.

Information like "revision author, status" for a field can be stored easily, by using CCK's new multigroup option and using computed fields. It is possible to create revision information like author and date by using computed fields. It would be enough, if Field API supports revisioning for a multigroup field as a single entity (single revision for a field group). There is no need to increase number of nodes, which decreases site's performance, by using a different node for storing each field.

Yes, one merit is decreasing database size. A populer movie database, which can be updated by users, can easily decrease its database size by 100 times, by applying revisioning based on fields, instead of duplicating all fields of a node for each revision.

Another merit is the easy moderation. Assume that you have some fields like starting date, ending date, director, title. First, a user updates starting date field. In the current node-based revisioning system, a new revision is created for node with duplicationg all other fields and put into moderation queue. Before the moderation, assume that another user updates the ending date. Now we have two node revisions in the moderation queue. Then a user updates the title. Now we have three node revisions in the moderation queue and all of them store different information. First node revision has new starting date, but old ending date and old title. The second revision has new ending date, but old ending date and old title. The third revision has new title, but old ending date and old starting date. A populer movie site may end up having dozens of revisions for a node waiting in the moderation queue. Which one would you make the "current" revision? There is no way to join all these node revisions to single node, automatically. Admin would have no other choice than choosing one of them and check all the other node revisions and detect the updated fields and copy the true information in other revisions to the selected revision BY HAND. It is a very time-consuming an inefficent way of moderation revisioning. Field-based revisioning can solve this problem.

wretched sinner - saved by grace’s picture

wretched sinner - saved by grace commented

With core's focus on solving the problems for the 80%, I would see this as being a candidate for contrib, not core. I agree that revisions of fields would be handy, however I also think that most people won't use it. But for those that do, I think a contrib module would be best.

I guess the question then would be, does the Field API, as it stands, support the ability for contrib to do revisioning of fields. If not, what changes need to be made to enable this?

Soli Deo Gloria

moshe weitzman’s picture

moshe weitzman commented
Status: Active » Closed (works as designed)

@mcload - see diff module in d6. you can diff versions that are 10 changes apart fropm each other and it will show just those fields that changed. it is not cumbersome at all.

marking 'by design' per barry's explanation in #4.

mcload’s picture

mcload commented

Yes, I know diff module, but it is not a solution to this problem.
As #6 said, it may be better to implement this as a new module and find out how field API can support it.

batigolix’s picture

batigolix
Primary language Dutch
Location Utrecht
commented

A note for time travellers: D7 now tracks field revisions

targoo’s picture

targoo commented

http://drupal.org/project/track_field_changes enable you to select which fields need to be audited and provide an integration with view.