Matt L

Ok guys, I haven't read all 113 or so pages of this thread, but I've looked around, and it doesn't look like there's a *SINGLE PAGE* of documentation for this contribution. While the contribution itself looks fantastic, there's zero docs on how it works. The FAQ isn't nearly sufficient. Releasing a contribution without documentation is like selling a car with an opaque windshield. We really need some nice fat documentation for this contribution explaining exactly how it works. I haven't even installed it yet because I don't know if it accomplishes what I want it to do, because there's no documentation explaining it. Guys, as a developer, I appreciate your work. But if you're going to spend the time working so hard on this code, you should spend some time writing thorough documentation for the people that want to use it. I would never release something like this without extensive documentation. There's not even a README file. I've seen many others complaining about this between this forum, sourceforge, and the .au forums, what's it going to take to get someone (even if it's not the developers) to write some good documentation on this contrib? This contrib was originally released in 2002 apparently, and this current version in 2003, and we're still without desperately needed documentation. -Matt

Will that make paypal re-try the IPN later? Otherwise it's not much use as the problem would still occur, it would just be a different error code in the logs. Also, what's the deal with the authenticate routine? What are the most common reasons it fails that aren't obvious things like timeout issues? Are there sometimes Paypal processing delays that can cause the authentication to fail for a seemingly legitimate reason? Anything subtle like that? A temporary solution would be to rename ipn.php to something non-obvious that only paypal would know about, then dropping the authenticate routine altogether until the bug is fixed. Obviously that's a lot less secure (and isn't good practice) than fixing the actual problem, and I tend to avoid those types of solutions... Anyone else having this specific problem? I know I've seen some chatter about it along the thread at some point, but not to this level of detail. -Matt

I now see that the dienice routine throws up 204 when the authenticate routine fails. Obviously there's any number of reasons this could happen intermittently. Anyone have any common issues with the authenticate routine that can be worked around? I'm considering increasing the CURL timeout, but for some reason I doubt that's the problem. I'm about to flip on debugging and try to catch the bug in the act again, but if someone's already been through this, I'd like to hear it. :) Thanks, -Matt

...make that 8 times since June 24th, amounting to around $200 in sales-that-were-paid-for-but-never-got-to-the-processing-stage. Ouch. :) Anyone who has ideas on what would cause ipn.php to throw up 204s intermittently, I'd like to hear them...my cart is live and I'm going to hold off on extensive code debugging until I hear if anyone else has dealt with this before and has a simple solution. Thanks, -Matt

Guys, I've been using osCommerce for a couple years, and recently upgraded my previous IPN solution to this one. Now, I'm getting the "stuck in paypal processing bug", which is directly related to some sort of bug in ipn.php that's causing it to throw back HTTP ERROR 204s (No Content). As shown here: 216.113.188.202 - - [28/Jun/2004:17:33:15 -0700] "POST /ipn.php HTTP/1.0" 200 0 "-" "-" 216.113.188.202 - - [28/Jun/2004:20:52:21 -0700] "POST /ipn.php HTTP/1.0" 200 0 "-" "-" 216.113.188.202 - - [28/Jun/2004:21:05:55 -0700] "POST /ipn.php HTTP/1.0" 204 0 "-" "-" 216.113.188.202 - - [30/Jun/2004:11:10:31 -0700] "POST /ipn.php HTTP/1.0" 204 0 "-" "-" You'll see that we had two successful (code 200) transactions, followed by two unsuccessful (code 204) transactions. Paypal attempted to give us an IPN on those four occasions, and two of them "broke" on our side, generating no response and not updating the order, and leaving nothing in the error log to go by. Note that in both of the 204 cases, the paypal payment was successful, and the order never got entered into our system, as it was stuck in "paypal processing". This caused both of those buyers to have orders that we never got, yet they paid for them. This also left us unable to "force" the generation of an order email without modifying the code, which was frustrating. This module, considering that it relies on third-party servers (paypal) talking to code on our end, should definitely have a "Something went awry, force this order to finish processing" button that can be activated from the admin interface. If anyone else has had the 204 problem and has a solution that will keep it from happening in the future, I'd like to hear it. I've had 3 204 errors in the past 7 days leading to orders being paid for and not generating emails or moving to the processing stage. Thanks, -Matt

Contribution Added - http://www.oscommerce.com/community/contributions,2170 This is a beta version, although is fully functional in my cart. Bug reports or questions can be posted here, I'll be checking on and off for the next few weeks. Enjoy. -Matt/barkode

This is the support thread for the about-to-be-announced cross-browser PNG Alpha Transparency addon. More information coming shortly.

I *just* emailed him about this: The code is missing characters all over the place. Here is the correct code. case 'del_images': $additional_images_id = tep_db_prepare_input($HTTP_GET_VARS['pID']); if ( ($HTTP_POST_VARS['products_id']) && (is_array($HTTP_POST_VARS['additional_images_id'])) ) { $product_id = tep_db_prepare_input($HTTP_POST_VARS['products_id']); $additional_images_id = $HTTP_POST_VARS['additional_images_id']; for ($i=0; $i<sizeof($additional_images_id); $i++) { tep_db_query("delete from " . TABLE_ADDITIONAL_IMAGES . " where additional_images_id = '" . tep_db_input($additional_images_id[$i]) . "'"); } } //tep_db_query("delete from " . TABLE_ADDITIONAL_IMAGES . " where additional_images_id = '" . $HTTP_POST_VARS['additional_images_id'] . "'"); tep_redirect(tep_href_link(FILENAME_CATEGORIES, 'cPath=' . $cPath . '&pID=' . $products_id)); break; As you can see, the sql statement, the tep_href_link, and the sizeof, were all missing characters. This occurs only in the categories_changes file, but is correct in the categories.php file provided with the contrib. I managed to guess that this was the case by guessing that "si" was a mistype for "sizeof", which lead me to this discovery. -Matt Lewis [/CODE][CODE]