Supertex

Any idea why I might find a cache file with the name: "1_index_manufacturers_id_243Fsort3D4actgacdCAEYACoUMTA1NTU3MTUyOTgyNzM1NDUyNzEyHDAwMjJhMzdjMmVhZTBhNzI6Y29tOmVuOlVTOkwusgAFQjCNF6xHLbJF9lRbY36cOH5hX1yctcOA.cache" I've seen similar strings reported when a site has been hacked, but I can't find any evidence pointing to that. Why would this even exist?

Apologies. I caught the ascending -> descending change, but I missed the $sort_id change. However, I posted this inappropriately anyway; I should have started a new thread. The V4 intl rate V2 module failed to apply insurance on my international shipping, (as seen here) so I have the 'original' USPS module in place (Methods V7.3.1), and it doesn't have that line of code in it. I know that module has lots of problems, but it works for the 3 methods I offer, and the insurance works. I'd resigned to the fact that I was stuck with it until Jim's 'Codes' module is in release. My thoughts in posting here were that there might have been a way to order it in checkout_shipping. I know wouldn't be the 'right' fix, but it would make for a temporary workaround. I'll reinstall V4 intl rate V2 and see if I still have issues with insurance. Thanks for putting up with my nonsense.

Thanks @a.forever. However, that would put Express Int'l on top in my case. Still, it would achieve my primary goal, which is to avoid the uninsured option being default...perhaps that would be enough. I have another question about how USPS (and other modules) handle address format alterations, but I think I need to put that in a different thread entirely.

Might be a good time for me to mention exactly what I'm doing. I'm trying to set two different default shipping quotes depending on a zone check. UPS Ground as the default domestic quote selection, and Priority Mail International for International. I have a check for continental 48 in checkout_shipping, and it's also defined in classes/shipping.php. To handle domestic, I set my UPS module's sort order to the top of the list. Then I used an if/else to set $cheapest[$i] to $cheapest[0] in the shipping class file IF the zone check returns true for the 48 states. Else, for international, it reverts back to $cheapest[$i]...which still sorts based on the cheapest quote ...invariably First Class International Package. If I can find a way to put Priority at the top of the list, I can reverse things and use $cheapest[0] to handle international, and then use my switch to trigger the "default shipping method" addon for domestic, in which I can define UPS. That should default to ground. It's just trying to figure out how to snag 'the middle quote' that has me vexed.

@@kymation Hi Jim, This is perhaps slightly off topic, but you're the go-to guy for USPS, so, I'm hoping you'll throw me a bone. I only allow First-Class International Package, Priority Mail International, and Priority Mail Express International. FC is uninsured, so I'd like to default to Priority mail. But since FC isn't viable for orders over $400.00, Priority Mail isn't always the second choice in the list...so I can't use the admin sort order to put USPS at the top and then use $cheapest[1] in place of $cheapest[$i] to select the second option. Is there a way to define this in checkout_shipping somewhere? Or perhaps alter the output of the includes/modules/shipping/usps.php, so that it isn't ordered by ascending price?

Bob to the rescue! Thank you so much for the reply. A bit there to digest, but I'll get on it and see what I can make happen. As far as commenting out the customer return,that's something I was considering, but was unsure of what side effects might come of it. As trier mentioned...the comments are not handled by the IPN, and I do use the comments section often, so I don't know. Leaving town for a few days tomorrow, but I'll hit this when I get back. Again, thank you very much.

Had another occurrence of something else that I've had happen a few times: A disappearing order. It's not an issue with a null or zero status ...the order just disappears from the database entirely. There was an IPN record in the logs, but no corresponding order. Now I think I -might- have a clue as to how this happens: Customer contacted me to ensure his order had been placed, because he'd gotten confused in PP's interface while trying to pay with CC. It seems he accidentally followed a link to apply for a PP credit card. Once he realized he was offtrack, he backed up, decided to pay with his PP account instead of a CC. His payment completed, but he was shown 'an error.' When he checked his PP account, he confirmed that I was sent his payment. So he contacted me and I found no order - even running queries for the order number in multiple tables. I refunded him in PP, and the refund showed up in the app logs too, but no record of the transaction other than that. So...what happens in this scenario? What conditions must be met in order for a customer return/IPN to delete an order? If there was an error at paypal, why did the order status not simply remain "pending"? Is it possible that because he navigated away from the normal 'path' of payment, that it flagged the order as having been subject to tampering?

I sincerely wish I could be more help than "holding the flashlight", heh.

