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@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?
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@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?
Could be either. So odd that they removed the one location that sets it and the one location that tests for it. The result would have been the same. Sent from my iPhone On May 22, 2012, at 12:08 PM, <jeff@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?
participants (4)
-
David Metzler -
Jeff Greenberg -
jeff＠ayendesigns.com
-
Steve Ringwood