First Report of Empty Cart Problem with 5.0.5

[Dirty Butter]

I've since updated to 5.0.6, but we had our first report the other day of the empty basket problem on 5.0.5. I have it set to go to basket immediately when the order is placed.

This is the information the person sent:

Using Internet Explorer 9 and Windows 7, I tried registering first, as you suggested, but each time I try to select the item I'm interested in, I am redirected to the "Your basket is empty" page. At that point, when I look at my login status, it is not showing me as logged in anymore.

I tried again with Firefox, and it worked just fine. It's possible that your site has an incompatibility with IE 9.

[Dirty Butter]

I've since updated to 5.0.6, but we had our first report the other day of the empty basket problem on 5.0.5. I have it set to go to basket immediately when the order is placed.

This is the information the person sent:

Using Internet Explorer 9 and Windows 7, I tried registering first, as you suggested, but each time I try to select the item I'm interested in, I am redirected to the "Your basket is empty" page. At that point, when I look at my login status, it is not showing me as logged in anymore.

I tried again with Firefox, and it worked just fine. It's possible that your site has an incompatibility with IE 9.

Of all times for the bug report site to be down!

PROBLEM 1

We haven't had a sale since Dec. 27. At first I thought it was due to the holiday, but on further investigation I find that we now have the dreaded EMPTY CART problem using FF 9.30.1, IE 9.0.4, and Chrome 16.0.912.63!

When I first open the browser I can sometimes see the cart the first time I add a product, but if I remove the item and try to put something else in the basket I get the Empty Cart message.

If not set to Jump to Basket it shows it in the side bar, but when VIEW BASKET is clicked, it says Empty. IF I refresh the page the basket shows as it should.

PROBLEM 2

Once I can see the basket I can't get an item to remove with either the X or the Remove button.

I can get rid of it by zeroing out the item and Updating the Basket.

STEPS I'VE TAKEN TO TRY TO SOLVE THIS

I replaced ALL my files via FTP with a copy from before the last successful sale.

I've checked the _inventory table to see if any of the products (lots) I've added since the 27th appeared to be corrupted in any way (GoogleBase feed shows no errors)

Tested with Cache enabled and disabled

Set Auto Save User's Cart

Tried disabling Jump to Cart

Disabled Olark

For now I've added some directions for potential customers suggesting how to get around the problem. UGH!!!

DEBUGGING INFORMATION

1 On click to Add to Basket

PHP:

[Warning] /home/dirtybut/public_html/plushcatalog/classes/session.class.php:58 - ini_get_all() expects at most 1 parameter, 2 given

[Warning] /home/dirtybut/public_html/plushcatalog/includes/lib/smarty/sysplugins/smarty_resource.php:679 - filemtime() [function.filemtime.php]: stat failed for /home/dirtybut/public_html/plushcatalog/cache/skin/7b24b464f26092eb140edb833fe4b8bcb21d2928.file.content.checkout.php.php

[Warning] /home/dirtybut/public_html/plushcatalog/includes/lib/smarty/sysplugins/smarty_internal_write_file.php:49 - unlink(/home/dirtybut/public_html/plushcatalog/cache/skin/7b24b464f26092eb140edb833fe4b8bcb21d2928.file.content.checkout.php.php) [function.unlink.php]: No such file or directory

[Notice] /home/dirtybut/public_html/plushcatalog/classes/seo.class.php:430 - Undefined variable: title

[Notice] /home/dirtybut/public_html/plushcatalog/cache/skin/02f2ff58fff54b0e14d35e03803811f6921f2368.file.main.php.php:217 - Undefined index: SHOPPING_CART

[Notice] /home/dirtybut/public_html/plushcatalog/cache/skin/02f2ff58fff54b0e14d35e03803811f6921f2368.file.main.php.php:217 - Trying to get property of non-object

