Patched It
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
