Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Terra

Pioneers
  • Posts

    887
  • Joined

  • Last visited

Profile Information

Terra's Achievements

  1. To anybody who has the following error: PHP Fatal error: Cannot access empty property in XXX/pdf_catalogue.php on line XXX The fix is fairly simply - find all instances of $this->$parent_category_name and replace with $this->parent_category_name But leave the first one alone: var $parent_category_name; Properties in Classes don't have $ signs in front of them. If they do, then PHP assumes we're calling a variable & tries to look for it's name. As it can't find a variable with the name it says "oi, this is empty!" and dies. By removing the $ sign you're back to standard PHP coding for properties in objects and all is well. All the best, Terra
  2. The payment status is updated every time PayPal sends an update to your site. These updates should only happen when the status of a payment changes (e.g. an eCheque clears). Order emails are sent when the payment update is to notify of a successful, cleared payment. On your site therefore PayPal keeps on sending the same success IPN update, resulting in the multiple entries. Why this is happening on your site I don't know. If you have time, I'd suggest contacting PayPal and ask them about repeat IPN updates to your site. For some reason, PayPal seems to think that it hasn't notified you yet, so it keeps on trying. And be aware -it's not just duplicate order emails, but also multiple stock reductions so I'd advise to check / correct your stock levels. If you can't rectify it, I'd recommend downgrading to v1.4 - at least, then there'll be no duplicate order emails / stock reductions although your admin will still show the multiple entries. Terra
  3. I don't think you're wrong and the thorough work you've done is fab - many thanks for investigating this! In my reply I thought about the standard GET variables but forgot that osCom of course has its own complete session handling mechanism ... which I haven't really looked at in the past as on my sites I can use force cookie use which usually cures problems. I guess there's a function which picks up POST session ids.. either way, if it works, then that's the way to go! all the best - Terra.
  4. With the PayPal IPN all orders are pre-saved i.e. BEFORE payment. You will therefore see quite a few orders in the admin which are pre-saved and abandoned, i.e. unpaid -these can be deleted (without restocking). I don't know where the information regarding "no table entry" comes from - that's wrong. The latest user guide states: all the best - Terra
  5. Hi drichter - glad it's working for you! I'm just trying to work my way through the fix but I'm struggling to understand why the switch to post makes a difference. The session ID is normally handled as GET variable in osCommerce, unless cookie use is forced (in which case the session details are in the cookie). Appending the session ID to the return URL should ensure that the customer's session continues. Within the osC store, session IDs are always GET - they are handed from page to page via appending to the URL. Sometimes GET session variables can be hidden (e.g. when SEO URLs are installed) but they are still there in the background. Can you confirm if in your testing the SessionID on checkout_confirmation and the SessionID in the PayPal return URL are the same? NB: if there's a problem with the session ID you may not see in the testing, as checkout_process redirects to checkout_success.php and if there's a problem, it would strip out the session ID in the redirect. To see if the URL is correct, you could e.g. put an "exit;" command at the top of checkout_process.php - that would stop the transaction at that point and you can then check the URL in the browser bar. all the best - Terra PS: I take you are not using RC1?
  6. You can set it to "per item" but this can cause issues - if you want to use per item, give it a go & test thoroughly. The main problems are around tax (especially shipping tax) and CCGV - as long as your shop is simple (no tax, no CCGV) the per item should work. All the best - Terra
  7. Make sure that each payment module has a unique sort order in your shop admin. Modules with the same sort order can cancel each other out. PS: PayPal is a PAYMENT method, not a SHIPPPING method .. flat rate has nothing to do with it! All the best - Terra
  8. You have enabled Enable Encrypted Web Payments but it's not working. Either disable it in your admin (set to false) or you'll need to configure it correctly. If you enable Enable Encrypted Web Payments you must enter all the other information (key, certificate, working directory, OpenSSL) correctly and OpenSSL must be enabled on your server. Please read the section about EWP in the user guide, there's also information on the support thread or see the PayPal site for help & advice. All the best - Terra
  9. This indicates that PayPal is trying to resend the payment information to your site - I've not come across this before, so in all likelihood it's a specific issue with your set-up. If you can't debug it, downgrade to v1.4 - at least then no order emails are sent out / no stock quantities deducted when the IPN update is sent. all te best - Terra
  10. This means you forgot to copy over the language level file (or copied it into the wrong place) - please double-check that you uploaded the correct file to /includes/languages/english/modules/payment/. All the best - Terra
  11. As far as I know the contrib in RC1 is an old version from 2005 - Harald obviously thinks my coding is sh*** so what the heck - it's only 2 1/2 years out of date. Terra PS: don't forget that RC1 translates in "beta version" - not suitable for live sites.
  12. This module was NOT written for WebPro so if you're looking for WebPro then this is not the right contribution. For the private key etc. I don't believe you need a WebPro account - just a business account with PayPal. But if you have an SSL or cURL enabled, then you won't need the private key stuff. all the best - Terra
  13. The IPN module I wrote is optimised for the UK and the variable you mention is the PayPal recommended field for UK phone numbers. I don't have plans to write a separate module for US optimisation but if any other developer has time, feel free to update the IPN with a US forke. Terra
  14. Pre-saving all orders (whether they are paid or not) is part of how the IPN works. There's no way around this - your client will have to check before sending out goods or use a different payment module. Terra
  15. Please note that this thread is ONLY for the following PayPal contribution: http://www.oscommerce.com/community/contributions,2679 As you are using a different contrib please do not post in this thread - thank you for your help in keeping this thread on topic. Terra
×
×
  • Create New...