[development] Hacked core - but why? D6
David Metzler
metzler.dl at gmail.com
Wed May 23 13:02:09 UTC 2012
My gut says that there are ajax form resubmissions that they were trying to stop the form validator from executing on, but didn't understand $form_state['rebuild'].
Dave
On May 22, 2012, at 9:12 AM, Steve Ringwood wrote:
> Gut feeling
>
> There is custom code using drupal_execute to submit a form but it fails to pass validation.
> Probably not a safe/secure hack.
>
> nevets
>
> On 5/22/2012 11:08 AM, jeff at ayendesigns.com wrote:
>>
>> Hi all. So, I'm working with a client who had work done by well-meaning-but-short-on-Drupal-experience coders, who achieved some things by hacking core, and I'm identifying the hacks and finding alternative ways to achieve the same results.
>>
>> One (probably not the only, just the first) has me puzzled. In the original drupal_execute, the form state is set to must_validate (this, as far as I can tell from a grep, is not checked for anywhere), and then form_error is called in a way to reset the static form error state.
>>
>> The hack comments out the form state assignment and call to reset the form error state. Why would someone would want to do that, given that it's occurring after a form is first loaded? The only thing that comes to mind is perhaps the same from is being loaded as was just displayed, and they don't want the displayed errors to be reset, but surely this would have consequences when the forms ARE different.
>>
>> Any thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20120523/dcac97cf/attachment.html
More information about the development
mailing list