Latest News: (loading..)

zzfritz

Members
  • Content count

    496
  • Joined

  • Last visited

1 Follower

About zzfritz

Profile Information

  • Real Name
    Fritz Clapp
  • Location
    California USA
  • Website
  1. I am SO glad to find this thread and quickly, too, and the fix using sprintf does indeed work. Before coming back here (I have been absent many months), I tried pinning this error down and was stumped except to recognize it was a rounding phenomenon. This happened to a site of mine that had run correctly for a full year at ipowerweb on one of its oldest servers, but when we migrated it to a new vDeck server, voila ... rounding occurs. Thank goodness for the osC forum and a robust user community! Happy Holidays to all.
  2. This is not an 'anomaly' but a feature known as 'tare weight' representing the added weight of packaging.<p>You shouldn't have to edit the database table; it should be set in admin => Configuration => Shipping, where you set the store's Postal Code, Country Code and maximum package weight.
  3. Now that I have achieved functionality with both PayPal IPN and Authorizenet Consolidated 1.7, I would like to address the problem noted above in posts #49-51 where the customer_id is not among the POST vars as expected. To answer Harald's question, I believe the only contributions affecting checkout in this installation are Authorizenet Consolidated 1.7 and QT Pro 3. (Among my dreaded tasks ahead is to bring this installation current to QT Pro 4.) Any suggestions to find why the customer_id is not being passed to PayPal?
  4. Greg's suggested coding and global declaration (post 47 above, on 7 Dec) does indeed solve the duplicate instantiation problem (of order_total) in my installation that has both PayPal IPN and Authorizenet Consolidated 1.7. Now both of these payment contributions are playing nicely together. So anyone else who uses them both should heed that suggestion.
  5. I found that order status was not being updated because the query string in ipn.php searched on both the order number and the customer id, and the latter was not in the POST vars as apparently expected. I edited the query, and the order status is being updated now. It is also important to note that IPN is not instantaneous: the status did not change from the interim 'Preparing [PayPal IPN]' for a few minutes and in one case it took 18 minutes before the verification was received and the order status updated.
  6. you state the obvious, mibble ... I guess that's how you racked up so many posts Inspecting the code, this appears to be a clash between Authorizenet Consolidated 1.7 and PayPal IPN. The authorizenet mod to checkout_process.php has its own 'new order_total' embedded inline, before the standard code calls all the payment modules' before_process(), which in the case of PayPal IPN includes another 'new order_total' instance. Can someone suggest a workaround? [specifics, not generalities]
  7. I had an opportunity to install and test the prerelease version from 11/26, and found it worked fine. Today I noticed the official contribution had been made, so I replaced all the files and installed it (after removing the old one, of course). Then I had someone test it, and the order went okay including the confirmation email, being listed in admin, and PayPal had the money. But she did not get returned to the confirmation success page, getting instead the error message: Fatal error: Cannot redeclare class order_total in /home/sonnybar/public_html/osc/includes/classes/order_total.php on line 13 While I sleuth this myself, I am posting hoping perhaps someone else will recognize the symptom more readily and save me some time/frustration. I really don't believe there had been any other relevant changes to the site. But I don't see any differences between the old and new scripts that appear likely to generate an extra class declaration ... hmm ...
  8. kingchui: be sure to set your country code in Admin -> Configuration -> Shipping/Packaging
  9. This error indicates you failed to upload the associated language file. I have no familiarity with this particular contribution, but doubtless it consists of a script named returns_track.php which you uploaded. Look again in the contribution and you should also find a file with the same name (but different contents) which must be uploaded to the directory includes/languages/english/. It is a general technique in osCommerce to supply language-specific files that contain the text displayed by the script. When returns_track.php runs, it references the text items defined in includes/languages/english/returns_track.php.
  10. Without making any recommendation, I am aware this export to QuickBooks exists: http://www.oscommerce.com/community/contributions,1861 and there are topics mentioning it in the Contribution Support channel. Tell us whether this is satisfactory (or if not, why not), as the subject is significant IMHO.
  11. The simplest thing (not requiring any coding) would be to use a tiny transparent gif as the image for all the products. You may as well use pixel_trans.gif, which is already in your images directory. Then the only oddity will be that the Show Larger button on the product page will not make sense. To remove that, we can help you edit the product_info.php code. Reading your post again carefully, I hesitate. If you want this feature for only some users, my suggestion would of course not be adequate. Detecting which users are on slow lines, and providing the alternative images (regular and tiny) would require quite a bit of coding.
  12. I am one of the co-authors, and posted the last revision v2.7. It is working fine for two of my sites and lots of others', so I suspect other mods made to your site may be interfering. Have you got any other shipping module to work? For instance, how about the standard USPS module? I always recommend getting a store working with standard payment and shipping modules before switching to contributed ones. Otherwise it is harder to troubleshoot.
  13. This is the support topic for Contact Us Choice, announced here: http://forums.oscommerce.com/index.php?showtopic=89801 I have endeavored to make the installation very simple. For the minimal enhancement, only two replacement files need be uploaded: catalog/contact_us.php catalog/includes/languages/english/contact_us.php To take advantage of the optional features to display additional store information, and link to an external map page, it is necessary only to edit the language file. The alternative email destination feature requires adding a single entry to the configuration table in the database, for which the SQL is included. Then the completion of the feature set up is done by using the Administration tool. No other osCommerce files need be edited to use this contribution, and I believe it is pretty well behaved. I am sure you will let me know if that is not the case.
  14. stevel: it does not "look awkward" for a post to be edited, in fact it shows you have taken the care to make corrections. Just be glad you have this capability, we didn't used to. To All: take caution and even seek advice when choosing the Category into which you make your contribution. There are some notable mis-categorized contributions that have not gotten the attention they deserved when people didn't find them in the expected place. Take for instance: AuthorizeNet Consolidated, which should be in Payment Modules, is in Credit Modules; and Discount for Payment Type, whose description even acknowledges it creates an order total class, is in Credit Modules but should be in Order Total Modules. Unfortunately, there is no present means for transferring contributions to their correct category.
  15. [gee, was it really necessary to post the whole script?] I am not familiar with the contribution, but a simple comparison to the original table.php discloses that the statement $order_total = $cart->show_shipping_total(); should be $order_total = $cart->show_total();