Ability to Incorporate -- Field collections -- Into Workbench Moderation

Hi HyperGlide,

The fundamental issue here is that Field Collections are separate entities that do not revision. So that node is storing a a reference to an fcid similar to the way it might store a node reference id. So if the fields within that fcid change, there's nothing the node and Workbench Moderation can do.

There is an issue in the Field Collection queue to make Field Collections revisionable. #1031010: Support revisions for field collections

And I wrote a patch to FC that will get the the functionality you want if you need it right now. Though as I mention in that comment, it's not a version of a patch that should go in FC. http://drupal.org/node/1031010#comment-4571890

I have the latest versions of Field Collections and Entity (Dec 15, 2012), but I am still having the issue as described by @HyperGlide. If I view the node/%/moderation page, it shows that there is no active version of the node-- only the Draft-- with this message at the top: "Currently there is no published revision of this node."

Using Workbench 7.x-1.1+7-dev and Workbench Moderation 7.x-1.2+13-dev.

I made this video which shows what happens with a Field Collection is edited in a node.

https://dl.dropbox.com/u/4770698/Drupal-org/Workflow%20Moderation%20with...

Great! If you need more information, be in touch. I can usually be found on #drupal-support as @capellic.

I can reproduce the problem at #5. The edited node (containing a field collection) is published immediately, without the added field collection. Under Moderation Actions, the revision is shown as transitioning from Draft -> Draft, twice (I do not use a "review" state).

Manually setting Publishing Options >> Moderation State to "published" before saving the node does result in the expected behaviour: the node is published immediately, includes the new field collection instance, and there is a single state transition under Moderation Actions.

The interesting thing here is that I am 99% sure that at some point in the past this was working - when I demoed the site for the client we made a point of checking that field collections were revisioning correctly via Workbench Moderation, and the site is now live. Gulp.

See also: #1844322: Unable to save draft when adding new field values on published node (workbench moderation)

I think we're on to something. If you create a node and leave a field collection empty, there is no way you're going to able to publish content to that field collection in the future.

Continuing on from my screencast above, I created a page node and this time I defined a single entity for the Banner field collection. Then I Published this node and the Banner content appeared.

Great.

Then I created a new draft, changed the title field for the existing Banner field collection entity. I was able to do so, but I found another problem. That updated title was immediately published as you can see in my screenshot.

So two things:

1. Use it or lose it. If you don't define the field collection values upon creation of the node, you can never do so.
2. Updating an existing field collection value in draft mode immediately publishes draft field collection values.

I've ruled out Workbench Moderation as the problem. I turned off Workbench Moderation and then went through the process of adding a node and defining values in the 0 instances of a field collection and then went back to update, created a revision and then the published version of the field collection was updated.

I'm confident the issue is either with Field Collections or with Entity API, but I haven't yet started to dig there too much.

Check out comments #140 and #141 on #1031010: Support revisions for field collections:

http://drupal.org/node/1031010#comment-6604330
http://drupal.org/node/1031010#comment-6979878

Some updates.

1. Use it or lose it. If you don't define the field collection values upon creation of the node, you can never do so.

Turns out we had an additional problem-- you couldn't add additional rows to a collection after the initial publish. I found this case, #1844322: Unable to save draft when adding new field values on published node (workbench moderation), applied the patch and have also noticed the "use it or lose it" workflow has been fixed.

2. Updating an existing field collection value in draft mode immediately publishes draft field collection values.

Still having trouble with this, but I've found that it's inconsistent. I have another content type that has the same field collection (field_banner_fc) on it and the draft/needs review/published workflow works as expected. I read a case where Conditional Issues were a problem (#1549364: Data not being saved on initial creation) but it doesn't really seem to fit my use case of publishing prematurely. I tested by shutting off conditional fields and it didn't help us out. @HyperGlide, anything to report from your upgrade?

2. Updating an existing field collection value in draft mode immediately publishes draft field collection values.

OK gang, this has turned out to be one red herring. But there is something learned here. The banner field collection was being displayed through a Panel node template as a View. I don't think Panels has anything to do with this, but Views has everything to do with this. Looks like Views will simply return whatever is in the field data table and assumes the latest version of the field is the right one.

So while you can call off the hounds that are sniffing through Workbench Moderation and Field Collection code, I still need to figure out why Views is not showing the Field Collection child fields attached to the current version of the node.

I'm going to close this issue again. The comment here ("Check the field collection value within a custom field_collection view = FAIL") seems to get have already identified the problem: http://drupal.org/node/1031010#comment-6604330

Thanks for diving in.

I still need to figure out why Views is not showing the Field Collection child fields attached to the current version of the node.

The field in a field collection is not really attached to the node how all other fields are. I've already seen this in linkchecker while dumping the $node. This seems to be a major problem as it uses it's own custom structure/logics and requires very special handling and loading the of these fields. If you found out, please tell me too.

Let's call this a duplicate, since there is a patch that needs to be applied. See #1807460: Field collection doesn't play nice with workbench moderation (patch).

I still have a possible problem with

2. Updating an existing field collection value in draft mode immediately publishes draft field collection values.

but there is a fair bit of custom display code supporting my use of field collections which I will need to check for its revision handling. If I still think I have a revision bug I will follow up in the thread linked above.

@John Pitcairn: I don't see how the Views issue (comment #15) is a duplicate of #1807460: Field collection doesn't play nice with workbench moderation (patch)

It isn't, but a more specific title in a new issue might provide better focus for the Views problem?

John, I've moved the issue to a new case: #1901892: Most recent Field Collection revision always appears in View when using Workbench Moderation

Thanks for your help.