Feature request (not sure I've seen this mentioned already): Non USPS insurance -

It's me again =P I just noticed that the quantity discounts module doesn't seem to be working with my install of Create Account & Manual Order Maker. I see that an early revision of your module introduced compatibility. I feel sure the two worked together on my site at the time I installed it. Do you happen to know what version of order editor the compatibility was established with? I don't know if it's changed or I broke it somehow, but I'd like to fix it...I just have no idea where to start looking. When I create a new order, the quantity discounts module is totally ignored, it seems.

I uninstalled, verified the USPS_codes table was empty, and then verified no %USPS_CODES% configuration entries. Reinstalled, added Webtools ID, saved. Then deselected all domestic methods except priority, saved again and got the white page with this: Notice: Constant FILENAME_FREE_SHIPPING already defined in /path/includes/filenames.php on line 85 Notice: Use of undefined constant choose_insurance - assumed 'choose_insurance' in /path/checkout_shipping.php on line 55 Notice: Undefined index: choose_insurance in /path/checkout_shipping.php on line 55 Notice: Use of undefined constant usps_codes - assumed 'usps_codes' in /path/includes/modules/shipping/usps_codes.php on line 105 Notice: Only variable references should be returned by reference in /path/includes/classes/xml_5.php on line 86 Fatal error: Cannot unset string offsets in /path/includes/modules/shipping/usps_codes.php on line 1932 Turning on Priority Express in addition to Priority restored page function, and changed the output to : Notice: Constant FILENAME_FREE_SHIPPING already defined in /path/includes/filenames.php on line 85 Notice: Use of undefined constant choose_insurance - assumed 'choose_insurance' in /path/checkout_shipping.php on line 55 Notice: Undefined index: choose_insurance in /path/checkout_shipping.php on line 55 Notice: Use of undefined constant usps_codes - assumed 'usps_codes' in /path/includes/modules/shipping/usps_codes.php on line 105 Notice: Only variable references should be returned by reference in /path/includes/classes/xml_5.php on line 86 Notice: Undefined variable: extra_name in /path/includes/modules/shipping/usps_codes.php on line 611 Notice: Undefined variable: extra_name in /path/includes/modules/shipping/usps_codes.php on line 611 Notice: Constant MODULE_BOXES_INFORMATION_BOX_CONTACT already defined in /path/includes/languages/english/modules/boxes/bm_information.php on line 21

Here's the output with the application_top modified as you instructed. It's huge, so I've attached it. UPSP_Codes_error_output.rtf

Here is an error email from today: The response from the USPS was empty. This could be a fault in the USPS server, or there is something very wrong with the request. Request: API=RateV4&XML=%3CRateV4Request+USERID%3D%22(omitted)%22%3E%3CRevision%3E2%3C%2FRevision%3E%3C%2FRateV4Request%3E Response: -2147221202Common:XmlParseThe element 'RateV4Request' has incomplete content. List of possible elements expected: 'RateClientType, Package'. Request: API=RateV4&XML=2 Response: -2147221202Common:XmlParseThe element 'RateV4Request' has incomplete content. List of possible elements expected: 'RateClientType, Package'. I don't know how to enable error display in template_top, but if you can tell me how, I will certainly make the changes. Also, I mispoke when I said having any single method would cause the page to go white. This morning, I went in and turned all methods off, and then turned them on one at a time. All of the FCM methods worked fine when they were the only method. The white page started with Library Mail Parcel. Beyond that, I checked Media Mail, & Priority Mail. But when I went to enable Priority Mail FR Env, the admin module lost everything after Standard Post...options disappeared, nothing for international, nada...the list just ends. There's not even a "save" button. So, I uninstalled, and reinstalled the module. I noticed that after it acquired methods, the list stopped after Priority Mail Express 1-Day™ Padded Flat Rate Envelope Hold For Pickup. Some of the options that were there before, including "Standard Post" are just gone from the list. But new methods like FCM Stamped Letter had appeared. So I guess they're still screwing with it.

I've been turning off methods that I don't use, and ran across a problem. For domestic, Priority Mail is the only option I offer. But when I do that, the shipping page goes entirely white, like the code is broken. As near as I can tell, it seems not to like only allowing one option. If I turn on Priority mail and ANY other domestic option, it works. But if I cut it back to a single option (regardless of which option, it seems) the screen goes white again. Another log for the fire. :)

@@kymation Out of the blue...with no updates to the files, USPS Codes is pulling rates now. I have yet to verify the pricing, but so far....

I just dropped .8 into my development directory, and if I leave admin set to residential...nothing shows at all on customer side. If I switch to commercial, then I see the "United States Postal Service" section, but no shipping types or prices. I did get emails for every time I refreshed the page. I'll attach the request as a text file, but the part that interested me was the last line: "-2147221202Common:XmlParseThe element 'RateV4Request' has invalid child element 'Package'." full text:usps_error_mail.txt I'm sure I've goofed something up here, but I'm not sure what it is. I used winmerge to modify the modules.php file, as mine had other modifications in place for the original USPS Methods contrib. My checkout_shipping is modified as well, but it seems like this produced more customer-side output last time I installed it.

@@Harald Ponce de Leon

