Work is under way to refactor D7's Field UI overviews ('Manage Fields', 'Manage display') so that contrib modules (fieldgroup...) can add their rows in the reorderable tables : #616240: Make Field UI screens extensible from contrib - part II.
The patch currently only takes care of the 'Manage fields' screen for now. 'Manage display' will receive the same treatment after the HTML changes in #796658: UI for field formatter settings get in.
Once this lands, fieldgroup D7 will be (at last) possible. Here are a couple thoughts on what a D7 version could be:
- I think this - and the fact that D7 ships with jqUI - would be a great opportunity to centralize 'grouping flavours' in a single super-fieldgroup module in a dedicated project, handling :
- fieldsets
- js tabs
- vertical tabs
- accordions
- ... ?
The base code should be basically the same, it's just a question of generating slightly different render arrays using D7 core features.
- D7's vertical tabs have a way of reorganizing the output without altering the structure of the form / render array (operating in #pre_render or something). Keeping the form structure intact was the main reason why we always "won't fix"ed requests for 'allow non-field elements in groups'.
Using this method for all grouping flavours would allow the module to be a generic, non strictly Field related, module for form / display grouping. Gives another reason to move this out of the 'cck' pack.
- It's also a good occasion (and probably a required preliminary step) to rewrite the module from scratch. Poor old fieldgroup code is roughly 3+ years old, and received little love since then. It's not a complex module, but IIRC, the CRUD code is kind of... perfectible...
I don't plan to work on this myself, so this is actually a call for feedback and volunteers :-).
Comment | File | Size | Author |
---|---|---|---|
#46 | work.patch | 879 bytes | jpstrikesback |
#45 | work.patch | 876 bytes | jpstrikesback |
Comments
Comment #1
yched CreditAttribution: yched commentedForgot to add : #616240: Make Field UI screens extensible from contrib - part II wires everything needed to support nested grouping on the UI side.
This allows nested 'fieldgroups' in D7 (as long as the fieldgroup module or its successor does the right job at storing and handling the parenting info accordingly, of course)
Comment #2
BenK CreditAttribution: BenK commentedSubscribing...
Comment #3
giorgio79 CreditAttribution: giorgio79 commentedI would like to recommend this module, http://drupal.org/project/multicrud, as a grouping flavor as well :)
Works like magic.
Also, if possible, it would be great to add single field storage option also, instead of the default CCK storage, since it is not always efficient to have a separate table with row for each selection in the case of unlimited value storage. For example, recently I needed 100 checkboxes for a field, but my db table would have gotten very big very fast if each selection would have had a row as per the standard CCK storage mechanism. I built a CCK computed field, where selections were stored as comma separated values in the main content type table. Much faster for my needs, and I can save a db admin down the road.
Here it is:
http://drupal.org/node/782974
Comment #4
SeanBannister CreditAttribution: SeanBannister commentedsub
Comment #5
yched CreditAttribution: yched commented#3 is out of scope, fieldgroup module is only presentational.
Comment #6
thekevinday CreditAttribution: thekevinday commentedsubscribe
Comment #7
RoSk0subscribe
Comment #8
fagoUnfortunately I have not the time to take over this, but I do think fieldgroup in d7 should be improved to only touch the rendered array, but not the FAPI structure itself. That way modules don't have to support the original and the fieldgroup altered $form structure. This should be doable by using #pre_render for inserting the groups.
Comment #9
G.A. Vinogradov CreditAttribution: G.A. Vinogradov commentedFieldgroup is the one thing I miss in the Drupal 7, so I want to develop it.
Will start work on this project since monday, 12 July.
Comment #10
yched CreditAttribution: yched commentedFYI, just found out a core bug : #857124: Collapsible fieldsets and vertical tabs do not work without form_builder() (Form API)
Comment #11
Anonymous (not verified) CreditAttribution: Anonymous commentedI dont exactly understand the bug in #10 but I need fieldgroups in D7 so Im interested in working on it. GAV: have you started to working on it?
I have a question: I was wondering if the fieldgroup could be programmed as a #post_render function that will see what fields are in a group and arrange them into fieldset "group" and add ahah functionality to add new sets of fields when set to multiple values? Or the logic has to go deeper?
Comment #12
Einkahumor CreditAttribution: Einkahumor commentedSubscribe. One feature request if that's possible here: I would love to be able to place a fieldgroup inside another fieldgroup (for example to place a collapsed fieldset inside a vertical tab on node forms). Also to be able to freely put the title and body fields (and any other field) inside fieldgroups. I guess that's two feature requests.
Comment #13
yched CreditAttribution: yched commentedNested groups is an obvious requisite for this D7 version, supporting Vertical Tabs kind implies it. The core UI work happening in #616240: Make Field UI screens extensible from contrib - part II has everything needed to support it from a UI point of view.
Supporting non-fields : yes, see the OP (paragrpah starting with "D7's vertical tabs have a way of reorganizing the output..."). And yes, that relies on reshuffling the render array at #pre_render time rather than at alter() time.
Comment #14
Anonymous (not verified) CreditAttribution: Anonymous commentedIve started to work on d7 version but Im not that skilled with ahah and javascript that Drupal uses to add new fields, validate them etc, so Ill just make a new field type that I need with multiple fields and use it instead of more flexible multigroup solution. Good luck GAV.
Comment #15
Kipp Elliott Watson CreditAttribution: Kipp Elliott Watson commentedSubscribe
Comment #17
mcreature CreditAttribution: mcreature commentedSubscibing
Comment #18
swentel CreditAttribution: swentel commentedSubscribing - I want to start a port of DS (Display Suite) in the next couple of days and with the patches which are already in, it could mean that we can use the CCK screens instead of implementing our own - which we really had to, D6 was a nightmare to extend those screens. I'm pretty hopefull especially in combination with Field API which is way mature now :)
The clue for me is to see if I can get fieldgroups so we can create our 'regions' system again which we have in Display Suite - if that works, the DS module for D7 should become so small and possibly also the only module we should maintain for the complete DS ecosphere of modules. So potentially exciting stuff for us maintainers. I'll start working on a fieldgroup module separatly, we'll see what code comes up :)
Comment #19
yched CreditAttribution: yched commented@all - The ongoing work on #616240: Make Field UI screens extensible from contrib - part II required me to implement the beginnings of a D7 fieldgroup module, just to make sure that the core patch has everything needed to support fieldgroup UI needs. This initial code takes care of the UI part (inserting fieldgroup rows to the 'Manage display' screens), and is mostly stub code for the rest (CRUD API, display of groups...).
I will post this here when I have a companion core patch ready to post in #616240: Make Field UI screens extensible from contrib - part II.
@swentel : sweet that you should post that :-).
Part of the work in #616240: Make Field UI screens extensible from contrib - part II is precisely to support regions, since with D7's d-n-d reordering on 'Manage display' screens, we now have a 'Hidden' region. While doing so, I'm trying to make it generic enough so that it supports any number of regions, precisely so that DS can plug into the existing screens.
It seems the main difficulty is to determine which form element determines the 'region' (in existing core rows for fields, region is 'hidden' if the value of the 'format type' select dropdown is 'hidden'). Needs to live on both the PHP side (displaying the table correctly) and the JS side (updating the form when a row is dragged to a new region).
I'll report back soon. Meanwhile, it would be great if someone explored a way to display fieldgroups in forms while keeping the $form structure unaltered until render / pre_render phase - like D7 vertical tabs currently do. That would open the way to have fieldsgroups act on any node component instead of only CCK fields in D6 - see the item that starts with "D7's vertical tabs have a way ..." in the OP.
Comment #20
swentel CreditAttribution: swentel commented@yched
'Meanwhile, it would be great if someone explored a way to display fieldgroups in forms while keeping the $form structure unaltered until render / pre_render phase'
Send me that beginning code and I'll have a look - and I can compore with my beginnings :)
Comment #21
yched CreditAttribution: yched commentedOK, posted my code in http://github.com/yched/field_group.
You'll need the core patch in #616240-46: Make Field UI screens extensible from contrib - part II.
For now I followed the D7 trend of not munging words in module names (nodereference D6 => node_reference D7, userreference D6 => user_reference D7, fieldgroup D6 => field_group D7). Not completely sure about that, though, because this complicates/forbids an upgrade path.
Comment #22
sun.crud.inc should use proper _load/_save/etc function names, regardless of whether it stores in db or not.
Renaming of modules should be fine, as long as old names no longer exist, also doesn't forbid an upgrade path. Re: *_reference, I wonder why those aren't simplified and merged into a single "reference field" module.
Comment #23
yched CreditAttribution: yched commentedCRUD API : sure, the current is only a draft, I did nit even intended to make it public that early. Note, though, that as far as the rest of the module is concerned, the one and only useful function is field_group_get_groups(), which is fairly faithful to what it should be in the future.
Re: "*_reference, I wonder why those aren't simplified and merged into a single "reference field" module."
Packaging them into a separate 'reference fields' module is one thing. Actually merging them, i.e being able to abstract out reusable code parts is another job, it just needs someone to sit down in front of the code and dig :-).
Whole different topic though - see #533222: node and user reference fields in D7 - maintainer needed (mainly the 1st posts, and #43 for my latest position to date)
Comment #24
swentel CreditAttribution: swentel commentedI forked the code into http://github.com/swentel/field_group
It has basic storage and CRUD, still needs a lot of work, but it's a start - more commits at the end of the day.
You need the patch in #21 to make the manage display screen work, but it breaks the manage fields screen completely.
Comment #25
swentel CreditAttribution: swentel commentedQuick update - the code in #21 is working: you can add groups on form & display for every entity - you can also see fieldsets when looking at a node.
Again, lots of stuff todo still and I'm not happy myself about the recursive function right now, although it does the trick nicely.
Let's get this further on, fork away people! :)
Comment #26
rfaysubscribe
Comment #27
ordually CreditAttribution: ordually commentedsubscribing
Comment #28
giorgio79 CreditAttribution: giorgio79 commentedyched could we consider, in addition to the standard cck method, an alternative storage for this module whereby the group is stored in a single db field, serialized? This would save some mysql processing required if no search or views is needed on those columns. I have in mind something like this : http://drupal.org/project/tablefield
Comment #29
yched CreditAttribution: yched commentedre #28: AFAIK, this is what http://drupal.org/project/flexifield does.
Completely out of scope for fieldgroup module, though. This is only presentational stuff, and doesn't have anything to do with storage.
Comment #30
egifford CreditAttribution: egifford commentedSubscribing.
Comment #31
kukle CreditAttribution: kukle commentedsubscribing
Comment #32
kreynen CreditAttribution: kreynen commentedsubscribing
Comment #33
yched CreditAttribution: yched commentedUpdated http://github.com/yched/field_group for the latest patch on #616240: Make Field UI screens extensible from contrib - part II.
Comment #34
manimejia CreditAttribution: manimejia commentedlistening and able to volunteer.
Comment #35
JeremyFrench CreditAttribution: JeremyFrench commentedSubscribing. And off to github.
Comment #36
KarenS CreditAttribution: KarenS commentedI wanted to try out the current state of this issue. I have a fresh installation with the latest D7 code, including the committed core patch referred to in #33. I then added first yched's and then swentel's field_group modules. In neither case does any option to add a fieldgroup show up on the manage fields screen.
There must be some other patch or configuration step I am missing. I've dug around in the code but can't find it.
Comment #37
KarenS CreditAttribution: KarenS commentedOK, found the problem. There is still a 'fieldgroup' module in CCK. Do not make the mistake of enabling that one instead of the substitute. We should either take that out of cvs or get one of these replacements into cvs to avoid confusion. Since that code is not correct, I guess it would be best to remove it from CCK. I'll try to get that done, in the meantime, anyone who tries this out should be warned to remove it (or at least don't accidentally enable it).
Comment #38
KarenS CreditAttribution: KarenS commentedUsing the latest version of yched's fieldgroup module I get the option to add a fieldgroup on the screen but cannot save it. Ditto with swentel's version.
I have no more time to dig into this now, is there work going on anywhere else that I'm missing?
Comment #39
sunI think it would be a good idea to move the current git repo's content into CVS, entirely replacing the current fieldgroup module. Middle-term, we might want to consider to separate it back out into http://drupal.org/project/fieldgroup, but short-term everyone is going to expect it in the CCK package, so that will be the best place to make it work first.
Comment #40
KarenS CreditAttribution: KarenS commentedI agree, plus this way we can file issues against it here to track the progress. I assume yched's module is the one to use, but just checking in case swentel thinks his version might be preferable for some reason.
Comment #41
swentel CreditAttribution: swentel commentedYched's version is more up to date, so you need to use that one.
Comment #42
KarenS CreditAttribution: KarenS commentedOK, old fieldgroup removed, new one added to cvs.
Comment #43
LoMo CreditAttribution: LoMo commentedSubscribe
Lots of activity on this today. That's good to see since we'd like to have this ready to go, too. :-)
Comment #44
jpstrikesback CreditAttribution: jpstrikesback commentedsubscribe
Comment #45
jpstrikesback CreditAttribution: jpstrikesback commentedThis makes it able to save/list for me.
Just needed the #required attribute set in each ['parent_wrapper']['parent']... to me it seems that if it doesn't indicate it's #required the default should be set as FALSE...is this really a Form API issue?
Comment #46
jpstrikesback CreditAttribution: jpstrikesback commentedoops, tab removed...
Comment #47
jpstrikesback CreditAttribution: jpstrikesback commentedComment #48
michaek CreditAttribution: michaek commentedI'm not having any luck testing this, even with the patch from #46. I've tried using @yched's github as the starting point (not sure where in CVS @KarenS's commit lives) in an otherwise fresh Drupal install, but I get strange behavior adding field groups.
My Drupal version is 7.0-beta1, but I have also tested with HEAD.
First error:
I create a field group. Then, every page view following a page view of the field manage ui (admin/structure/types/manage/page/fields) this error is displayed:
Second error:
Rearrange anything on the field manage ui, then save. The request to save times out, as does any attempt to view the field manage ui.
For reference, here's my Drush make lines for setting up the module:
Comment #49
michaek CreditAttribution: michaek commentedGot the version from CVS, just in case, same issues.
Comment #50
michaek CreditAttribution: michaek commentedDoes this still require any core patching? I thought the patch @yched's github refers to was already in HEAD (and beta-1?). #616240: Make Field UI screens extensible from contrib - part II
Comment #51
yched CreditAttribution: yched commentedI had no time to look back at this recently, but yes :
- the prerequisite core patch has been included in D7 beta1
- Karen took the github code and committed in the HEAD branch of the CCK module
Comment #52
KarenS CreditAttribution: KarenS commentedIf you used that drush make file you put the code from git into modules/field_group and then you pulled down cck head which has the module in modules/cck/modules/field_group, which would give you two copies of the file. So start by making sure you actually have the code from cck HEAD, the only code you need. Do not add the code from github to the mix.
Comment #53
yched CreditAttribution: yched commentedI prefer not to completely wipe the github code for now, but I added a warning on the repo description stating that the code now lives in CCK HEAD.
Comment #54
michaek CreditAttribution: michaek commentedI did wipe the github from my codebase and start over with the CVS code. I didn't check to see if the code is identical or not, but I'm getting the same error. Wouldn't be much use as an update to the bug report if I hadn't removed the github code first. :)
Comment #55
michaek CreditAttribution: michaek commentedIt appears that part of the error I'm seeing is that a new field group erroneously gets all fields (including the "new field" fields) assigned to it as children. I don't have my head wrapped around this code (at all) yet, but the timeout and the children issue suggest it might be an infinite loop or recursion. I'll keep looking at it...
Comment #56
Stalski CreditAttribution: Stalski commentedsubscribe
Comment #57
Stalski CreditAttribution: Stalski commentedIs there anyone here who can give me a roadmap or some starting point?
Comment #58
michaek CreditAttribution: michaek commentedI didn't mean when I said "I'll keep looking at it" that people with more experience with the code should just leave me to assess this issue. :) If no one can duplicate it, then I'll assume I'm doing something obviously wrong, but I don't have any reason to suspect that yet.
Unfortunately, the thin response from other developers on this issue (no judgement - I know everyone is busy) makes it seem like I'd be on my own, at least in the short term, in getting this module ready for use, and I just can't take that chance, currently. The project that I'm starting was balanced on a knife's edge between Drupal and a simpler but more easily customized application framework. I've got to be working on building this thing, starting now, so I'm going to be stepping out of this issue, except as a free-time pursuit.
Comment #59
Stalski CreditAttribution: Stalski commented@michaek : i had the error as well and the fix is simple. I 'll provide a patch shortly with updates on this.
at line 162 or so , make sure you have the following:
If this is not set this way, the group name get their own parent name since there is only one option. and that's food for endless loops ;)
Comment #60
Stalski CreditAttribution: Stalski commentedIn general: i am more working on a way to have fieldgroup formatters in much the same way as field do. As swentel says in the .module file comments, it's very ironic, almost sarcastic that it would just work out of the box when fieldgroups are fields.
In my opinion, i once built a OOP form generator, and the field as we know it was just a leaf in a tree of field components. So if you see it that way, then the only thing that would have to change is that a field is an instance of a FieldComponent where a FieldGroup implements the FieldComponent as well as Iterator. An extra property children does the job.
Since a field and instance is still an array, we could look for a way to have the same pattern with functions. The main problem imho is the word "field", but i could live with the fact that a fieldgroup is a extension of a field.
That's said, i am still following the comments in the .module file and trying to work out a formatter thingy for every module to use and/or alter.
Comment #61
michaek CreditAttribution: michaek commentedThanks, @Stalski. I'll give the change in #59 a try!
Comment #62
yched CreditAttribution: yched commented@michaek :
the bug should be fixed in latest CCK HEAD - the core patch in #936536-7: Missing #empty_option on a couple selects is also required.
Note that the current state of the code is still largely a proof of concept, to make sure that core's Field UI was flexible enough to allow fieldgroup UI in contrib. Not much actually works, and I wouldn't encourage anyone to start developping an actual site on this yet..
Comment #63
drclaw CreditAttribution: drclaw commentedSubscribe
Comment #64
Stalski CreditAttribution: Stalski commentedJust a status update. Locally i have working now:
- configuration of field group formats
- 3 new hooks to define grouping formatters, create elements of a form and create corresponding summary.
- Added a div next to fieldset in the display form
- Changed the function to render fieldset, div, tabs ... to real theme function delegating from a field_group_render function.
The most difficult part was the row-rerender after selection. The configuration would not change so only form_state could help here. I must say it already rocks.
TODO:
- create simpletest for the new added features and introduced hooks.
@yched: do you want me to send a patch (i synced yesterday with the head since changes were made there) or upload it immediately here?
Comment #65
bonobo CreditAttribution: bonobo commentedIs it correct to assume that the Field Group module is the result of the work here?
http://drupal.org/project/field_group
Comment #66
yched CreditAttribution: yched commentedYes. I asked Stalski if he was willing to to take over field_group as a separate D7 module, and he very kindly accepted.
The field_group project at http://drupal.org/project/field_group now contains the previous code from CCK HEAD's modules/field_group, along with the work Stalki mentioned in #64.
I'm about to play with it, but the screenshots posted on the project page are simply gorgeous !
I removed the previous state of field_group from CCK HEAD (D6 fieldgroup still lies in CCK, of course), and updated the "D7 status" section on http://drupal.org/project/cck
Comment #67
Stalski CreditAttribution: Stalski commentedJup that's correct. There are still some key main features that need to be added and some newly added bugs worked out.
So there will be a development phase going on but it can easier be followed now on drupal.org.
Comment #68
yched CreditAttribution: yched commentedWhich means we can set this issue to rest :-).
Comment #69
KarenS CreditAttribution: KarenS commentedYay! Thanks so much Stalski, it looks great! And thanks yched for all your work on this :)