Posted by SirClickALot on January 17, 2010 at 2:50pm
14 followers
| Project: | Modal Frame CCK Editor |
| Version: | 6.x-1.x-dev |
| Component: | Miscellaneous |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
OK, this looks great - I've set it all up as prescribed, tagging just one of my CCK Fieldgroups as 'Enabled, and refresh the target element after a successful edit operation'
BUT, when I click the little pencil edit icon, the model window contains an edit form for the whole node and not just that fieldgroup.
Am I missing the point somewhere along the line?
Comments
#1
hmm... I have been committing code to CVS, so it may depend on if you have the latest...
Also, please make sure you have installed the latest version of Modal Frame API.
In any case, it works ok here. So I may need more information. Not sure what, but it's hard to tell when you cannot reproduce the issue...
#2
OK Mark, tell me what you do need and I'll furnish you with the goods right now because I think this module holds greate promise for what I'm trying to do and I'm sure others will come across this problem before long. What I can tell you now is...
1) I'm using a modified node.tlp not that that should make any real difference.
2) Modal Frame 6.x-1.6 and Modal Frame CCK Editor 6.x-1.x-dev
My configuration of the fieldgroup and the display settings are shwon in the attached PNGs.
Finally (and this is particuarly key point I think) I actually don't want the fields and labels to show on the node view so I would normally hide them in the Display settings. However I had to 'show' them when trialling this module because if I didn't, the 'pencil' icon wouldn't show. I think this will be a very common use case to want to hide the whole fieldgroup because one of the great facilities offered by you module is that developers can hide away lengthy, complex and possibly seldom altered field revealing them only on a click. BUT, since the pencil only shows if the fields are on show, it rather defeats the object.
#3
Whoop sorry, the PNGs!
#4
Re: "Modal Frame CCK Editor 6.x-1.x-dev"
hmm... I have committed stuff today, so you may need to check out from CVS, or wait until the next development snapshot is built.
It seems there are 2 different issues here:
This may depend on the theme layer. Does it generate the proper CSS classes, so that we can find the target elements with our jQuery selectors?
Also, if the theme varies a lot, you may need to style the edit button in your theme. Look at the file js/parent.js for Drupal.theme stuff. The module uses standard Drupal methods to allow external modules theme certain stuff, and I'm sure this is documented somewhere in the Drupal handbooks.
If not... things to check:
1) is the URL to edit the node in the modal frame being altered by something else?
2) is the structure of the node form being altered in a way that is not compatible with our changes?
Well, this is something that needs to be debugged on site.
#5
Can we see the edit icon in node view?
Absolutely, my theming is pretty good I think and the answer is a definite YES, we can see it loud and clear and the URL attached to it is...
[my local host]/node/381/edit?modalframe_cck_editor=group_area_inclusionsSeems that your JQuery is targeting the fieldgroup ‘group_area_inclusions’ perfectly well.
The potential problem as I said earlier is that in order to see the pencil, the actual fieldgroup itself has to be on show - might it be a neat idea to use your JQuery to append a DIV ‘after’ the fieldgroup which contains the 'modalframe-cck-editor-button-edit' anchor instead of having that link actually 'inside' the fieldgroup itself?
Do we get the correct node edit form in the Modal Frame?
Yes I think we do a, it is just that it seems to bring up the whole edit form rather than rebuilding the form.
Even when I remove all my custom node.tpl and page.tpl files from the Theme and Flush all caches, the behaviour is still the same.
As you may notice, I am currently developing this site offline on my laptop but I’d be happy to put it up somewhere so that you can get to it and have a poke around if you wish?
#6
Re: "might it be a neat idea to use your JQuery to append a DIV ‘after’ the fieldgroup which contains the 'modalframe-cck-editor-button-edit' anchor instead of having that link actually 'inside' the fieldgroup itself?"
Whatever we add, should be within the fieldset the field group belongs. So if you want to see the edit button, you need to render at least one field in the field group. The fact that the field group label is not visible should not affect this.
If you're altering the output of the field group fieldset, then you may need to tweak also the javascript code of this module.
Re: "it seems to bring up the whole edit form rather than rebuilding the form"
Well, we are not rebuilding the form here. We're just altering it using hook_form_alter(). Our module needs to execute between CCK and the fieldgroup module, which is something that we control when the module is enabled, in our hook_enable() implementation, by altering the weight column of the {system} table. Otherwise, our hook_form_alter() won't see the fields added by CCK to the form, or it won't see them on the top level of the form, if the fieldgroup module has already altered the form structure.
AFAICT, there should be no other conflicts here with other modules. I do not have the time to debug your site, so you may need to do it yourself. Try to follow the what happens when our hook_form_alter() executes... how does it find the form? Note that our code here may bypass the form processing if certain conditions are not found as expected. Look at includes/node_form.inc
Still... note that I have committed more changes to CVS, so if you're testing with the -dev packages, you do not have the latest.
#7
Have you had the chance to test with the latest -dev snapshot (it should be up to date in regards to our previous comments).
For the record, we have tested the module with different content types, on different sites, and it seems to work like a charm in all cases. So, if it does not work for you, it could be caused by another module that breaks our hook_form_alter() processing in some way... this is something that could be tested adding a few prints here and there to see if our code is being executed, and if it flows as expected, or why it does not.
#8
Unable to reproduce, and since there were changes committed to CVS, I'm assuming the problem here is fixed.
#9
I can confirm that this problem still exists. I have tried both stable and DEV releases. This opens the entire node form, with the exception of other fieldgroups I have selected to open in modal.
#10
Ok, so I need a step by step method to reproduce the issue. It just works here, and on other sites where this module has been implemented. What's different in your sites that it does not work?
This may also need debugging on site. I mean, you may need to edit the code and add prints and/or vardumps here and there to follow the flow of execution of the form building process.
#11
It looks like a bug for me. I can reproduce the same in my local installation. Node body always appears in modal edit form. I will provide more input when i get time.
#12
I'm still seeing the same problem (#1) - the module always (in my case) loads up the complete node into the pop up window.
#13
I'm running into a similar issue. The body_field, notifications field_group, and notifications field_group are showing up in the node form in the modal window.
I ran into a similar issue when working on another module that tweaks the location fields on the node form. It's likely that there are modules using hook_form_alter and adding these groups, and updating the body_field after the modal_frame hook_form_alter call.
@markus_petrux : how do you feel about utilizing the hook_late_form_alter module and it's corresponding hook to modify the form? I think the other alternative would be to set a #after_build callback on the form, and then strip the unwanted fields and field groups there.
Hope these ideas help.... I will try to supply a patch using hook_late_form_alter against the 6.x-1.0 codebase.
#14
Ok,
I also found that the body_field element was not getting caught by the logic in modalframe_cck_editor_node_edit_form_alter() . Is this because of the updated teaser??
Anyway, I added a special condition to handle the body_field.
I also updated it to use hook_late_form_alter which got rid of the extraneous fields for me.
Note that this adds a dependency for the Late Form Alter module: http://drupal.org/project/late_form_alter
Patch is attached
#15
I do not like the idea to rely on a separate module such as late_form_alter. If we need this, then we can use an after_build callback. Note that in both cases, the fieldgroup module has already altered the form, so the fields are not in their original positions. This makes things more complex for our module, but an after_build callback is Drupal core, so we do not need a separate module.
We could add a special condition for the body field, but then there may be more incompatibilities with other modules out there, so maybe the best approach would be to try with an after_build callback.
#16
Sorry for not getting back on this previously. I did do an update using #after_build rather than late_form_alter. But, I realized there was a third, much more simple, option to solve this that I had overlooked. The core of the problem is that hook_form_alter runs in the middle of the pack somewhere among all the other hook_form_alter implementations. The simple solution is to raise modalframe_cck_editor's weight in the system table sufficiently that it runs last. I'm dropping my patches above for that solution.
If anyone is curious, here is the SQL I used to change the weight of the module:
update system set weight = 1000 where name = 'modalframe_cck_editor'
Note that 1000 is just an arbitrary weight I selected that is greater than all of the existing modules on my system. YMMV.
There is still the problem that the node body winds up in the modalframe_editor form. I'll submit an updated patch with only that part included.
Has there been any work to include the node body as an editable field? I'm hoping to tackle that myself soon, but I don't want to redo the work if some else has already done it.
#17
Here is the updated patch. This only has the code to remove the body field from the modalframe_cck_edit form.
#18
Moved to needs review
#19
Please, provide the patch in a simple text file.
http://drupal.org/patch/submit
http://drupal.org/patch/create
#20
I'm buried in another project right now, but I'm come back to this and resubmit a patch in the correct format.
#21
I'm seeing the same problem plus a nodereference field using hs_nodereference is also loading. I'll try to look more later, but just reporting for now.
This set of modules is great. Thanks for your work.
#22
Here is the patch - I have not changed the code - just extracted the patch to the proper format. It seems to apply, but I have not tested it further.
#23
I can confirm that the patch in #22 works to remove the body field.
#24
same problem exists also with filefield fields with patch applied, patch is ugly btw :)
Anyways, filefield is affected same way. If I add same IF() as in patch and change body_field to field_profile_photo modal frame would consist of everything (title, save button) EXCEPT my field, but then again, Im not good at writing code, I barely can read it...
#25
#22 fixes the problem for me.
#26
I'm still seeing leftover form items from notifications.module and og.module...
#27
similar problem - og and taxonomy fields appear.
#28
subscribing
#29
subscribing
#30
Ok, so I get the module weights issue as it relates to "hook_form_alter."
Secondly, the weight of "fieldgroup" must be higher than this module, or the frame won't render the field.
((The latter part might be an anomaly in my case since I'm using "multigroup")).
#31
Based on #26, #27, It looks like this needs a more generic solution than #22.
#32
Yeah, people are just going to have issues with random fields popping up in the modal that they don't expect. Hierarchical select boxes are another funny one. Messing with the weights works most of the time, but it's a bit of a confusing process.
The issue with multigroup ended up being based on the below issue. Messing w/ weights in this case was just a hackish solution.
http://drupal.org/node/999506