Google Conversion Tracking

Is there a variable available at checkout success in OC 2.x that contains the order amount?

I setup Google conversion tracking a while back, looked and couldn't find one, and I'm just now getting back to it.

Am I going to have to write an extension?

I dont think there is any total variables in the success controller, which handles the success page although it wouldn't be too hard to pull the latest order from the database in this controller & model to grab the total amount. to insert into your conversion code.

that should point you in the right direction

Paul

Thanks for the reply but, for others with the same issue: Don't modify core files, it's never worth the pain in ass it makes version updates. It's like crack, you tell yourself you're only going to do it a couple of times but pretty soon you're giving fellatio to anyone who will do your 20 file mod list every time time you need to update

Write an extension, buy one, even degrade your performance with VQMod if you really have to. Anything but changing core files in an app this size.

DBI wrote:Thanks for the reply but, for others with the same issue: Don't modify core files, it's never worth the pain in ass it makes version updates. It's like crack, you tell yourself you're only going to do it a couple of times but pretty soon you're giving fellatio to anyone who will do your 20 file mod list every time time you need to update

Write an extension, buy one, even degrade your performance with VQMod if you really have to. Anything but changing core files in an app this size.

I meant with VQmod, although to be fair.. this would be adding code rather than changing any previous core file elements ie. how have you added the conversion code in this page in the first place? VQmod? or straight copy and paste job?

Paul

Maybe we're talking about two different things... I can't think of any reason to use VQMod to add 3rd party tracking code when you can just drop it in the template. VQMod adds a significant performance hit, it should be used sparingly.

DBI wrote:VQMod adds a significant performance hit, it should be used sparingly.

hardly? VQmod makes a cached copy of your page with the modifications, this page is then loaded rather than the original, thats hardly going to cause a big performance issue and wont make a difference between 1 modification and 20 once the page has its VQmod cached version.

As for using VQmod to drop in google tracking code, well you could do that or you could just drop it in. That was my point I was getting at in my previous post, If you are adding code to opencart that does not effect the core files then where is the harm? by adding a script inline that would pull the latest order total and store it in a variable for use in the success.tpl where your tracking code is could not in any way cause any issues with other mods.

VQMod means extra database and disk IO on every page load, more on page loads where a replacement exists.

This absolutely makes a difference on a high traffic website. Disk I/O is generally always the bottleneck that forces hardware upgrades. Not so much on a low traffic one, but I already said that.

DBI wrote:VQMod means extra database and disk IO on every page load, more on page loads where a replacement exists.

This absolutely makes a difference on a high traffic website. Disk I/O is generally always the bottleneck that forces hardware upgrades. Not so much on a low traffic one, but I already said that.

Nope

Well this got off topic and I should probably drop it, but misinformation sucks so...

Here is how VQMod works:

- Modifications are made to OpenCart core so that VQMod runs with every page request. This in itself is negligible.
- VQMod then uses it's own modding system to modify pretty much every require/include call in OpenCart.
- This allows there to be a check on every call to see if: (A) modifications exist for the given file and (B) a cached replacement for the file exists. If a replacement is needed then the cached file is loaded instead of the original file.

During this process the file system is accessed a bunch of times: checking to see if various directories exist, checking to see if files exist, checking timestamps on files, and of course loading files. We can ignore all the work that gets done if a cache doesn't exist or needs to be rebuilt because that only happens occasionally.

It's important to keep in mind that the above doesn't just happen once when an OC page is loaded, it happens MANY times because there are a lot of include/require calls in OC.

A lot of the above is part of the base VQMod installation. There is additional disk I/O related to custom mods (for instance they are all loaded and checked as part of the bootup process).

In most cases the weak link on a web server, especially a budget server with a conventional hard drive, is disk I/O. This is because disk access is both relatively slow and painfully serial.

Nothing that VQMod does is particularly time consuming or inefficient, and some of it is going to be cached in memory by the webserver OS if all goes well, but nevertheless on a heavily loaded server where there's a queue for disk I/O, small things compound dramatically.

I'm not saying there's anything wrong with VQMod, or with using it, most websites will never run into performance issues. Just pointing out the reality of using it for the sake of accurate info.

its a good debate

DBI wrote: nevertheless on a heavily loaded server where there's a queue for disk I/O, small things compound dramatically.

well firstly, a heavily loaded server with a queue for Disk I/O is going to cause a delay regardless of whether VQMod is being used.

Opencart uses the useCache method as described below, the following is from the author of VQMod, So i`ll let him have the last words from me on the subject.

What about performance?

Performance has been my concern from the first idea of this project. But the way the code is designed has reduced any effect on performance. We've got over 30 vQmod scripts on our test sites with page times and have seen absolutely no performance change when enabled or disabled. Of course any script that causes a change to db queries or has code that takes longer will be a factor but that would not be a vQmod performance issue. When the actual source files are parsed, only the files that have changes need to parse the xml scripts. Additionally, multiple performance tips and tweaks have been added as well as an optional "useCache" feature that allows you reload the changes made already from the vqcache files. All in all, performance suprisingly does not appear to be a factor at all.

It's as if all of those things VQMod does magically happen in another dimension, allowing it to have NO effect on performance. Wheeeee!

DBI wrote:It's as if all of those things VQMod does magically happen in another dimension, allowing it to have NO effect on performance. Wheeeee!

Its all about the caching, it only has to do all that work to create a cached page, once thats done, all it has to do is check which page to load. the cached modded page or the original.

The process I explained above is the work it has to do provided everything is cached and no changes have been made to the files. I invite you to look at the code if you doubt it.