Closed (won't fix)
Project:
Views (for Drupal 7)
Version:
7.x-3.x-dev
Component:
User interface
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
14 Sep 2011 at 06:32 UTC
Updated:
22 Nov 2011 at 07:56 UTC
Jump to comment: Most recent file
Comments
Comment #1
dave reidComment #2
dave reidActually now I think I know the reason why - the $form array when passed from views_ui_edit_display_form() to views_plugin_display::options_form() isn't actually the root form array, it's $form['options']. We should be giving access to the original $form array somehow. Maybe a third parameter of $complete_form
Comment #3
dawehnerAaaaaaaaah davereid is in the queue :) My mail inbox runs away... :)
Thanks for creating all this detailed issues!
All this forms have $form['buttons']['submit']/$form['buttons']['cancel'] etc.
As far as i remember if you have a custom submit handler on a sub-form-element only the sub submit handlers are executed.
Could this be a case here?
Comment #4
dawehnerWhy do you not use options_submit in your display extender?
Just wondering whether this would be the better way to actually do it.
Comment #5
tim.plunkettI'm not sure if this is the same issue, but neither row or style plugins seem to be getting their options at all.
Inside $form, their section is nested within 'options'. I couldn't track down why, but this fixes it.
I'm posting to this issue because I think they are related, but if I'm wrong I can open a new one.
Comment #6
dawehnerThanks! Commited to 7.x-3.x. This seems to be some leftovers from the UI update, but i really don't think that this was the issue mentioned above.
Comment #7
dawehnerI still think that you shouldn't set $form['#submit'] for yourself in the display extender but use options_submit, so let's mark this as won't fix.
Feel free to open if i'm wrong.