No way to flush form errors during iterative programatic form submission
andremolnar - October 1, 2007 - 20:11
| Project: | Drupal |
| Version: | 6.x-dev |
| Component: | forms system |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
Currently form_set_error holds errors in a static variable. There is no way to flush this variable.
Use case: You are writing a script to programatically submit the same form iteratively using drupal_execute with different values in each iteration.
Current Problem: If any form sets an error during code execution (in any iteration) - all subsequent form submissions will fail with the same error since the errors are stored in a static variable.
Possible Solution: provide an interface to flush the errors.
Attached is a patch that would do this. It simply adds a param to form_set_error. form_set_error could then be called between iterations to 'flush' or 'reset' the error array.
andre
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| form.inc__5.patch | 726 bytes | Ignored | None | None |
#1
there's a patch - changing status to reflect this
#2
Instead of resetting $form to NULL, shouldn't it be reset to an empty array? Corrected patch attached.
#3
I would like this to get in. Runned all tests without problems. The patch was not made on the right way though. Right patch supplied.
#4
I believe we typically use $reset instead of $flush (e.g. node_load()). Otherwise, this looks good. Feel free to RTBC it after that change.
This issue is killing mailhandler module as it tries to validate multiple nodes/comment submissions in a single request.
#5
Reworked $flush to $reset. As moshe suggested patch to RTBC
#6
Sorry, not yet. This needs doxygen.
#7
With doxygen :d
#8
well done. thanks.
#9
I concur, this is fine.
#10
Lets commit. #273570: attachments should (optionally) inherit the exposed filters from parent display and #260934: Static caching: cannot call drupal_validate_form on the same form more than once and #272042: There is no way to reset validation errors are all dupes of this issue.
#11
Moshe, I'm not sure http://drupal.org/node/260934 is a duplicate. That one is a static cache in the validate function. If a form doesn't get past that, it will never even get to this place in the code.
#12
Still applies.
#13
Seems sane, and has the thumbs-up from the FAPI maintainer. Committed. Moving to 6.x, since the two referenced bugs were against 6.x modules. I don't know that we can apply it there since it's an API change, but moving it for Gabor nonetheless.
#14
We've done a similar small API expansion with the XML-RPC error handler on call from Dries, so I see no reason this should not get in. it does not affect the existing code. Committed to 6.x.
#15
Automatically closed -- issue fixed for two weeks with no activity.
#16
Is this fixed for 5.x?