[Warning] /home/dirtybut/public_html/plushcatalog/includes/lib/smarty/sysplugins/smarty_resource.php:315 - filemtime() [function.filemtime.php]: stat failed for /home/dirtybut/public_html/plushcatalog/skins/mykurouto/js/common.html

2 On click to remove item

PHP:

[Warning] /home/dirtybut/public_html/plushcatalog/classes/session.class.php:58 - ini_get_all() expects at most 1 parameter, 2 given

[Notice] /home/dirtybut/public_html/plushcatalog/classes/cubecart.class.php:472 - Undefined index: billing_address

[Notice] /home/dirtybut/public_html/plushcatalog/classes/cart.class.php:646 - Undefined index: delivery_address

[Notice] /home/dirtybut/public_html/plushcatalog/classes/cart.class.php:646 - Undefined index: delivery_address

[Notice] /home/dirtybut/public_html/plushcatalog/modules/shipping/USPS/shipping.class.php:58 - Undefined index: country_id

[Notice] /home/dirtybut/public_html/plushcatalog/modules/shipping/USPS/shipping.class.php:69 - Undefined index: country_id

[Warning] /home/dirtybut/public_html/plushcatalog/classes/cubecart.class.php:1289 - Invalid argument supplied for foreach()

[Notice] /home/dirtybut/public_html/plushcatalog/classes/cubecart.class.php:1324 - Undefined variable: shipping_values

[Warning] /home/dirtybut/public_html/plushcatalog/classes/cubecart.class.php:1324 - Invalid argument supplied for foreach()

[Warning] /home/dirtybut/public_html/plushcatalog/classes/cubecart.class.php:1336 - Shipping not setup or allow no shipping not enabled

[Notice] /home/dirtybut/public_html/plushcatalog/classes/cubecart.class.php:530 - Undefined index: shipping_verified

[Notice] /home/dirtybut/public_html/plushcatalog/cache/skin/7b24b464f26092eb140edb833fe4b8bcb21d2928.file.content.checkout.php.php:130 - Undefined index: QUAN_READ_ONLY

[Notice] /home/dirtybut/public_html/plushcatalog/cache/skin/7b24b464f26092eb140edb833fe4b8bcb21d2928.file.content.checkout.php.php:130 - Trying to get property of non-object

[Notice] /home/dirtybut/public_html/plushcatalog/cache/skin/7b24b464f26092eb140edb833fe4b8bcb21d2928.file.content.checkout.php.php:180 - Undefined index: TAXES

[Notice] /home/dirtybut/public_html/plushcatalog/cache/skin/7b24b464f26092eb140edb833fe4b8bcb21d2928.file.content.checkout.php.php:180 - Trying to get property of non-object

[Notice] /home/dirtybut/public_html/plushcatalog/cache/skin/7b24b464f26092eb140edb833fe4b8bcb21d2928.file.content.checkout.php.php:195 - Undefined index: COUPONS

[Notice] /home/dirtybut/public_html/plushcatalog/cache/skin/7b24b464f26092eb140edb833fe4b8bcb21d2928.file.content.checkout.php.php:195 - Trying to get property of non-object

[Notice] /home/dirtybut/public_html/plushcatalog/cache/skin/7b24b464f26092eb140edb833fe4b8bcb21d2928.file.content.checkout.php.php:245 - Undefined index: CHECKOUTS

[Notice] /home/dirtybut/public_html/plushcatalog/cache/skin/7b24b464f26092eb140edb833fe4b8bcb21d2928.file.content.checkout.php.php:245 - Trying to get property of non-object

[Notice] /home/dirtybut/public_html/plushcatalog/cache/skin/7b24b464f26092eb140edb833fe4b8bcb21d2928.file.content.checkout.php.php:258 - Undefined index: RELATED

[Notice] /home/dirtybut/public_html/plushcatalog/cache/skin/7b24b464f26092eb140edb833fe4b8bcb21d2928.file.content.checkout.php.php:258 - Trying to get property of non-object

