[ic] mv_click caveat - beware of overwriting [set]'s

[Mike Heins]

Quoting Ed LaFrance (edl@newmediaems.com):
> Hello all -
> 
> I have seen a particular issue pop up occasionally - enough that it bears 
> mention - which could be a potential stumbling block, particularly for 
> newer users, so I think it is worth some bytes.
> 
> A client contacted me earlier today regarding some strange behavior in an 
> IC 4.6.0 catalog I had put together for them.  It seemed that, if the user 
> clicked the checkout button on the basket page (which displayed the 
> checkout page), then clicked their browser's "back" button to re-display 
> the basket page, then clicked the checkout button again, the order would be 
> submitted immediately, bypassing all the checkout page validation and 
> processing - not normal or desirable behavior.
> 
> A little digging revealed the cause.  At some point, while editing the html 
> of the basket page, the client had changed the name of the checkout button 
> to "Place Order".  This button reference a block of variable settings via 
> mv_click, so they updated the name of that as well:
> 
> 	[set Place Order]
> 	mv_todo=return
> 	mv_nextpage=the_checkout_page
> 	[/set]
> 
> It so happens that the submit button on the checkout page was also called 
> "Place Order", and was similarly tied to a [set] block via mv_click:
> 
> 	[set Place Order]
> 	mv_todo=submit
> 	[/set]
> 

Yes, this has always been true. Nothing to be done about it, though you
can do some things to check yourself like:

	[set Place Order]
	    [if cgi lname]
	    [and cgi fname]
		mv_todo=submit
	    [/if]
	[/set]

You can also name the button itself mv_todo.submit and get the
action automatically.

Thanks for taking the time to put this on the list; maybe it can find
its way into the docs and/or FAQ.

-- 
Akopia, Inc., 131 Willow Lane, Floor 2, Oxford, OH  45056
phone +1.513.523.7621 fax 7501 <heins@akopia.com>

Friends don't let friends use Outlook. -- Bob Blaylock