Field overview conflicts with _form_alter

also reported in http://drupal.org/node/121412

The cck default value handling in the 1.0 release of imagefield wasn't implement. Update to imagefield 5.x-1.1 and empty your cache. thanks.

I can't reproduce with cck 1.3 + imagefield 1.1 for drupal 5.x. Can you verify your versions and make sure you don't have two copies of imagefield in your modules tree?

I had and now have this issue again. For me, the Image Field does appear in my Display Fields list and is function in my Page Types no matter what. However, it was not available in Manage Fields in version 1.0. I updated to 1.1 and it was visible, but shortly thereafter it was gone again. This is on a new install of Drupal 5.1 so I am turning on and off a few modules to get this how I want it, so perhaps it's a conflict with another module. I'll do some experimenting and see what I can come up with. I have cleared my cache, reuploaded and cleared the module, etc. and that didn't help.

Ok that was fairly easy to find, this appears to be a conflict with the FormFilter module. When the FormFilter module is enabled, the Imagefield module is not visible in Manage Fields. Perhaps there's additional conflicts with other modules that are causing other folks to have more severe problems? I hope this helps out, but keep up the good work because this is still module is still a great help in CCK!

The field overview tab internally builds a node edit form in order to list the fields, pseudo-fields (title, body, terms..) and fieldgroups.

So yes, there will definitely be a conflict with Formfilter, and probably any additional form_alter - and this is not specific to image fields...

http://drupal.org/node/122401 has been marked a duplicate of this

I was curious what formfilter was doing that was such a problem and it is actually moving cck fields to a different spot on the form. Form_alter() is not a problem itself if it is being used to add additional fields to the form since that's exactly what we're trying to detect. The problem is that in this case form_alter is being used to move our CCK fields somewhere else in the form, which will completely break the manage fields page which assumes the fields are where the content module put them.

So the question is do we try to figure out which modules are doing things like that and leave them out of the module_invoke, or should we find some way to find the new location of CCK fields on the adjusted form and represent them that way (but it could be quite hard to do that), or ditch the whole idea of trying to provide a way to see what else is on the form (and penalize people not using problematic modules).

Not sure which way we should go here...

Try disabling everything other than the basics -- core, CCK, and imagefield -- and see if that works. If so, add other modules back in until it breaks to see if you can tell what might be causing the problem.

http://drupal.org/node/123821 was marked a duplicate of this one

I personally think field grouping should only handle CCK fields, and not worry about the form_alter and what other modules may add or change. Field Grouping would probably need to be implemented as a formAPI construct, not as a part of CCK, to be implemented dependably. It stretches the scope of CCK in strange ways.

Dopry, while I fully i agree with what you say about fieldgroups and FAPI, the form_alter issue is not related to the fieldgroups per se, but rather to the fact that we want to have non-cck fields (title, body, taxonomies...) listed in the overview ,to allow the user to set the weights on CCK fields accordingly.

The current way of "finding" those fields is to build a dummy node form, and detect non-cck fields. Karen found that, and right now I can't think of any other way to achieve this.
The same trick allows us to grab fieldgroups as well, but I guess if it were only for them, we could build the overview form without the dummy node form stuff...

We could go back to providing no context for the fields, just listing them, but IMO that would be a big step backward, and we'll go back to fielding lots of 'Why is the title now in the middle of the page' issues.

I've been trying to figure out another way. My best idea is to show only title, taxonomy, body, fields, and groups. We can do that much without creating a dummy form, since we know where they are (or should be), hence without any need to call hook_form_alter. It's somewhat less useful, but maybe useful enough.

But hook_form_alter means there is no way to be sure that this representation is anything like what the final form would look like. FormFilter is moving the fields to new and different places, and any number of other modules could be doing that. They could even be changing weights and moving things out of the groups they were put in.

So one way to represent the way the form will *actually* look is to create a complete dummy form, as we're doing now, then drill down through it to find all our fields and groups and see where they ended up, not something I myself have the time or inclination to do.

Or maybe we can add a 'preview' button to the form to make it easier for users to see where things will end up, possibly linked to a preview that displays weights in the way that the devel module does it.

okay... so dont' form_alter youre field into strange places, is our stance... This won't be fixed in D5...