Reproducible BUG found!

Here were the circumstances:

I created a form yesterday and applied verification to each of the required fields. I also attempted to filter each field of what I thought were invalid characters.

After having done this I today added another form to the page, just above the one from yesterday. This new form had a single button and no input fields. It allowed me to capture a button click and redirect to a new page.

The client sent an email and complained that the fields on the form created yesterday were not allowing enough characters. He want to be able to enter commas, pound sign characters and the like. My first thought was to add in the allowable characters and realized that simply omitting the alphanumeric validation would achieve the same effect, so I did.

I clicked the FINISH button and went to test the validation. The form kept complaining that a field intended to hold a ZIP CODE was invalid. I was stunned so I started checking what could be causing this.

It was then that I discovered that each of the fields as described in the ONSUBMIT portion of the FORM tag had the very same field name. I tried nearly a dozen times to get it to produce the validation text correctly but it would not.

Finally I decided to remove the first form and re-enter the page and try to add the corrected validations again. This time it worked. I ended by pasting the newly created form back into its location and everything worked well.

SUMMARY: The bug appears to be associated with the presence of the second form. Not sure why but it was repeatable.

Could you post a link to the page with the forms? Also were you applying client validation or server validation to the forms?

Originally Said By: Jimmy Wu

  Could you post a link to the page with the forms? Also were you applying client validation or server validation to the forms?  

The URL to my test pages is here:

ppmemb.php

The validation was CLIENT side.

I worked again with this page and think that the problem is how the forms are specified. You are using ".forms[0]" in the validation code in the FORM tag. But the table that was added was ABOVE that form. So when the code is re-examined upon re-opening the page the position of the form in the page hierarchy has gone from ".forms[0]" to ".forms[1]". I am guessing that your code in the extension does not take this into account?

So I checked with another engineer and this is how Validation Toolkit works. When Form Builder came out, validations were updated to use the form id rather than the index. If you have CSS Form Builder, this error shouldn't occur when applying validations for that.

Granted IF I owned the CSS Form Builder this would not have been a problem. But I bought the uppermost package you folks sell and it has a "bug". Are you now suggesting that I pay additional money to find a proper solution?

I just checked and see that what I purchased was the SUPER SUITE. However it appears that at the time CSS Form Builder was not part of the selected group of items. I purchased this suite fairly recently, so I am concerned that what I got (which has since been updated) leaves me "high and dry".

Does this seem acceptable?

I was just checking to see if you had Form Builder. I have already logged a bug under Validation Toolkit for this. For now, if you change where it references the form index:
form[0]

to reference the form name:
getElementById('form1')

where form1 is the name of the form being validated.

Then the validation will be applied to the correct form even if you add a new form above it.

I see that the bug that was reported over a year ago is present in the current version. Is this going to be fixed?

It was logged less than a month ago, and I am currently unsure about when a Validation Toolkit update is scheduled to be made. Currently you can follow the steps to change the reference to be that of the form name and not the form index.

I hate to chime in on an older post but I it still very relevent to me. I posted a complaint about this exact problem about a year ago (I know others had as well), and was told that PHP now only supports the form index and not the id... or something of that nature, so that is why the index has to be used from now on. The problem is that when dealing with forms when there is an include file above with another form, or when adding new forms above existing ones, the WA Validation gets confused. This has been one of the banes of my existence for the last year... whenever I have to update certain site with Validation Toolkit... I shudder because it has become so aggravating under these circumstances.

I was looking at this forum to see if Validation app is worth the money, or if the library payment is worth the money, when this is one of the apps I would use.

Reading this thread just convinced me not to go w/ the app or the library payment. Nearly every forum reports bugs & problems w/ software. (And my own purchase of the first version of CSS Sculptor left me very disappointed. The software is insanely slow -- it's really unusable except to generate an initial default site framework. I've heard later editions are faster, but this should have been fixed in the very first version. Plus, later versions of any extension here require purchasing later versions of Dreamweaver...)

Anyway, I just want to let WebAssist know that business can be lost when bugs are not fixed.

And, you know, there are developers out there who fix bugs within 24 hours of reports. Check out the support that Oleg provides at Metaproducts, for example!