VirtueMart Developer Portal

Resolving the "Empty Cart" Problem

General

VirtueMart stores all user information - including the cart and it's product contents - on the server side. Only the server knows what products a customer has in their cart.

But how does the customer keep the cart?

The customer's browser stores a small cookie with the name "virtuemart". This cookie's value refers to the correct "Session ID" on the server, so the server knows what session it needs to load.
When a customer browses your shop, the browser sends the cookie value to the server each time before the page loads. The server loads the correct session and presents all the products the user has in their cart. Actually PHP cares for the Session Management.

And why does the cart empty each time I browse to a new page?

This could be due to many different reasons. Some of the more common ones are:-

Do NOT use VirtueMart in a framed site

If you run a VirtueMart shop in a framed site, you will run into serious problems.

• Cookies are only stored for the domain they are set to. If www.example.com loads the shop from the domain shop.2lm2lcm.net in a frame, the cookie can't be stored for www.example.com, but only for shop.2lm2lcm.net. This prevents the cart contents from being kept.
• Internet Explorer has very restrictive security settings. When frames come into play, it blocks cookies from other domains. You can confirm this by the red sign at the right bottom of the browser window.

Is your Session Save Path writable?

What? "Session Save Path"?

This is the path where all the sessions' data is stored by the server. If this path is not writable, no sessions will be stored at all. This results in empty carts, because the information about which product was added into a cart couldn't be saved.

You can overcome this issue by checking your session save path. In the Administration Backend go to "System" => "System Info". In the section "Relevant PHP Settings" you will find the value for the session save path. Now make sure this directory exists AND is writable.

You're using Shared SSL?

Shared SSL allows you to use a SSL certificate at a very low price. The downside is that you share the certificate with other users of the same provider.

The problem with Shared SSL is that it uses a domain other than your shop domain. As explained above, cookies are only valid for the domain where they are set.

So even if exactly the same site loads on a new domain - all login information and the cart contents are gone.

Luckily VirtueMart has a mechanism that copies the session information from the "http" domain to the "https" domain, so the customer can proceed smoothly in the checkout.

Here it is absolutely necessary to keep your "image directory" -

/components/com_virtuemart/shop_image/

- which is used to store the temporary session files - writable.

Keep VirtueMart and Joomla!/Mambo up-to-date!

Different version of Joomla! and Mambo come with different session mechanisms and cookie names. This tohuwabohu makes it hard for VirtueMart to stay compatible with all those versions. There are known incompatibilities with

• VirtueMart 1.0.4 and Mambo 4.5.3
• VirtueMart 1.0.2 and Joomla! >= 1.0.7
• VirtueMart ? 1.0.3 and Joomla! > 1.0.8

You're using Mambo >= 4.5.3 ?

When using Mambo 4.5.3 and a VirtueMart version earlier than 1.0.5 it's recommended to follow these intructions.

You're using a bridged Forum (SMF) ?

Please follow the instructions from this topic.

Note: All code changes affect the file

/administrator/components/com_virtuemart/classes/ps_session.php

.

Shared SSL Fix by Asterix:

I was having cart drop problems and problems even just with the SSL redirect in general (cluster server for http seperate https:// with different urls for secure server (i.e. https://secure1.myhost/mydomain). Disable SEF URLs and change your .htaccess like this:

##  Can be commented out if causes errors, see notes above.
#<IfModule mod_php5.c>
#Options +FollowSymLinks
#</IfModule>
#
#  mod_rewrite in use

RewriteEngine On


#  Uncomment following line if your webserver's URL
#  is not directly related to physical file paths.
#  Update Your Joomla!/MamboDirectory (just / for root)

RewriteBase /


########## Begin - Joomla! core SEF Section
############# Use this section if using ONLY Joomla! core SEF
## ALL (RewriteCond) lines in this section are only required if you actually
## have directories named 'content' or 'component' on your server
## If you do not have directories with these names, comment them out.
#
#RewriteCond %{REQUEST_FILENAME} !-f
#RewriteCond %{REQUEST_FILENAME} !-d
##RewriteCond %{REQUEST_URI} ^(/component/option,com) [NC,OR] 		##optional - see notes##
#RewriteCond %{REQUEST_URI} (/|\.htm|\.php|\.html|/[^.]*)$  [NC]
#RewriteRule ^(content/|component/) index.php
#
########## End - Joomla! core SEF Section



########## Begin - 3rd Party SEF Section
############# Use this section if you are using a 3rd party (Non Joomla! core) SEF extension - e.g. OpenSEF, 404_SEF, 404SEFx, SEF Advance, etc
#
RewriteCond %{REQUEST_URI} ^(/component/option,com) [NC,OR] 		##optional - see notes##
RewriteCond %{REQUEST_URI} (/|\.htm|\.php|\.html|/[^.]*)$  [NC]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) index.php
#
########## End - 3rd Party SEF Section



########## Begin - Rewrite rules to block out some common exploits
## If you experience problems on your site block out the operations listed below
## This attempts to block the most common type of exploit `attempts` to Joomla!
#
# Block out any script trying to set a mosConfig value through the URL
#RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|\%3D) [OR]
# Block out any script trying to base64_encode crap to send via URL
#RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]
# Block out any script that includes a <script> tag in URL
#RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL
#RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL
#RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Send all blocked request to homepage with 403 Forbidden error!
#RewriteRule ^(.*)$ index.php [F,L]
#
########## End - Rewrite rules to block out some common exploits

It's also important to check with your host to see how they handle session variables if you run on a similar model. And try uncommenting the security blocking (Apache Module "mod_security") and re-enabling sef urls in the .htaccess after you get it working.