V154 Still Getting Handshake Error After Upgrade

Rick5150:

Ah, it is looking for flatone.php...

So does this file actually exist? (probably not). That being the case you'll probably find that there is a file called flatone.php located in the /languages/english/modules/shipping folder. To get rid of the error you'll need to either replace the missing file, or remove this existing one. (these files are used in tandom).

This will have nothing to do with any SSL errors.

Cheers
RodG

This file did not exist in the new installation. I cannot remember if flatone.php is part of a module, but unless there was a old database reference, why would a new installation have the need for a file that does not exist in the original files?

Anyways, I added the file from my backup and PayPal express went straight through. No more white page. I think that the second time I imported everything, it seemed to 'take' better. Thank you for the help.

I contacted the customer who was most anxious about placing an order and had him try with the new site. It went right through.

I did not get a notification from the store or PayPal, but the transaction is not even showing in PayPal even though the balance show an increase in the amount of the order. Maybe this takes some extra time?

Is the order showing in your store? If so, what payment module does it say it was paid with?

I am not sure which module was used...

The invoice does say "Payment Type: PayPal Express Checkout (instant)"

The transaction only showed in PayPal a few moments ago - over 3 hours from when the order was placed.

PayPal is reporting that they've been having some server problems today:
https://www.paypal-notify.com/

I suppose that might explain the delay for it showing up in your account ... although it's quite unusual.

It looks like there are multiple and unrelated issues happening here. The orders are going through now and that part is solved.

As for thee e-mail notifications, I double checked my e-mail settings in ZenCart and they are the same as the previous installation, so everything should be fine, right?

Here is the kicker: I have sales -mails going to [email protected] with a forwarder pointing that e-mail address to [email protected]. I went to BlueHost to check the forwarder to make sure it is active and there is no longer one for [email protected]. The order was sitting there all by itself, meaning that hundreds of orders have been successfully forwarded, but this one was not forwarded. This unhooking of the forwarder had to be recent since mid-January or so. I just put my direct e-mail address in the "Send Copy of Order Confirmation Emails To" field, although I would rather have it go to a sales address... still nothing from PayPal though.

For many years I would get an email from the store with the subject line "[NEW ORDER] Order Confirmation No: ###]" and an additional notice from whichever payment gateway that was used - in this case, PayPal. Weird that in the midst of everything else that is going on with my site and store, other issues like this would be occurring simultaneously.

You'll have to of course recreate that forwarder yourself, and discuss its disappearance with your hosting company. That's got nothing to do with Zen Cart.

As for the [NEW ORDER] Order confirmation emails, in Admin->Configuration->Email Options you can set which email address to send "admin extra copy" of notifications to, for various different kinds of messages. And you can turn (most of) various messages on/off by setting to 1 or 0 respectively. All of those settings would have been preserved across versions because they're stored in the database. Nothing in the upgrade touches those settings.

Rick5150:

This file did not exist in the new installation.

That's because it isn't a standard part of ZenCart.

Rick5150:

I cannot remember if flatone.php is part of a module,

If I had to take a guess, I'd say it is/was a modified copy of the flat rate shipping module (flat.php)

Rick5150:

but unless there was a old database reference,

The problem/error has nothing to do with the database. (where did you get the idea that it was?)

Rick5150:

why would a new installation have the need for a file that does not exist in the original files?

Because it would have been a new installation plus some files from and older installation.

Rick5150:

Anyways, I added the file from my backup and PayPal express went straight through. No more white page. I think that the second time I imported everything, it seemed to 'take' better. Thank you for the help.

If you don't know what the 'flatone.php' payment module is used for it is probably best that you delete it again, and don't forget to delete the same named file in the /languages/modules/payments folder otherwise you'll be getting the same "No such file or directory" error that you previously reported.

As I stated previously, the /includes/modules/payments/filename.php files all have a corresponding file in the /languages/modules/payments/ folder (the names are the same, the contents and purpose of them are different).
These files need to be added or removed as pairs. If only one of the two files exist an error will occur.

Also as previously stated, the presence or absence of the flatone.php files will have no effect on the PayPal SSL handshaking in any way. What is/was happening in your case is that the error created is/was causing the PHP processor to 'die' before it even had a chance to load the PayPal modules.

If you are having a PayPal SSL error then it is a different problem with a different cause.

Cheers
RodG

Rick5150:

It looks like there are multiple and unrelated issues happening here.

Exactly.

Rick5150:

The orders are going through now and that part is solved.

One thing at a time. It is very rare for unrelated issues to have a common cause.

Rick5150:

As for thee e-mail notifications, I double checked my e-mail settings in ZenCart and they are the same as the previous installation, so everything should be fine, right?

In theory (and as long as it had previously been working) then Yes.

Rick5150:

