A



SNIPPET 1 is part of code we used to provide. Anyway, you only need it once per page.

SNIPPET 2 is what we provide currently and you only need it once per page.

SNIPPET 3 is not something we provide but if you use config() and shown() functions, you only need them once.



B

The JavaScript part of the VIEW CART code (that's what these snippets are) can go anywhere in the page.



C

box.js line loads the code which makes our inline cart works. EJEJC_lc function is a blank function which ensures that buyer does not prematurely open a pop-up cart by clicking on the button before page is loaded.



config and shown function are used for cart customization. config() function can include various lines of code to modify cart's appearance and behavior. It is called BEFORE the cart is rendered. It can also include a line of code to call the shown() function AFTER the cart is rendered and shown() function can include any code you want to change cart's appearance or anything pretty much.



For more information about this, see cart customization section in the help page.

Just to clarify a bit, if you are going to put multiple View Cart buttons, the following is the complete part of that button code you only need to have once in the page (either inside the BODY or, if you wish, up in the HEAD). First, here's that part from older versions of our View Cart code:



<script language="javascript" type="text/javascript">

<!--

function EJEJC_lc(th) { return false; }

// -->

</script>

<script type="text/javascript" src="https://www.e-junkie.com/ecom/box.js"></script>





...or here's the same part from the View Cart code we issue currently:





<script language="javascript" type="text/javascript">

<!--

function EJEJC_lc(th) { return false; }

document.write("<scr"+"ipt src='" + document.location.protocol + "//www.e-junkie.com/ecom/box.js' type='text/javascript'></scr"+"ipt>");

// -->

</script>





You can use either version of code; the only difference is that the newer version automatically determines if your page is using HTTP or HTTPS and will load the box.js accordingly, so that your HTTP pages (the vast majority of cases) will load box.js into browser cache and read all future references to box.js from that cached copy (= improved page-load performance), whereas if your pages happen to use HTTPS, that would necessarily redownload a fresh copy of box.js for every reference (= slower load performance).



The older version of our code just used the latter (HTTPS) behavior in all cases, so just in case the code was placed in a secure page it wouldn't trigger any secure-encryption warnings in the buyer's browser, but that also impairs page-load performance unnecessarily in the vast majority of HTTP pages (if you don't know whether your pages are HTTP or HTTPS, then they are almost certainly HTTP, as HTTPS is kinda a pain to set up). Note that none of this has anything to do with security or encryption of the buyer's private/payment data, as that is always secure-encrypted during Checkout automatically using HTTPS and regardless of anything else.



In either case, if you are adding lines for config() and shown() functions to apply cart customization, those lines would go just before the "// -->" lines in the examples above.