Intermittent Add to Cart not working

[Dirty Butter]

We've had a sprinkling of emails from customers who cannot get the Add to Cart button to work, even though others during the same time period experienced no issues. This is NOT the empty cart issue - the button simply is not doing anything. The number of such emails seems to be increasing.

 

This is on our SSL plushcatalog 5.2.13 Blueprint skin. I've tried it with the Ajax window on and off - no problem for me. Turning off Javascript in the browser does cause the Add to Cart button to stop working, but having Popups turned off doesn't affect it for me. I tested the site on IE, FF, and Chrome.

 

The latest customer having problems wrote me back to say they got the button to function properly by Pinning the item and then returning to our site from Pinterest. Does that sound like a Session issue to you?

 

I've been receiving customer emails about this ever since upgrading to 5.2.13.

 

BUT our most recent mod developer created a ini-custom.inc.php file. Could this have anything to do with this issue becoming more frequent lately?

<?php

# Custom initialization commands
# Filename: ini-custom.inc.php
# File location: main CubeCart folder

ini_set('memory_limit', '256M'); // Platypus Suhosin limit is 256M
ini_set('max_execution_time', '60');
ini_set('error_log', 'error_log');
ini_set('log_errors', 'on');

?>

Here are the most recent error log entries:

 

 

[30-Sep-2014 14:26:32 UTC] PHP Warning:  session_start() [<a href='http://docs.php.net/manual/en/function.session-start.php'>function.session-start.php</a>]: Cannot send session cookie - headers already sent by (output started at /home3/butter01/public_html/plushcatalog/ini-custom.inc.php:1) in /home3/butter01/public_html/plushcatalog/classes/session.class.php on line 598
[30-Sep-2014 14:26:32 UTC] PHP Warning:  session_start() [<a href='http://docs.php.net/manual/en/function.session-start.php'>function.session-start.php</a>]: Cannot send session cache limiter - headers already sent (output started at /home3/butter01/public_html/plushcatalog/ini-custom.inc.php:1) in /home3/butter01/public_html/plushcatalog/classes/session.class.php on line 598
[30-Sep-2014 14:26:32 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /home3/butter01/public_html/plushcatalog/ini-custom.inc.php:1) in /home3/butter01/public_html/plushcatalog/classes/session.class.php on line 504
 

 

[bsmither]

"Headers already sent" indicates that a file is inadvertently having PHP see something that is not enclosed within the <?php and ?> delimiters, or PHP is echoing out something unplanned.

 

The clue "Output started at ini-custom.inc.php:1" tells me that there is something in front of the <?php characters on line 1.

 

Typically, this something, if not actually visible, is what's called the "byte-order-mark" of the file.

 

