WorldPay Module for ZenCartv1.3x

[duncanad]

Rikki,

Doesn't appear to be anything wrong with your language file either - it was a bit of a longshot anyway.

I did a quick search on Google to see if there were any reported bugs for the IF statement in any paticular version of PHP. I didn't find anything but I didn't pursue it too hard.

I am no PHP expert but my understanding is that when you are testing for a numerical value you do not use quotes.

if ($testMode !== 0) {echo WP_TEST_HEADING . "<br /><br />";}

However if you are testing for a string value, ie text, you do use quotes

if ($testMode !== "zero") {echo WP_TEST_HEADING . "<br /><br />";}

You could try using quotes in case the value 0 is being presented as text rather than as a number although if that were the case I would expect the transaction to fail at WorldPay. (I've just looked this up in the WorldPay integration Guide which states " . . . Set this parameter to "0" or omit it for a live transaction." Perhaps it wouldn't fail then!?)

On re-reading the syntax for IF statements it would appear than the curly brackets surrounding the executable code is not strictly necessary if there is only one line of executable code so you could try:

if ($testMode !== "zero") echo WP_TEST_HEADING . "<br /><br />";

Make only one change to your code then test it. If it doesn't work change things back and try another change. Otherwise you can make an awful mess of things and you can easily lose track of what caused what.

If either of the above works let me know.

I'll reply to your PM tomorrow.

Regards,

Alan

[Rikki]

After adding quotes around the IF statement:

***removed humongus screenshots***

Ta-da!

I always thought PHP was clever with its variable assignments and could swap between string and numerical no problem at all but when its dealing with variables passed through to other scripts it must interpret everything as a string and therefore the : IF ($testdata !== 0) { ... } statement would be read as being "IF $testdata is NOT false display the test transaction message" as a comparison to 0 is a test for the variable existing/having data inside.

This is just what I reckon is going on with my limited PHP/C knowledge from a few years ago, I stopped doing all that and got more into making things look pretty as its easier to fix when things go ######## up

The curious thing is though, why is it only this installation that is affected by this? Surely there must be a lot of other folks with your gateway system installed.

Anyway, I think thats it sorted out (I hope) so thanks for your continued support and help.Drop me a reply tomorrow regarding the PM and I can hopefully put some business your way, its the least I can do.

Many thanks,

Rikki

[duncanad]

Rikki,

Firstly, for clarity, the solution to your problem is to change includes/templates/template_default/templates/tpl_wpcallback_default.php at lines 208 and 321 from

if ($testMode !== 0) {echo WP_TEST_HEADING . "<br /><br />";}

to

if ($testMode !== "0") {echo WP_TEST_HEADING . "<br /><br />";}

I've been doing some research and some testing to try to get to the bottom of this.

My understanding is that PHP handles variables in context. In lay terms if the context is numerical ie mathematical operands are in use like + - etc then PHP treats the variable as a number. If the contect is textual it treats the variable as a string.

The conclusion I have come to is that it shouldn't matter which way the above code is written. It works both ways for me. You seem to be the only one to have experienced this problem - at least the only one to have reported it. What version of PHP is installed on your server?

I also wanted to understand exactly what is hppening here in terms what 'type' of variable $testMode actually is.

The value of $testMode is stored in the database in the 'configuration' table as the 'configuration-value'. In the database 'configuration_value' is a text field so it follows that the default type for $testMode will be 'string'.

I set up a test to display the type of the variable $testMode

echo '$testMode type = ' . gettype($testMode) ."<br /><br />";

The result? $testMode is indeed a string.

According to WorldPay $testMode should be sent to them as an integer so I changed the code which sets the value of $testMode in includes/modules/payment/worldpay.php at line 138 from

zen_draw_hidden_field('testMode', MODULE_PAYMENT_WORLDPAY_TEST_MODE) .

to

zen_draw_hidden_field('testMode', intval(MODULE_PAYMENT_WORLDPAY_TEST_MODE)) .

