Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

chuckh2d

Pioneers
  • Posts

    54
  • Joined

  • Last visited

Profile Information

  • Real Name
    Chuck Warner

chuckh2d's Achievements

  1. Hi Alex- I have updated catalog/includes/modules/payment/paypal_ipn.php from your PayPal_IPN 2.3.4.7 with the code for SDS 1.0 using the instructions that you referred me to here [#entry1036762 ] While the unchanged file [paypal_ipn.php,v 2.3.3.0 11/17/2007 11:15:28 alexstudio] works fine, as does my heavily-amended previous version [paypal_ipn.php,v 1.3.0.0 2006/06/22 19:29:00 Edith Karnitsch (whose components of course are arranged in a different sequence)], the SDS1.0 additions cause BOTH files to fail - whether it's an attempted download purchase (bypassing checkout_shipping.php) or when a customer attempts a standard purchase (proceeding normally from checkout_shipping.php to checkout_payment.php. Working with your 2.3.4.7 file (+SDS1.0) I get this error at the point where checkout_payment.php should appear: Parse error: syntax error, unexpected T_STRING, expecting ')' in .../catalog/includes/modules/payment/paypal_ipn.php on line 158 where line 158 is totally normal: 'delivery_state' => $order->delivery['state'], By adding blank lines in different places I was able to determine that the actual error comes from the added line 176: 'last_modified' => 'now()', (Adding four blank lines before line 176 changes the error message from "...line 158" to "...line 162". Adding the blank lines after line 176 results in the original error message for line 158. It makes no difference whether the new line is inserted before or after the line "'date_purchased' => 'now()',") If I comment out the added 'last modified' line, I get this error instead: Parse error: syntax error, unexpected T_STRING in .../catalog/includes/modules/payment/paypal_ipn.php on line 230 where line 230 is: $attributes_query = "select popt.products_options_name, poval.products_options_values_name, pa.options_values_price, pa.price_prefix, pad.products_attributes_maxdays, pad.products_attributes_maxcount , pad.products_attributes_filename All these tables and fields are present in my database. (And I do not think there is any error-line transposition occurring here. This line 230 and in fact the entire stretch from 211 to 254 are the unchanged original IPN language - and are identical in my previous version.) My checkout_payment.php (in whose place the error message is displayed) is an unaltered file from the 2.2 rc2a release. The 'last modified' field in my orders table is working properly and is set to null=yes, default=null. and my settings in the osC control panel are conventional. What could be causing the failure message? thanks for your help - C.
  2. paypal_ipn.php adaptation needed for SDS 1.0+ please? I've been comparing both the current RC2a paypal_ipn (catalog/includes/modules/payment/paypal_ipn.php) and my previous version with the SDS1.0 changes to checkout_process.php and - whatever my expertise may be with php - it is not at all clear where to insert/duplicate the SDS1.0 code to paypal_ipn.php, especially where it's a decision whether to insert them before a segment that is unique to paypal_ipn.php, or where lines in checkout_process.phpypal_ipn.php (for example, lines 161-172 in the SDS1.1 checkout_process.php). Are there explicit instructions for this anywhere? I've been through the entire SDS support forum several times - which was massively difficult until I figured out where the settings were for the new display system [hiding the topic titles by default... what's up with that?], and I can't find anything like that. Better yet, Alex, is there any reason why we can't get a plain vanilla paypal_ipn.php that's been successfully adapted for SDS 1.0? Either (1) included as part of the standard SDS download or (2) posted as a stand-alone add-on to the main contribution (#4868). Or even built into one of your separate paypal contributions? Please, have mercy on us unworthy disciples and show us the way! I will gladly donate to the cause. To any other SDS users, even if you can't post it to this thread, I'd be grateful for a PM or an e-mail if you've solved the paypal_ipn.php riddle. The other thing on my SDS wish-list is a full set of instructions for entering and updating data into the new SDS admin/products_attributes.php screen. I've now got it more-or-less figured out, but it seems like each item I add brings new confusions and surprises. For instance, how to set File Groups back to status "0" - or how to either hide or attach file sizes to the Product Attributes entry area - instead of having to enter them as "Option Values". (I have a record-label with 50+ releases - with three or four download formats each that's 150-200+ option values I'll need to establish...). At this point I may need to simply hide that on the product display page and include the actual download sizes in the product description... gratefully, C.
  3. (continuing the message) ...do not seem to correlate with anything in paypal_ipn.php (for example, lines 161-172 in the SDS1.1 checkout_process.php). Are there explicit instructions for this anywhere? I've been through the entire SDS support forum several times - which is massively difficult with osC's horrible new display system [hiding the topic titles - what's up with that?], and I can't find anything like that. Better yet, Alex, is there any reason why we can't get a plain vanilla paypal_ipn.php that's been successfully adapted for SDS 1.0 either (1) included as part of the standard SDS download or (2) posted as a stand-alone add-on to the main contribution (#4868). Or even built into one of your separate paypal contributions? Please, have mercy on us unworthy disciples and show us the way! I will gladly contribute to the cau$e. To any other SDS users, even if you can't post it to this thread, I'd be grateful for a PM or an e-mail if you've solved the paypal_ipn.php riddle. The other thing on my SDS wish-list is a full set of instructions for entering and updating data into the new SDS admin/products_attributes.php screen. I've now got it more-or-less figured out, but it seems like each item I add brings new confusions and surprises. For instance, how to set File Groups back to status "0" - or how to either hide or attach file sizes to the Product Attributes entry area - instead of having to enter them as "Option Values". (I have a record-label with 50+ releases - with three or four download formats each that's 150-200+ option values I'll need to establish...). At this point I may need to simply hide that on the product display page and include the actual download sizes in the product description... gratefully, C.
  4. paypal_ipn.php adaptation needed for SDS 1.0+ please! I've been comparing both the current RC2a paypal_ipn (catalog/includes/modules/payment/paypal_ipn.php) and my previous version with the SDS1.0 changes to checkout_process.php and - whatever my expertise may be with php - it is not at all clear where to insert/duplicate the SDS1.0 code to paypal_ipn.php, especially where it's a decision whether to insert them before a segment that is unique to paypal_ipn.php, or where lines in checkout_process.php
  5. Hover changes background color back to white... I've just spent the weekend finishing up a move to a new server and installing BDP 2.5 (then deciding that I didn't want the resize and css buttons features - see next posting). Everything's now the way I want it at my site (http://hyped2death.com/catalog/), except that when a user mouses over the table-cells for the category images and descriptions on the front (index.php) page, the table background turns white - and stays that way, even if the category is not selected. There are no "hover" or "table" background statements to explain this in stylesheet.css, and the identical background does not change with hovering anywhere else on the website. The problem occurs with Firefox and Safari/Webkit, and presumably with any other browser. Does this ring any bells? It's not a major bug, but it's annoying to me after making all the stylesheet changes. (I can't get osC search function to recognize spaces today and I hatehatehate the new collapsed-thread views: they're awful for any but the most obvious searches!!) Thanks much!
  6. Just in case this helps anyone. I installed Sort Order 1_2_3 carefully and was able to use the "back end" features, but like several others I was not seeing any change in my front-end displays. I think I made Beer Monster's "order by" fix to index.php and nothing changed.(but see below) I removed the database changes (which I had done directly) and re-did them by pasting the text commands into my SQL window (I feel stupid but thanks for showing me that trick) -and still nothing changed. Then I went back to the product list and hit the "Sort Order" button again. I was a litle surprised to see that that zeroed out my previous sequence, but after I re-entered a fresh sort-sequence, and hit save sort order... voila, the sequence is now correct at the front end of my site. UNFORTUNATELY: Every time a customer tried to get to a second page of products under any of my site's categories, there was an SQL error message: It certainly looked as if the problem was my addition of "order by" to the line $listing_sql .= "p.products_sort_order , pd.products_name " . ($sort_order == 'a' ? 'asc' : ''); ..so I took it out again (reverting to the original Sort Order 1_2_3 contribution). And now everything (at last) works fine. Potential moral of this story --if you don't see a proper sort order on your front end-- before you go looking for installation errors, try erasing, re-entering and re-saving your sequence. Thanks much for the contribution. It certainly beats my antique SQL-ophobic workaround from '03 (=inserting invisible numbers before every product name ;o)
  7. Thanks for Vger etc for underlining the perils of card-numbers. Here is a critical message about reverting to SIM and the standard authorize.net module: In brief, it appears that if you have installed any AIM module for authorize.net you cannot go back to the standard osCommerce SIM module without getting Authorize.net to re-set your Response/Receipt urls - this is something you cannot do yourself. I've just had a nightmarish 8 days of lost sales due to a separate sql corruption issue on my server, but while waiting/fuming for my hosting service to restore (or allow me to restore) a backup database, I double-checked my Authorize.net settings - and noticed that settings:Response/Receipt URLs was blank. I looked through the osCommerce forums (there is nothing in the Milestone 2.2 documentation) and found conflicting advice, although catalog/checkout_process.php is "correct". I entered that for both return and relay settings. ...and went on waiting for my database to be restored. When the back-up was restored (at the cost of two weeks' data), PayPal worked perfectly. Authorize.net produced the error message, "There has been an error processing your credit card. Please try again." I realized eventually that this was a problem with the return url settings and --since everything had worked properly before my server problem-- I tried getting rid of them and returning my settings Response/Receipt URLs to blank. When I attemtped a test-mode purchase this returned the error, ""The following errors have occurred. (14) The referrer, relay response or receipt link URL is invalid." With that I contacted an Authorize.net live-chat representative and explained that I wanted to get my Response/Receipt settings restored to their defaults -i.e. before I as the account-holder had entered any information, because deleting them on the settings page did not work. He told me that the catalog/checkout_process.php was correct for AIM, and I said but my module is SIM and ...after a bit more negotiation he was indeed able to restore the defaults quite easily. My settings now LOOK exactly the same as when I had deleted the URLs myself, but my authorize.net works. Perhaps there is a better return page to specify to Authorize.net for the SIM module, but the return setting should obviously be left unconfigured if possible. (I have suggested to authorize.net that they add a user-accessible "clear all settings/return to set-up defaults" option, because once anything has been entered, deleted-and-blank does not mean "none", even though it looks the same. I will try to integrate AuthorizenetConsolidated_1.7.12 AIM later on (Please tell me that the team leaders are already dusting off 1.7.12 and that its thread and support will be back online soon!) but for now I'm just glad to be back in business.
  8. I haven't had someone from outside contact me since my last round of tweaks. Please visit my web-store http://hyped2death.com/catalog and send me a message. I'll post my script (though it should be exactly the same as the Feb/March 06 update with lines 204-251 commented out.) -C.
  9. I don't know how much of the current VVC patch is shared in Super Contact Us, but it looks as though people on your thread have been having similar problems with messages not being sent. The current version 2.1 of VVC is missing an essential file in includes/languages/english/images/buttons/ called button_submit.gif (other languages don't have it --or an equivalent-- either) I've posted a usable button_submit.gif at the contribution page and hopefully it will become part of vvc2.2 rather soon.
  10. The fix and the missing button_submit.gif are available at the VVC contribution-page: http://www.oscommerce.com/community/contributions,1560 With some luck the extra tables will go away with version 2.2
  11. While I was puzzling out the stuff around the second flagged VCC patch, I noticed that there is a "submit" button around line 188 that SHOULD have been visible. (1) There is no button_submit.gif in the current (or any of my earlier) versions of osCommerce, so when the vvc2.1 script called for it, the page displayed a (very small and) ambiguous default button centered underneath the text area. With the 'continue' button five times as large, it was easy to assume that was the correct one to click. I made a rather ugly temporary submit button myself and put it in includes/languages/english/images/buttons, but I assume there's one somewhere at the VVC contribution page that just got left out of the current download. (2) But speaking of sloppy code (my learning curve is quite gradual...), I successfully commented out the confusing extra tables at the bottom (TEXT_IM, etc.: these should be opt-n, not comment-out: how many stores are taking IMs from customers?) and moved up the continue button so that you don't have to scroll down for it. (I think 'discard and return to the store' would make more sense.) to delete the TEXT_PHONE, TEXT_IM, and TEXT_MAIL tables: comment out from line 204 of the current vvc2.1 contact_us.php file (line 201 might be better: I may have left some orphaned code behind as a result... Tables everywhere.) to the end of line 251 (just after the mysterious first of two 'continue' buttons that is already commented out) I'll post a bug report for the misssing .gif file at the contribution page.
  12. Two things: (1) Perhaps not surprisingly the error message ...means exactly what it says. I had inadvertently run the SQL script on a secondary database with too similar a name :-" (lazy db-managers beware!). With the VVC table installed on the correct database, the display works perfectly. (2) I am now having the same problem as I've seen on other threads, which is while 'create an account' works perfectly (sends notices, rejects wrong codes), with vvc2.1 "contact us" 'is worse than broken: the VV code shows up --it doesn't object if it is filled in incorrectly-- and wither tru or fales there is no 'your message has been delivered' splash. (I get the 'Welcome Back [tester]' screen instead). And no messages are sent to me as the store owner. I'll try getting rid of the unnecessary tables (TEXT_IM, TEXT_PHONE, etc) and report back. (My catalog/contact_us.php without the VVC add-on works okay in the meantime as long as Mr. [email protected] doesn't come calling again.) Is Snuff still subscribed to this thread? peace, -C.
  13. I also noticed several differences between the non-VVC portions of the files in the VVC2.1 patch and the same files in Milestone2/05113 (and earlier versions) and I noted them where I could, although I went with the downloaded files. I never got as far as the images, however: my contact us page now has the VVC image missing and an error message The same thing happens at create an account and tell a friend... Has anyone else encountered this? The database table does exist, so along with olimits7's problem I'm looking at GD library issues.
×
×
  • Create New...