Please use a programmer's text editor, load the file into it, then save the file as a plain-text file (no BOM). The programmer's text editor must of the type that can do this. (Notepad++ is one such programmer's text editor).

 

The "bom exists" problem should manifest itself every time the file is called, which, for this file, is for every page request. So, for now, I cannot blame it for the inability for some persons to add an item to the cart.

 

Not being able to start or maintain a session should not affect how javascript is executed in adding an item to the cart. It may affect how CubeCart responds to the ajax request. You can verify this by looking at the Net tab in Firebug (but it will only show your experience).

[Dirty Butter]

I copied the custom ini file into Notepad++ and saved it as a text file, but I still don't see anything different from the code I displayed above. - nothing in front of <?php

 

I have tried the Net tab in FF, but I've not been able to reproduce this issue and see what shows when it does NOT work. I can see that no javascript is called when the cart DOES show correctly.

[bsmither]

In Notepad++, click Encoding on the menu bar. Make sure "Encode as UTF-8 without BOM" is selected.

 

The BOM is not visible unless you switch the text editor to Hex View mode.

[Dirty Butter]

Thank you for your help in using Encode as UTF-8 without BOM on Notepad++. That does seem to have stopped the constant error message. Then all of a sudden there the error messages are again! But if they don't have anything to do with the cart issue, I can live with it.

 

But I'm at a loss as to how to find the issue with the Add to Cart button when I can't replicate it.

[bsmither]

"Then all of a sudden there the error messages are again!"

 

That's bizarre! The exact same error message?

[Dirty Butter]

 

[30-Sep-2014 17:57:22 UTC] PHP Warning:  session_start() [<a href='http://docs.php.net/manual/en/function.session-start.php'>function.session-start.php</a>]: Cannot send session cookie - headers already sent by (output started at /home3/butter01/public_html/plushcatalog/ini-custom.inc.php:1) in /home3/butter01/public_html/plushcatalog/classes/session.class.php on line 598

[30-Sep-2014 17:57:22 UTC] PHP Warning:  session_start() [<a href='http://docs.php.net/manual/en/function.session-start.php'>function.session-start.php</a>]: Cannot send session cache limiter - headers already sent (output started at /home3/butter01/public_html/plushcatalog/ini-custom.inc.php:1) in /home3/butter01/public_html/plushcatalog/classes/session.class.php on line 598

[30-Sep-2014 17:57:22 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /home3/butter01/public_html/plushcatalog/ini-custom.inc.php:1) in /home3/butter01/public_html/plushcatalog/classes/session.class.php on line 504

[30-Sep-2014 17:57:22 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /home3/butter01/public_html/plushcatalog/ini-custom.inc.php:1) in /home3/butter01/public_html/plushcatalog/includes/functions.inc.php on line 569

[30-Sep-2014 13:48:55 America/Chicago] PHP Notice:  Cleaning cached files... in /home3/butter01/public_html/plushcatalog/classes/cache/cache.class.php on line 134

[30-Sep-2014 19:01:14 UTC] PHP Warning:  session_start() [<a href='http://docs.php.net/manual/en/function.session-start.php'>function.session-start.php</a>]: Cannot send session cookie - headers already sent by (output started at /home3/butter01/public_html/plushcatalog/ini-custom.inc.php:1) in /home3/butter01/public_html/plushcatalog/classes/session.class.php on line 598

[30-Sep-2014 19:01:14 UTC] PHP Warning:  session_start() [<a href='http://docs.php.net/manual/en/function.session-start.php'>function.session-start.php</a>]: Cannot send session cache limiter - headers already sent (output started at /home3/butter01/public_html/plushcatalog/ini-custom.inc.php:1) in /home3/butter01/public_html/plushcatalog/classes/session.class.php on line 598

[30-Sep-2014 19:01:14 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /home3/butter01/public_html/plushcatalog/ini-custom.inc.php:1) in /home3/butter01/public_html/plushcatalog/classes/session.class.php on line 504

[30-Sep-2014 19:01:22 UTC] PHP Warning:  session_start() [<a href='http://docs.php.net/manual/en/function.session-start.php'>function.session-start.php</a>]: Cannot send session cookie - headers already sent by (output started at /home3/butter01/public_html/plushcatalog/ini-custom.inc.php:1) in /home3/butter01/public_html/plushcatalog/classes/session.class.php on line 598

[30-Sep-2014 19:01:22 UTC] PHP Warning:  session_start() [<a href='http://docs.php.net/manual/en/function.session-start.php'>function.session-start.php</a>]: Cannot send session cache limiter - headers already sent (output started at /home3/butter01/public_html/plushcatalog/ini-custom.inc.php:1) in /home3/butter01/public_html/plushcatalog/classes/session.class.php on line 598

[30-Sep-2014 19:01:22 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /home3/butter01/public_html/plushcatalog/ini-custom.inc.php:1) in /home3/butter01/public_html/plushcatalog/classes/session.class.php on line 504

 

[bsmither]

I'm wondering if this file actually got edited. Yes, you loaded it into Notepad++, and it was presumably saved, overwriting the original. I wonder if the FTP program "fixed" the file -- especially if the file was FTP'd using ASCII mode instead of Binary mode.

[Dirty Butter]

I thought maybe I had done something wrong when I FTP'd it back. I use CuteFTP. Would it be better to upload from cpanel?

[Dirty Butter]

I decided to open the file in cpanel and copy/paste from Notepad++ straight into the file. When I saved it, the editor said I had not made a change... so now I'm not sure what's going on with that.

[Dirty Butter]

No more of that error message, so even though the cpanel editor didn't acknowledge it, the "without BOM" version did finally "take".

 

Now back to my original serious issue. I have been able to reproduce the strange Add to Basket behavior on Chrome on Windows 7 and 8.1. Thinking it would help, I have disabled all of Turbo, tried with and without Ajax popup basket window, tried with and without CC Jump to Basket. None of these efforts seem to make any difference. I've checked my Chrome settings and they are identical to FF as far as I can tell.

 

There are no error log entries on loading the page before the button does not work.

 

I CAN usually get it to work from the homepage IF I do a hard refresh of the page. If I try to add another item, I have to do the Ctrl/F5 again. I have NOT been able to get the Add to button to work at all from within the product description.

 

This is killing us!! We haven't had an order since yesterday. ShopDev is MIA, and since this is not a stock skin, I can't get help from CC, either.

[bsmither]

"I have been able to reproduce the strange Add to Basket behavior"

 

I would really like to see a listing of the traffic going in and out the browser (like Firebug's Net tab).

 

I might have a Win7 laptop around here somewhere that might have Chrome on it. If I do, I'll try to get something added on to the browser to watch the browser's traffic.

[bsmither]

There is a standing problem I have had with ShopDev's skins and that is the weird way the skins load javascript files.

 

Looking at the Chrome Developer thingy, Console tab, I see nine references where jQuery or the $ is not defined. I have to guess that the order these plugins are being loaded, before (or after, I don't know) the loading of jQuery 1.5.1 from Google, then loads it again from the a copy in the skin folder.

 

Maybe Chrome doesn't like this. (Such a wild, wild guess!)

[Dirty Butter]

I did try to look at the Net traffic as best I can in Chrome, but it's still not easy for me to understand what I'm seeing.

 

There are 2 different jquery files in the Blueprint/js/lib files - 1.5 and 1.7min.js. Is Google the only part that uses 1.5? If so, I'd rather comment the Analytics out than lose the skin.

[bsmither]

Looking at the browser's View Source mode (if you can get it), near the bottom is a call to googleapis.com, followed by a javascript statement that adds a javascript call to the HTML document that then makes a call for the jQuery code in the skin folder.

 

Sorry, but I'm not familiar enough with javascript to figure that one out. I am not able to figure out why there is a jQuery file in the skin, unless some countries ban access to google.

[Dirty Butter]

I did some searching for the ajax.googleapis.com. As I understand it, the page has to go get the needed code from google. BUT the browser does NOT show that it is still loading anything.

 

I noticed I can tell on the full product page BEFORE I click the Add to Cart button if it is going to work correctly or not. IF the image box shows magnification when the cursor is moved over it - then the script has completely loaded.

 

So - I moved these two lines of code from the bottom up near the top of main.php and now it seems to be working!!! I've tried it on Windows 7 and 8.1 in IE, FF, and Chrome. (I did comment out the Analytics code.)

 

And I was able to enable part of Turbo, too.

{if isset($fusion)}

	{assign var="layout" scope="global" value=$fusion->get("page_layout_{$SECTION_NAME}")}

	{if !$layout} {assign var="layout" value=$fusion->get("page_layout_default")} {/if}

	<!doctype html>

	<!--[if lt IE 7 ]> <html lang="en" class="no-js ie6" dir="{$TEXT_DIRECTION}"> <![endif]-->

	<!--[if IE 7 ]>    <html lang="en" class="no-js ie7" dir="{$TEXT_DIRECTION}"> <![endif]-->

	<!--[if IE 8 ]>    <html lang="en" class="no-js ie8" dir="{$TEXT_DIRECTION}"> <![endif]-->

	<!--[if IE 9 ]>    <html lang="en" class="no-js ie9" dir="{$TEXT_DIRECTION}"> <![endif]-->

	<!--[if (gt IE 9)|!(IE)]><!--> 

		<script  src="//ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.min.js"></script>

		<script >!window.jQuery && document.write(unescape('%3Cscript  async src="{$STORE_URL}/skins/{$SKIN_FOLDER}/js/libs/jquery-1.5.1.min.js"%3E%3C/script%3E'))</script>

But I have found that version 1.5.1 is pretty old. The most recent jQuery version that still supports IE 6,7, and 8 is v 1.11.1.

 

 

jQuery 1.x

The jQuery 1.x line had major changes as of jQuery 1.9.0. We strongly recommend that you also use the jQuery Migrate plugin if you are upgrading from pre-1.9 versions of jQuery or need to use plugins that haven't yet been updated. Read the jQuery 1.9 Upgrade Guide and the jQuery 1.9 release blog post for more information.

Download the compressed, production jQuery 1.11.1

Download the uncompressed, development jQuery 1.11.1

Download the map file for jQuery 1.11.1

jQuery 1.11.1 release notes

 

Should I try to upgrade to a newer version of jQuery?

[bsmither]

I know that stock CubeCart uses files, /js/common.js and admin.js, that has not been updated to work correctly past jQuery 1.7. Thus, common.html makes this specific fetch.

 

Since (it seems) the ShopDev skins want to make the fetch for itself (not using common.html), either:

* jQuery was the highest version when being developed and the skins have simply not been upgraded, and/or

* It is known for a fact that jQuery 1.5.1 is the absolute highest version that the javascript in the ShopDev skins can work under.

 

I did not know about a migrate plugin. That is intriguing!

 

"IF the image box shows magnification when the cursor is moved over it - then the script has completely loaded."

 

The way I see it, the scripts have loaded, but in the wrong order. OR, I see the word 'async' in the <script> tag. This may have some affect on how/when javascript starts to be executed during/after the jQuery framework is currently/finished  being loaded. I don't really know.

 

What I do know is that if effects that need to be under javascript control do not work, then the javascript has crashed. (Assuming the traffic monitor shows that the javascript files were not 404.) And javascript can crash at any point in time. That is to say, if Latest Products needs javascript to be positioned and made visible, and they don't appear, then javascript has crashed (or I haven't enabled javascript to be executed on this site) just after the page has loaded.

 

But if the products do display, but the Add to Basket does not trigger an ajax request, then the javascript has crashed at some point later.

[Dirty Butter]

I took all the async's out I could find, too. A developer (not ShopDev) helped me make the upgrade from 5.2.10 to 5.2.12 - I couldn't get Blueprint to work after attempting the upgrade myself. He had to make some core changes to Blueprint to get it to work. I think he added the v1.7.1 jQuery version, but I don't know where it is used.

 

I did try, just to see what would happen, to edit the 1.5.1 and just make it 1.7.1 in main.php. It seems to work for this one, but not for the first one:

		<script >!window.jQuery && document.write(unescape('%3Cscript  src="{$STORE_URL}/skins/{$SKIN_FOLDER}/js/libs/jquery-1.7.1.min.js"%3E%3C/script%3E'))</script>

It is certainly true that there has not been a Blueprint upgrade in some time, other than changes another developer has made to it.