[EXPORTING] Export of Workflow Field using machine_name, not $wid

Not sure how to accomplish this, but it needs also some dependencies:

  $export['dependencies']['workflow'] = 'workflow';
  $export['dependencies']['workflowfield'] = 'workflowfield';

And perhaps inclusion of the workflow itself.

The following blog gives more info: http://foxinbox.org/content/features-magic-how-features-adds-additional-...

Adding this as a feature request. For simple usage, the wid will always be '1'.

There is no solution yet, but this fix does the following:
- When a workflow_field is exported with Features, the corresponding Workflow is exported, too.
- The exported workflow contains its machine_name and 'original_wid', so this could be mapped upon insert. Perhaps this is not sufficient, and should the mapping be exported using a 'variable'.

I tried the make the field settings saving the machine_name instead fo the sid, hence all the changes regarding ['settings']['wid'].
But this would break the site if someone changes the machine_name.

Your suggestion in the OP might do the trick, too.

I tried to resolve this. But it is too complicated. D8 will have named entites and UUID-support by default.
I suppose it will take D8 to resolve this ...

Remind me a bit about problems exporting user groups in D7. Have you tried looking at how they addressed that in https://www.drupal.org/project/role_export ? It is bit "hackish" though it does the trick :)

could use uuid and uuid_features like taxonomy does.

Is this likely to be fixed for D7? Or is it a lost cause? I'm rather toast without this, becuase workflow fields in imported features just lose their associated workflows. :(

@samwilson, As a maintainer, I have tried to make this working, adding all bits and pieces one at a time.
ATM I am happy to accept patches, but am not working actively on it. (trying to manage D8 :-/ )

@Artusamak is/was working on a patch in #2286559: [META] Make Workflow's subobjects things exportable (a.k.a. machine names).. It replaces the Workflow Id by the Workflow machine_name.
But As I stated in comment #10 and #19, The machine_name should only used in the export, not in the module itself.

@johnv thanks, sounds good. I'd love to help; I'm still getting my head around how it all works though. I'll try... :-)

Wow... This broke our site several times and never saw this post. Just kept deleting workflow fields and re-addding.

Took me hours to figure what was wrong in our feature export to testing site:

For the reference if anyone else in the future wonders you might get this error message:

Workflow 1 cannot be loaded. Contact your system administrator.

To clarify this issue for anyone who will come here wondering:

So my original site had just one workflow. This workflow was the second one created though hence it is number 1 (first one is 0).

On my testing site I had re-imported the feature many times so now the workflow was on number 4, even though it was the only one it was the fourth one created since installing the module.

I fixed this by editing the workflows table and changing the wid from 4 to 1. Is are there risks in this? My feature wants workflow 1 but is the wid referenced somewhere else?

EDIT:
..Of course there is. Just have to look for wid column and change all 4 to 1 and hope I found everything

Can you guys let me know if my patch in #7 of #2484297: Features import / revert broken in 2.5+ works for this case too?

The code already allows $field['settings']['wid'] to be a machine name (at least in most cases). It's not too hard to just use machine names all the time, which this patch does. It also upgrades existing fields to use the machine name. Now, when you export a workflowfield with features, it will connect to the correct workflow by using machine names.

This doesn't solve the issue with wid/sid/tid's existing all over the export of the workflow itself, https://www.drupal.org/node/2484297 . It also doesn't handle the problem with field values, those remain sids, which may break on import.

That's such a hack... wid should be numeric. It's a number in the schema, and mis-using the wid as though it were the machine name is just inviting confusion for developers, especially for existing modules that plug-in to Workflow.

FYI There is no issue with Workflow using numeric wid, sid, etc internally. That's the main reason why I have such an issue with the other patch that you did. Drupal internally uses numeric node IDs, taxonomy uses term IDs, etc. It makes no difference what they use internally as long as the export does not rely on those IDs. Rewriting the whole module to query everything by name is a massive breaking change, and slows down fetching states, etc because the DB has to do the look-up based on strings instead of integers.

I'll address the field export issue separately in my patch.

Thanks for the feedback, GuyPaddock. I think you're confusing me with somebody else, though, when you say "That's the main reason why I have such an issue with the other patch that you did." I don't think I made any other patches to workflow…

I definitely agree with your general approach to workflow featurization! Entities can continue to use numeric IDs internally, and use machine names for export only. However, although your patch does a great job featurizing the workflow itself, it doesn't help with the export of the field_base. It still uses a numeric wid, so when you enable the feature, the field may end up pointing at a non-existent (or incorrect) workflow. My patch is a complement to yours, not a competitor.

I'd be very happy if there was a way to keep a numeric wid in the field settings, but then somehow intercept the field_base export so that it becomes a machine name in the feature. However, I haven't been able to find any such mechanism that's at all reasonable. Please let me know if you have any ideas.

On the other hand, I don't think it's terrible to use a machine name in the field settings, for several reasons:

1. This is just the wid in the field settings, not the wid in the database—there's no schema specifying that it must be an integer.
2. Many comments already within workflow indicate that it can store a machine name, eg: "@todo: to make this exportable: use machine_name??", "$field['settings']['wid'] can be numeric or named.", etc.
3. Other Drupal modules usually store machine names in the field settings, eg: taxonomy.

I look forward to more discussion, and I'll take some time to look at your patch in the other bug.

Okay, looks like there's now a solution to the other issue and this is the main issue of interest to prevent features from being flagged as overridden.

@vasi: My apologies for confusing you with someone else; I do remember coming across a patch that pretty much just changed everywhere we used wid and sid with machine names, breaking the API.

Removed

The exporting of workflow and Workflow Field definition is now decoupled. See #2375261-7: [EXPORTING] Workflow exported to new feature even if it already exists in an other feature

John, not sure how that applies here. I was saying that the state IDs and workflow IDs won't always be the same across environments. The fact that the two are decoupled doesn't seem to apply, unless I'm missing something.

Indeed. I posted this in 3 relevant issues, so everyone is uptodate.
And this issue is only completely solved if the workflow_field export a workflow machine-name, too.

The following code sems to update the settigns with the Workflow machine_name, but the ex

function workflowfield_field_update_field($field, $prior_field, $has_data) {
  if ($field['type'] == 'workflow' && $field['module'] == 'workflowfield') {
    static $field_name = '';
    if ($field_name == $field['field_name']) {
      // Avoid recursive call to field_update_field.
      return;
    }

    $field_name = $field['field_name'];

    if ($wid = $field['settings']['wid']) {
      /* @var $workflow Workflow */
      $workflow = workflow_load_single($wid);
      $workflow_name = $workflow->getName();

      // Use the opportunity to delte the contents of the textarea.
      unset($field['settings']['allowed_values_string']);
      // Add the machine_name, for features export.
      $field['settings']['workflow_type'] = $workflow_name;

      // Save the enriched data again.
      field_update_field($field);
    }
  }
}

What impact does this have for updating a feature on a site with existing content as the field values/revisions table will have data that references the SID. As I'm understanding wouldn't that make all historical data corrupt.

Should enable maybe check for workflow by name and if it exists assign its WID to the field in the case of an update. Otherwise any time feature is enabled or disabled it would create entirely new workflow instance with different WID/SIDs.

I'm new to much of this so please let me know if I'm wrong in my assumption

New features for D7 are not processed anymore, (unless a patch is provided)