E-junkie Help >

Cart does not retain items added during testing

Delete your browser cookies to resolve the most common cause of this problem. Sometimes when you are adding or editing products and other settings in Seller Admin while also testing your shopping cart buttons at the same time, the cookie we set in your browser to track your cart contents can get confused, so only the latest item added to a cart will show up in the cart, and any previously-added items will seem to disappear from your cart. Clearing the cookies in your browser will fix this for you.

E-junkie cart needs to be tested online. For the cart in your page to work correctly, the page where you paste your E-junkie cart button codes must be:

  • Uploaded on a live Web site (a "local" copy of a page saved to your computer's hard drive won't work);
  • Have a domain name in its URL (a URL using just a numeric IP address won't work);
  • Tested in a regular Web browser (the "preview" mode built into many Web-design programs probably won't work);
  • Accessed from a computer with a live Internet connection (loading the page and then going offline will not work).

Make sure you have at least one complete block of your View Cart code from Seller Admin on every page of your site that has any number of Add to Cart buttons, and don't mix-match our standard JavaScript-enhanced cart button codes with the non-JavaScript version of button codes in the same site -- i.e., all of the cart button codes on your site should be the same type of code (JS or non-JS)

Our standard JS cart button codes display the cart as a nice overlay "inside" your page when the full View Cart code is present in that page; however, if you're using the non-JS version of button codes, or if the buyer has JS disabled in their browser, of if the View Cart code is missing, incomplete or garbled in a page, the cart buttons on that page will work in "fallback" mode by displaying the cart in a popup window/tab. Due to the limitations of browser cookies, items added to that popup/fallback cart cannot be shown in the overlay-style cart, nor vice-versa.

If the information provided above didn't resolve the problem for you, see below for some other, more obscure reasons that may be causing your problem.


Also, make sure all your products are priced in the same currency. The cart can only hold items that are all priced in the same currency because payment processors cannot handle checkout totals split into differing-currency subtotals. Clicking the Add to Cart button for an item priced in a currency different from items previously added to the cart would "reset the cart" by dumping the earlier items and adding only the latest item to the buyer's order.

Shared hosting on a subdomain

This could affect some sites hosted at a subdomain of a Web site host's domain -- e.g., your-name.hosting-domain.com. If your site is hosted on this type of domain, and your E-junkie cart is not retaining items added to it, try adding these lines to your View Cart code on every page, just before the // --> line in the standard View Cart code you obtained from Seller Admin:

function EJEJC_config() {

(If you're already using other cart customizations, just add the line EJEJC_CDOMAIN='true'; to your existing function EJEJC_config(){} section.)

The reason for this is that our cart script needs to set a cookie in the buyer's browser, so we can keep track of which cart instance is theirs; this allows the buyer to keep viewing and adding items to the same cart as they show/hide the cart and move from page to page. Cookies must be set for a specific domain name, which can only be read by other pages on that same domain, so our cart tries to set this for your page's base domain (e.g. example.com); this way, if the buyer wanders between example.com and www.example.com, they would still see the same cart under either version of that domain.

However, browsers won't allow setting a cookie for just plain .com, because that would mean any page hosted on a .com domain could read that cookie. By the same token, they also won't allow setting a cookie on well-known shared-hosting base domains (e.g., the appspot.com domain used by Google's AppEngine service), so if your site happens to be hosted on one of these domains, you may need to use the above code to force your cart to set a cookie for your page's full domain, rather than just the base domain.


We have identified an issue affecting newer browsers and certain sites using frames, where the domain of the master frameset page URL does not match the domain of the actual pages being displayed inside the frame which are using our cart buttons.

E.g., if you are using a site-builder service that hosts your actual, individual pages at something like this:
...but you are displaying those individual pages inside a frameset "wrapper" page with a URL on your own custom domain, so that a visitor's browser only shows the site's Web address as:
...then our standard JavaScript cart buttons with the nice overlay-style cart display will not work for certain visitors, depending on their browser's cookie settings. This also affects cases where the page at one domain is using an IFRAME to display a page from another domain which contains our cart buttons.

Modern browsers (starting with Internet Explorer 7, Safari 3, Firefox 3, Google Chrome and Opera) have increasingly added an option to "Block third party cookies" or "Only accept cookies from sites I navigate to directly"; Safari and lately Firefox 22 even make this the default setting, whereas the other browsers optionally allow the user to enable that setting. Our standard cart always sets the buyer's cart-tracker cookie as a "first party cookie" with the same domain as your page which contains our View Cart button code; however, if the URL of the cart page itself has one domain, but the Web address visible in the browser's address bar has a different domain (because of a frameset wrapper or IFRAME), then newer browsers will treat that as a third-party cookie (just as if it were a banner ad displayed in an IFRAME).

If you cannot get the domain of your page URLs to match the domain of your frameset URLs -- or better yet, just do away with the outdated frameset approach entirely and point your domain directly to the server where your pages are actually hosted -- then you must use either our non-JavaScript cart button codes (which displays the cart in a popup window) or else use our Buy Now buttons for instant Checkout of just one item at a time. There is no other easy fix or workaround to keep using your existing buttons and cross-domain framesets as-is and have them work in newer browsers when their setting to refuse third-party cookies is engaged.