Stamps.com getting error while importing

OK so live and learn and read the post more thoroughly, I found the above was generating log errors and not very practical having to open a connection to the database just to utilize the newer MySQLi equivalent functions it was an experiment. I wound up changing the MySQL statements to $db->prepare_input as indicated above by Lat9 and this seems to be working much better and not generating any log errors.

My question now is does this still give you the same level of protection from things like SQL injection etc as the old mysql_escape_string() depreciated functions did?

attached is the fully modified and working test version using ($db->prepare_input) instead with zencart 1.5.5e and php 7.0

I recently upgraded my site from 1.5.1 to 1.5.5. The process involved building the new store on a new server. Everything seemed to be working perfectly, so went live and started accepting orders in the new store. When it came time to import the orders into my stamps.com software. (Using the latest software version on my machine here, not the web based stamps.com app) I keep getting the error of "no new orders".

My database specs-
PHP Version 7.0.27-0+deb9u1

The error that is coming up in my log files-

 [06-Apr-2018 08:43:10 America/New_York] PHP Fatal error:  Uncaught Error: Call to undefined function mysql_real_escape_string() in /usr/local/4admin/apache/vhosts/site.com/httpdocs/zen/admin/stamps.php:829
Stack trace:
#0 /usr/local/4admin/apache/vhosts/site.com/httpdocs/zen/admin/stamps.php(847): GetCountryID('United States')
#1 /usr/local/4admin/apache/vhosts/site.com/httpdocs/zen/admin/stamps.php(493): GetStateCode('United States', 'Indiana')
#2 /usr/local/4admin/apache/vhosts/site.com/httpdocs/zen/admin/stamps.php(385): WriteOrder(Object(queryFactoryResult))
#3 /usr/local/4admin/apache/vhosts/site.com/httpdocs/zen/admin/stamps.php(176): Action_GetOrders()
#4 {main}
  thrown in /usr/local/4admin/apache/vhosts/site.com/httpdocs/zen/admin/stamps.php on line 829

I've been talking to stamps.com about the issue and at the moment its at their "level 2" support department and has been for about a week. I was hoping to see if anyone has had the same issue and might be able to offer some insight? Surely with the upgrades to 1.5.5/the new PHP version that uses "mysqli" statements someone has run into this?

I'm leaning towards the zencart plugin for stamps.com needing to be updated? (I'm using the one that's available from stamps.com)

But what's really strange is I have been manually printing the orders and updated my zencart admin to mark the orders as shipped. After doing a few orders, I tried importing them, and got about 15 to successfully import into stamps.com (yet not all of the orders that needed to be imported) However the post back by stamps.com to zencart to mark them as "shipped" and add the tracking number did not work.

Thanks in advance for any help!

Free or paid stamps.com account? If paid, you might consider shipstation which is owned by stamps.com no plugin to keep updated, since it is browser based interface and postage should transfer since it is purchased using stamps.com login.

The last time stamps.com referredmy issue to tier 2, received an answer 9.5 months later. 9 months after swiching to shipst########

Thanks so much for the input, yikes on how long it took tier 2 to get back to you!

I have a paid stamps.com account, didn't know there were free ones. I've looked shipstation, it might be an option. Stamps.com has been working out really well for me, so I'd like to stick to it if possible.

Actually that's not it.... Here are the changes

Around line 829 find

mysql_real_escape_string($country_name));

change to

zen_db_input($country_name));

Then around line 856 find

mysql_real_escape_string($country_id),
mysql_real_escape_string($state_name));

Change to

zen_db_input($country_id),
zen_db_input($state_name));

~Melanie

Hello everyone,

After updating PHP to 7.1, I was also getting this same issue. Melanie's suggested edits fixed the issue of the orders importing into the Stamps.com software. Thanks so much for that! Stamps.com support was no help.

Now, although the orders import into stamps.com, it is no able to postback updates to zen-cart. Which means I still have to manually update the order. Any ideas?

Thanks for reviewing this. I really appreciate it guys.

Mike

Someone mentioned an error on PHP 7, and I see that there's a fix needed for using PHP 7.2 or newer.
Updated zip attached (taken from Stamps.com site download, applied the mysql_xxxx function fix and the while/each-to-foreach fix for PHP 7.2+).

Their original download, and install instructions are at: https://stamps.custhelp.com/app/answers/detail/a_id/1204/r_id/100233

Does this still work? It seems like Stamps is trying to get people to upgrade to ShipStation now.

swguy:

Does this still work? It seems like Stamps is trying to get people to upgrade to ShipStation now.

As of today....my orders no longer import, even with Dr. Byte's updated PHP file. I cannot go to ShipStation - they price on volume, and my volume is way too high, it would cost me thousands of dollars per year. Is there any other option that works with ZC, like PirateShip?

Are any PHP errors logged, either as /logs/myDebug-adm-xxxxx.log files, or generally in your server's error logs?

DrByte:

Are any PHP errors logged, either as /logs/myDebug-adm-xxxxx.log files, or generally in your server's error logs?

There's nothing in /logs/ with that filename. I'd have to ask my web person to look in the server logs, as I have no idea what I would be looking for.

DrByte:

Are any PHP errors logged, either as /logs/myDebug-adm-xxxxx.log files, or generally in your server's error logs?

Running ZC 1.5.7 and PHP 7.2

DrByte, I spent a lot of time with my web person this afternoon trying to figure this out. She couldn't find any PHP errors specific to stamps.php or stamps.com; however, we did discover this:

Friday, October 30 was the last day I imported orders to stamps.com using the stamps.com software.
Saturday, October 31, I changed my password (it's set on a 90 day cycle).
Monday, November 2, I was unable to import orders.
Today, while speaking with her, I was shipping packages. Some of the shipments were orders that had been imported last week. I shipped against the imported record and the corresponding order in ZC was updated with the tracking information and the status of "Delivered".

So, we know that stamps.com is able to write back to ZC, but stamps.com is not successfully extracting new orders from ZC.

We saw the shipstation error thread and wondered if the same issue existed with the stamps.com error I'm experiencing, so we added the following lines to english.php:
define('DATE_FORMAT_SHORT', '%m/%d/%Y'); // this is used for strftime()
define('DATE_TIME_FORMAT', DATE_FORMAT_SHORT . ' %H:%M:%S');

There was no change in the performance.

We're still scratching our heads as to what changed on Saturday - so I did change my admin password, since we thought the ^ character might be giving ZC fits. No change. This next part is important, I think - because I put in an entirely fake password in the stamps.com data connection setup and it did not error out.

No errors are generating in the admin activity log or any other error log she can see. I'm using your updated stamps.php file and it's been working fine - up until Monday, November 2, when stamps.com stopped importing orders.

Any ideas?

I wouldn't have expected it to be able to go "either" direction if the issue is really password-related.

The fact that there are no error logs only indicates there are no PHP errors. Doesn't mean anything about logic errors/problems.

Before I reauthorized access to the ZC database in the stamps.com program, I again attempted to import orders. It still reported no new items (although I received several orders overnight). Then, I reauthorized access with the new "old" password, and waited an hour. It still gives the no new items message.

Huh. This morning, it started importing again, like magic. I have no idea, other than maybe stamps.com was having issues (no, really? Like normal!) and they fixed something. At any rate, it works now.

I have seen this exact scenario multiple times with stamps. Not sure what the root cause is - maybe caching on their side?

As it turns out, I a client of mine just spoke with stamps and they acknowledged they had an issue on their side.

Any idea if they have rectified the problem?