Here is the kicker: I have sales -mails going to [email protected] with a forwarder pointing that e-mail address to [email protected]. I went to BlueHost to check the forwarder to make sure it is active and there is no longer one for [email protected]. The order was sitting there all by itself,

So that explains yet another problem.

Rick5150:

meaning that hundreds of orders have been successfully forwarded, but this one was not forwarded. This unhooking of the forwarder had to be recent since mid-January or so.

This has nothing to do with ZenCart or its updates (I assume that you know that though?)

Rick5150:

I just put my direct e-mail address in the "Send Copy of Order Confirmation Emails To" field, although I would rather have it go to a sales address... still nothing from PayPal though.

Emails from PayPal are sent to the account that you set up with PayPal. As with your forwarding, this isn't a ZenCart problem.

Rick5150:

For many years I would get an email from the store with the subject line "[NEW ORDER] Order Confirmation No: ###]" and an additional notice from whichever payment gateway that was used - in this case, PayPal.

DrByte will probably need to set me straight on this, but it is my understanding that PayPal only sends emails to the store owner when using the old/obsolete IPN method. When the express checkout is used the emails a generated by the store.

Rick5150:

Weird that in the midst of everything else that is going on with my site and store, other issues like this would be occurring simultaneously.

Yes, quite weird and unusual, but not totally unheard of. Having said that, what often happens is that these unrelated issues actually occur at different times (and for different reasons) but can often go unnoticed until yet another problem pops up which leads to finding the previously unnoticed errors and an assumption is then made that all the problems are somehow related.

Cheers
RodG

PS: Is anyone (Bluelion, Royaldave?) in this thread still having a problem with the PayPal Handshake (as per the subject line?). It appears that this thread has gone off in a completely different dircetion.

Thank you for the responses.

RodG:

If I had to take a guess, I'd say it is/was a modified copy of the flat rate shipping module (flat.php)

I believe you are correct. Now that you mention it, that seems familiar. Thanks!

RodG:

The problem/error has nothing to do with the database. (where did you get the idea that it was?)
RodG:

Because it would have been a new installation plus some files from and older installation.

I thought that because I installed a clean version of ZenCart, and the only thing that it shared with the 1.5.1 version is the database. I do not understand how these "older installation" files could be part of a clean installation unless there was some reference to the PayPal Express module somewhere in the database. I guess I was wrong, but it makes zero sense as to where the flatone.php reference came from otherwise. Other than the configure.php files there was nothing from the old installation.

RodG:

If you don't know what the 'flatone.php' payment module is used for it is probably best that you delete it again, and don't forget to delete the same named file in the /languages/modules/payments folder otherwise you'll be getting the same "No such file or directory" error that you previously reported.

But the problem is that I get a blank white page without the flatone.php file. After I copied it over to the new installation, I got a message stating that the file was missing from the /languages/modules/payments folder, so I had to add that one as well to get the sale to go through. Neither were there. Deleting these files will put me right back where I was with a blank page.

RodG:

Emails from PayPal are sent to the account that you set up with PayPal. As with your forwarding, this isn't a ZenCart problem.
RodG:

This has nothing to do with ZenCart or its updates (I assume that you know that though?)

I completely understand it has nothing to do with Zencart and tried to explain that it was an e-mail forwarding issue for exactly that reason.

RodG:

Yes, quite weird and unusual, but not totally unheard of. Having said that, what often happens is that these unrelated issues actually occur at different times (and for different reasons) but can often go unnoticed until yet another problem pops up which leads to finding the previously unnoticed errors and an assumption is then made that all the problems are somehow related.

That makes sense.

RodG:

Also as previously stated, the presence or absence of the flatone.php files will have no effect on the PayPal SSL handshaking in any way. What is/was happening in your case is that the error created is/was causing the PHP processor to 'die' before it even had a chance to load the PayPal modules.

Yes, that is correct but I had no way of knowing that the SSL handshake error was fixed after I did the clean install the second time because I could not get to that point in the error checking process due to the "flatone.php" issue.

EDIT: Just for reference, the customer order was placed via PayPal Express at 5:44am EST and the PayPal notification finally came through at 1:03pm - over 7 hours later, but it came...

Rick5150:

I thought that because I installed a clean version of ZenCart, and the only thing that it shared with the 1.5.1 version is the database. I do not understand how these "older installation" files could be part of a clean installation unless there was some reference ... somewhere in the database. I guess I was wrong, but it makes zero sense as to where the flatone.php reference came from otherwise.
Shipping and payment module names are indeed cached in the database. That cache is reset when you visit the Admin->Modules screen.
So, yes, your old database was telling the store to still look for the non-existent module. Simply visiting the Admin shipping modules page would remove it because it was no longer physically present on the server.
This rarely affects people because most are upgrading those same modules in the admin as part of setup activity before transacting in the storefront.
We may consider deleting that cache as part of future upgrades, but that has its own downsides. Nevertheless this discussion does point out the need for us to investigate that. Thanks.