Less optimization for admin file

I'm playing around with this because it could be so incredibly useful. I'm not familiar with the macro module, but I tried a test recording of adding a new user and got a different macro than you are using. I got:

$macro[7]['form_id'] = '_content_admin_field_add_new';
$macro[7]['values']  = array (
  'label' => 'user',
  'field_widget_type' => 'userreference-userreference_select',
  'op' => 'Create field',
  'submit' => 'Create field',
  'type_name' => 'story',
  'form_token' => 'b92320af9cad6b1ef7ffae5f4808b9cc',
  'form_id' => '_content_admin_field_add_new',
);
$macro[7]['parameters']  = 'a:1:{i:0;s:5:"story";}';

I then deleted the user from the content type, imported the macro, and it successfully added the user field back in. The obvious difference is that it is a different form with some different values than the one you were using. I also got some macros that looked like yours (whith the form id in your example) and when I tried to import them, they failed. I'll have to do some digging to see which is which and why one works and not the other.

Also, per your request in #1, I see no reason not to make this change in the code. I'll try to remember to do it later, got to run right now.

OK, there are two macros that go together to create a new userreference field. This combination works:

$macro[7]['form_id'] = '_content_admin_field_add_new';
$macro[7]['values']  = array (
  'label' => 'user',
  'field_widget_type' => 'userreference-userreference_select',
  'op' => 'Create field',
  'submit' => 'Create field',
  'type_name' => 'story',
  'form_token' => 'b92320af9cad6b1ef7ffae5f4808b9cc',
  'form_id' => '_content_admin_field_add_new',
);
$macro[7]['parameters']  = 'a:1:{i:0;s:5:"story";}';

$macro[8]['form_id'] = '_content_admin_field';
$macro[8]['values']  = array (
  'widget_type' => 'userreference_select',
  'label' => 'user',
  'weight' => '0',
  'description' => '',
  'required' => 0,
  'multiple' => 0,
  'referenceable_roles' => 
  array (
    2 => 0,
  ),
  'op' => 'Save field settings',
  'submit' => 'Save field settings',
  'type_name' => 'story',
  'field_name' => 'field_user',
  'form_token' => 'bc31e5fcaaed69e241d46dd53c3d57f6',
  'form_id' => '_content_admin_field',
);
$macro[8]['parameters']  = 'a:2:{i:0;s:5:"story";i:1;s:10:"field_user";}';

The first macro creates the field, the second updates it with the settings.

There are some complication of using a macro on CCK fields, since you need to test for things like whether or not the field already exists in the content type you are copying it to, or anywhere else in the database. But I got inspired by this module to find a way to get a decent import/export capability into CCK. See the explanation at http://drupal.org/node/99446.

For whatever it's worth I've identified some of the reasons why programmic submissions are not working for node types and cck.

For node types, the important node type info is in #parameters, but that must be passed to the node_type_form as an object rather than an array. I got it working by unserializing the #parameters part of the macro, then casting it as an object. So maybe the macro module needs to check whether #parameters should be rendered as an array or an object when the value is stored and use that info to cast it correctly on execution.

I believe the cck forms should work as macros if you build the site from scratch while running macro function and then use the macro to build a new site from scratch. In other words, if you don't have to worry about whether or not fields already exist in the database or in the content type. If you try to use the macro on a site with existing data, you'll run into problems, but the import/export capability I'm working on in the link I mentioned earlier should provide a method that can be used for that.

It would be helpful if the macro module provided a hook so you could intervene after importing the macro but before executing it to see if any values need to be changed instead of blindly executing the macro, since some things can't be determined until you know something about the environment you are trying to execute the macro in. Perhaps that would also be useful to other modules trying to do things programmatically.

This change has been committed. I went ahead and did it in 4.7, too even though we don't have programmatic capability there just in case we try to backport some of those features.