No Webform confirmation message after redirection with Boost installed

What's your redirect URL? If you're being redirected to an external site, the message can't be shown since you're no longer within Drupal. It may also be a caching problem. Could you try turning off the page cache at admin/settings/performance? Finally, what's adding that "nocache" option to your request? Do you have some caching module like Boost installed?

Could you turn off Boost and see if the problem goes away? I'm unable to reproduce the problem on a fresh install of Drupal. Boost is likely interfering with the request and not showing the messages.

nocache=1 means to skip the boost cache so the message will be displayed... how easy is this to repo?

Moving to the Boost queue, since you should be able to configure Boost to not interfere with the normal operation of the site.

I've got this issue too, in a related form submission: if somebody registers with admin approval, he is redirected to the frontpage and there should be a message there like "Your registration awaits approval etc."

- The user is redirected to frontpage and the url shows nocache=1 but still no messages.
- However, when I look in the source of this page, it doesn't have the "cached by boost" footer.
- I'm using Drupal pressflow 6.19, boost 1.18 and "do not cache is messages on screen" is checked.
- When I disable boost, the messages appear.

Can this be related to Pressflow (as it doesn't use sessions for anonymous users)?
Any best way to help debugging?

(PS: as a workaround I used the Logintoboggan module to redirect the user to a specific page with the message)

If drupal_set_message is set then a session should be created if your using pressflow. For pressflow I know that if the user has a session then it turns off page caching till the session is destroyed.

Way to debug is to make sure the sess* cookie is getting set. If not, then there needs to be some more digging around as to why a session is not getting set when a message is queued to be sent out.

It probably is some Pressflow + Boost interaction bug then. I'm having a similar problem with messages not being displayed for anonymous signups with the Signup module. Even with the page caching and Boost static caching disabled, messages won't show. Disabling the Boost module or replacing Pressflow with stock Drupal fixes the problem.

This bug still exists in 7.x. I've a webform block on several nodes which redirects to the node page itself. Error messages are shown, but no success messages.

@Tekl Is this an issue with Boost? If you don't experience it without Boost, then it's still a support request from the Webform side. If it doesn't involve boost, this is the wrong issue to be reporting the problem. I don't support Boost because I'll always use real caching software (like Varnish or nginx) rather than Drupal-based work-arounds.

Oh, er, sorry I thought this was in the Webform queue. Didn't mean to butt in on the Boost queue. :(

I'll move this back to bug, but I think it's likely an issue of how these two modules interact with each other more than a bug in either one. If you redirect from Webform to a Boost-created static page, of course it's not going to show a status message because you're looking at a flat HTML file.

Looks like I need to get the session message detection code up and running. It's something that's been talked over a lot for ubercart-boost issues.

Hi Mikey,

So what's the status on this? I'm having the same issue with the others here. Thx.

Subscribe, I am having the same issue, at a loss how to fix this. I was not having this issue before boost was installed.

See if one of the patches in #1242416: Avoid caching Drupal messages fixes the issue here

Same here, on Drupal6.

Confirmed.

Noticed that drupal_goto() calls drupal_session_commit() -- at least in my version.

A bit of time in the debugger tells me that this is probably where the messages are getting stored for the next page load.

However, boost_exit() bypasses the session commit because it exits instead of returning to drupal_goto().

Adding drupal_session_commit() just above the exit calls in boost_exit() appears to fix the problem. Confirmed via debugger that session data is there on next page load.

D6 patch attached.

Changing to "needs review" in hopes that the D6 patch either will also apply to D7 or can be reviewed itself.

#20 is working for me
Thank you!!!