WorldPay Module version 2.0 - Support thread

[philip_clarke]

I'll fix the things I can today.

I've noticed the UTF-8 problem before because the worldpay pay on an "undefined" test site has some garbled characters, I work by default in UTF-8, half of the module is old and may be in cp-1252, the email template issue is certainly a left over from the old module and currently I don't have a worldpay account to test things with which presents quite an interesting problem.

[rued]

I don't have a worldpay account to test things with which presents quite an interesting problem.

That is for sure a problem. :)
Odd if WorldPay don't want to help you with that, when you help them with customers ...

Anyway, I tried converting all files into iso-8859 but still get characters messed up. Have noticed that the address shown i browser is https://select-test.worldpay.com/wcc/card (not the store address as normally) when we're returning to the shop, that is also odd - and might influence on characters?!

[philip_clarke]

I applied multiple times for a test account and they never responded.

Someone let me borrow their account for a while but I have a way of faking a worldpay response anyway but then I got this far without having an account so it's not that bad. I could apply for an account with my own business banking set up, but I have no motivation to do so.

[philip_clarke]

Just got time to test your module Philip, excellent work - well done. :)

But a few issues is there in it:

define for FILENAME_WORLDPAY is missing in admin, causing the file not to be found.

FILENAME_WORLDPAY is defined in 2.04 in the admin side but it's in

./admin/includes/languages/english/worldpay_response.php

the english bit probably raising the problem, since there is no template default system in admin, that is not possible to fix apart from copying over to whatever language you may be working with.

I'm just working through the others

[philip_clarke]

Just got time to test your module Philip, excellent work - well done. :)

But a few issues is there in it:

define for FILENAME_WORLDPAY is missing in admin, causing the file not to be found.

The only solution for this one is to sort out a language for your own admin installation, as previously mentioned, there is a define for FILENAME_WORLDPAY in ./admin/includes/languages/english/worldpay_response.php so it's a matter of creating the folder and copying the file across, tell me and translate anything and I'll put an admin language file in the next release.

email template for email_template_wp_callback.html missing, giving big nasty error twice on top of sites when returning to shop:

That was caused by the lack of an email template for HTML messages, strangely that shouldn't have got through the system as it must be very configuration specific as although I can trace it (and have fixed it), I've never seen that myself and my default test user is set to receive HTML emails. My guess is that your version is displaying the error->messagestack and for some reason mine has this disabled to the "public". That's curious as I've installed this module on at least 9 servers for people from this forum and I've not seen it on any installation.

Modules core files and language files is in UTF-8, causing problems for most shops with t.ex. latin languages, since Zen Cart up to 1.3.8 is iso-8859-1 as default (will change in 1.4 to UTF-8).

I have saved the templates into IS0-8859-1 BUT I think it will make no difference. I did a byte count of the pages and in UTF-8 and ISO-8859-1 they came up identical and I can see massive implications for the future (not just in this module). My theory is that in this case when the page is pulled from the shop and displayed at WorldPay, then worldpay is setting a header for UTF-8 but the shop's main text is in ISO-8859-1 and so some characters are getting mangled. I would need a VOLUNTEER (I do not need direct access to a merchant account or to admin or to having the site in test mode as I can fake all that) to prove this, but the big implications are that for years people have been editing the pages and storing all the information in a MySQL Latin-1 charset database (or getting paypal info back into the DB as a windows charset) and all that information is going to be pulled out in ZC 1.4 and displayed on a UTF-8 page.

Anyway, the fix for the email issue has been done along with the conversion to ISO... though I don't think it will make much of a difference. It's been submitted to the downloads page, but early adopters can get it here:

http://########################.co.uk/WorldPay_ZC1.3.x_v2.05.zip

I shall await a volunteer to see if there's anything I can do about the character set display.

Philip.

[rued]

The only solution for this one is to sort out a language for your own admin installation, as previously mentioned, there is a define for FILENAME_WORLDPAY in ./admin/includes/languages/english/worldpay_response.php so it's a matter of creating the folder and copying the file across

In ./admin/includes/boxes/extra_boxes/worldpay_response_customers_dhtml.php you have defined the db table, also FILNAME define could go here then. Or best, all defines moved into new files in ./includes/extra_datafiles/ and ./admin/includes/extra_datafiles/

That's curious as I've installed this module on at least 9 servers for people from this forum and I've not seen it on any installation.

Was this maybe English sites/language then? My workaround was to copy and rename ./email/email_template_checkout.html into ./email/email_template_wp_callback.html AND ./email/no/email_template_wp_callback.html

I did a byte count of the pages and in UTF-8 and ISO-8859-1 they came up identical

Not sure that you should see a different, as long as there isn't any special characters (like å,ø,æ,ä,ö etc.).

