Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

kymar

Archived
  • Posts

    64
  • Joined

  • Last visited

Everything posted by kymar

  1. You may need to delete and re-install the module via Admin (or delete and re-create the database), not just replace the file, to get the changes to work. Otherwise (someone correct me if I'm wrong), the database may not be fully updated.
  2. Fix here: http://www.oscommerce.com/forums/index.php?showtopic=301960
  3. First Class International has also stopped working at my store - I'm not sure when it happened - I suspect it's some US Postal Service glitch or change. Will continue researching and will post or check back for any updates.
  4. If you follow all of the instructions at the COMPLETE fix (see prior post) at the link noted, it should work. Otherwise, much in this thread is irrelevant or mistaken, as previously noted (some good partial efforts, but not the complete solution). Various other problems have been noted on other threads, and you might want to search through them for more extensive discussion.
  5. Best check to see that you're using the add-on that includes the SQL file, not the most recent one that includes only the usps.php file. But it's been a couple of weeks, so maybe you've figured that out for yourself by now. If you need help with PHPADMIN or SQL, then that's another issue.
  6. I believe the part that "draws the check boxes" - if I understand you correctly - is the function called by tep_cfg_select_multioption with the subsequent array variables. As you probably know, all it takes is a single missing quote or other mis-punctuation to throw the whole thing off The values look correct to me on first glance, but, if your table is corrupted or otherwise impaired, either as a result of your own edits or of other problems that can develop over time and use, then it might need either to be repaired or replaced. Without figuring out how the code and database interaction work in their entirety and why precisely they're written as they are - something I've never done and that might take a good bit of time for a mere hacker like me - it's probably worth going back to your last working database backup (or a true clean install if that's a workable option for you), and then re-installing from there using the contribution files or some other working version of usps.php exactly as written. Once you've got things appearing more or less as expected, even if it's a largely or partly obsolete version, then you can proceed to whatever remaining alterations you need to make, proceeding very carefully, of course.
  7. Corrupted table? You might want to look into the PHPMYADMIN repair routines. Hard for me to say.
  8. Possibly the tep_db_query section, where all of the variables appear again. I'd recommend that you start over again: Backup and uninstall your current settings and files. Replace them fully with the contribution files following the instructions to the letter, and not installing the module in admin or testing it until everything is set. If you're still getting the error, then it may be "above my paygrade" or at least beyond my expertise to help you. If you have custom changes to the files, re-insert them only after you've made sure that the "clean" (re-)install works properly.
  9. What you're asking for there is very simple - it doesn't sound like you're worried about calculating specific weights, adding weights together accurately, or having different prices for different zones, countries, or delivery methods. If that's true, then all you'd need to do is an extra field to the products table - call it shipping_charge. Look for Products Extra Fields contribution for details, though, again, what you need to have done may lead you to apply it differently (i.e., more simply). Essentially, the bare minimum would be to create the extra field in your products table, and have it show up 1) somewhere in admin so you could edit it for each item, and 2) incorporate into your order total calculations at the appropriate time or times. If you want to be able to download it and upload it via Easypopulate, then you'd need to add the field variables in Easypopulate. If you want it to appear during checkout, then you'd need to alter and format the appropriate the relevant files in the appropriate locations - both the checkout-related files and the order calculation files, as well as potentially the product information files. It's not really that complicated. But you can't get anywhere until you know and can state exactly what you need and want. (I wanted to be able to calculate multiple "tare" weights for different kinds of items, so I added a tare_weight field, then hacked up some adequate (for me) formulas that could be added to the order classes and functions before shipping costs are calculated. If I were a little less busy right now, and if all of my files weren't already heavily modified, meaning they're useless for a public contribution as is - I'd put up a contribution in the hopes that someone more skilled and experienced would improve on some of the shortcuts I took to get something that worked. I do hope to get around to that one of these days - maybe during the post-Xmas lull.)
  10. If what you pasted here is the file you're using, then you somehow missed or lost the upper case tags in the variable declaration section. $this->intl_types = array('Global Express' => 'Global Express Guaranteed', 'Global Express Non-Doc Rect' => 'Global Express Guaranteed Non-Document Rectangular', 'Global Express Non-Doc Non-Rect' => 'Global Express Guaranteed Non-Document Non-Rectangular', 'Express Mail Int' => 'Express Mail International (EMS)', 'Express Mail Int Flat Rate Env' => 'Express Mail International (EMS) Flat Rate Envelope', 'Priority Mail Int' => 'Priority Mail International', 'Priority Mail Int Flat Rate Env' => 'Priority Mail International Flat Rate Envelope', 'Priority Mail Int Flat Rate Box' => 'Priority Mail International Flat Rate Box', 'First-Class Mail Int' => 'First-Class Mail International'); should be $this->intl_types = array('GLOBAL EXPRESS' => 'Global Express Guaranteed', 'GLOBAL EXPRESS NON-DOC RECT' => 'Global Express Guaranteed Non-Document Rectangular', 'GLOBAL EXPRESS NON-DOC NON-RECT' => 'Global Express Guaranteed Non-Document Non-Rectangular', 'EXPRESS MAIL INT' => 'Express Mail International (EMS)', 'EXPRESS MAIL INT FLAT RATE ENV' => 'Express Mail International (EMS) Flat Rate Envelope', 'PRIORITY MAIL INT' => 'Priority Mail International', 'PRIORITY MAIL INT FLAT RATE ENV' => 'Priority Mail International Flat Rate Envelope', 'PRIORITY MAIL INT FLAT RATE BOX' => 'Priority Mail International Flat Rate Box', 'FIRST-CLASS MAIL INT' => 'First-Class Mail International'); same problem in the tep_db_query section, for both domestic and international variables refer to the usps-2.9.2a_1 contribution for details
  11. Not having that problem on my site. I enable only 1st Class Int, Priority Int, and Express Int. I have to ask, have you proofread your typing very carefully and removed and re-installed the module in admin, or did you use the contribution files? Have you seen whether the same errors occur with identical options enabled across the multiple sites?
  12. At this point, I'm not really sure what the problem is. I just hack and hack at this stuff myself. If your web-host doesn't have a tech department to help you with phpmyadmin and SQL stuff, and no one who's truly expert turns up in these parts, there are a lot of other things you could try, with a range of difficulty and time factors involved, but all likely to teach you a few things about the SQL and phpmyadmin even if they turned out to be blind alleys. First, of course, you'd want to search through the documentation to get clear on exactly what your message means. If that doesn't lead you to an easy fix, you might try checking and repairing the table. You might try replacing it with a back-up, and so on, and so on. If the site was new and unmodified, I'd try reinstalling it. You could even try a second install on a second database and see if you could duplicate the error. Sorry I can't be more help.
  13. Can you be more specific about what it is exactly you're trying to achieve?
  14. I referred to the above e-mail on my reply on the "HERE'S THE FIX" thread, instead of here, with other notes on variations in approaches. The main info for the newbie question is as follows: It shouldn't really make much difference whether you run a sql update before or after changing the php file, as long as you do both. Not sure why you were getting the error you mentioned, but if you're running phpmyadmin, you should be able to find your store database (you may have more than one database set up on your server, I don't know), probably named something like "youruserid_p_os2 (63)" - click on it, then either click import if you're using a sql update file as in the contribution at the link directly above, or go to SQL and paste in the update info if you're just cutting and pasting. If you go to the contribution link - http://addons.oscommerce.com/info/487 - and follow the instructions, it should work. If you've performed custom alterations to your usps.php module, you'll have to do a file compare, and maybe strain your eyes and scratch your head a little.
  15. Thanks for your work - BUT THIS IS NOT THE RIGHT FIX. Among other things the above changes (don't know whether you were being sloppy or what) include defunct international mail categories. As noted on other threads the simple fix, IF YOU HAVE A MODULE THAT WAS UP TO DATE UNTIL AROUND A WEEK AGO, requires only that you ensure that the "keys" are sent as capital letters. I'm not sure anyone knows at this moment exactly what the USPS did (much less why they did it), but in any event for the moment that seems to solve the problem. And even if they go back to a case-insensitive set-up, it won't hurt to have your keys in all-caps. I hope. Big note: If you just modify the keys to uppercase, you'll have to uninstall and reinstall your module to make sure the changes take effect. If you run the sql update, then I don't think you have to do it. I confess I'm not 100% clear on why the usps.php file is written the way that it is, but things seemed to work fine when I did both - uninstall and re-install, also just update the file and run the sql update. However, as others have noted, if you go the "quick" route and just modify to uppercase and re-install, be sure to locate or to copy your USPS userid, password, and module settings (at your admin modules page) before you remove the shipping module, since, when you reinstall it, you'll have to provide the info again. Here's the fix for updated USPS modules: My recommendation: go to http://addons.oscommerce.com/info/487 for working, updated modules and instructions. If you've performed custom alterations to your usps.php module, you'll have to do a file compare, and maybe strain your eyes and scratch your head a little. As for the "newbie" question: It shouldn't really make much difference whether you run a sql update before or after changing the php file, as long as you do both. Not sure why you were getting the error you mentioned, but if you're running phpmyadmin, you should be able to find your store database (you may have more than one database set up on your server, I don't know), probably named something like "youruserid_p_os2 (63)" - click on it, then either click import if you're using a sql update file as in the contribution at the link directly above, or go to SQL and paste in the update info if you're just cutting and pasting. If you go to the contribution link, and follow the instructions, it should work.
  16. I think you should note that additional files may have to be altered - otherwise you'll get errors on any other processes that use the mail function. When I have more time, I'll investigate whether the lines in application_top that require the mail class really need to be commented out. Without requiring the mail class there, you get errors on newsletters and on account-related e-mails, to begin with.
  17. Look for how the count_contents() function is used in checkout_shipping, and/or how $total_weight is used in most of the shipping modules. If you know how to write simple if/then/else statements and how to declare variables, you should be able to hack up your own extremely simplified version of the zone, table, or usps modules (I think I'd start with the table), leading to 1 of 3 modes for domestic shipping: envelope, box, or request quote (for very large orders). You don't really need to request quotes from the USPS, as in the USPS Methods module, and you don't need to worry about zones and such, you just need to set up alternatives for either number of items or total weight (which in you case should be same difference).
  18. Hmmm... other than uninstalling and re-installing the whole thing, step by step, beginning with your last back-up (at least for the configuration table), you might want to check your tables: Go to PHPADMIN, select the database, check all the tables, and run analyze. If any, especially the configuration table, come up with warnings, then repair them. It may just have been a coincidence, but I discovered a lot of problems - apparently new ones - in the period just after I converted according to the above suggested method. I had several tables crash, and I also ran into a max_resources issue that I had to solve.
  19. Thanks FoundSoul - mucho! Don't know about $100, but, if it was proper to offer it hereabouts, I'd gladly give you a discount at my store! Still have to research the flat-rate box and other peculiarities of the new rules. For the moment, I expect I'll eat extra shipping costs on the handful of higher priced items I have that also might be affected by new dimensional weight stuff. In most cases, I have international customers query me first anyway for shipping quotes for such pieces (it's a peculiarity of the kinds of items I sell that shipping is usually exorbitant by any means for the very oversized and heavy pieces). Anyway, the fix worked fine for me. I hesitate to offer any advice to Joe, but you might want to ask your web-host about phpmyadmin configuration peculiarities, assuming the host configured and provided phpmyadmin and mysql for you.
  20. I had the impression the changeover was taking place even sooner - or is there going to be a transition period during which the old international methods co-exist with the new ones? I'm not looking forward to the headache, but I'm also hoping that hacking the files won't be too difficult. Thanks in advance for whatever work you do, and I'll be checking this space!
  21. Just to be clear, I'd try putting the variable declaration $total_weight = $cart->show_weight(); before line 52 (or whatever it is in your checkout_shipping.php), then edit line 52 (now line 53 or so) as follows if ( (DOWNLOAD_ENABLED == 'true') && ($total_weight == 0) ) { // Edited for CCGV then again, maybe it's something totally different - I'm just hacking away...
  22. Hi Wendy, I just posted to the separate thread I created related to this problem before I realized it was most likely a CCGV-related problem. I'll re-post here, and I'm sorry that I've got to run right now and can't completely test what I'm suggesting: There are two places in checkout_shipping.php where redirects to checkout_payment occur. The first involves a change related to CCGV where line ca. 52 in the osCommerce default file if ($order->content_type == 'virtual') { is replaced by if ( (DOWNLOAD_ENABLED == 'true') && ($cart->weight == 0) ) { // Edited for CCGV If the problem is here, it would also explain why disenable download fixes the problem - so long as you're not using virtual products. I don't have enough time to trial and error it right now, but my first guess is that $cart->weight == 0 is wrong and should be amended along the lines of the show_weight function used to arrive at $total_weight a few lines later: $total_weight = $cart->show_weight(); The second redirect occurs in relation to the free_shipping module. I could imagine possible interactions here also, but I'd have to examine the related files and definitions.
  23. I don't have that problem with IE6 on my site - at least I don't think I do - . Could be a function of a relatively slow connection (I'm using cable modem). I believe that IE6 sometimes stumbles over PHP/Java calls, and that you can solve it by embedding the full code for the menu wherever it's supposed to appear rather than relying on a PHP require or include or whatever you're using. Maybe someone with more expertise can answer more fully. In the meantime, why don't you check my site at ckmac.com, and see if you have the same problem. If you do, I'd be interested to know. If you don't, then you might try the solution I suggest.
  24. I did read your post. Indications weren't clear to me, or very specific, other than that they involved processes, functions, and possibly new coding with which I'm not in the least familiar. If working out precisely how such an option would work is of interest to you as developers - great - if not, it's something I may get to some other month, and I guess in the meantime I'll just trust you for the moment that the full start to finish no complications or conflicts solution is already embedded in the suite. Really, I'm not trying to beat a dead horse here or squeeze free work out of you guys. I'm already very happy with what you've done.
  25. I understand, and I certainly don't want to be argumentative, but I'd suggest that you look, for example, at the way that Amazon handles gift certificates, including the choice of goofy to pretty e-card styles as well as other aspects of the process. Even with as elaborate a set-up as Amazon has, getting someone to buy a gift certificate from a little on-line shop from nowhere may be too difficult, but it's even harder to get someone to cast their hard-earned money into the virtual void without even getting a pretty picture to commemorate the transaction. Product Attributes is probably the right avenue or jumping off point for implementing something similar - I can't really say. Obviously, there'd have to be further work on the fancy e-card delivery end. Otherwise, PA have been completely irrelevant to my store - one-off items that don't have "attributes" of this type - and wherever they appear in the suite I've either commented them out or deleted them. It's just a quirk of my store and otherwise a side issue: I'm not seeking a non-PA solution or really any solution at all at the moment (not that I'd turn one down if it was handed over to me wrapped up neatly with a bow).
×
×
  • Create New...