Simple Google Analytics - Support

[dreamdaily]

Yes, the site that did not pose any problems is a brand new 1.3.7.

I just enabled it for the GA today and it's collecting the first load of data. The 'view page source' shows the right numbers and the checkout_success -- the correctly filled utmform.


And so does the old trusted 1.2.5.
Enabling it on the old version was not too hard at all: I had to "update" the query_factory.php file in the classes/db/mysql to include then missing bindvars() function et al.
This query_factory update did not have any effect on the Configuration "no-show" that started my question.

Do you know what function/file assembles dhtml menus for the admin console? Is there a max limit on the number of entries to put in the admin menu?

Any ideas?
--AW

[cuda]

Yes, the site that did not pose any problems is a brand new 1.3.7.

I just enabled it for the GA today and it's collecting the first load of data. The 'view page source' shows the right numbers and the checkout_success -- the correctly filled utmform.


And so does the old trusted 1.2.5.
Enabling it on the old version was not too hard at all: I had to "update" the query_factory.php file in the classes/db/mysql to include then missing bindvars() function et al.
This query_factory update did not have any effect on the Configuration "no-show" that started my question.

Do you know what function/file assembles dhtml menus for the admin console? Is there a max limit on the number of entries to put in the admin menu?

Any ideas?
--AW

You may want to start at admin/includes/boxes/configuration_dhtml.php
if 1.2.5 has that I really didn't use the 1.2 series so I am not much help with it. I doubt there is a maximum number that can be shown but you never know...let us know if you do track down the problem....sorry I can't be of more help but luckily you shouldn't have to change those settings very often if at all.

[dreamdaily]

OK, the mistery of the missing menu option is solved.

My bad, of course: it was just the "Admin Level" mod that was blocking the access to the new admin action. Everything is fine now.

Just in case someone is still on 1.2.x and wants to implement the Google Analytics:

Here is what needs to be done on 1.2.x:

1) Install the Mod like described in the README file.
2) Modify the core file /includes/classes/db/sql/query_factory.php:

a) Find around line 268

function queryTime() {
return $this->total_query_time;
}

}

b) Add right AFTER the function queryTime() and BEFORE the second curly brace the following code from the 1.3.x version of this file.
The final result looks like this:

function queryTime() {
return $this->total_query_time;
}

function getBindVarValue($value, $type) {
$typeArray = explode(':',$type);
$type = $typeArray[0];
switch ($type) {
case 'csv':
return $value;
break;
case 'passthru':
return $value;
break;
case 'float':
return (!zen_not_null($value) || $value=='' || $value == 0) ? 0 : $value;
break;
case 'integer':
return (int)$value;
break;
case 'string':
if (isset($typeArray[1])) {
$regexp = $typeArray[1];
}
return '\'' . $this->prepare_input($value) . '\'';
break;
case 'noquotestring':
return $this->prepare_input($value);
break;
case 'currency':
return '\'' . $this->prepare_input($value) . '\'';
break;
case 'date':
return '\'' . $this->prepare_input($value) . '\'';
break;
case 'enum':
if (isset($typeArray[1])) {
$enumArray = explode('|', $typeArray[1]);
}
return '\'' . $this->prepare_input($value) . '\'';
default:
die('var-type undefined: ' . $type . '('.$value.')');
}
}
/**
* method to do bind variables to a query
**/
function bindVars($sql, $bindVarString, $bindVarValue, $bindVarType, $debug = false) {
$bindVarTypeArray = explode(':', $bindVarType);
$sqlNew = $this->getBindVarValue($bindVarValue, $bindVarType);
$sqlNew = str_replace($bindVarString, $sqlNew, $sql);
return $sqlNew;
}

function prepareInput($string) {
return @mysql_real_escape_string($string);
}
}


It seems to be working without a glitch on the 1.2.5 code.

All the best,
--dreamdaily

[dreamdaily]

Dear cuda,

I have another question, now regarding the workings of the mod:

My assumption is that it does not touch the ipn_main_handler.php, therefore, it does not report on the PayPal bound clicks (regular PayPal, NOT the Express).

If this is true, then 'checkout_confirmation' page will report a larger number of exits/bounces/etc. than it really has, since many PayPal users will not be tracked once they go to the PayPal site to pay.

Also, after running ZC sites for almost 2 years I noticed that a lot of PayPal users do not "return to merchant" after paying and thus will never see the checkout_success page. In these cases, the transactional data will not get to Google.

1) Is my assumption regarding the ipn_main_handler.php correct?
2) If no, how does Google count the PayPal-ers?
3) If yes, what do you think about rigging the ipn_main_handler.php?

What do you think?
--dreamdaily

[a_berezin]

Too it's interesting that the developer of this problem thinks.

[cuda]

Too it's interesting that the developer of this problem thinks.

Ok look Andrew (a_berezin) you are resorting to insulting now...go back and read this thread I have given an apology for your misunderstanding of what I said and also stated that this mod is a version of your "Google Analytics Integration" mod that I changed and renamed "Simple Google Analytics." This is a community opensource project we share code and edit code to our liking. From my understanding of the GNU license I am more then welcomed to do so as long as I give credit in the files and such to any code written by others. What is your understanding of GNU license???

It is not like everytime we talk about Zen Cart we have to give a disclaimer that it started out as osCommerce.

If you would rather not share your code then do not but I do not appreciate your unnecessary insults and your lack of community support.

[virtualahmad]

i must agree that it was uncalled for. cuda did clarify his stance earlier in the thread.

[cuda]

Dear cuda,

I have another question, now regarding the workings of the mod:

My assumption is that it does not touch the ipn_main_handler.php, therefore, it does not report on the PayPal bound clicks (regular PayPal, NOT the Express).

If this is true, then 'checkout_confirmation' page will report a larger number of exits/bounces/etc. than it really has, since many PayPal users will not be tracked once they go to the PayPal site to pay.

Also, after running ZC sites for almost 2 years I noticed that a lot of PayPal users do not "return to merchant" after paying and thus will never see the checkout_success page. In these cases, the transactional data will not get to Google.

1) Is my assumption regarding the ipn_main_handler.php correct?
2) If no, how does Google count the PayPal-ers?
3) If yes, what do you think about rigging the ipn_main_handler.php?

What do you think?
--dreamdaily

Dreamdaily-

1. Google analytics tracks when you land on a page with the google analytics code not when you exit (exits are when you do not return to the site)... you can however track button clicks if desired. If a user does not return to the success page their transaction data can not be tracked you are correct.

3. How are you going to call the javascript?

[a_berezin]

So there are a lot of empty words, and answer is not present.

Once again ask.
That the developer thinks about PayPal ipn_main_handler?

[cuda]

So there are a lot of empty words, and answer is not present.

Once again ask.
That the developer thinks about PayPal ipn_main_handler?

Ok then you are the almighty....what would you suggest o great developer. Give an answer that will satisfy you so none of us need to hear your ridicule anymore....