Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.After debugging a couple of "why this does not validate"-kind of issues in webform I'd be happy to see a notice for a webform owner / users with a certain role(s) if
* additional validation or
* additional processing
will not get properly evaluated. Like if there is a typo in code (missing a ";" or something like that), webform owner would get a notice about it while testing. And maybe there could be a "contstructing" - kind of checkbox to enable/disable this feature to lighten executing a production webform. Maybe one could use "published" -checkbox instead of it? Like unpublished webforms would be checked and after publishing webform this evaluation / code checking would not be done.
(There is a comment about this in documentation.)
Comments
Comment #1
cdale commentedThis would actually be a lot harder than it first appears, as to test the validation when the node is saved, you would actually need to populate a 'submission' entry for the validation to work and the very nature of "custom" validation on a webform submission makes it pretty much impossible to generate random content to test that validation, as the system would not know what kind of content to create. Not only that, but you would actually most likely need to build the entire form, and most of form_state to cover all the cases and possibilities that custom validation might do.
Parse errors could potentially be searched for, but it may end up with a situation where the custom code can't be saved because of the way eval might return when the code receives input it does not expect, not resulting a parse error, but still triggering an error non the less.
Trying to accommodate all this seems like a lot of work for something webform really has no control over. If you're using custom validation, then it really is up to you to make sure it works as expected. Webform can't (and arguably) shouldn't be holding hands at this point. Webforms are just too dynamic to manage this feature correctly.
I'd argue that this is a won't fix, but I'll leave that up to the maintainer. They may have an idea I haven't though of.
Comment #2
cdale commentedLooks like I jumped the gun a little. :) The idea of checking on submission could work. It is certainly an idea I hadn't though of. Though it doesn't feel like a good idea to me. I could be wrong (again) though. :)
Comment #3
rpsuI think that validation of code could be done (in case of php-code-errors) on submitting the webform itself, not just submitting the form.
I'm not familar with how Drupal checks (probably it does not) node code validity at all on add-node submit, but I guess submitted 'validation' and 'processing' -field could be run through eval() -function and check for errors (see http://www.php.net/eval , validation errors return false).
But it may not be possible to gain error proper checking with it.
Another matter is the fact that IF webform logic could be checked more properly /automaticly while submitting unpublished webforms, but then Drupal should know what user wants to ask (and know things a whole a lot more like humans...).
Comment #4
quicksketchAs noted, this is a very difficult task to validate. The trouble with validating on node_save is that the variables don't yet exist that the additional validation and submission code will likely use. Meaning you'll probably get a bunch of errors if we tried to run it on node save. I'm planning on moving the additional validation/submission stuff entirely out of Webform and into a different module in the 3.x version, it's just too dangerous to have as a bundled option.
Comment #5
quicksketchThe additional validation and submission fields are now completely removed from 3.x anyway, so there's nothing needing to be done here.