[ic] Problems with account_change profile in etc/profiles.order

[Ethan Rowe]

Mark Bryant wrote:

> Hi Everyone,
>
> I'm having a really odd problem with the account_change profile in 
> that fields that are marked as required are not being picked up by IC.
>
> The account_change profile in  etc/profiles.order is as follows:
>
> __NAME__                            account_change
> fname=required
> lname=required
> address1=required
> city=required
> country=required
> [if value country =~ /^(US|CA)$/i]
>         state=state_province
>         zip=postcode
> [/if]
> &or phone_day=phone, phone_night=phone Must have day or evening phone 
> number
> email=required
> &fatal = yes
> email=email
>
> __END__
>
>
> If a customer is on the account.html page and for example leaves out 
> their First Name, IC doesn't seem to be honouring the profile.
>
> The data is being collected as follows:
>
>   <td align=right>[error name=fname std_label="First Name" 
> required=1]:&nbsp;</td>
>   <td colspan="3"><INPUT TYPE=text NAME=fname VALUE="[value fname]" 
> size="15" maxlength="20"></td>
>
> I believe that this should tell IC that the field "fname" is required 
> (married with the profile above) as part of this form for a successful 
> process and follows the example in the foundation store/pages.
>
The [error] tag, in the case above, is a way of presenting the label for 
a particular field when there's no error associated with the field, and 
to show the error generated by the form profile check when an error does 
exist.  The required flag is simply a matter of telling the [error] tag 
how to present the label; it doesn't actually have any effect on the 
form profile check of that variable -- the form profile operates quite 
independently of what you specify in the [error] tag, though the errors 
generated by the form profile check are ultimately the data source for 
errors displayed by the [error] tag, so to speak.

Incidentally, the presentation of the label from the error tag can be 
customized on a per-catalog basis by setting the MV_ERROR_STD_LABEL 
variable.  For instance, in catalog.cfg:

Variable MV_ERROR_STD_LABEL <<EOF
<FONT color=RED>{LABEL}{REQUIRED *}</FONT><!-- %s -->
[else]{LABEL}{REQUIRED *}[/else]
EOF

The "[else]...[/else]" clause is used when there's no error against the 
particular field.  Otherwise, the main stuff is used.  In this example, 
a field's label is presented without special formatting when there's no 
error, but indicating that the field is required means that an "*" will 
get tagged on to the label.
The "%s" is where the error text generated by the form profile check 
goes in the output of the [error] tag when an error exists.

> I am using the following code to detect the errors (in case someone 
> can see something silly in that) and was lifted directly from the 
> foundation account.html page:
>
> [if type=explicit compare="[error all=1 show_var=1 keep=1]"]
> <P><b>There were errors in your last submission.</b><br>
> They are shown in <FONT color="red">this color</FONT> below.</FONT>
> <P>
> [/if]
>
> What's really odd is that the checkout profile is working just fine, 
> it's just the account_change one that's not and I can't see any 
> difference other than the options for the various payment methods.
>
I'm afraid I have to ask the obvious question:
Does your account change form actually indicate which form profile to 
use?  By way of:
<input type="hidden" name="mv_form_profile" value="account_change">

Furthermore, is the action of that form set appropriately?
<form action="[process]"...> (or [process-secure] if you like).

Without directing it to the special "process" pseudo-page, I believe 
that Interchange won't check your form profile.  I've poked around in 
Dispatch.pm to see how this stuff works exactly but I don't remember the 
details for certain.

In any case, it's pretty critical that you have the "mv_form_profile" 
variable set correctly.

-- 
Ethan Rowe
End Point Corporation
ethan at endpoint.com