Double First Name Stored In orders.OrderShipName

I've got a strange little quirk going on here and I'm assuming I caused it somewhere.

My transactions are going through just fine. Both with PayPal and with Credit Cards. But when the Orders show up in the database, in each case the OrderShipName field looks like this ...

Joe Joe Jones
Mary Mary Smith
Bill Bill Brown

I figure somewhere in all the pointing and clicking and code tweaking that somewhere I've got a variable that's not set right. It's either one of two cases ...

1) (Firstname + Firstname) + Lastname
2) Firstname + (Firstname + Lastname)

Either way, the end result is the same. Mike Mike Hunt :-)

I've picked through all the code very carefully and I don't see anyplace where it's doubled up like this. Anybody have any ideas?

The business is not suffering for this. I can easily go in and tweak the database after an order arrives. The order volume is not heavy yet but if it does pick up some steam, I'm not gonna wanna do this every day for dozens of orders.

Thanks, Bob Hunt

if you are using paypal payments pro, the order in formation gets stored to the database on the Confirm page, go the the server behaviors panel, and double click the store Order Summary behavior and rebind the OrderShipName column to the eCartCheckoutForm_shipping_firstname session variable.

if you are using paypal express checkout, the eCart store order summary behavior is on the PP_confirm page.

Okay, I fixed this bug on my site. Jason, you may want to dig into this a little deeper to see if it's systemic or perhaps something I did to myself and had to fix.

As I suspected, it was either a case of the OrderShipName column being filled with either ...

(First Name + First Name) + LastName or ...
FirstName + (FirstName + LastName)

It was the *second* one, that is, the last name field had already been pre-formed as a concatenation of firstname + ' ' + lastname somewhere else.

What tipped me off was your suggestion to rebind the eCartCheckoutForm_shipping_firstname session variable to the OrderShipName field in the eCart Store Summary In Database server behavior on the pp_confirm.php page.

Well, that session variable ... eCartCheckoutForm_shipping_firstname ... does *NOT* exist on my pp_confirm.php page. I looked everywhere for it in the behaviors panel and in the code itself and it's not there. There is a session variable called ... eCartCheckoutForm_firstname however. (Note the lack of the word "shipping".)

There is a session variable called ... eCartCheckoutForm_shipping_lastname ... but that variable is not copied from eCartCheckoutForm_lastname. Instead it gets turned over to a function call in PP_ECO_PHP.php using a token called "Name". I looked all thru the PP_ECO_PHP file and couldn't find anywhere where that "Name" token performed a concatenation of first and last name but I had a hunch that was where it was happening.

So now back to the pp_confirm.php page. The binding for the OrderShipName column in Store Summary in Database behavior originally looked like this ...

<?php echo (isset($_SESSION['eCartCheckoutForm_shipping_firstname'])?$_SESSION['eCartCheckoutForm_shipping_firstname']:$_SESSION['eCartCheckoutForm_firstname']); ?> <?php echo (isset($_SESSION['eCartCheckoutForm_shipping_lastname'])?$_SESSION['eCartCheckoutForm_shipping_lastname']:$_SESSION['eCartCheckoutForm_lastname']); ?>

Remember I said I don't have '_shipping_firstname' session variable but I do have a '_firstname' session variable so that means the first half of that code defaults to the '_firstname' variable, i.e, 'Joe'.

The second half of that code tacks on the '_shipping_lastname' session variable which I *do* have but remember I suspected it had been "magically" concatenated already into 'Joe Jones'. If my hunch was correct, this was where I was getting "Joe Joe Jones" written into the database.

So not knowing where the magic concatenation was happening, I decided to remove the first half of the block altogether leaving just this ...

<?php echo (isset($_SESSION['eCartCheckoutForm_shipping_lastname'])?$_SESSION['eCartCheckoutForm_shipping_lastname']:$_SESSION['eCartCheckoutForm_lastname']); ?>

Notice that now I'm just processing the magic "lastname" session variable given that I suspect it has already been pre-processed into "Joe Jones".

And so I ran a test with the OrderShipName bound to just the "magic" last name and sure enough that was it. I processed a test order and "Joe Jones" was written nicely into the database. Yippee !!!!!! Golf claps all around.

So now I'm happy but I'm still wondering if somehow I did this to myself or if this is a bug in the eCart code. I don't like tinkering with other people's code (especially code that I've purchased and could risk support warranty loss) so I didn't change anything of yours. All I did was put a workaround in place, that is, use the magic lastname only because it already was first + last name. That I did on *my* pp_confirm page.

But the mystery still remains ... Where did the magic concatenation happen?

Hope this makes sense and can help someone else.

Bob Hunt

when testing did you process a transaction by filling out the checkout page, then process another one using express checkout with out closing the browser between tests?


I bet the sessions created by the first test where still active when you placed the second test so where creating the double first name.

to prevent this you can destroy the session on the sucess page by adding the following code after the </html> tag:

<?php

// Initialize the session.

// If you are using session_name("something"), don't forget it now!

@session_start();



// Unset all of the session variables.

$_SESSION = array();



// If it's desired to kill the session, also delete the session cookie.

// Note: This will destroy the session, and not just the session data!

if (ini_get("session.use_cookies")) {

    $params = session_get_cookie_params();

    @setcookie(session_name(), '', time() - 42000,

        $params["path"], $params["domain"],

        $params["secure"], $params["httponly"]

    );

}



// Finally, destroy the session.

@session_destroy();

@session_regenerate_id();

?>

No, all tests done were singular with no predecessor or ancestor. Also, the very first *transaction* OrderID = 1 went in as 'Joe Joe Jones'. And it was consistent. *Every* order when in that way. I ran a weeklong beta with about 10 users and got about 30 orders entered and every single one of them was 'first first last'.

As for the session destroy code, I used to have that in there but I replaced it a few days ago with an Empty Cart behavior. The session destroy is a bit too much for my taste. Not only does it kill all the session variables, it also logs you out in doing so. I don't want them to have re-login just because they bought something. So I switched to emptying their cart and letting them stay logged in as long as they want.

Thanks for your help so far on this but I'm still of the opinion that the bug is something is "automagically" concatenating first + last name and then sticking it into the '_session_lastname' variable which is causing the "echo" affect.

Is anyone else seeing this happen on their sites?

I have created a support ticket so we can look into this issue further.

To view and edit your support ticket, please log into your support history:
supporthistory.php

If anyone else is experiencing this same issue, please append to this thread.