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

[Ed LaFrance]

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]

...you can probably begin to see where this is going.  The first time they 
clicked "Place Order" on the basket page, the [set] on the basket page was 
parsed properly, and then the [set Place Order]mv_todo=submit[/set] block 
from the checkout page was loaded into the session, overwriting the block 
of the same name from the basket page.  When they used the browser's "Back" 
button to return to the basket page, the IC session still contained the 
[set] block from the checkout page (mv_todo=submit), because no new 
interaction with the IC server had occurred.  Lastly, when they clicked 
"Place Order" on the basket page once more, IC looks up the mv_click 
reference in the session, finds mv_todo=submit, and does what it is told.

This kind of confusion could occur anywhere mv_click or mv_check is 
used.  There are no doubt several ways to avoid this.  The easiest would be 
to avoid duplicating the names of mv_click and mv_check variables, at least 
on forms which are loaded sequentially.  This is easy when the variable is 
set with a hidden form field; perhaps not so easy if the setting is 
borrowed form the button label for reasons of association (value="Place 
Order") and the client demands unity in naming.  Another approach might be 
to employ mv_check instead of mv_click (where possible) so that some 
conditional cgi logic could be employed within it, to validate what page 
the submission came from. There are no doubt others, I haven't run across 
this problem often enough to explore work-arounds in depth.  It would be 
nice if IC recognized a page-based context for mv_click and mv_check 
references, so their parsing could be qualified based upon the page which 
contained the submitting form; perhaps this can be included in future versions.

I hope others on the list will have some useful input in this topic.

- Ed L.
 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
New Media E.M.S.               Software Solutions for Business
463 Main St., Suite D          edl@newmediaems.com
Placerville, CA  95667         http://www.newmediaems.com
(530) 622-9421                 (530) 622-9426 Fax
(866) 519-4680 Toll-Free
 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>