Or maybe better said: enable fieldgroups to also work for module-provided data in forms and not only cck fields.
I initially had planned to only get location data into a fieldgroup, but once the mechanism is there it should work for all module provided data - tested only with 'location'!
My private branch has a few more lines to strip the outer fieldset in the form for location in a fieldgroup, but since I have neither a configuration-mechanism nor an admin-gui to enable/disable this, it's not part of this patch.
If wanted I could extend the patch to do a bit refactoring on content_admin_field_overview_form(), but I didn't want to do that for an initial version.
Comments?
Comments
Comment #1
ray007 commentedall right, 2 fixes for warnings, plus my strip of outer fieldset for location in edit form included.
Comment #2
ray007 commentedNo comment at all?
I must say I had hoped for some more feedback ...
Comment #3
jhm commentedI would love to test this patch, but I seem to dense to apply it. While I am googling how to do that, maybe you see this and respond with a tip?
Jan
Comment #4
ray007 commentedI guess we should request a link in the "contributor links" box to http://drupal.org/patch/apply
Comment #5
jhm commentedthanks. patch applied, will test and report back later
Comment #6
jhm commentedI don't see how to access location information for a node thru CCK. What am I missing?
Comment #7
ray007 commentedIf you enable location for the content type, you can place the location input fields and form into a fieldgroup. Check the "manage fields" tab for the content type.
Comment #8
ray007 commentedSince I had troubles to fit all my fields between -3 (taxonomy) and 0 (body) I extended my patch so it's possible to change to weight of the body.
Patch attached.
Maybe now some more comments?
Comment #9
ray007 commented*Bump*
I had hoped for some more feedback here.
Comment #10
yched commentedYes, I guess so. Sorry about the delay, lots of things to do, not that much time...
I did not actually test the patch, and did not take the time to take a close look at the code. While the feature is definitely interesting and would surely be much welcomed, I must admit mixed feelings about the idea. It exceed CCK's initial scope (manage custom fields) in directions I'm not sure we're willing to take.
The proper way to tackle this is the (yet largely to be discussed) refactoring of nodes that's in the air for D7, and ultimately, 'CCK in core'. Something like : let nodes be 1. metadata (nid / author / type/ timestamp, etc) 2. 'fields' (taxonomy, menu path, 'cck fields as we currently know them', etc...). Then a unified handling of form elements, fieldgroups, etc, can be
Until then, I'm not sure I'm willing to bend current CCK to force the feature in. CCK is a complex and fragile enough ecosystem as is, and having it act on entities that are outside its current scope is not something I personally look forward to. Best thing would be to let that happen in an external contrib module - not sure it's possible, of course...
Well, this being said, I still have to actually look at your code :-)
Comment #11
ray007 commentedThanks for taking a look.
I don't think it's possible to put it in another module, at least not if fieldgroups should still work ... but you'll see ;-)
Comment #12
dopry commentedJust to keep my life as a CCK maintainer simple... I'm going to mark this won't fix... Not that it isn't a great feature, but I'm really worried about the potential support headache of altering large form structures for other modules that may be expecting a set form structure... I don't think I or the other CCK maintainers have time to field the additional support load this might incur.
Comment #13
Anonymous (not verified) commentedCan someone port this patch for Drupal 6.
Thanks,
tristan.oneil
Comment #14
socialnicheguru commentedi'll try this on D5.14.
C