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

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

andremolnar’s picture

Status: Active » Needs review

there's a patch - changing status to reflect this

TheMystic’s picture

FileSize
729 bytes

Instead of resetting $form to NULL, shouldn't it be reset to an empty array? Corrected patch attached.

R.Muilwijk’s picture

FileSize
769 bytes

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.

moshe weitzman’s picture

Status: Needs review » Needs work

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.

R.Muilwijk’s picture

Status: Needs work » Reviewed & tested by the community
FileSize
769 bytes

Reworked $flush to $reset. As moshe suggested patch to RTBC

chx’s picture

Status: Reviewed & tested by the community » Needs work

Sorry, not yet. This needs doxygen.

R.Muilwijk’s picture

Status: Needs work » Needs review
FileSize
968 bytes

With doxygen :d

moshe weitzman’s picture

Status: Needs review » Reviewed & tested by the community

well done. thanks.

chx’s picture

I concur, this is fine.

KarenS’s picture

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.

catch’s picture

Still applies.

webchick’s picture

Version: 7.x-dev » 6.x-dev

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.

Gábor Hojtsy’s picture

Status: Reviewed & tested by the community » Fixed

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.

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

vivianspencer’s picture

Is this fixed for 5.x?

westbywest’s picture

I can't find this particular issue (#180063) listed as fixed on any recent D6 release. Has it been fixed yet?