The default output when Worldpay calls the callback URL is plain white text.

We can do better.

Some more code stolen from the Ecommerce Worldplay Module

Forgive the lack of patching - can't roll one from here.

at line 325 or so remove

 print $output;
  exit();

replace with

  global $base_url;
  drupal_set_html_head("<base href=\"$base_url/\" />\n");
  print theme('page', $output);
  return;

This gives a fully themed page - much better customer experience.

Regards
Alan

CommentFileSizeAuthor
#11 confirmationpage.png468.09 KBhixster
#6 uc_worldpay.module.theme_.patch2.34 KBdavej

Comments

dublin drupaller’s picture

dublin drupaller commented

hi Alan,

Some more code stolen from the Ecommerce Worldplay Module

LOL!

glad the Drupal ecommerce worldpay.module was of help...do you have a live worldpay account I can test the module on?

Cheers

Dub

NecroHill’s picture

NecroHill commented

Page looks better, thank you!
but WorldPay still returns URL which looks like https://select.worldpay.com/wcc/card?op-PMGetNextPage&PaymentID=xxxxxxxx...
instead of http://www.yoursite.com/cart/worldpay/complete
therefore customer doesn't have saved cookies for this URL and sees User login form
any ideas?

alanburke’s picture

alanburke commented

Assuming the user login form is contained in the login block,
set the block visibility for the login block to NOT appear on that page.

As soon as the user navigates to another page,
they are back on your site, and their session is active.

That page is always served from the Worldpay site, so that might be your only option.

Alan

davej’s picture

davej commented

Is there any reason not to replace:

  print $output;
  exit();

with simply:

  return $output;

and similarly for the other print/exits in function uc_worldpay_complete? - That function is the page callback for cart/worldpay/complete and a page callback normally returns, rather than prints, the page content, which is then themed as normal. Have I missed something?

Thanks,

Dave J

alanburke’s picture

alanburke commented
Status: Needs review » Active

Have I missed something?

Yes.
This "page" isn't actually returned from your server.
It is returned by the Worldpay server.

This is the reason for setting "base href".

It also explains the problems at
http://drupal.org/node/369096#comment-1284460
The login block appears because the response is coming from the Worldpay server,
and therefore the cookie which knows you are logged in doesn't work.

Alan

davej’s picture

davej commented
Status: Active » Needs review
StatusFileSize
new uc_worldpay.module.theme_.patch2.34 KB

Good point! Here's my patch, applying the theming for all cases rather than just successful transaction.

Dave J

andrew.lansdowne’s picture

andrew.lansdowne commented
Status: Active » Needs review

This is good, but is it possible to use the node template to display the messages? Or to create a new themeable template? in our theme, if the content is written directly to $content in page template, it has no content wrapper divs which place margin/padding around the content. I would do this if i knew how.... will try

thanks

Alice Heaton’s picture

Alice Heaton commented
Status: Needs review » Needs work

Hello,

Thanks for this patch :) It works well for anonymous users, however there is a problem for logged in users : when uc_worldpay displays those messages, the page is actually loaded by Worldpay and displayed by Worldpay : the original cookies are not available, and so the page displays as if the user was not logged in.

This can be confusing, so I think it would be better to theme this using a separate template - which can be made to be the same as 'page' for people who are ok with this approach.

I've posted a patch to solve a different problem (here : http://drupal.org/node/506286#comment-1975864 ) which also implements the themeing (in a way similar to davej's patch) but by using a different theme function ('uc_worldpay_redirect').

What do people think ?

Anselm

matason’s picture

matason commented
Status: Needs work » Fixed

Thanks alanburke, davej - code committed - http://drupal.org/cvs?commit=281064

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

hixster’s picture

hixster commented
StatusFileSize
new confirmationpage.png468.09 KB

Hi guys,

First time using UC_Worldpay module. I am using the 6.1rc-1, so I should have all the patches etc described in the thread. Unfortunately the confirmation page world page generates for me is garbage (see attached), I have a hunch that this could be due to my Acquia Prosper based theme that uses Skinr and the fusion base theme, although I could be wrong.

How /Where can I switch the module to use my own custom themed page or handcode markup?

regards

Hixster

matason’s picture

matason commented

