Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Jerah

Archived
  • Posts

    56
  • Joined

  • Last visited

About Jerah

  • Birthday 04/28/1971

Profile Information

  • Real Name
    Jeremy
  • Location
    Australia
  • Website

Jerah's Achievements

  1. In its current form, I was still not able to get PWA and this contrib (CSS) to work together. What i ended up doing was adding the refresh_form (appropriately modified, with form_name defined as the name of the form on that page) to every page that would call the function. Suddenly it started working. (Yes I checked and double checked that form_check.js.php was being included, and it is...) Someone better at Javascript can scratch their head over that one, I'm just glad it's working for me again. :)
  2. Line 79 of your english.php is define('BOX_HEADING_WHATS_NEW', 'What's New?'); This error has nothing to do with the PWA contribution. Did you OSCommerce run OK before you installed PWA? Always look on the line number mentioned for a typo or an error. If you haven't got a text editor (not Wordpad or Word, a text editor) that shows line numbers, I recommend you get one as it is very helpful. With that error, you especially what to look for something that will start or end the string/words you are trying to define. Can you see what I think is the problem in your line 79 yet? Once it dawns on you, you will slap yourself on the forehead with a Homerific "D'oh!" Okay, time's up. You can see in the define statement above that what you're trying to define (BOX_HEADING_WHATS_NEW) and the value you're giving it (What's New?) are surrounded by apostrophes like so ' '. You will also notice that in the word What's you've got, yes, another apostrophe. So PHP is thinking that you're ending the value there after the letter t in the word What. It's defining BOX_HEADING_WHATS_NEW as 'What' and then it has no idea what the hell you're trying to say with the rest, until it eventually reaches another ' and now it's so confused, it spits out an error at you. What you need to do is add the "escape" character, which is a character that tells PHP to IGNORE the character that immediately follows it. The escape character is \. So, the correct line is: define('BOX_HEADING_WHATS_NEW', 'What\'s New?'); Somehow, you lost the \. If OSC was working prior to you installing PWA, somehow you changed it. Never mind, it happens, and testament to that is the amount of hair I've pulled out over stuff like this. :)
  3. I've done a search and not found a good answer to this question. Is there an easy way to remove PWA customers/details from the database? It can be done through direct db access (eg phpMyAdmin) and search for customers with a PWA setting of 1. However, to delete the customers you then have to delete not only from the customers table but customers_info, matching up customer ids. Is there an easier way? A "one button" solution?
  4. I had the same issue. I fixed it, but I don't recall what file that routine (tep_get_header_tag_products_desc) is in. Here's how I did it though: Do a search of the php files in your /includes directory for that phrase (tep_get_header_tag_products_desc). When you find it, you'll also find that that line is commented out with a double slash (//). Remove the //, save, upload. Works. Now, why that line is commented out I have no idea. Especially since other parts of the code still refer to it. Uncommenting that line doesn't appear to have affected how the contrib acts in any other way. This was the only way I could get my Reviews pages to work correctly.
  5. Please don't resort to name calling or insulting other people's intelligence. Not everyone has the same level of design, coding or language skills. Refer to Forum Rules. Check out the Contributions section (link at the top of this page) and search for "Simple Template System". Or, try here: http://www.oscommerce.com/community/contributions,1524
  6. I've just found another slight bug in PWA. Nothing serious. What happens is when you update an order status, and an email is sent to the customer, instead of the name of the store appearing as the first line in the email they instead get This is due to a typo in orders.php. This typo is located in the pwa changes to this file. For me, this is around like 51. The line is: $pwa_check_query= tep_db_query("select purchased_without_account from " . TABLE_ORDERS . " where orders_id = '" . tep_db_input($oID) . "'");$pwa_check= tep_db_fetch_array($pwa_check_query); if ($pwa_check['purchased_without_account'] != '1'){ $email = STOR_NAME . "\n" . EMAIL_SEPARATOR . "\n" . EMAIL_TEXT_ORDER_NUMBER . ' ' . $oID . "\n" . EMAIL_TEXT_INVOICE_URL . ' ' . tep_catalog_href_link(FILENAME_CATALOG_ACCOUNT_HISTORY_INFO, 'order_id=' . $oID, 'SSL') . "\n" . EMAIL_TEXT_DATE_ORDERED . ' ' . tep_date_long($check_status['date_purchased']) . "\n\n" . $notify_comments . sprintf(EMAIL_TEXT_STATUS_UPDATE, $orders_status_array[$status]); } Of course it should be: $pwa_check_query= tep_db_query("select purchased_without_account from " . TABLE_ORDERS . " where orders_id = '" . tep_db_input($oID) . "'");$pwa_check= tep_db_fetch_array($pwa_check_query); if ($pwa_check['purchased_without_account'] != '1'){ $email = STORE_NAME . "\n" . EMAIL_SEPARATOR . "\n" . EMAIL_TEXT_ORDER_NUMBER . ' ' . $oID . "\n" . EMAIL_TEXT_INVOICE_URL . ' ' . tep_catalog_href_link(FILENAME_CATALOG_ACCOUNT_HISTORY_INFO, 'order_id=' . $oID, 'SSL') . "\n" . EMAIL_TEXT_DATE_ORDERED . ' ' . tep_date_long($check_status['date_purchased']) . "\n\n" . $notify_comments . sprintf(EMAIL_TEXT_STATUS_UPDATE, $orders_status_array[$status]); } Note: STOR_NAME has been made STORE_NAME. Now the name of the store will print correctly in the email. I advise everyone using PWA to run a check of their status update emails.
  7. For those following along, Spaceboy's recommend change I've detailed below. 1. Backup "Order_Info_Process.php". 2. Edit "Order_Info_Process.php". 3. Find (around line 423 in a vanilla PWA 0.81 - it's about four lines from the bottom): tep_redirect(tep_href_link(FILENAME_CHECKOUT_PAYMENT, '', 'SSL')); 4. Change to: tep_redirect(tep_href_link(FILENAME_CHECKOUT_SHIPPING, '', 'SSL')); 5. Save and upload. It worked for me a treat. Hopefully it will help with anyone else having this issue. :thumbsup:
  8. Of course, it doesn't really require a support forum. It's an extremely simple hack, but just a resolution for something that has annoyed me for a little while about osc - that if a customer checks out in a different currency than your default, the order comes through in that currency. At least this way you can see what the prices are in YOUR currency.
  9. BINGO! It was something to do with State/Country selection. After changing that line, when I put in a made up address, the page after was asking me to confirm those details and select a state for the country I had entered (Australian in this case). There rest of the process went fine and when I got to the confirmation page - NO ERROR. Woohoo!! I completed the order and checked the admin - yes, the order is there. I double checked with a country for which I do not have the state information. Worked! The contrib functions perfectly. Time to update your code m'lad! And a hearty well done.
  10. I really appreciate the work you're doing on this. It's a fantastic contrib.
  11. Support forum for "Show per item default currency price in orders" contribution available at: http://www.oscommerce.com/community/contributions,2617
  12. Thanks for your hard work! I'm a novice PHP programmer - mostly I can examine and copy/paste once I figure out what code does, but finding and isolating bugs is beyond me at this stage. I don't have the Ship In Cart contrib installed, so it's not that. :) I find it interesting that the Billing Address has so such error - for a PWA they are, of course, the same data but the BA comes up fine on the Order Confirmation page. Something worth examining?
  13. It appears every time. I use both PWA and Accounts (I call them Profiles for marketing purposes ;) ). For testing I just make up an address, so I don't replicate something I've used before. Though supposedly that's not an issue with .81 of PWA... It's a pain in the butt. When the shop went live PWA was working, then suddenly I started getting the blank page problem after entering details (NAV_TITLE_BAR2 or whatever the missing text definition was) so I decided to upgrade PWA to the latest version. It was fiddly trying to follow the install for an upgrade, but I got there. :) Now though, I get that error. The orders DO work and come through though, but I just hope no customers get scared off by the PHP error.
  14. I just installed 0.81 (had a previous version of PWA but don't recall exactly what that is) and now I'm getting an error on the "Confirm order" page: (The directories have been edited.) It has something to do with the customer's address, as it appears in the Delivery Address box on the order confirmation page. This is the offending part of general.php: function tep_output_string($string, $translate = false, $protected = false) { if ($protected == true) { return htmlspecialchars($string); } else { if ($translate == false) { return tep_parse_input_field_data($string, array('"' => '"')); } else { return tep_parse_input_field_data($string, $translate); } } } Since general.php was working fine before, I know it's not that. It's some change that PWA has made. Any ideas?
  15. For some reason, I find the trailing 0 in the default currency total is stripped from the output. Anyone else had this problem? For example (with numbers pulled from the air): Total: US$3.00 Total in AUD: $4.5 I've looked through the code but for the life of me can't figure it out (but then, I'm not much of a coder).
×
×
  • Create New...