[Notice] /home/dirtybut/public_html/plushcatalog/classes/seo.class.php:430 - Undefined variable: title

[Notice] /home/dirtybut/public_html/plushcatalog/cache/skin/02f2ff58fff54b0e14d35e03803811f6921f2368.file.main.php.php:217 - Undefined index: SHOPPING_CART

[Notice] /home/dirtybut/public_html/plushcatalog/cache/skin/02f2ff58fff54b0e14d35e03803811f6921f2368.file.main.php.php:217 - Trying to get property of non-object

[Warning] /home/dirtybut/public_html/plushcatalog/includes/lib/smarty/sysplugins/smarty_resource.php:315 - filemtime() [function.filemtime.php]: stat failed for /home/dirtybut/public_html/plushcatalog/skins/mykurouto/js/common.html

I hope, I hope, I hope somebody can suggest a way to fix this!!!

[bsmither]

All of the Notices can be ignored. And the Warnings about filemtime.

However, several lines are a direct result of a prime-offense. I am concerned about: Invalid argument supplied for foreach(). I'll look into this later.

There is a bug report I saw that suggests a change to the code in the file session.class.php at around line 58:

$ini = (PHP_5_3) ? ini_get_all(null, false) : ini_get_all(null) ;

Also, a more appropriate set of troubleshooting info would be to report on the cookie being received and subsequently sent back by the browser. Then, see if the cookie value matches any records in the _session table, session_id column.

[bsmither]

The following is no assurance that lost carts will get fixed from this, but:

On many shared hosts all sessions are stored in the same location. Because of the way garbage collection works, this means everyone's sessions get deleted after the shortest GC interval.

One solution is to do:

ini_set( 'session.save_path', CC_ROOT_DIR.CC_DS."sessions");

Try to find a directory one up and sideways from your store directory. For example:

/html_docs/cc5/{doc_root} which is where www.mycc5store.com points to.

/html_docs/cc5_sessions/{session files here}

This way, a visitor to your store can't access the cc5_sessions folder. Also, thus, your code has complete control over garbage collection on your CC5 sessions.

Go and fetch the server info from the admin screen first to determine what the session.save_path is set to. You may already have a discreet folder for your hosted space's session files.

This should be tried in the series of $ini tests in the file session.class.php.

