The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.This patch adds a new option for "afterSubmit" to hook_popups(). The "afterSubmit" option makes it possible to call a JavaScript function after successful submission of a form through a popup. We're using popups to dynamically update multiple parts of the page at once, so the existing targetSelectors option is not enough. Adding a custom callback allows us to make any changes we desire with the returned data manually, rather than depending on popups to simply inject the new content into the page for us.
If desired, the afterSubmit callback can return the value "false", and skip all remaining processing normally done by popups.
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | popups_after_submit.patch | 3.09 KB | sirkitree |
| #13 | popups_after_submit.patch | 3.1 KB | sirkitree |
| #11 | popups_after_submit.patch | 2.92 KB | quicksketch |
| #9 | popups_after_submit_function.patch | 786 bytes | quicksketch |
| #7 | popups_after_submit.patch | 2.85 KB | quicksketch |
Comments
Comment #1
starbow commentedI like it.
I am curious where the targetSelectors option falls short. You know it accepts a hash as input right?
Comment #2
quicksketchHmm, I realized this patch isn't even going to be much help to me. In a previous version of popups.js, the DOM object for the link that was clicked was passed into the Drupal.popups.formSuccess() function as a third parameter "a". Without it, this patch doesn't add a lot of value.
The scenario we had was configuring blocks on the page, inline. A "configure" link was added to every block on the page using a single selector "a.block-edit". The problem was after the block had been reconfigured, we needed to update that block with the new contents of the block. We used the "a" parameter to identify which link had been clicked on and therefor which block had just been edited. We'd find the parent DIV containing the block and update it with the new contents of the block.
So I'm moving this to code needs work, since you're right, it doesn't do anything new without knowing contextual information about what was actually clicked.
Comment #3
quicksketchComment #4
quicksketchHere we are, this re-instates the "a" parameter that was removed several revisions of popups ago. My guess is that popups.js never needed the "a" parameter, so it was just taken out to clean things up a bit. However, in our case it'd be very helpful to have that information when running a custom afterSubmit function.
Comment #5
quicksketchThat last patch had a small bit of unnecessary cruft. Here we are again.
Comment #6
starbow commentedHmm, ok, I get how this is useful if you have context. You can't name the variable 'a' though. One of nedjo's patches made it possible to trigger popups on any type of element. So the obvious variable name is 'element', but you will have to make sure that 'element' isn't already being used in one of those function.
Comment #7
quicksketchSeems like "element" was free in all contexts, here's a reroll.
Comment #8
starbow commentedIt passes my hairy eyeball test, but I still try it out.
Can you reroll against D6-dev when it becomes available?
Comment #9
quicksketchHere's a reroll against the latest CVS.
Comment #10
starbow commentedThat looks like a reroll of the original patch, not the improved one from #7.
Comment #11
quicksketchI'm a dunce. I uploaded the wrong file. :P
Comment #12
starbow commentedOk, I am branching to 6--2 for this patch and #336641: Auto-load needed JS and CSS files (and settings). The 6--1 is now closed to new features and will be just for bug fixes. Of course, I added a bunch of new comments and code cleanups before branching, and now this doesn't apply any more. Sorry.
Also, in Drupal.popups.formSuccess
Drupal.popups.openContent(data.title, data.messages + data.content, options);
should probably be
Drupal.popups.openContent(data.title, data.messages + data.content, options, element);
Comment #13
sirkitree commentedHey guys! I found I need this function pretty badly unless I wanna keep using popups-form-reload, in which case my status messages aren't retained. So here's the patch rolled against the latest 6.x-2.x-dev
I just manually read Nate's patch and also took into account your suggestion in #12 Tao.
Comment #14
sirkitree commentedLooks like I did something wrong here... #popups element is being duplicated with this patch... hrm
Comment #15
sirkitree commentedalso, this is not available when trying to use on-popups-options and should be documented as such.
Comment #16
sirkitree commentedI see what went wrong here, there was a line you had commented out that I uncommented. This was causing the dup. Here's a revised patch that so far seems to be working correctly for me.
Comment #17
starbow commentedOk, I still haven't really wrapped my brain around the js/css loading stuff over in 2.x-dev, so I have wrapped this patch into the upcoming 1.2. It fits in with the lifecycle event triggers I am playing around with (which, might be a better way to get the same effect, but I don't have any afterSubmit callbacks to test, so I am not sure).
Comment #19
kristen polIs there an example of how to use this? If you have an after submit function that returns false, will the normal redirection occur for the popup... for example, if if the popup is the login form and you are on some random page, will it redirect you to the page the login form normally redirects you to?
I'm trying to figure out how to get a popup to redirect to where it normally goes and am hoping this will help. There was information here: http://drupal.org/node/455894 about hijackDestination yet I'm not seeing that in the code anymore.
Kristen