Twice now, my store has had the customer's return from PP and the IPN both land at the exact same time. When this happens, stock is deducted twice. I'm no code whiz, but it -appears- that the catalog/ext/modules/payment/paypal/standard_ipn.php is missing the check that I find in catalog/includes/modules/payment/paypal_standard.php: // Before the stock quantity check is performed in checkout_process.php, detect if the quantity // has already beed deducated in the IPN to avoid a quantity == 0 redirect if ( $this->enabled === true ) { if ( defined('FILENAME_CHECKOUT_PROCESS') && (basename($PHP_SELF) == FILENAME_CHECKOUT_PROCESS) ) { if ( tep_session_is_registered('payment') && ($payment == $this->code) ) { $this->pre_before_check(); } } } I only noticed this because I happened to be watching when a customer purchased a quantity of 4 of one item. We had 7 in stock prior to his purchase. When his order completed, we had "-1". Then again yesterday, I looked at the orders section and found a large order (many line items) in which every line item's stock count was double decremented. I ended up having 4 products with negative quantities. I have the store set NOT to allow checkout while out of stock. And as I already mentioned, this ONLY happens when the customer's return and the IPN land at the exact same time. Also, I feel sure this is in the IPN file, as I have both catalog/includes/modules/payment/paypal_standard.php and catalog/checkout_process.php commented out in order to leave products "active" when stock reaches zero, instead of disabling them completely. I have not yet done this to the IPN file. Since I'm getting negative quantities, it seems the culprit must be the IPN file: //if ( ($stock_left < 1) && (STOCK_ALLOW_CHECKOUT == 'false') ) { //tep_db_query("update " . TABLE_PRODUCTS . " set products_status = '0' where products_id = '" . tep_get_prid($order->products[$i]['id']) . "'"); //} This has only happened twice so far, that I know of. But if it ever slips one past me, my inventory will be wrecked. I could sure use a hand here - I have no idea how this is happening.

I should have pointed this out earlier, but when double decrements occur, both the customer return and the IPN have the exact same timestamp, to the second.

This is also causing stock to go into negative figures, and in such cases, setting product to inactive. This, in spite of the fact that I have : // if ( ($stock_left < 1) && (STOCK_ALLOW_CHECKOUT == 'false') ) { // tep_db_query("update " . TABLE_PRODUCTS . " set products_status = '0' where products_id = '" . tep_get_prid($order->products[$i]['id']) . "'"); // } In both catalog/checkout_process.php & catalog/includes/modules/payment/paypal_standard.php

@@Harald Ponce de Leon Finding another problem that's intermittent. There are some instances where a customer makes an order, and stock gets decremented twice. I just happened to be watching as this happened. A customer bought 4 of an item...inventory qty was 7 before the sale. After the sale, inventory was -1. Normally, I see the customer's return from PayPal, with PayPal [Transactions], then our status update: "PayPal Complete" and then 15-20 sec later, there will be an entry for the IPN: PayPal [Transactions]. When I get a double decrement, I see the customer's return, then the IPN, then TWO status entries for "PayPal Complete." The logs don't show any duplicity. I don't understand what's happening, except it looks like the customer return and the IPN hit us at the same time. This is wrecking inventory.

Try adding it right after /* $Id$ osCommerce, Open Source E-Commerce Solutions http://www.oscommerce.com Copyright (c) 2014 osCommerce Released under the GNU General Public License */

@a.forever Thanks for the reply. I haven't posted back up to now, because I got hit by one of my manufacturers with the whole "you cant advertise our products that cheap" thing...so I've been neck-deep in a price obfuscation module install. I'll be back on this shortly. I dodn't want you to think I have no interest =P

@@Harald Ponce de Leon Few more anomalies: First: Had another occurrence of a paid order vanishing - not because of status_id / admin timeout. No idea what's happening here. When I query the DB for the invoice id from the paypal email, and the paypal app logs, the order simply does not exist anywhere in the database, in any table. The only place it shows up on the site at all is in the app log and the email from PayPal. 2nd: had an order where customer funding was on hold with paypal,...status within the order was "Pending", but it showed up in the orders list with the status assigned to "New Orders" per the app. If I hadn't been unusually observant, I could have shipped an unpaid order. How is the app supposed to handle a paypal payment status of 'pending' as opposed to 'completed'? Does it distinguish? See the image below: 3rd issue: Had email open when a paypal payment notification hit my inbox. That prompted me to check the orders list, as it was nearing the cutoff for same-day shipping time. There was no order...and it didn't show up for several hours after the payment cleared. I'm not sure if that is really a 'problem' but should it take that long for the IPN to hit the site and set new order status? And could this be part of the process of vanishing orders?

I wanted a way for customers with a UPS account to complete their order without adding on any shipping costs. I already had 'Store Pickup" installed and working, so I tried to clone it to 'freight collect'. I've gone in and renamed the "spu" and "_SPU_" to "fr_collect" and "_FR_COLLECT_" throughout the file, renamed the module and english files accordingly, and it appears to have installed correctly. I can install and uninstall without affecting the original. However, when I run a transaction, and select the freight collect module, it just loops me back around to checkout_shipping. I've no idea what I might have missed. Anyone done this, or run into a similar scenario?