<html><head></head><body bgcolor="#FFFFFF"><div>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. <br><br>Sent from my iPhone</div><div><br>On May 22, 2012, at 12:08 PM, <<a href="mailto:jeff@ayendesigns.com">jeff@ayendesigns.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><span style="font-family:Verdana; color:#000000; font-size:10pt;"><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt; ">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.</div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt; "><br></div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt; ">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. </div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt; "><br></div><div><font face="verdana, geneva" size="2">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. </font></div><div><font face="verdana, geneva" size="2"><br></font></div><div><font face="verdana, geneva" size="2">Any thoughts?</font></div></span>
</div></blockquote></body></html>