(I have my CC5 application's session.save_path set to a specific directory via the Apache VirtualHost group.)

[bsmither]

For expiring session lifetimes, the way I figure it, is that for a default installation of PHP:

A session file is garbage after 24 minutes of inactivity.

But CC5 sets the lifetime to 60 minutes (regardless of the comment about 30 minutes).

The chance that garbage collection runs is 1 in 100 invocations of the PHP script processor - system-wide, and PHP installers usually set this to 1 in 1000. So, for 1000 times PHP is started up to run any script anywhere on the server, there will be one time that the garbage collection will delete session files older than the lifetime.

But CC5 sets this to a chance of 15 in 100 invocations. How this affects the other session files belonging to the other scripts running on the server???

One hint I found about the chance of garbage collection is that everytime PHP is run, it generates a number between 0 and 1. If this number is less than probabilty/divisor, garbage collection will happen: all session files older than the lifetime will get deleted.

Now, a session file has a filesystem timestamp. As mentioned before, if the current time minus the timestamp is greater than lifetime, it gets deleted. And the session file is updated everytime a valid cookie is sent by the browser to CC5.

(The cookie is also set to expire after a certain time has elapsed. That's why it is important to track the cookies being transmitted.)

Disclaimer: this is how I suppose CC5 sessions are supposed to work. I haven't come to a solid conclusion that this is how CC5 actually makes it work.

[Dirty Butter]

However, several lines are a direct result of a prime-offense. I am concerned about: Invalid argument supplied for foreach(). I'll look into this later.

There is a bug report I saw that suggests a change to the code in the file session.class.php at around line 58:

$ini = (PHP_5_3) ? ini_get_all(null, false) : ini_get_all(null) ;

Also, a more appropriate set of troubleshooting info would be to report on the cookie being received and subsequently sent back by the browser. Then, see if the cookie value matches any records in the _session table, session_id column.

I'm not sure if I understand what you're asking about the cookie value. But I tried this:

I deleted all dirtybutter.com cookies

refreshed the page and found cookie for PHPSESSID with value of 946ccdba7fc743ea740ea732a23fe455

I did find that same value in one of the session entries in cpanel

That means absolutely nothing to me, and I don't even know enough to know if I did the right thing.

I commented out the line in session.class.php and added your version. I also made the change you suggested in the Admin Timeout thread I had started. So we'll see if that does anything.

Something else is messed up that I just found that must be related:

I tried logging in as a registered user and after submitting info it went back to the front page, but it did NOT show the Welcome, person logged in info at the top. If I refresh the screen the normal Welcome info shows at the top.

Now that the info is there, if I click on an item the logged in info disappears again. Add to basket - Empty - refresh and it's back in basket and Welcome info shows again.

Talk about a MESS! And I have no idea how it happened. All I've done recently is add products.

OK. I've rebooted, logged in and out of Admin several times to set the Admin timeout if possible, and tried putting an item in the cart.

It STILL worked correctly to add the item the first time only. After that I had to use the refresh screen to get it to show. Remove also still does not work without zeroing out and updating basket.

I have the session.class.php set to private $_session_timeout = 1800;

I tried your line with 1 at the end, but since I'm still apparently having some kind of session problem, I currently have it set to $this->_session_timeout = (ADMIN_CP) ? 60 * 60 * 24 : 60 * 60 * .5;

[Dirty Butter]

I really appreciate all the help you've offered, bsmither, with several of my needs. Al fixed this. It turned out to be some caching code I had added to the .htaccess file.

[Dirty Butter]

We had another empty cart report yesterday. She had already registered and I have Olark installed, so I was able to chat with her real time. At my suggestion she tried refreshing the page, but that did not fix it. She's on IE9, as one other customer was. Thanks to Olark I didn't lose the sale, as I invoiced her directly from PP.

[bsmither]

Been doing some more research. Without getting into specifics, let me ask:

Are you aware if the customers who lose sessions have had two or more IE9 windows open to your store?

Do you have Flash anywhere on your site?

(Aside: the call for the image valentine.70.jpg is using the hostname of 'www.plushcataog.dirtybutter.com' and that is inconsistent with all other calls using the hostname of 'dirtybutter.com/plushcatalog/'.)

[Dirty Butter]

Been doing some more research. Without getting into specifics, let me ask:

Are you aware if the customers who lose sessions have had two or more IE9 windows open to your store?

Do you have Flash anywhere on your site?

(Aside: the call for the image valentine.70.jpg is using the hostname of 'www.plushcataog.dirtybutter.com' and that is inconsistent with all other calls using the hostname of 'dirtybutter.com/plushcatalog/'.)

I don't know if she had more than one window open, but if it happens again, I'll certainly ask. I'll lool into the image, too, and get back to you on that. Thanks.

[bsmither]

I'm going to run another experiment, but the results of what I just saw are as follows:

* I visited your site and got a cookie 57...70 for host 'dirtybutter.com'.

* After clicking the 'Register' link, registering, and ending at the accounts page, I clicked the HOME link.

* I got a new cookie, 5d...51 for host 'www.dirtybutter.com' and it seems I am not signed in. (I am using Firefox 9.)

* Actually logged in and it seems I am still logged in.

* Went to 'dirtybutter.com/plushanimals/' and sent back the 57...70 cookie. But I'm still logged in.

Please examine every link that appears on your page. It seems some are www.dirtybutter.com (category box), most are dirtybutter.com, and one is www.plushanimals.dirtybutter.com (holiday box).

[Dirty Butter]

I'm going to run another experiment, but the results of what I just saw are as follows:

* I visited your site and got a cookie 57...70 for host 'dirtybutter.com'.

* After clicking the 'Register' link, registering, and ending at the accounts page, I clicked the HOME link.

* I got a new cookie, 5d...51 for host 'www.dirtybutter.com' and it seems I am not signed in. (I am using Firefox 9.)

* Actually logged in and it seems I am still logged in.

* Went to 'dirtybutter.com/plushanimals/' and sent back the 57...70 cookie. But I'm still logged in.

Please examine every link that appears on your page. It seems some are www.dirtybutter.com (category box), most are dirtybutter.com, and one is www.plushanimals.dirtybutter.com (holiday box).

I picked up that holiday image url from the category page, but I have no idea why the urls aren't the same. This is obviously where the cookie problem is coming from, if I can just figure out why so I can fix it.

They were all supposed to be redirected to http://dirtybutter.com/plushcatalog without the www. We changed hosts some time ago now, so maybe the redirects were never done. I'll check that.

[Dirty Butter]

I just checked, and all the permanent rewrites from www to without are in place on the host. Here's my .htaccess file. Is there something missing there?

Deny from all

</FilesMatch>



#### Apache directory listing rules ####

DirectoryIndex index.php index.htm index.html

IndexIgnore *





#### Rewrite rules for SEO functionality ####



<IfModule mod_rewrite.c>

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteCond %{REQUEST_URI} !=/favicon.ico

RewriteRule ^(.*).html?$ index.php?seo_path=$1 [L,QSA]



</IfModule>

global.includes.php shows 

$glob['storeURL'] = 'http://dirtybutter.com/plushcatalog';

And to make it even stranger, I just checked the urls of the items and photos in the exported Google file, and they don't have the www, which is correct!! Al was recently working on our site, but I don't know what files he changed. The links that are correctly done on the home page have been there for some time. The newer links I've added are the ones that are wrong in the sidebar, and then obviously all the CC generated links are wrong.

[bsmither]

A couple of things:

The category tree (a PHP array) is cached. If the tree is being pulled from the cache, that may explain why the category tree has www.

So, in the admin screens, clear the cache. Hopefully, this will force a rebuild of the category tree.

In the file mykurouto/styles/common.css, line 729, you have this as a graphic for the submit button:

url("../mykouruto/images/common/button_generic.png")

This needs to be:

url("../images/common/button_generic.png")

The way it is now is creating a link 'dirtybutter.com/plushcatalog/skins/mykurouto/mykouruto/images/common/button_generic.png' which does not exist (404). Add to that, you have a custom 404 Response page, which in turn calls for 'dirtybutter.com/_borders/canvasbkgd.jpg' and 'dirtybutter/_borders/canvasbkg.gif' that both do not exist (404). Then, in response to that, the server sends the custom 404 Response page twice again, and the whole thing explodes exponentially.

[Dirty Butter]

A couple of things:

The category tree (a PHP array) is cached. If the tree is being pulled from the cache, that may explain why the category tree has www.

So, in the admin screens, clear the cache. Hopefully, this will force a rebuild of the category tree.

In the file mykurouto/styles/common.css, line 729, you have this as a graphic for the submit button:

url("../mykouruto/images/common/button_generic.png")

This needs to be:

url("../images/common/button_generic.png")

The way it is now is creating a link 'dirtybutter.com/plushcatalog/skins/mykurouto/mykouruto/images/common/button_generic.png' which does not exist (404). Add to that, you have a custom 404 Response page, which in turn calls for 'dirtybutter.com/_borders/canvasbkgd.jpg' and 'dirtybutter/_borders/canvasbkg.gif' that both do not exist (404). Then, in response to that, the server sends the custom 404 Response page twice again, and the whole thing explodes exponentially.

OK. I changed the button code on line 729, and I'll put the canvas images back in _borders. How can you see my files?????

[bsmither]

Your javascript, css, and images are "resources" used by the web page. The browser requests these resources according to the HTML code almost just as if the human at the computer were requesting them manually. Having said that...

There are development, troubleshooting, and diagnostic tools for professional web site developers. A very popular tool that couples with the Firefox browser is "Firebug". Additionally, "HttpFox" and "Live HTTP Headers" are very useful. I also use Wireshark to watch all the traffic going in and out of my network interface.

[Dirty Butter]

It just surprised me that you could see inside my CC files and find the mistake with the button. I had done some major housecleaning on my site, as I've been on this domain since 2005 and used to use Frontpage to create my website, which of course makes very messy code. In the process I got rid of the _borders file, thinking I wasn't using it anymore. Thanks for the catch.

So now the question from me is - why was it showing www??? And what can I do to keep that from happening to someone again??

[bsmither]

As I said, the category tree is (probably) cached. Plus, there may be an issue with how the SEO feature reconfigures the URL (I haven't explored that code yet) and the SEO url may be databased.

To keep it from happening? I don't know. If the URLs were cached or databased, I would then keep it in mind to clear out everything and allow the code to rebuild it all should you change domains - including subdomains (www or something else) and sub-folders.

Mind you, we haven't proven that the differing URLs are what is causing the loss of session state - necessary for shopping basket to cart continuity and logged in status.

[Dirty Butter]

The correct url form is in the _config file of the database. The seo_urls table only shows the unique custom urls for each product I created.

[Dirty Butter]

The www is still on the Category box links. All those category and subcategory links have www, and if you go to a product via the Category route you get www with the item link. If you search in the catalog for the item it has the www, too. If you come to a product from a Google search it does NOT have the www on it, since the Export on Admin creates a file without the www.

And the login, etc., all have www, too.

So do I have my .htaccess set up wrong?

## File Security

<FilesMatch ".(htaccess)$">

Order Allow,Deny

Deny from all

</FilesMatch>



#### Apache directory listing rules ####

DirectoryIndex index.php index.htm index.html

IndexIgnore *





#### Rewrite rules for SEO functionality ####



<IfModule mod_rewrite.c>

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteCond %{REQUEST_URI} !=/favicon.ico

RewriteRule ^(.*).html?$ index.php?seo_path=$1 [L,QSA]



</IfModule>

And I attached my cpanel redirects. I must have something wrong somewhere!!

[Dirty Butter]

With the cpanel redirects gone the urls appear to be correct, without the www! STILL not completely right. I tried a test order, taking it all the way to PayPal without actually paying, returned to the cart, and went back to the basket. I marked the order as Cancelled in Admin and then logged out on the site. AFTER I logged out, I was taken to the Home WITH www!

[Dirty Butter]

If I could figure out how to stop the Category box from using the www version I think I could solve this empty cart problem. But I don't know enough to know what file is controlling that box.

[fairtomidland]

I don't know if this helps, but under File Manager, documents, On my home page General tab, my url is blank in that space, and everything works great. Do you have a specific url there? could that be causing the two cookies?

[Dirty Butter]

I don't know if this helps, but under File Manager, documents, On my home page General tab, my url is blank in that space, and everything works great. Do you have a specific url there? could that be causing the two cookies?

Thanks for the suggestion. Mine is blank, too. It's our plush animal shoppe that's having the problem. If you have time could you go through the purchase process and check the urls to see if the Category links ever show with the www at any point during registering/checkout? Just cancel when you get to the PayPal page, and feel free to use fake info. I'll just delete it when you're through.

I haven't been able to reproduce the www since I disabled cache. I'm going to leave it that way for about a month and continue random testing, unless someone writes saying they have the empty cart before then.

[Dirty Butter]

I haven't been able to reproduce the www since I disabled cache. I'm going to leave it that way for about a month and continue random testing, unless someone writes saying they have the empty cart before then.

I tried enabling cache again today, and the www showed up again, so it's disabled again.