This I think should set the type to integer. However the value returned by WorldPay is still of type string.

I then changed line 42 in includes/templates/template_default/templates/tpl_wpcallback_default.php from

if(isset($HTTP_POST_VARS['testMode'])) {$testMode = $HTTP_POST_VARS[testMode];}

to

if(isset($HTTP_POST_VARS['testMode'])) {$testMode = intval($HTTP_POST_VARS[testMode]);}

This change resulted in the type being set to integer so this change should make the original code work on your server. However the easiest change is just to add the quotes as you have done. This too should work in all cases - unless anyone else knows differently!

I'll consider this change for the next version which I will be working on soon.

Regards,

Alan

[Rikki]

Yeah, this seems to be it sorted now thankfully.

When passing a variable from a script to another script it will be turned into a string no matter what as there is no data format on the web for POST or GET commands, everything is in ASCII and should be sanitized when it arrives at the receiving script.

Its amazing that this should crop up right here and right now as I had just finished listening to a Podcast by PHP inventor Rasmus Lerdorf and he specifically talks about just such things!

http://www.twit.tv/FLOSS

In particular : http://www.podtrac.com/pts/redirect..../FLOSS-012.mp3

At time point 38:35

Have a listen

BTW (PHP Version 4.4.2) is whats running on my server here FYI. Still puzzled as to why Im the only one to spot this problem, but happy its sorted out and I've learned something along the way too.

Kind regards,

Rikki

[duncanad]

Rikki,

Just had a listen. Very interesting - but I'm not sure I understood it all!

My servers running PHP version 4.3.11.

I suppose if the data arrives as text the correct thing to do is to treat it as text and code accordingly in which case your solution is the better coding practice.

Well as they say "Every day's a school day!"

All the best,

Alan

[tigerbalm]

Hi Alan / Rikki,

Read your conversation with interest. I have exactly the same problem to the letter - as you Rikki.

Firstly, I don't know which solution to test out - Rikki's or Alan's - Rikki's seems less hassle and likelyhood of human error as it's a quick change - but Alan's seems the more correct solution if you're a dab hand at PHP - hhhhmnnnnn

What do you both suggest ....

Also - there's nothing worse than to solve a problem but not understand where it's coming from - ie: why only you and I Rikki? - so I'm with you on that one ...

For my 2pence worth - I'm running PHP as a CGI module which is not the best way for a zen cart installation - I'm wondering are you Rikki and do either of you think this would have any bearing on this particular problem??

For the record - here are my settings ...

Server OS: FreeBSD 4.10-STABLE
Database: MySQL 4.1.19
PHP Version: 4.3.10 (Zend: 1.3.0)
HTTP Server: Apache

Another quick one though not important - V1.3 is compliant but the worldpay image sidebox causes serious havoc with the validator. I'd sort this out myself if I could but I'm not confident enough to tackle someone elses code :o( - - - yet!


On a final note - cheers for your convo guys and to yourself Alan - well what can I say - thanks a bunch!

Rikki,

Just had a listen. Very interesting - but I'm not sure I understood it all!

My servers running PHP version 4.3.11.

I suppose if the data arrives as text the correct thing to do is to treat it as text and code accordingly in which case your solution is the better coding practice.

Well as they say "Every day's a school day!"

All the best,

Alan

[tigerbalm]

Hi Guys,

Ok - so I put the quotes in as per what Rikki did and all is fine and working properly so thanks!


Now another problem crops up and I don't know whether it's an issue with the worldpay module, or the discount coupons but here's my problem ...


Everything works fine, I'm running the latest worldpay and zencart and all is perfect and fully tested by me before going live.

The first purchase that comes through after the upgrade is completed appears in the new orders but the money hasn't come through to worldpay (my configuration of both WP and zen is perfect)

The customer is trusted and contacts to advise that she received the checkout success page after clicking the final confirm and was at no time transfered to worldpay - and her order is in my database.

I promptly freak out and over the next few hours try to replicate her order. By process of isolation of all possible parameters individually, I worked out it was the discount coupon that was creating the problem. Just to make sure, I tested like this ...


1) Created a discount coupon for 10%

