Anonymous users do not see updated versions of a webform when page caching is enabled

Ok. this is weird. I upgraded to the newest version of webform and the permissions problem went away. However, the imput filter thing is different from when I am logged in, to when I am not. So, when I'm logged in, the strong tags work and when I'm logged out, they don't.

Becky

Not sure if this will help you or not, but have you checked your Input Filter permissions for Full HTML? (they can be found under "admin/settings/filters")
Does the Anonymous Role have permission to use the Full HTML Input Filter?

Aww! Yes, that was it. After letting anonymous users have full html privileges it all worked out. Thanks! I would never have thought of that.

Becky

Granting anonymous users permission to use Full HTML is not a good solution because it is a huge security risk. See http://drupal.org/node/213156, http://drupal.org/node/224921, and http://heine.familiedeelstra.com/input-formats-beware for more information on why this will allow a site to be hacked. Giving Full HTML privileges to anonymous users is only OK in extremely rare instances (for example, a private intranet where the only people who have access to the site are all trusted...)

Also, it is interesting that doing this solved your problem, since it shouldn't have helped at all :) Granting anonymous users permission to use Full HTML means that you are allowing them to create content in this format. However, in your case, the content was created by an administrator (you) and saved to the database as Full HTML. Once that happens, anyone who views it should be able to see it as intended, regardless of their permission level. So it sounds to me like there is a bug here.

I looked through the relevant code in Webform and couldn't find an obvious bug, nor could I figure out how to reproduce the problem. Can you give more details on how to reproduce it - e.g., maybe you could post the specific HTML markup that's causing the problem?

@David
Agreed that Anonymous should not be granted Full HTML, it was merely a means of identifying Becky's problem.

@Becky
I've also tried to reproduce the issue using various clean installs / permissions changes and the works, but was unsuccessful, everything in this area seems to check out ok.
What other modules are you using on the site, anything that could possibly conflict with Webform?
Because stand-alone the issue can not seem to be duplicated.

Ok. What i did, with screenshots.

I created a webform with form components (text areas and html mark up and select lists.

I made the form and it looked fine except that when I logged out, the html markup form component called Legal, went away.

Under the webform permissions, I gave no special permissions to the anonymous users.
I thought it was a problem with my bu editor so I turned the editor off. Still nothing special.
I looked at the filter admin permission on the permission page and decided not to give those permissions to anyone.

I looked at my input settings for the html markup from and tried it at html filter with the p tag and strong tag being allowed - nothing. I changed it to html full and then it showed up, minus the strong tag and then I gave anonymous users permission to use html full inputs and I got the mark up form to show up bolded, the way I wanted.

{update}
I don't really understand why but I took away permissions for anonymous users to use full html and then logged out and viewed the page and it looks fine now..... hmmmm..

Becky

Thanks for the screenshots - that helped! I think I figured it out, and it is a page caching bug. I can reproduce the problem, but only when page caching is enabled on the site.

The bug is due to the fact that Drupal normally clears the page cache when a node is saved, to ensure that anonymous users will see the updated version of the node; however, a webform can get updated without the underlying webform node itself getting saved, so Drupal never clears the page cache, and anonymous users will still see the cached version. The reason the problem went away when you edited permissions is that Drupal also happens to clear the page cache when the permissions form is submitted (running cron would have done the trick too).

The attached patch should fix the bug. I'm actually thinking maybe I should have moved the cache_clear_all() functions further down into webform_component_insert() and webform_component_update() -- that would be more robust, although it would lead to more unnecessary cache clearing. Probably it is the right thing to do to move them down there, but anyway, for now the patch works...

Thanks a ton David on catching this one and figuring it out.
Much appreciated!

Awesome!

Thanks,

Becky

[Never mind! sorry! The issue is fixed now. It had nothing to do with the patch]

Hi, I'm not sure this patch worked.... I applied it and then later I changed a field and now the field won't show up at all... This field is again an html markup form component.

http://www.wimaxroaming.org/wricode/wri-code-application-form

Becky

@David, your comment

unnecessary cache clearing

sparked an idea.

Cache clearing should be an operating initiated by the user, or cron job.
I personally am not a big fan of Contrib Modules just cache clearing on the fly, not a very good idea for larger Production sites.

How about notifying the user that the changes may not show up until the cache is cleared, instead of doing it in the code?

I'm using version 2.7 and the issue i've found is this:

If you pick a default value for a field which is dynamic for anonymous users, like %server[REMOTE_ADDR] for instace, and you have page caching enabled, the default value of some (unlucky) user would get cached and displayed to all the others.

Is it possible to fix this in webform, without disabling the page cache?

Removing the ability to user %server, %profile, and %post variables was part of the security fix in 2.8. Unfortunately there is no way to use these variables with the page cache enabled, and so the ability to use them for anonymous users was removed in 2.8. Now they will just be cleared out entirely and not show up for anonymous users.

@quicksketch, comment #13 is not the same as the original issue. I just confirmed that the original issue still exists, and that the patch in #8 still fixes it.

Basically, to reproduce the bug, all you have to do is visit a webform as anonymous user (on a site with caching enabled) and thereby get it into the cache. Then, log in, edit the webform, go to "form components" and add a new one. Save that (but do not hit the submit button on the webform node as a whole). Log back out and viewing the webform again you will still see the old cached version.

Re #12, hm, I'm not sure about that... I think it's always correct behavior to clear the cache when the cache is known to be out of date. All we're doing here is the same thing that Drupal normally does when a node is saved the normal way.

Ah, sorry. Yes indeed a different issue than the patch you provided solves. I'll put this change in next time I'm reviewing Webform patches.

Generally speaking Webform is just following the behavior of all other nodes in Drupal. If the page cache is enabled, then there is a delay before the changes are shown. However considering the dynamic nature of Webform and needing to actually respond to POST requests based on that cached page, I see why it's important to make this exception for Webform nodes.

Generally speaking Webform is just following the behavior of all other nodes in Drupal. If the page cache is enabled, then there is a delay before the changes are shown.

Hm, there shouldn't be a delay for other nodes in Drupal. Whenever a node is saved the normal way, there is a cache_clear_all() call that automatically happens -- see http://api.drupal.org/api/function/node_save/6

In any case, thanks!

Ah, fair point! I must've been thinking about comments. Thanks again.

The same problems I had with my forms with dimamic fields, but I'm lucky to find out, that is the module:
http://drupal.org/project/cacheexclude
This module exclude from caching need nodes. I feel so good with it:))) enjoy!