Latest News: (loading..)

aspenshops

Members
  • Content count

    54
  • Joined

  • Last visited

About aspenshops

Profile Information

  • Real Name
    Ron Lee
  1. Kelly, I did get this contribution to work with the Paypal_IPN contribution. Be careful, there is more than one Paypal contribution out there. I got mine to work with the one titled: "osCommerce PayPal IPN Module v1.0 For 2.2MS2". The problem with the country being printed with only one character was resolved, but not cleanly. First, there was a typo in the /functions/general.php file and secondly, due to a change in the OSC update of 060817 that fix got messed up again. The problem stays fixed in the Admin side of things, but the customer's online view of invoices and packing slips still has the problem. It would require a major rewrite of code to completely fix things. I have switched to ZenCart so have not worked with OSC for about a month. As a result my memory is a bit fuzzy on the details of all the fixes, however they should be documented in the threads. You can do a search on my username (aspenshops) and I believe all the relevant info will come up. Ron I
  2. Frank: Check catalog/includes/filenames.php on the line that reads: define('FILENAME_DEFAULT'......... make sure it reads define('FILENAME_DEFAULT', 'index.php'); Regards, Ron (aspenshops)
  3. I didn't find any installation instructions, so simply uploaded the two files in the respective directories. How do I get these two modules to show up in admin? Once activated in admin I assume these options will show up during checkout? Ron
  4. Lets make that url http://forums.oscommerce.com/index.php?showtopic=168637 Ron
  5. Sergio: This thread is for the contribution titled Fancier Invoice & Packingslip and you are asking a question about Professional Invoice and Packing Slip. Try going to http://forums.oscommerce.com/index.php?sho...=168637&hl= and check that thread for answers to this question or post the question there. Regards, Ron
  6. This doesn't answer your question directly, but thought I would share a method I use to verify if emails are going out. Try creating a dummy customer account and use your own email address as this customer's address. Make a purchase (I use cash/money order for payment method) and see what comes through. For me, my emails come back within one minute. Just delete the order when you're finished. A couple of areas I know some folks have gotten tripped up on are: In Admin --> configuration --> email options: Make sure both 'Send HTML or Text Invoices to Customers' and 'Send Emails' are set to true. Make sure you have a valid Default E-mailed HTML Invoice Template' selected. Make sure you have the correct 'E-Mail Transport Method' selected. sendmail is the most common entry. Even if you think this is set right, experiment with the other settings and use the dummy customer account to test. Some other tips: If you have a webmail interface available on your server account try setting it to save all sent messages and then monitor the sent folder to see if the message is getting out of osCommerce. (The web mail interface should save all messages sent whether from web mail itself or from your SMTP/POP3 email client (like MS Outlook, Eudora etc.) Verify that your email address is correctly defined. (I would tell you where to check this, but I can't find it.) Ron (aspenshops)
  7. Marty: Thanks a bunch! It work perfectly! Great contribution! Ron
  8. Tom: Are you sure about the second block of code ($sendto )? The first block fixed the problem in the bill to: address, but the second block had no effect. Ron
  9. nu-oro: This means that the file /home/nu-oroco/public_html/osCommerce/catalog/includes/modules/email_invoice/email_invoice.php is looking for home/nu-oro.com/public_html/catalog/admin/includes/languages/english/invoice.php and can't find it. I see two possibilities: 1. The file is actually missing from the server in which case you will need to upload catalog/admin/includes/languages/english/invoice.php to your server from your backup files (or a copy from the original installation files). Using your backup files will assure that any modifications made earlier will be restored as of the date of the backup. or, more likely 2. In the Admin panel, open up Localization/languages and make sure you have entered the language name and code . 3. You can also verify catalog/admin/includes/config.php. Make sure these lines have the correct settings: define('DIR_WS_ADMIN', '/admin/'); define('DIR_WS_LANGUAGES', DIR_WS_INCLUDES . 'languages/'); The two definitions above should appear as above (no changes) Ron (aspenshops)
  10. The code looks good to me. It is unmodified. Some first steps: 1. verify the path: catalog/includes/modules/email_invoice.php 2. Review Step 6 in the installation instructions (Install.htm): in the above, change /home/YOUR_DOMAIN/public_html/catalog/admin/'); // absolute path required to reflect your absolute path to /catalog/admin/. 3. The above steps may not be necessary if the emails are getting to your customers.... it can't hurt to check tho.. I'm a puzzled by the line that reads: if (SEND_EXTRA_ORDER_EMAILS_TO != '') { You have it correct, and I have this installed and working, but it seems this code would want SEND_EXTRA_ORDER_EMAILS_TO to be 'true', not null..... but hey, it works here. Have you tried adding some temporary test code just above the if statement that would set SEND_EXTRA_ORDER_EMAILS_TO to true, false, or null just to see what happens? If changing to one of these states gets the email coming, then you know the problem lays ahead of this code where SEND_EXTRA_ORDER_EMAILS_TO gets set. You mentioned needing a quick and easy fix. If setting SEND_EXTRA_ORDER_EMAILS_TO true, false, or whatever works you could commit blasphemy and just leave it in hardcoded. You won't be able to shut off the emails from the admin console. If it were me I would leave it in just to get the business operating properly and followup and fix the problem later. The hard part is having the incentive to follow up. And you really need to in order to avoid a can of worms later on if some other contrib or feature you want depends on this being fully functional.
  11. Tom - perfectpassion (and others) Pertaining to: problem with emailed invoices having truncated address causing partial printout of the country name or emailed invoices with htmlspecialchars() error at beginning of Buyer's address. Affects: osCommerce 2.2 Milestone 2 060817 Update with 'osCommerce PayPal IPN Module v1.3 and Fancier Invoice & Packingslip v1.3 contributions Using your clue, I went back into catalog\includes\functions\general.php and found the code you referenced. I found my comment that [title] was added to make this work with the osCommerce Paypal IPN Module v1.3 per some super sleuthing by d1llon. If I take [title] out of the code it fixes the address in the emailed invoice for non-paypal customers, but reinserts the htmlspecialchars() problem for Paypal transactions. I think the best approach is for me to put [title] back in so it works with Paypal and try to find a way to make the non-paypal invoices work with it in. That's a little beyond my skill levels, so any help from anyone would be appreciated. Again, if I find a fix I'll post it. Ron
  12. Country truncated in emailed invoices / okay in admin Mary Doe 1234 Main St Anytown, USA 99999 U Thanks Tom for the lead. I did recently apply the Milestone 2 update 060817 about that time. I will look into that later today (been up all night with a contribution that I couldn't get to work so will take a long nap before tackling this problem.) I appreciate the guidance. If I nail it I'll post feedback on what the fix is. Ron
  13. tomliuwhite: Which one got changed? the server or the database? Dr_Lucas: I have a thought: Is it possible that the folks having problems getting this to work are hosted on virtual servers. I would guess a lot, if not most, websites hosted in other countries are on shared servers and the putenv("TZ=xxxxx/xxx") may be disabled. I tried to install, found the instructions clear enough and after reviewing all the messages believe I installed correctly yet in my case the server date appears to have been adjusted correctly but the database date/time is on Hong Kong Date/Time (I'm located in Colorado and my host is is Hong Kong). Well now, I just realized that puts the lie to the idea shared servers is the problem, doesn't it? It seems the problem is narrowed down to adjusting the database time stamp. Doesn't putenv act on the database, not the webserver? If so, and the database refuses to change, therein might lay the crux of the problem. Bad code, database configuration to not recognize putenv, or what? It seems to me that there are two approaches that could be taken to accomplish the goal here: 1. Adjust server and database times to the preferred time zone or 2. Configure osC to compensate for the time difference. There are definite advantages to both approachs. #1 is a much cleaner approach, if we can control the timestamps coming out of the database and webservers. If not, it seems #2 may be the only viable approach unless one wants to force local terminal timestamps into the mix (that would open up a new can of worms what with with some terminals being subject to whatever time is set on their LAN). The second approach would make the osC installation independent of server and database time function restrictions that may vary from host to host. It would be nice if it could be done without modifying code in numerous osC files and locations. (I presume it would however, which is probably why you took the server/database approach). Dr_Lucas, it's gotta be frustrating, but want you to know you have done some good work here, and this contrib apparently works fine in your setup. I sure hope together we can figure this out for the rest of us out here. I've seen some other contribs out there for the time zone offset and they do look very intimidating (sort of bloatware approach). Your's is clean, concise coding. You and I both know it's probably some simple thing affecting a bunch of us from getting this to work. Please stick with this as it's badly needed. Ron
  14. Young Tae sorry, my previous reply got away from me while trying to edit it. Perhaps this will seem more lucid: First steps: This is saying it can't find includes/languages/english/invoice.php on your server. 1. using your FTP software, your host's control panel, or other method to access your server files, navigate to and find: /admin/includes/languages/english/invoice.php 1a. If you don't find the file skip to step 2 (below). 1b. if you find it, open it and make sure it's the invoice.php that has a bunch of define statements in it (i.e: define('INVOICE_TEXT_THANK_YOU', 'Thank you for shopping at');. If not, you probably have the wrong invoice.php file in that location. Go to step 2. 2. Retrieve the correct file from your backups and upload to /admin/includes/languages/english/. This will be the file with the define statements in it. You may have to add in any revisions you made earlier to this file such as defining your 'STORE_URL_ADDRESS', 'INVOICE_IMAGE', etc. The fact that your orders are coming through is good and tells you that the problem is clearly in the admin. Ron
  15. First steps: This is saying it can't find includes/languages/english/invoice.php on your server. 1. using your FTP software, your host's control panel, or other method to access your server files, navigate to and find: /admin/includes/languages/english/invoice.php 1a. if you find it, open it and make sure it's the invoice.php that has a bunch of define statements in it (i.e: define('INVOICE_TEXT_THANK_YOU', 'Thank you for shopping at');. If not, you probably have the wrong invoice.php file in that location. Go to step 2. Retrieve the correct one from your backups and upload to /admin/includes/languages/english/ 2. Retrieve the correct file from your backups and upload to /admin/includes/languages/english/ The fact that your orders are coming through is good and tells you that the problem is clearly in the admin area.