Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

TomB01

Members
  • Posts

    414
  • Joined

  • Last visited

  • Days Won

    3

TomB01 last won the day on July 17 2022

TomB01 had the most liked content!

About TomB01

  • Birthday 12/24/1954

Profile Information

Recent Profile Visitors

10,122 profile views

TomB01's Achievements

  1. Mine works with TM and the changes recommended by Smoky Barnacle above. BTW, if you edit the database "configuration" table directly to change the 1st Class Package string to USPS Ground AdvantageTM in the Types field, you don't have to do all the ridiculously tedious uninstall and re-install of the USPS shipping module. That's all the uninstall and re-install do, btw - is populate the correct values in the database to match the strings in the usps php file.
  2. Here's the latest version I have - USPS Rate V4 Intl Rate V2_r3.6. USPS Rate V4 Intl Rate V2_r3.6.zip
  3. See my post above. Go into phpMyAdmin on your Internet Host's Control Panel (or whatever they use) and access your oscommerce MySQL database. click on the "configuration" table and scroll through all of the lines to find the USPS keys. There's a bunch of them and my configuration is 30+ lines now, so it may take you a while. Don't get mixed up with UPS keys, if you have them. Anyway, find the MODULE_SHIPPING_USPS_TYPES key, click on the "configuration_value" column for that key, and edit out the TM values to "RM." You need to be very careful doing this, because you can blow up the database if you mess something else up. Unless you are fairly confident with phpMyAdmin, the safer way is to uninstall and re-install the USPS shipping module, as suggested earlier. You do that in the oscommerce Admin Control Panel. Login as Admin to your store and the Admin Control Panel (or whatever you may be calling it). Look for Modules->Shipping. Click on "- Remove Module." After you've done that, go right back and click on "Install Module," select "USPS," and install it. WARNING: Print out all of your USPS settings on the right hand side of the page before you uninstall the module. I believe you're going to have re-edit all of those settings when you uninstall and re-install the module. That's why I went for manually editing the database, but as mentioned - that can be dangerous if you're not confident about what you're doing. P.S. I'm running Phoenix, so your mileage may vary from that description above.
  4. Many, many thanks for this. I changed all the Priority MailTM, Priority Mail ExpressTM, and Priority Mail Express InternationalTM to "RM", but it didn't work. Saw your post and changed the items in the key MODULE_SHIPPING_USPS_TYPES of the configuration table with phpMyAdmin, and everything worked - no need to uninstall and re-install the USPS module. It's great to see that the legacy oscommerce forum stuff works. I didn't know about this, although I've had a customer or two order with UPS shipping options (the only shipping working, unbeknownst to me). I thought that was strange, but sometimes customers choose higher rates for their own reasons. However, I got an e-mail this morning because I had subscribed to this thread. I hadn't logged into the oscommerce forum in over a year, but got all of this fixed in about a half-hour. YAYYY! P.S. Still stuck on Phoenix 1.0.5, but I guess that's another whole story ... and forum, too!
  5. Thanks for replying, John. I'm running Phoenix 1.0.5.0. You actually gave or told me how to modify the orders_edit_order.php file back on 12/24. I think you uploaded it all in your 1.2.8 version. Note that your later versions after Denkster still can't be found on the Apps Marketplace. I went searching earlier this morning and couldn't find anything. This worked at the time, when I installed this from you: Somewhere along the way to 1.0.5.0 and Supporters Code updates, I lost the Edit button again, but don't know when - or obviously, how.
  6. I discovered recently that my "Edit" button has disappeared from my Order Details view in Admin, where the order's Summary, Products, and Status History are displayed. I checked by toggling the Edit button feature in the Order Editor configuration and the Order Editor is functioning correctly. I normally do not like to have that Edit button in the orders list view go directly to an order editing screen, but to the orders detail screen, instead. So, I typically have that feature disabled in the configuration. However, I get no "Edit" button at all in the order details view. I first noticed this because the Details box has the following characters displayed erroneously at the bottom left of each Summary, Products, and Status History box: " '); " I traced these three characters to this code in the HTML for orders.php when displaying the order details in Admin: Sure enough, what little I can interpret is that string of script code controls the appearance of the "Edit" button in the order details view. I suspect those ending characters are invalidating the script code. I believe that script should end in only " </script> " instead of " </script>'); " Can anyone direct me to which file that script is developed, so that I can try to find the error? I've checked orders.php and edit_orders.php and it doesn't appear that any of that code is included in those files. My orders.php file was somehow modded, because I have it archived under a "FixEditButton" folder. Unfortunately, it doesn't appear that I commented the code and I can't remember what was done. 😕
  7. @dculley, Your first one up there had a red period before "key" in "configuration_key". Maybe it was a copy-paste thing?
  8. Here is the post with the SQL (on the previous page):
  9. Yes, of course! Please note my previous posts. There are two SQL statements included that you need to poke the appropriate values into the configuration table. They are in my most recent posts (typing this on the phone right now, or I'd copy them again for you).
  10. @dculley I'm sorry - this is beyond me. As for the "(;" I see something similar at the bottom of my Order-Summary-Products-Status History-Paypal page, but it seems innocuous, so I left it alone. It's some sort of trailing code that the PHP is not recognizing. Hopefully, someone else will have some suggestions. Keep me in mind if you end up willing to pay someone to do a USPS module for Phoenix. I might be able to chip in something. EDIT: The other possible issue is going well beyond Phoenix 1.0.5.0. The changes they made in going to 1.0.5.1 were severe. It's why I stopped at 1.0.5.0. I'm not sure we can even make the shipping modules work under the newer changes.
  11. @dculley modulesphx.php shows this from lines 40 to 47: foreach ($_POST['configuration'] as $key => $value) { if (is_array($value)) { $value = implode(';', $value); } $key = tep_db_prepare_input($key); $value = tep_db_prepare_input($value); tep_db_query("UPDATE configuration SET configuration_value = '" . tep_db_input($value) . "' WHERE configuration_key = '" . tep_db_input($key) . "'"); modulesyours.php shows this from lines 35 to 47: foreach ($_POST['configuration'] as $key => $value) { /* kymation mod for Phoenix (11/26/2019) - https://www.oscommerce.com/forums/topic/383307-usps-rate-v4-intl-rate-v2-official-support-thread/?do=findComment&comment=1793962 */ // if( is_array( $value ) ) $value = implode( ', ', $value ); //End kymation mod for Phoenix // /* Updated mod in greasemonkey post (11/30/2019) - https://www.oscommerce.com/forums/topic/494460-ups-xml-17-for-phoenix/?do=findComment&comment=1799248 */ if (is_array($value) ) { $value = implode( ", ", $value); $value = preg_replace ("/, --none--/", "", $value); } // End greasemonkey mod // Continued from line 36 USPS V4 tep_db_query("update " . TABLE_CONFIGURATION . " set configuration_value = '" . $value . "' where configuration_key = '" . $key . "'"); Except for the comments, they are essentially the same, except for these two lines: $key = tep_db_prepare_input($key); $value = tep_db_prepare_input($value); There was an additional line included by ecartz in the version that I use, but it was mainly applied by user greasemonkey when he was trying to get UPS XML to work. I've tried it both ways on my installs and it doesn't seem to make a difference, but I kept it just in case. So, the operative code is this in the NEW Phoenix modules.php: if (is_array($value)) { $value = implode(';', $value); } Whereas, we were previously including this: if (is_array($value) ) { $value = implode( ", ", $value); $value = preg_replace ("/, --none--/", "", $value); } Without knowing exactly what these changes mean, it appears to me that the newest Phoenix version included the corrective code in the modules.php file by default, except for that seemingly superfluous code ecartz suggested for greasemonkey: $value = preg_replace ("/, --none--/", "", $value); The newest Phoenix modules.php includes those new "$key" and "$value" statements above, but those are assigning variables, so I'm not sure there going to interfere with anything (probably something with the Hooks call). My guess is that you should simply try the newest Phoenix modules.php file - without editing anything - and see if it works. Do you have a test store installed? If not, I'd work on that so that you can simply test these things without worry of crashing your live store. Try it and see if it works. As stated, there's definitely extra code and features in the newest modules.php file. However, it appears that Burt and crew have included the important "if (is_array($value)) { $value = implode(", etc., correcting code as standard in modules.php now. Remember that the only thing that this modules.php correction changed was how the module settings in Admin were saved. Without that code (it appears it's included by default, now), if you went to change/edit the module settings in Admin, it would lose/change all the configuration values for the usps.php module. Worst case, you could manually punch those values back into the configuration table in phpAdmin. (Granted, that would be a lot of work for the USPS module, because there's a ton of settings.) If you try it and it doesn't work, maybe we can elevate this to ecartz or someone else and see if they can figure it out.
  12. The only part you insert is that part bounded by the comments for "//Correction …" and "//End correction …" // //Correction for legacy shipping modules // if (is_array($value) ) { $value = implode( ", ", $value); $value = preg_replace ("/, --none--/", "", $value); } // //End correction for legacy shipping modules // Use the rest of the code that I pasted in with that to find the proper place in the modules.php. IOW, look for this section: if (tep_not_null($action)) { switch ($action) { case 'save': foreach ($_POST['configuration'] as $key => $value) { Insert the "//Correction - //End correction" code on the next line after the last "{" shown immediately above. Go back up to my previous post if you don't understand, and look for where that "//Correction - //End correction" code is placed.
  13. Well, you're way ahead of me. I stopped at 1.0.5.0 and am waiting until 1.0.6.0 to upgrade. That said, this is the section of code that is in the modules.php file (/catalog/admin/) that has the corrections. I insert the lines bordered by the comments into the modules.php file, every time I load a new update to Phoenix. I don't think it really matters if there are other changes to the file, as long as the section below stays the same. If you don't insert the commented code below, when you attempt to set the parameters for the shipping module in Admin, you'll lose all of the settings and future attempts won't save it back to the database. (IOW, it becomes corrupted.) The code that I insert is bordered below by the "Correction/End Correction for legacy shipping modules" section (it also applies to UPSxml add-on and I think the FedEx Web services add-on): if (tep_not_null($action)) { switch ($action) { case 'save': foreach ($_POST['configuration'] as $key => $value) { // //Correction for legacy shipping modules // if (is_array($value) ) { $value = implode( ", ", $value); $value = preg_replace ("/, --none--/", "", $value); } // //End correction for legacy shipping modules // tep_db_query("update configuration set configuration_value = '" . $value . "' where configuration_key = '" . $key . "'"); } tep_redirect(tep_href_link('modules.php', 'set=' . $set . '&module=' . $_GET['module'])); break; case 'install': case 'remove': $file_extension = substr($PHP_SELF, strrpos($PHP_SELF, '.')); $class = basename($_GET['module']); if (file_exists($module_directory . $class . $file_extension)) { // include lang file include($module_language_directory . $language . '/modules/' . $module_type . '/' . $class . $file_extension); include($module_directory . $class . $file_extension); $module = new $class; if ($action == 'install') { if ($module->check() > 0) { // remove module if already installed $module->remove(); } $module->install(); $modules_installed = explode(';', constant($module_key)); if (!in_array($class . $file_extension, $modules_installed)) { $modules_installed[] = $class . $file_extension; } tep_db_query("update configuration set configuration_value = '" . implode(';', $modules_installed) . "' where configuration_key = '" . $module_key . "'"); tep_redirect(tep_href_link('modules.php', 'set=' . $set . '&module=' . $class)); } elseif ($action == 'remove') { $module->remove(); $modules_installed = explode(';', constant($module_key)); if (in_array($class . $file_extension, $modules_installed)) { unset($modules_installed[array_search($class . $file_extension, $modules_installed)]); } tep_db_query("update configuration set configuration_value = '" . implode(';', $modules_installed) . "' where configuration_key = '" . $module_key . "'"); tep_redirect(tep_href_link('modules.php', 'set=' . $set)); } } tep_redirect(tep_href_link('modules.php', 'set=' . $set . '&module=' . $class)); break; } } Note that as mentioned in an earlier post up there, you must add these items to the configuration table in the database: Also note the change recommended by ecartz that I had to add to the usps.php file (line 126): Anyway, see if that works -
  14. @ecartz and @BrockleyJohn, I greatly appreciate you both adding to the thread and offering suggestions! I agree that USPS regularly breaks the API from time-to-time. That's definitely been the history since I've been using OsCommerce, over a decade ago. However, this is not new. @ArtcoInc had the very same issue a couple of pages back in this thread, in early September of 2019: About the only difference is that his error message says line 132; mine is line 126 - but it's the same foreach statement. I implemented the very first suggestion that @ecartz made like so: foreach (($Package['ExtraServices']['ExtraService'] ?? []) as $key => $val) { That appears to have worked! As BrockleyJohn said, maybe it was just a warning (but horribly presented to customers) and it looks like it's now suppressed. MANY THANKS!
  15. OK, it's not the USPS server. The error is 100% consistent and repeatable this morning on my live store: Warning: Invalid argument supplied for foreach() in/***/***/***/***/catalog/includes/modules/shipping/usps.php on line 126 The foreach loop in the usps.php file is as posted above: 126. foreach ($Package['ExtraServices']['ExtraService'] as $key => $val) { if ( is_array ( $val ) && array_key_exists ( 'ServiceName', $val ) && isset ( $iExtras[$val['ServiceName']] ) && tep_not_null($iExtras[$val['ServiceName']]) && ((MODULE_SHIPPING_USPS_RATE_TYPE == 'Online' && $val['AvailableOnline'] == 'True') || (MODULE_SHIPPING_USPS_RATE_TYPE == 'Retail' && $val['Available'] == 'True'))) { $val['ServiceAdmin'] = $iExtras[$val['ServiceName']]; $Services[] = $val; } This only happens on International addresses, not domestic (US) ones. The ExtraServices are as follows: Registered Mail, N, Insurance, N, Return Receipt, N, Restricted Delivery, N, Pick-Up, N, Certificate of Mailing, N As can be seen, I've selected NO (N) ExtraServices. The error is printed 12 times ahead of drawing in the checkout_shipping.php page on the browser. Once the checkout_shipping.php page is drawn in, there are 3 USPS quotes, and a couple each of UPS and FedEx quotes, now all showing correctly. I guess it's going through the foreach loop 12 times, which is why the error message prints out that many times. As best I can tell using file comparisons, etc., the files and database settings on both my live store and test store are identical, but only the live store shows the errors. In addition, I am manually re-writing the admin/modules.php file with each Phoenix update (I'm at 1.0.5.0) with the following code inserted: // //Correction for legacy shipping modules // if (is_array($value) ) { $value = implode( ", ", $value); $value = preg_replace ("/, --none--/", "", $value); } // //End correction for legacy shipping modules // Ideas? Help?
×
×
  • Create New...