My theory is that in this case when the page is pulled from the shop and displayed at WorldPay, then worldpay is setting a header for UTF-8 but the shop's main text is in ISO-8859-1 and so some characters are getting mangled.

I think you're right on this one, but not sure if I can help you debug it as I don't have any WorldPay account myself - just helping someone out with it. But I'll see if I can arrange something for you, and if so PM you.

but the big implications are that for years people have been editing the pages and storing all the information in a MySQL Latin-1 charset database (or getting paypal info back into the DB as a windows charset) and all that information is going to be pulled out in ZC 1.4 and displayed on a UTF-8 page.

ZC 1.4 will hopefully come with a migration tool to overcome this issue, if not each and one having special characters stored would need to convert their database manually into utf8 collation. Not really a hard thing to do, can also be done directly in phpMyAdmin. Done it for some Joomla! sites, migrated from 1.0 to 1.5 - where the extensions wasn't supported by the migration tool.

[philip_clarke]

In ./admin/includes/boxes/extra_boxes/worldpay_response_customers_dhtml.php you have defined the db table, also FILNAME define could go here then. Or best, all defines moved into new files in ./includes/extra_datafiles/ and ./admin/includes/extra_datafiles/

Ahh, but I was working from the paypal template using

/admin/includes/languages/english/paypal.php

so that would be the correct place in theory. It could go into ./admin/includes/extra_datafiles/ but that would kill the ability to translate it into a different language as that's a global load.

Was this maybe English sites/language then? My workaround was to copy and rename ./email/email_template_checkout.html into ./email/email_template_wp_callback.html AND ./email/no/email_template_wp_callback.html

The sites were English language but I suspect something else is different in the configuration, I debugged it from your error message which gave me the page ./includes/functions/functions_email.php

and this:

    if (!file_exists($template_filename)) {
      if (isset($block['EMAIL_TEMPLATE_FILENAME']) && $block['EMAIL_TEMPLATE_FILENAME'] != '' && file_exists($block['EMAIL_TEMPLATE_FILENAM
E'] . '.html')) {
        $template_filename = $block['EMAIL_TEMPLATE_FILENAME'] . '.html';
      } elseif (file_exists($template_filename_base . str_replace(array('_extra','_admin'),'',$module) . '.html')) {
        $template_filename = $template_filename_base . str_replace(array('_extra','_admin'),'',$module) . '.html';
      } elseif (file_exists($template_filename_base . 'default' . '.html')) {
        $template_filename = $template_filename_base . 'default' . '.html';
      } else {
        $messageStack->add('header','ERROR: The email template file for (' . $template_filename_base . ') or (' . $template_filename . ') c
annot be found.','caution');
        return ''; // couldn't find template file, so return an empty string for html message.
      }
    }

So there should be something on your system displaying the messagestack whereas on the other systems it's probably turned off. It only needs one file on the system to be found though, so I just copied it to email_template_wp_callback.html. It's a pity but I can't add the wpdisplay box to the email as it's a worldpay pull that puts it on the page.

Not sure that you should see a different, as long as there isn't any special characters (like å,ø,æ,ä,ö etc.).

I think you're right on this one, but not sure if I can help you debug it as I don't have any WorldPay account myself - just helping someone out with it. But I'll see if I can arrange something for you, and if so PM you.

all that really needs doing, is examining what headers worldpay sends out when it pulls the page through, and a start would be Mozilla 3 and Tools > page info. I could go onto a friend's website or find an un-patched one and break into it, in "test mode" but I thought I'd ask for volunteers first.

ZC 1.4 will hopefully come with a migration tool to overcome this issue, if not each and one having special characters stored would need to convert their database manually into utf8 collation. Not really a hard thing to do....

Not hard, but

1. Time consuming
2. Beyond the understanding of most basic shop administrators

The forums shall be filled with people claiming ZC is broken because of "the squiggles".

[corris]

Not sure if this is the right place --> ZC 1.3.7 - php4 (sorry, other apps require) - worldpay mod 1.4 (I'm very olde worlde, I know)


This has worked fine for yonks and yonks. Suddenly, worldpay or 'bye now' buttons replaced by 'contact me' buttons (ie worldpay disappears to the shopper)
Still active in admin payments module.

Worlpay say the site is still fine for payments and not their problem (they would though)


Any ideas why a working shop suddenly becomes an unworking shop (and surprisingly, I'll also say I've not changed anything) ????




THANKS

[corris]

Re above

I chickened out - moved to a php5 server.

Removed old worldpay module + installed new worldpay module 2.0.4

No difference ---> shop has no buy buttons, just a contact me which directs to my contact me page

So, tis not php or module version me thinks ---> but, what else is there for me to have lost my shop?

[philip_clarke]

You've been hacked. I you didn't do anything, then someone else did. Private message me and I'll have a look around, it's not the module but something is amiss.