2) Created an account

3) Put some products in the basket and successfully ended up at the Worldpay payment page

4) Cancelled the payment at Worldpay, went back to the site, deleted a couple of products and added some more - once again successfully getting to the payment page

5) Repeated steps 3 and 4 over 60 times - successfully

6) Repeated the process once more but this time I added the discount coupon and when I clicked final confirmation - expecting the WP page - I was held for a couple of seconds and directed to the checkout success page - on checking, my order was in the database but I never went near Worldpay

7) It must be stressed that during my extensive testing, the discount coupon worked successfully with payment page many times - that's what confuses me and that's what makes it so difficult to pinpoint the problem

So This looks like a discount coupon problem. What made me think it might be Worldpay is that Alan mentioned somewhere else on this thread - that the order is not completed and entered until the call back is received from WP - so by that reckoning, could it have bounced off worldpay to get success? I contacted WP who assured me that they did not recieve any contact to my account during the offending 'purchases'


kind regards :o)

Any ideas - I'm sure all my settings are correct - I have checked and double checked and

[duncanad]

Tigerbalm,

I'm a great believer in the KISS principle - the simple solutions are always best. I'd go with Rikki's 'just add quotes' solution and the next version of the mod will have this change. I see this is what you have done and it works for you too.

Like you I'm puzzled by why this has been a problem for some but not others. As I said above I believe PHP sets data type according to context. Perhaps in this instance there is not really any numerical context other than not having used quotes ie there are no mathematical operands used so perhaps its pot luck whether PHP handles it correctly or not. If there are any PHP gurus out there perhaps they may be able to shed some light.

Your Discount Coupon problem is a new one on me. Sounds to me as though ZenCart thinks there is sufficient value in the coupon to cover the whole cost of the order, in which case there would be no need to go through the WorldPay process and it would be quite correct to jump straight to the 'Checkout Success' process creating the order and displaying the standard 'Checkout Success' page - not the 'WorldPay Callback' page.

At the risk of being just a bit too obvious are you sure you created a 10% discount coupon and not a £10 discount coupon? A £10 discount coupon would produce the result you are experiencing if the total value of the sale was £10 or less? (Or even a 100% discount coupon!!!)

I don't think this is a WorldPay Module issue since there is nothing in the module code that looks at whether a coupon is being used or not. This is handled by the Orders Total module.

With regards to the 'We accept ...' sidebox I'll ensure that this is standards compliant for the next release. In the meantime have a go yourself. It's only HTML.

includes/templates/template_default/sideboxes/tpl_wp_cc_accept.php

I suspect the main problem is that it is just a row of images with nothing separating each one which is non compliant markup. I did it that way so that the display would be fluid and would adjust itself according to whatever width the sidebox happens to be. Seemed like a good idea at the time!

Keep us posted of any developments with your Discount Coupon problem.

Regards,

Alan

[Rikki]

Rikki,

Just had a listen. Very interesting - but I'm not sure I understood it all!

My servers running PHP version 4.3.11.

I suppose if the data arrives as text the correct thing to do is to treat it as text and code accordingly in which case your solution is the better coding practice.

Well as they say "Every day's a school day!"

All the best,

Alan

I've got into pod casts lately, TWIT is pretty good and the FLOSS ones can be hit or miss but the best one is Security Now with Steve Gibson. www.grc.com

Not sure I understand it all, if any, but it was ironic that the bloke mentioned something I'd remember when looking at the code in the WP gateway scripts.

Kind regards,

Rikki

[BigMacYin]

I would just like to thank all involved in this thread. I too had exactly the same problem as Rikki and couldn't get rid of the test transaction text. I copied tpl_wpcallback_default.php file to my templates folder and added the quotes as suggested but it didn't resolve the problem. I then used Alan's information, changed the if statement and all is now working fine.

Thanks again to all concerned and I hope that helps someone else.

Kind regards,

Hamish