Hi,

I'm assuming this isn't possible, and that this should be a Feature Request instead of a Support Request, but I could have missed it:
Is it at all possible to export a CCK Field without an attachment to a Content Type, so that on enabling the Feature the user would be able to choose which Content Type(s) to apply the the Feature to?

If this is not available, the reason I would want such functionality is so that I could setup an ImageField in a specific way to be ready to use with another module (WYSIWYG ImageField - Requires an ImageField with Insert enabled, Unlimited files, and a checkbox ticked) then have the setup of the ImageField as a Feature so that users could simply say choose which Content Types they wanted to use the WYSIWYG ImageField module with and have the Field with settings automatically applied.

Just a thought, seems like something that could be quite useful.

Cheers,
Deciphered.

Comments

yhahn’s picture

yhahn commented
Status: Active » Fixed

It's currently possible to export CCK field instances without the node type (see #872052: CCK fields UI export options) but it's not possible to create "abstract" field instances that can then be assigned dynamically to any number of node types.

It should be possible to do this, however, using the fields defaults alter hook to introduce new instances of the field for the selected node types.

function mymodule_content_default_fields_alter(&$fields) {
  // Check a variable or other user-setting for node types
  foreach (variable_get('mymodule_nodetypes', array()) as $nodetype) {
    // Define field instances here
    $fields["{$nodetype}-field_foo"] = array(
      ...
    );
  }
}

Let me know if you have any other questions.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

aaronbauman’s picture

aaronbauman
he/him
commented
Status: Closed (fixed) » Active

Forgive me for reopening this issue, but I have a followup question directly related to comment #1.

I've built a module to roll up a set of fields into a feature, and exposed those fields by implementing hook_features_api() and relevant component hooks (call it "base component"). When I define extra fields in the way that Young suggests, using hook_content_default_fields_alter(), other features that include "base component" are always marked "overridden".

Is there a workaround so that they'll be marked "default" -- maybe by some magic with 'default_hook' in hook_features_api() or elsewhere -- or will I have to live with this annoyance? I've been looking at the examples of features.content.inc and other features core components, but I have so far come up empty.

The end goal is to feature-ize a kind of prototype -- fields, fieldgroups, etc. -- in order to reduce the overhead of reusing fields between content types.

Any help appreciated, thanks.

kenorb’s picture

kenorb commented
Status: Active » Closed (fixed)

The same problem as in #3.
Created separated bug report for that.
#1101256: Exporting field without CCK cause non-revertible Overridden status