Jump to content

TomB01

Members
  • Content count

    386
  • Joined

  • Last visited

  • Days Won

    2

Reputation Activity

  1. Like
    TomB01 got a reaction from Mac2256 in From Frozen to Phoenix   
    Oh no - so sorry for that.  I hope that your business returns soon.
  2. Like
    TomB01 got a reaction from Mac2256 in From Frozen to Phoenix   
    Oh no - so sorry for that.  I hope that your business returns soon.
  3. Like
    TomB01 got a reaction from valquiria23 in From Frozen to Phoenix   
    I don't think we are trying to be discouraging; just realistic.  It's not actually a fair assessment.  I can only speak for myself, but I have at least 3 add-ons whose original developers are either long gone, or refuse to support the newer changes required.  If I lose one particular add-on (USPS shipping), I'm out of business. So, if I applied the 5-10 minute upgrade, it could result in days or longer before getting help with an error.  Meanwhile ... if I beg for help, I get responses suggesting that I pay for an outside developer to fix things.  If I could pay for an outside developer, I'd never have gone with OsCommerce in the first place.  (I've actually paid for something in the past, but never got anything for it.)
    Yeah, if we back things up we can put it back in short order, but that's still scary as hell with a live store.  Sometimes, even after checking as extensively as you can, things break a week or two later on something you never predicted.  Meanwhile, you've had some new orders and new customers added to the database.  How do you go back to the backup then?  Perform an incremental database update/conversion again?  Your store is broken and it might even be in the database.  Heck, I'm taking a chance just going with Phoenix as it is.  What do I do when USPS changes something again?
    Please understand.  I didn't set out to complain.  Phoenix is a wonderful project and I'm 100% behind it and you.  But you seem to be asking where these views come from. 😉
     
    EDIT: Just to be clear, all those Russian fake user accounts with 2.3.4 was driving me crazy.  Phoenix and the Supporters Code stopped that completely (well, I've had one in about a month - used to get 6-12 per day).  So, taking the chance with Phoenix has been very, very, well worth it.  There's just some nagging worries that continue ...
  4. Like
    TomB01 reacted to ecartz in FedEx - Web Services v9   
    If it is traversable, then replacing line 313 with
    $cost = (reset($rateReply->RatedShipmentDetails)->ShipmentRateDetail->TotalNetCharge->Amount)/MODULE_SHIPPING_FEDEX_WEB_SERVICES_CURRENCY; might work. 
    Setting it to List and explicitly casting to array might work. 
    foreach ((array)$rateReply->RatedShipmentDetails as $ShipmentRateDetail) I'm not sure what line that is, but it is before 313 and I just added (array) to it. 
    In a test store (not a live store, as it would break it), you could add
    var_dump($rateReply->RatedShipmentDetails); exit(); just before line 313 and see what it says.  Try twice, once each for domestic and international. 
     
  5. Like
    TomB01 reacted to BrockleyJohn in NEW! Complete Order Editing Tool!   
    The code checks which config group ORDER_EDITOR_USE_AJAX is in but it doesn't check if there's more than one occurrence of it (hence my original question).
  6. Like
    TomB01 reacted to BrockleyJohn in NEW! Complete Order Editing Tool!   
    I guess you have been installing and uninstalling. You have somehow added the new settings to config group 18 instead of 19.  Simply edit the config group for the second and last rows to 19.
  7. Like
    TomB01 reacted to raiwa in Featured Products BS   
    Hello Tom @TomB01,
    Featured Products CE v2.1.0r1 still uses the deprecated setting:
    Admin : Configuration : Product Listing : Product Image (defunct)
    You have to leave this setting set to 1
    This will be fixed in the next update.
  8. Like
    TomB01 got a reaction from Dan Cole in Upgrade Path TO Phoenix   
    Dan is correct and glad you found the solution.
    To others - if this will help - take a look at that error message that Krisz1 got:
    I'm sure this is like explaining 2+2 to some of you, but when I saw similar messages, I keyed on the "Unknown column" part.  That tells you there's a field (column) missing in the database table the follow-on SQL statement is trying to access.  Then I looked in the SQL "Select" statement for the "from" word.  The name that comes after the "from" word in the SQL statement is the database table.  You will also see the "products_gtin" field name in the collection of field names that the "Select" statement is trying to gather.  So in this case, "products p" looks like the source table for the SQL statement.  I don't know enough about SQL to know if the comma after that is specifying another table.  I also don't know what the "p" means at the end of "products," or at the beginning of the field (column) and table names, but that doesn't matter.  I'm going to check the "products" table, first. 
    With those partial bits of information, go to the phpAdmin (or whatever client you're using) and find the "products" table in the database.  Look at the structure for the "products" table in 2.3.4 and then look at the structure for the "products" table in Phoenix.  In phpAdmin, there's an actual tab for "Structure."  That should show you the extra fields (columns) existing in 2.3.4 that you need to add to Phoenix.  You should see the "products_gtin" field in the 2.3.4 "products" table (in this example).  Develop a similar SQL "Alter" statement as above, adjusting/editing for the variable type (TEXT, VARCHAR(##), etc.).  Run that in the SQL window in phpAdmin on the database (don't touch the 2.3.4 one), then re-load the Phoenix store page that caused the error.  It should go away.  Or, at least the error changes to something else that you can also research similarly.  Eventually, you should arrive at no errors when you re-load the store's page in question.
    Interestingly, I don't have a "products_gtin" field in my "products" table - either 2.3.4 or Phoenix.  That's probably because I never installed the same add-ons that you guys did.  So, maybe everyone arguing against a do-all script is correct.  I had a horrible experience in the past trying to use an all-at-once SQL script for porting an OsC database (coming from MS2.2 to 2.3.4).  Granted, it's not a single button-push, but maybe it really is better to encourage the logic and method of manually copying the database.
    Remember to back up, back up, back up - both before and after. 😉  This is very rudimentary, but hope it helps ...
  9. Like
    TomB01 got a reaction from Krisz1 in Google reCAPTCHA v3   
    Anyway to make this work under php 5.4?  I tried replacing "[]" with "array()" everywhere, but the google recaptcha doesn't appear on either page, create_account or contact_us.
  10. Like
    TomB01 reacted to raiwa in Featured Products BS   
    Uploaded Update:
    Featured Products CE v2.1.0
    Featured Products CE v2.1.0. (CE Phoenix) 
    Compatibility: Phoenix 1.0.4.x Lower versions, please use Featured Products CE v2.0.0.
    You may use the store side files of this version Featured Products CE v2.1.0. for Phoenix 1.0.2.x-1.0.3.x stores. Changes version 2.1.0.:
    Updated for OSCOM CE Phoenix 1.0.4.x Updated index content module template files to match Phoenix 1.0.2.x-1.0.4.x product modules Removed word length settings Bootstrapped Admin/featured.php and Admin/select_featured.php Removed Catalan and French admin language files Translated Spanish and German admin/select_featured.php language files Added Spanish and German store language files Updated instructions


  11. Like
    TomB01 got a reaction from Dan Cole in Upgrade Path TO Phoenix   
    Dan is correct and glad you found the solution.
    To others - if this will help - take a look at that error message that Krisz1 got:
    I'm sure this is like explaining 2+2 to some of you, but when I saw similar messages, I keyed on the "Unknown column" part.  That tells you there's a field (column) missing in the database table the follow-on SQL statement is trying to access.  Then I looked in the SQL "Select" statement for the "from" word.  The name that comes after the "from" word in the SQL statement is the database table.  You will also see the "products_gtin" field name in the collection of field names that the "Select" statement is trying to gather.  So in this case, "products p" looks like the source table for the SQL statement.  I don't know enough about SQL to know if the comma after that is specifying another table.  I also don't know what the "p" means at the end of "products," or at the beginning of the field (column) and table names, but that doesn't matter.  I'm going to check the "products" table, first. 
    With those partial bits of information, go to the phpAdmin (or whatever client you're using) and find the "products" table in the database.  Look at the structure for the "products" table in 2.3.4 and then look at the structure for the "products" table in Phoenix.  In phpAdmin, there's an actual tab for "Structure."  That should show you the extra fields (columns) existing in 2.3.4 that you need to add to Phoenix.  You should see the "products_gtin" field in the 2.3.4 "products" table (in this example).  Develop a similar SQL "Alter" statement as above, adjusting/editing for the variable type (TEXT, VARCHAR(##), etc.).  Run that in the SQL window in phpAdmin on the database (don't touch the 2.3.4 one), then re-load the Phoenix store page that caused the error.  It should go away.  Or, at least the error changes to something else that you can also research similarly.  Eventually, you should arrive at no errors when you re-load the store's page in question.
    Interestingly, I don't have a "products_gtin" field in my "products" table - either 2.3.4 or Phoenix.  That's probably because I never installed the same add-ons that you guys did.  So, maybe everyone arguing against a do-all script is correct.  I had a horrible experience in the past trying to use an all-at-once SQL script for porting an OsC database (coming from MS2.2 to 2.3.4).  Granted, it's not a single button-push, but maybe it really is better to encourage the logic and method of manually copying the database.
    Remember to back up, back up, back up - both before and after. 😉  This is very rudimentary, but hope it helps ...
  12. Like
    TomB01 got a reaction from Fredi in Upgrade Path TO Phoenix   
    Yes - no disrespect meant toward Gary.  It's sort of like Santa Claus keeps pushing presents down the chimney, but you're still trying to unwrap the first one. 😀
  13. Like
    TomB01 reacted to ecartz in Upgrade Path TO Phoenix   
    https://stackoverflow.com/a/193860
    SELECT DISTINCT TABLE_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE COLUMN_NAME = 'customers_id' AND TABLE_SCHEMA='YourDatabase'; Replace YourDatabase with whatever DB_DATABASE says in includes/configure.php
    define('DB_DATABASE', 'osCommerce'); The default (as shown here) is osCommerce, but it may be different in your shop. 
    And of course the customers_id is particular to this issue. 
    In this particular case, the customers_info table is also necessary but does not show.  Because it uses customers_info_id instead of customers_id.  You don't need the temporary data from whos_online which uses customer_id instead of customers_id. 
  14. Like
    TomB01 reacted to BrockleyJohn in NEW! Complete Order Editing Tool!   
    That should show up in the configuration group - I guess it means that your original settings didn't have it and you've left it with the second config group id. When you did the update did you get a redirect with a message telling you there were new settings and to check them? It checks for a pre-existing install by looking for one of the settings being defined. I've just put in a change to test a different config (ORDER_EDITOR_USE_AJAX) which should be present in any existing installation of any age.
    I confess I'd not looked at the uninstall sql since updating the addon. I've now redone it to take out any and all configs and groups for the editor.
  15. Like
    TomB01 reacted to BrockleyJohn in NEW! Complete Order Editing Tool!   
    pah, I knew I was going to regret upgrading office 2010
    They're landscape but it didn't pdf them so in word 2020. Try the attached instead
    Order Editor Readme.pdf
  16. Like
    TomB01 reacted to BrockleyJohn in NEW! Complete Order Editing Tool!   
    So, adding the same product on two different order lines was messing up the shipping calculations (even if with different options). I reckon that shipping modules based on price didn't get the right results either. This is fixed (cart products are now indexed on uprid and the restore checks for existing key), along with the Edit button issue and also the redirect error on a fresh install.
    Uploaded to https://apps.oscommerce.com/Apps&wwEZ9&order-editor-for2-3-v1-0
    @ArtcoInc @TomB01
    Tested on 2.3.4 classic, Phoenix 1.0.4.0 and a bunch of bs versions in between but please flag up any issues.
  17. Like
    TomB01 reacted to ecartz in USPS Rate V4, Intl Rate V2 (official support thread)   
    The ones that remain are the ones that change from store to store.  For example, your catalog directory might be in the root at / or at /catalog/ or at something like /shop/.  Each store can choose to do something different.  Meanwhile, images/icons/ is always images/icons/ -- there is very little reason to ever change it.  Even if you did want to change it in the URL, you could use something like mod_rewrite so that the directory structure would stay the same. 
    In general, most of the constant ones have gone, leaving only the few variable choices.  I find it rather unlikely that we'd take out more of the DIR_WS values (except possibly DIR_WS_HTTPS_CATALOG).  More likely to go would be HTTPS values and USE_PCONNECT.  USE_PCONNECT because mysqli does that in the DB_SERVER.  The HTTPS values because very few stores used mixed HTTP and HTTPS today.  So why support something that no one uses? 
    The two DIR_FS_DOWNLOAD values may go.  And STORE_SESSIONS. 
    The following are pretty safe, although the HTTP ones might get renamed (or not): 
    define('HTTP_SERVER', ''); // eg, http://localhost - should not be empty for productive servers define('HTTP_COOKIE_DOMAIN', ''); define('HTTP_COOKIE_PATH', ''); define('DIR_FS_CATALOG', dirname($_SERVER['SCRIPT_FILENAME']) . '/'); // define our database connection define('DB_SERVER', ''); // eg, localhost - should not be empty for productive servers define('DB_SERVER_USERNAME', ''); define('DB_SERVER_PASSWORD', ''); define('DB_DATABASE', 'osCommerce'); DIR_WS_CATALOG is defined elsewhere, but also pretty safe. 
  18. Like
    TomB01 reacted to ecartz in USPS Rate V4, Intl Rate V2 (official support thread)   
    I wouldn't say it that way.  What should be replaced is
    " . TABLE_CONFIGURATION . " and it gets replaced with
    configuration So that the string looks like
    insert into configuration ( It will sort of work if you replace TABLE_CONFIGURATION with configuration, but it will generate a notice that may appear in the logs.  And of course if anyone ever made a constant named configuration, it would break. 
    Normally, I'd recommend replacing
    $this->icon = DIR_WS_ICONS . 'shipping_usps.gif'; with
    $this->icon = DIR_WS_CATALOG . 'images/icons/shipping_usps.gif'; Because that will work regardless of where the catalog directory is located. 
    If you use the <> tool to insert code in the forums, it will be easier to tell it from the surrounding text. 
  19. Like
    TomB01 got a reaction from Heatherbell in Tax Errors in Phoenix Checkout   
    @Heatherbell,
    I greatly appreciate the help - from everyone of you!
    I'm mightily embarrassed again, because it was user-induced error pointed out by ecartz on the Phoenix club.  I was not correctly including Georgia in the created Tax Zone.  It's fixed!
    I appreciate the patience from everyone; guess I've been working so constantly on this, I can hardly read correctly anymore.  I will get a Phoenix store up and running soon.
     
  20. Like
    TomB01 got a reaction from Heatherbell in Tax Errors in Phoenix Checkout   
    @Heatherbell,
    I greatly appreciate the help - from everyone of you!
    I'm mightily embarrassed again, because it was user-induced error pointed out by ecartz on the Phoenix club.  I was not correctly including Georgia in the created Tax Zone.  It's fixed!
    I appreciate the patience from everyone; guess I've been working so constantly on this, I can hardly read correctly anymore.  I will get a Phoenix store up and running soon.
     
  21. Thanks
    TomB01 got a reaction from valquiria23 in UPS XML 1.7 for Phoenix   
    Thanks!  I will work on new updates to the addons (both UPS and FedEx).
  22. Like
    TomB01 got a reaction from burt in UPS XML 1.7 for Phoenix   
    Well, I have it working!
    It wasn't your post specifics, but the idea you hit upon in the SQL inserts above.  I kept looking at the error codes e-mails that were stating "Missing/Illegal Shipper/Country Code" trying to figure out which was the issue - Shipper or Country Code.  I decided to create log files on the server.  Then I compared the Phoenix log file to my working 2.3.4 log file.  The UPS reply on the working log file was lengthy.  Then I went to WinMerge to compare the two log files exactly.  The 2.3.4 log file had CountryCode "US", the Phoenix log file had CountryCode "United States."  Long story short, my Chrome browser was auto-filling the Admin settings for UPS XML shipping and I accepted "United States" instead of following the instructions that stated Enter the country's two-character code.  What a dummy I am!
    Checked it again, then the error code changed to "Invalid Destination."  I guessed the UPS Server was very smart, so I input my own real address.  It worked.
    Bottom line, the insert into the languages file suggested by Burt fixed the Admin errors about the "UPS_SERVICE_CODE_."  Elsewhere, I had to input into the upsxml.php file, complete path strings instead of the DIR_ stuff, and remove the TABLE_ prefixes and use lowercase database table names.  Then I ensured that correct data was entered into the Admin settings, and used a REAL checkout address.
    Success!
     
    Attached are the modified-for-Phoenix includes/modules/shipping/upsxml.php and includes/languages/english/modules/shipping/upsxml.php files. (Enter your own store's path string where needed.)
     
    upsxml.php
    upsxml.php
  23. Like
    TomB01 got a reaction from burt in UPS XML 1.7 for Phoenix   
    Well, I have it working!
    It wasn't your post specifics, but the idea you hit upon in the SQL inserts above.  I kept looking at the error codes e-mails that were stating "Missing/Illegal Shipper/Country Code" trying to figure out which was the issue - Shipper or Country Code.  I decided to create log files on the server.  Then I compared the Phoenix log file to my working 2.3.4 log file.  The UPS reply on the working log file was lengthy.  Then I went to WinMerge to compare the two log files exactly.  The 2.3.4 log file had CountryCode "US", the Phoenix log file had CountryCode "United States."  Long story short, my Chrome browser was auto-filling the Admin settings for UPS XML shipping and I accepted "United States" instead of following the instructions that stated Enter the country's two-character code.  What a dummy I am!
    Checked it again, then the error code changed to "Invalid Destination."  I guessed the UPS Server was very smart, so I input my own real address.  It worked.
    Bottom line, the insert into the languages file suggested by Burt fixed the Admin errors about the "UPS_SERVICE_CODE_."  Elsewhere, I had to input into the upsxml.php file, complete path strings instead of the DIR_ stuff, and remove the TABLE_ prefixes and use lowercase database table names.  Then I ensured that correct data was entered into the Admin settings, and used a REAL checkout address.
    Success!
     
    Attached are the modified-for-Phoenix includes/modules/shipping/upsxml.php and includes/languages/english/modules/shipping/upsxml.php files. (Enter your own store's path string where needed.)
     
    upsxml.php
    upsxml.php
  24. Like
    TomB01 got a reaction from burt in UPS XML 1.7 for Phoenix   
    Well, I have it working!
    It wasn't your post specifics, but the idea you hit upon in the SQL inserts above.  I kept looking at the error codes e-mails that were stating "Missing/Illegal Shipper/Country Code" trying to figure out which was the issue - Shipper or Country Code.  I decided to create log files on the server.  Then I compared the Phoenix log file to my working 2.3.4 log file.  The UPS reply on the working log file was lengthy.  Then I went to WinMerge to compare the two log files exactly.  The 2.3.4 log file had CountryCode "US", the Phoenix log file had CountryCode "United States."  Long story short, my Chrome browser was auto-filling the Admin settings for UPS XML shipping and I accepted "United States" instead of following the instructions that stated Enter the country's two-character code.  What a dummy I am!
    Checked it again, then the error code changed to "Invalid Destination."  I guessed the UPS Server was very smart, so I input my own real address.  It worked.
    Bottom line, the insert into the languages file suggested by Burt fixed the Admin errors about the "UPS_SERVICE_CODE_."  Elsewhere, I had to input into the upsxml.php file, complete path strings instead of the DIR_ stuff, and remove the TABLE_ prefixes and use lowercase database table names.  Then I ensured that correct data was entered into the Admin settings, and used a REAL checkout address.
    Success!
     
    Attached are the modified-for-Phoenix includes/modules/shipping/upsxml.php and includes/languages/english/modules/shipping/upsxml.php files. (Enter your own store's path string where needed.)
     
    upsxml.php
    upsxml.php
  25. Like
    TomB01 got a reaction from azpro in UPS XML 1.7 for Phoenix   
    Thanks for the advice.  I never liked UPS that much anyway. 😉
    USPS is my absolute primary shipping and that now works.  If I have FedEx, too - maybe I can make a go of it.  I will keep working and try to follow up as you suggest in the meantime.
×