Hi hixster, it's worth checking your completion page for empty divs, RBS makes a mess of them and it can make your theme look broken.

hixster’s picture

hixster commented

Thanks for the quick response matason. I have a couple of questions relating to it.

- even if I find missing divs, how/where do I fix them.
- how does the confirmation page get generated, is it from the page.tmpl template as mentioned above (assuming yes
)
- the page is missing my cufon fonts etc and im assuming this is due to some missing CSS classes and/or JavaScript
- for above reasons I think it would be easier to provide a really simple page template of my own, how would I do that

Thanks for your time

matason’s picture

matason commented

even if I find missing divs, how/where do I fix them.

It depends, I think the first thing is to determine whether this is your problem, then we can worry about how to fix it ;)

There are a number of things you can do here:
a) Make sure your completion page produces valid mark-up when you visit it directly. i.e. not by going through the normal check out process but by hitting the URL directly, (empty divs are valid mark-up AFAIK) but if you find any chances are RBS are messing those up.
b) Take the HTML source from your completion page that you get back from RBS and compare against the source in you got in a.

Here's the email exchange I had with RBS when I was testing and got this issue, I was on a pretty clean install of Drupal 6 using Garland:

Hello,

I *think* there maybe an issue with the way you treat 'empty' divs in
the payment response url.

My payment response url is a valid xhtml strict page, here is an excerpt:

<div class="clear-block" id="header-region"></div>
<div class="other-content"><p>Your order was completed etc...</p></div>

Line 1 is the important line, this is the 'empty' div, line 2 is for
clarification only as you will see in a moment.

When this is parsed by the whatever means you use to return the
payment response url line 1 is transformed into this markup:

<div class="clear-block" id="header-region" />

The problem being that browsers interpret this as a wrapping div hence
the resulting complete markup ends up as this:

<div class="clear-block" id="header-region" />
<div class="other-content"><p>Your order was completed etc...</p></div>
<div>

If I code line 1 above like this (a space):

<div class="clear-block" id="header-region"> </div>

It is NOT transformed in any way.

Can you confirm whether this is a bug or whether this is by design in
terms of your treatment of 'empty' divs and the if so the reasoning
behind it?

And their classic "feature not a bug" response...

Dear Chris,

Thank you for your email.

I am afraid that yes, this is a feature whereby we will requires you to include an empty space if your

tag doesn't contains any codes.

Please do not hesitate to contact us should you require our further assistance or clarification.

To answer your other questions:

- how does the confirmation page get generated, is it from the page.tmpl template as mentioned above (assuming yes
)
- the page is missing my cufon fonts etc and im assuming this is due to some missing CSS classes and/or JavaScript

The page is generated by an anonymous callback to your completion page by the RBS server, it grabs your completion page, does some parsing (as you've probably realised by now) and spits out the result, at this point the user is still on the RBS server... the next click takes them back to your site, incidentally we've started working on an idea to redirect users back to the source site automatically, see #371758

The 'parsing' that RBS does, although I have no proof, is probably responsible for your CSS and JS issues.

for above reasons I think it would be easier to provide a really simple page template of my own, how would I do that

See http://drupal.org/node/104316 - Using different page templates depending on the current path

Good luck!

hixster’s picture

hixster commented

Thanks for all the help Matason. I switched of all my blocks and customised the CSS a bit specifically for that page.
Thankfully Acquia prosper/fusion has custom id's per page, so quite easy. All working well now.

Many thanks.

thoughtcat’s picture

thoughtcat commented

I've had this problem in my site, where the "payment complete" message was squished into a sidebar (I'm using Analytic). I resolved it by turning off all blocks on the cart/worldpay/complete page so the "payment complete" text now appears fine in the page, at least in Firefox (8). In IE(9) however *ALL* styles drop off that page altogether :-(

The WorldPay URL is even different depending on the two browsers. In FF my complete page url is https://secure-test.worldpay.com/wcc/card and in IE it says https://secure-test.worldpay.com/wcc/card?Lang=en&DispatcherID=mm2imscs4...

I don't know if this makes any difference to configuring the solution "Using different page templates depending on the current path" but I've not been able to get my head round the instructions there tbh. Is there a simpler CSS solution for this?