Jump to content


  • Content count

  • Joined

  • Last visited

Posts posted by phwoarrr

  1. There appears to be a significant bug in the current IPN contribution.


    I've been debug-testing and found that it's before_process() method never gets called and therefore an order confirmation email is not sent to the customer, amongst other things. This is also why the customer comment is lost because the order_status_history table is not updated.


    I wrote my own customer-comment capture code in the confirmation() function recently to solve that, but I've now realised there's a fault with the module - possibly a result of recent changes to the code-base?


    I'll investigate some more and report back, but be aware of these issues... I've now got a list of about 5 issues with the latest download for this contribution that need patching.

  2. dompaz... it should be pretty self-contained but here is the information flow to help you understand it better.


    Product -> Cart

    Cart ->Checkout

    Checkout->PayPal IPN


    IPN pre-loads the order into the tables


    Confirmation->PayPal Payments Site


    Customer makes payment and is returned to the store


    Confirmation->Continue shopping


    Independently of that process, and at some point after (seconds to minutes) the payment is successfully processed, the PayPal IPN server will make an HTTP POST to your store to catalog/ext/modules/payment/paypal_ipn/ipn.php


    This script immediately posts exactly what it received in the POST query-string back to the PayPal IPN server.


    The IPN server replies with one word: VERIFIED or INVALID.


    If its INVALID the ipn.php script sends an email to the Debug E-Mail Address configured in the module's settings with the title PayPal IPN Invalid Process.


    If its VERIFIED the ipn.php script updates the order_status_history table comment to read PayPal IPN Verified [Completed (Verified; ?30.00)] and updates the orders table setting orders_status to 1 (Pending).


    Its now up to you, or other contributions/modifications you make, to process the order. Usually this involves changing the order status to Delivered which triggers notification of order, with an email sent with the title Order Update.

  3. Check the product descriptions for every Invalid email, see if the product description has a non Alpha Numeric character in it. Possibly a + or -.


    Rename the product description of one of the failing items, and do a test payment.

  4. Hi Rinon, thanks for the reply.


    If you've got a workload on already how about if I design my installer-library so it can function as a plug-in to your work, and then work out how best to modify your Installer without needing to change lots of code?


    Then I simply have to let you have the library and the required modifications to your code, and you can have it working quickly and reliably.


    I'll set up a developer installation of osCommerce on my server and then you can test my Installer and see how it operates.


    Have you got any minimum/maximum version requirements for PHP, MySQL or osCommerce?

    I've tried to make my PHP 5 code backwards-compatible with PHP 3 but I've not tested it on other versions of PHP so far. I guess I need to do that. I'm not even sure what the minimum PHP version is for osC !

  5. Hey Rinon and Vlad...


    Last weeked I began writing my own Installer, not being aware of your contribution. Mine differs in many ways from yours but having found yours I wondered if we should combine efforts?


    The key differences as I see them are:

    • My Installer uses a sophisticated matching algorithm which doesn't rely on original untouched files, and doesn't need to know line numbers. It uses MD5 checksums of the areas to be changed to ensure it only changes code it expects to see.
    • It has 2 levels of detection logic that says "Find findFirst, and then shortly after find the area that starts with Start and ends with End and has an MD5 checksum of checksum and replace/insert/delete with new-content.
    • It works as a stand-alone installer to be combined with a contribution, rather than as an integration with osCommerce.
    • It can make multiple passes over the same file without writing changes to disk, and does all its work in-memory.
    • It calculates the current user's database permissions to detect whether it has required privileges (CREATE /ALTER/DROP for example).
    • It falls-back easily to non-automatic mode when database privileges or file-system permissions prevent it making changes.
    • It doesn't require a configuration file or special directives, but could be easily combined into your XML logic.

    Its thoroughly bug checked at this point, and going through some serious testing before I used it to release a contribution I've written.


    If you'd lke to take a look at the source code let me know and I'll put it on my web site.

  6. Boidy mentioned the issue that IPN doesn't store customer comments and asked me to take a look at it.


    I believe I've come up with a solution to it, but in trying it bear in mind I've only been hacking the OSC code for about 3 days. Having said that, I've almost completed a proper Virtual Products module so I'm doing pretty well.


    The issue with IPN is it has to create an order before payment is authorized. It inserts data into many of the tables that the normal checkout_process.php usually fills after confirmation, but doesn't insert a record into the orders_status_history table.


    It does this when PayPal connects with the IPN response. When that happens it inserts a record into the orders_status_history table with the comments field containing the IPN response.


    I can't see any reason why IPN can't insert the record at the same time as it creates the order, and updates it when IPN confirmation arrives.


    The problem is when records are deleted from the order tables because an order has not received an IPN response from PayPal. Currently the logic detects that situation by the absense of a record in the orders_status_history table, so if we're going to pre-insert to capture the customer's comment we need another way of detecting that IPN never happened.


    Fortunately that is simple to do. My code inserts the customer comment into orders_status_history pre-payment, and then when the IPN confirmation arrives prefixes the current comment with the IPN result. So to delete unconfirmed orders the detection logic simply looks for orders_status_history->comment that doesn't begin "PayPal IPN Verified".


    So, to the modifications (beware typo's here - I was very tired when I knocked this together)...


    In catalog/includes/modules/payment/paypal_ipn.php at or around line 186 add the insert logic:

    			tep_db_perform(TABLE_ORDERS_TOTAL, $sql_data_array);
    	  $sql_data_array = array('orders_id' => $insert_id,
    					  'orders_status_id' => $order->info['order_status'],
    					  'date_added' => 'now()',
    					  'customer_notified' => '0',
    					  'comments' => $order->info['comments']);
    	  tep_db_perform(TABLE_ORDERS_STATUS_HISTORY, $sql_data_array);
    	  // *** END MODIFICATION
    	  for ($i=0, $n=sizeof($order->products); $i<$n; $i++) {

    and alter the delete unconfirmed orders logic at or around line 95 by changing

    $check_query = tep_db_query('select orders_id from ' . TABLE_ORDERS_STATUS_HISTORY . ' where orders_id = "' . (int)$order_id . '" limit 1');


    $check_query = tep_db_query('select orders_id from ' . TABLE_ORDERS_STATUS_HISTORY . ' where orders_id = "' . (int)$order_id . '" and comments NOT LIKE 'PayPal IPN Verified%' limit 1');

    In catalog/ext/modules/payment/paypal_ipn/ipn.php at or around line 105 add the comment-update logic:

    		// new code to cope with customer comments being inserted during the pre-payment phase
    	$sql = "select * from ".TABLE_ORDERS_STATUS_HISTORY." where orders_id='"$_POST['invoice']."'";
    	$result = tep_db_query($sql);
    	if (tep_db_num_rows($result) > 0) {
    	  $order_status = tep_db_fetch_array($result);
    	  $comment_status .= ']-[' . $order_status['comments'] . ']';

    and a few lines further on, replace the tp_db_perform() statement so the current

    tep_db_perform(TABLE_ORDERS_STATUS_HISTORY, $sql_data_array);


    tep_db_perform(TABLE_ORDERS_STATUS_HISTORY, $sql_data_array, 'update', "orders_id='".$_POST['invoice']."'");

    Hopefully that lot isn't too full of holes. Try it out and report back errors... I'll try it myself in a fresh development setup this week.

  7. Correction/update

    Fix for the cart not being cleared on checkout


    The cart isn't cleared because in includes/application_top.php the cart is rebuilt from the session-variable cart. The fix appears to be simple (anyone know why this isn't a good idea, please shout!) ...


    In catalog/checkout_success.php at or around line 13, after the require('includes/application_top.php'); add two lines to rcreate an empty cart:

    tep_session_unregister('cart'); // TJ mod
    $cart = new shoppingCart; // TJ mod to clear cart after successful transaction

  8. When Paypal send the IPN info back and modifies the order status table, it should add simple comments i.e. PayPal IPN Verified [Completed] . Instead however, I'm getting HTML formatting codes in there aswell, PayPal IPN Verified [Completed (Unverified; <span class=currency_symbol>?</span>5.89<span class=currency_symbol></span>)] , which makes it look very untidy.

    The comment is built at or around line 87 of catalog/ext/modules/payment/paypal_ipn/ipn.php:

    $comment_status = $_POST['payment_status'] . ' (' . ucfirst($_POST['payer_status']) . '; ' . $currencies->format($_POST['mc_gross'], false, $_POST['mc_currency']) . ')';

    currencies->format() is defined in catalog/includes/classes/currencies.php at or around line 35. The commands executed are in the else clause because calculate_currency_value = false.

    		$format_string = $this->currencies[$currency_type]['symbol_left'] . number_format(tep_round($number, $this->currencies[$currency_type]['decimal_places']), $this->currencies[$currency_type]['decimal_places'], $this->currencies[$currency_type]['decimal_point'], $this->currencies[$currency_type]['thousands_point']) . $this->currencies[$currency_type]['symbol_right'];

    I'd guess from this you have defined your currency strings with CSS styles in Admin->Localization->Currencies, or have used a template or other modification that does this.

  9. Here's what I've added:

    define('MODULE_PAYMENT_PAYPAL_IPN_TEXT_TITLE', 'PayPal (Credit Card / Debit) <br></b>After payment at paypal, please click <b>Return to Mechant</b> to complete your order.');




    Any takers on this. I know it's only a simple line added during checkout but I'm not 100% confident when playing with the IPN php files. Just need to know if there any other files I need to alter. Cheers Andy.

    I meant to say earlier that if the PayPal account has its Auto-Return enabled and set to the location of your ]checkout_success.php the browser will be automatically returned to the shop, and the customer will not see the Return to Merchant button.




    Fix for the cart not being cleared on checkout


    The cart isn't cleared because in includes/application_top.php the cart is rebuilt from the session-variable cart. The fix appears to be simple (anyone know why this isn't a good idea, please shout!) ...


    In catalog/checkout_success.php at or around line 13, after the require('includes/application_top.php'); add a line to recreate an empty cart:

    $cart = new shoppingCart; // TJ mod to clear cart after successful transaction

  10. Per-item vs Encryption In IPN v.1.1 MS2

    -- Per-Item Display Feature Blovked by Web Payment Encryption


    Just wonder if anyone else also experienced the problem below:

    I wondered about this... checked out the IPN source code in catalog/includes/modules/payment/paypal_ipn.php and found this in function process_button():

    	$parameters['cmd'] = '_cart';
    	$parameters['upload'] = '1';

    Inside this conditional clause the IPN module only builds a list of items if Encryption is disabled. The else clause has this:

    		$parameters['item_name'] = STORE_NAME;

    It means that an encrypted transaction doesn't get the list built. I suspect it has something to do with PayPal accepting limited data when using encryption.


    However... I decided to try it anyhow, and it worked :-" I simply changed the initial if() statement to:


    I don't know if there are reasons for this not to be allowed, or whether there were reasons which have since been worked out, but its worth testing it.

  11. Using the Paypal sandbox I've satisfied myself that the Paypal account IPN and Auto-Return options don't need to be set when using the OSC IPN module - phew!


    A slight correction to this. If the PayPal account Auto-Return option is disabled then the customer sees a Return to Merchant button. The option has to be enabled in the PayPal account for the customer to be returned to the shop automatically.


    I had mistakenly thought that the OSC IPN module set the Auto_return option itself.

  12. Andy, I think that change to the title might present a problem if other modifications rely on the contents of the orders.payment_method field being PayPal (Credit Card / Debit).


    I've just modified catalog/checkout_success.php to show the PayPal-mandated auto-return text if the payment method is IPN, and I detect the payment method using that value.


    This is my article about it, in a different topic. Now i've found this topic I guess I should move it here.

  13. I added the variable/code you suggested and in testing it discovered what seems to me to be a serious issue with the IPN module.


    First, how to add the detection logic.


    In catalog/checkout_success.php add the payment_method field to the query on or around line 41:

    $orders_query = tep_db_query("select orders_id, payment_method from " . TABLE_ORDERS . " where customers_id = '" . (int)$customer_id . "' order by date_purchased desc limit 1");

    and add conditional logic to the echo statement that prints the success message, on or around line 80:

    <?php echo ($orders['payment_method']=="PayPal (Credit Card / Debit)" ? TEXT_SUCCESS_PAYPAL : TEXT_SUCCESS); ?>

    Then finally add the definition to the language files. For English this is catalog/includes/languages/checkout_success.php:

    define('TEXT_SUCCESS', 'Your order has been successfully processed! Your products will arrive at their destination within 2-5 working days.');
    define('TEXT_SUCCESS_PAYPAL', 'Thank you for your payment. Your transaction has been completed, and a receipt for your purchase has been emailed to you. You may log into your account at <a href="http://www.paypal.com" target="external">www.paypal.com</a> to view details of this transaction.');


    Now to the IPN problem. I currently have one product in my test shop, which has three product options, and therefore three price options.


    After completing the first purchase IPN returned me to the checkout_success.php page from where I continued shopping. I selected the product again and chose a different product option and added it to the cart.


    I was surprised to see the cart still contained the product I'd just successfully purchased, but I left it as it was and continued.


    When I reached Paypal and signed in, after clicking the Pay Now button, I got an error report

    Error Detected

    This invoice has already been paid. For more information, please contact the merchant.

    The Order shows in OSC with status Preparing [PayPal IPN].


    I then tried emptying the cart in my shop and starting again, and got the same error.


    I signed out of the shop (to cancel the session) then signed back in again. The cart still contained the single item so I went through the checkout process again, and got the same error.


    I emptied the cart, signed out of the shop, signed back in and tried again, and this time it succeeded.


    Firstly, why is the item remaining in the cart? Is this something to do with the IPN pre-insert order into database logic?


    Secondly, I can't understand why Paypal thinks the order is the same one. Surely the orders_id is passed as an identifier to Paypal? I'm choosing different options to give different order values. In the IPN module I have configured Transaction Type as Per Item.


    I also noticed that PayPal shows the item being paid for as the name of the shop, not the item(s) choosen. I seem to recall reading about that as an issue here on the forums but can't find the article now I want it. Can anyone recall where the information on fixing this problem is?

  14. Using the Paypal sandbox I've satisfied myself that the Paypal account IPN and Auto-Return options don't need to be set when using the OSC IPN module - phew!


    I have however come across an issue, to do with the placing of the Paypal-mandated text on the auto-return page.


    With IPN this is the page checkout_success.php. I added the text to the includes/languages/english/checkout_success.php page, in the TEXT_SUCCESS variable.


    It occurred to me that this isn't a good idea, because this page will be seen by customers using other modules to make their payments - having to mention Paypal in that situation would be extremely confusing!


    Is there another way to deal with this?

  15. I found this post by mightymidget which says, in passing, that when using the IPN module from the OSC team, we do not need to configure the Paypal account IPN or Auto-Return options because those details are passed to Paypal when the IPN module sends the customer there for payment.


    As a side note, once the IPN is installed you do not need to enable IPN at paypal, or switch auto return on, these will make no difference what so ever. All of this fuctionality is built into the modules code and is sent with the payment request.

    Is this correct? If so it would explain why I've been getting so confused. It certainly seems the way to do it from a technical point of view, but I'd like it confirmed by people who know whats what.


    If it is, please get this information added to the IPN contribution install.html in BIG LETTERS so it doesn't take several hours of cotton-wool-brain searching of forums to ferret out :blink:




  16. While this discussion is on-going, can someone explain clearly and precisely how the OSC IPN module and Paypal's Auto-Return operate (the data flow is what I need to understand) ?


    How precisely is the IPN notification received? Is it the HTTP RESPONSE to an HTTP REQUEST made by the OSC IPN module or an asynchronous HTTP POST initiated from Paypal to the OSC IPN module?


    In the Paypal account's IPN settings it requires an IPN URL belonging to the shop, but I don't see any documentation of what that should be set to in the IPN module. What should it be set to?


    How does Paypal Auto-Return relate to this? I've seen various posts saying this should be enabled and set to the OSC checkout_success.php page (presumably we have to manually edit that to contain the Paypal-mandated text?).


    If the Payal account Payment Data Transfer is enabled, there is an Identity token to go with it. I don't see anywhere in the OSC instructions on where that should be set.


    I've configured the OSC IPN module with openSSL and set up the key and certificates, and I'm a PHP open-source hacker so I'm not short on technical ability, but everything I've read so far seems just so disjointed and incomplete.




  17. I've discovered a logic error in one of the Javascript functions.




    In check_input(field_name, field_size, message)


    if (field_value == '' || field_value.length < field_size) {

    error_message = error_message + "* " + message + "\n";

    error = true;


    The condition in the if clause doesn't allow for field_size being set to 0 (zero) in the osCommerce Admin->Configuration->Minimum Values.


    It should read:


    if ((field_size > 0 && field_value == '') || field_value.length < field_size ) {

    error_message = error_message + "* " + message + "\n";

    error = true;



    Its an issue that affects many, many applications where the designers arbitarily assume that everyone will have an Anglo-Saxon-style first-name last-name. My name in particular often causes such applications to refuse data or get confused - its simply "TJ" - not an abbreviation, and only one word.

  18. I've discovered the reason for the failure of the BTS templates...


    After installing them and doing an initial run-through, I re-enabled the osCommerce cache.


    Checking the Admin->Tools->Cache Control I noticed that two 'boxes' listed were the two showing problems with BTS - Catagories and Manufacturers.


    I tried clearing the caches for these, and the help template again showed the CSS developer info but not all the Categories or Manufacturers.


    I then disabled caching in Admin->Configuration->Cache "Use Cache"=false and the site appears to be working correctly.

  19. I've been running osCommerce 2.2-M2 in its 'vanilla' out-of-the-box configuraiton without any problems with Windows 2003/IIS/PHP 5.0.3/MySQL 4.1.7-nt (with the hacks mentioned previously) without a problem for a year now.


    It was only when I installed BTS (hoping to make it easier to customise the look-n-feel) that I ran into this problem.


    I guess I'll just have to go back to the vanilla installation.

  20. I've just installed BTS v1.5f over a virgin installation of osCommerce 2.2-ms2, on Windows 2003 Advanced Server with IIS, using PHP 5.0.3 and MySQL 4.1.7-nt.


    After installation of BTS whenever product_info.php?products_id=XX is called the product info shows "Product not found!" and the page title is prefixed with "- ?0.00".


    Also, I've just noticed that all the Categories are failing to display in the Categories box.


    I seem to have solved the "Product not found!" issue by adding into /catalog/includes/application_top.php my fix for working with PHP 5.0.3 documented in my post No Language Text in Admin console


    // added to support PHP 5.0.x by TJ (add at or before line 25)



    There are still issues with the Categories box being empty, and I've found when switching to the fallback template the Categories and Manufacturers boxes lose their box-borders and formattin.


    I'm hacking about to try and fix this, but at the time of writing you can see the store with these issues at Phwoarrr Store