Problem/Motivation
Currently I have a use case in the Facet API module illustrated at http://drupal.org/node/593658#comment-5322096 where I need to alter the redirect of the ctools_export_ui::edit_form() form so it maintains the query string variables on redirect. Specifically, when I visit the edit form via a contextual link, a "destination" query string variable is passed so that form submissions redirect back to the page the site builder came from. Viewing the screenshot in the link above, I have an "Add item" button that should always redirect back to the edit form but maintain the "destination" variable so when the user is done adding items and clicks "Save", they are redirected back to the page they came from as expected. However I cannot add query string variables to the redirect since CTools only allows $this->plugin['redirect'][*] to be a string which is passed as the first argument to drupal_goto(). This is unlike core $form_state['redirect'] where it can also be passed as an array that is translated the into arguments passed to drupal_goto().
Proposed resolution
By modifying the logic to make $this->plugin['redirect'][*] behave more like the $form_state['redirect'], developers can either set $this->plugin['redirect'][*] to a string (as the module currently works) or an array to have the added flexibility of being able to pass additional options to drupal_goto().
API changes
The proposed change wouldn't effect the current API since we are simply modifying the $this->plugin['redirect'][*] variables to accept an array in addition to a string.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | ctools-1373048-7.patch | 3.11 KB | cpliakas |
| #4 | ctools-1373048-4.patch | 2.95 KB | cpliakas |
| #1 | ctools-1373048-1.patch | 2.42 KB | cpliakas |
Comments
Comment #1
cpliakas commentedThe attached patch makes the proposed change.
The current_search_export_ui::edit_execute_form() is a working example of how the change could be utilized to meet the use case illustrated in #1.
Comment #2
merlinofchaos commentedWhen we have the same code 4 times, and it's now 3 lines of code, this is a clear sign that we should abstract.
Something like this would work as an export ui class method: (this is just off the top of my head, no testing or verifying):
This also incidentally makes the variable name more meaningful.
Comment #3
cpliakas commentedThis approach makes perfect sense to me. I will re-roll a patch with the proposed change.
Thanks for the review,
Chris
Comment #4
cpliakas commentedThe attached patch makes the requested changes. I tested against my customization in the Facet API module and it works as expected. I also removed the customization to test backwards compatibility and that works as well.
The only use case I could find for not passing the
$itemparameter is the "delete" operation, however looking at the defaults set in the ctools_export_ui_process() function, the "delete" operation is not set as a default so cannot be used with the newctools_export_ui::redirect()method added in this patch. I can work on it if you feel it would be useful, I just didn't want to introduce too much at one time.Comment #5
merlinofchaos commentedMaybe if $op is not set in the plugin, the redirect should fall back to the base path; it doesn't feel right for the redirect to not actually perform a goto and fail silently if somehow the op is not set.
Comment #6
cpliakas commentedMakes sense. Will roll another patch.
Comment #7
cpliakas commentedThe attached patch adds the change suggested in #5.
Comment #8
merlinofchaos commentedCommitted and pushed! Thanks!
Comment #9
cpliakas commentedExcellent! This will remove about 40 lines of code in my module, so I appreciate your attention to this :-).
~Chris
Comment #10
emattias commentedCould someone explain/show example code of how this should work?
I tried adding this in panels_mini.inc (a export_ui plugin in panels core):
Unfortunately my specified redirect get's overridden with this code in ctools/includes/export_ui.inc:
Either the code above should only append to $plugin['redirect'] or I have completely missuderstood how this should be implemented..
I got it working by changing the code above with this:
I wasn't sure if I had missunderstood this completely so I didn't do a patch. I'll do it if you want me to.
Comment #11
emattias commentedI was trying to solve this issue: #934738: Don't redirect on update and save for mini panels
What I would like to do is basically say don't redirect at all. From what I can see there is no way to do that? You either specify a location to redirect to or it will redirect to the plugins base path, there is no way to only display the form again. Which is what I want.
Comment #12
cpliakas commentedSeems like this is a separate issue that the goal of this thread and the patch that was committed. Might be worth opening up a separate issue so that we can follow single ideas more easily and discuss the issue you brought up.
Comment #13
emattias commentedYeah, but first I'd like to be sure that I've implemented this new feature correctly. Could someone please explain or point to an example of how/where you specify the redirect path.
Comment #14
cpliakas commentedHere's a quick example. Whether this is the correct place for redirects is irrelevant, I just forked if from Facet API where I did the redirect in this method because I had some complex logic that required it being here.
I guess you could also set the redirect to an array in the plugin definition as well, i.e.
$plugin['redirect']['edit'] = array($path, $options).Hope this helps,
Chris