Latest News: (loading..)

ecartz

‚ô•Ambassador
  • Content count

    1,975
  • Joined

  • Last visited

  • Days Won

    3

ecartz last won the day on December 3 2012

ecartz had the most liked content!

7 Followers

About ecartz

Profile Information

  1. Have you checked Spam and All Mail? Sometimes the validation emails can get stuck in places like those. I had problems like that when they first switched to the new tab interface, as it was helpfully hiding something under Social. So my suggestion is to try it again and then check under Spam and All Mail to see if the notification is stuck in either place.
  2. I don't understand what you are asking. Are you talking about a specific block of code? A file? Or something else?
  3. if (substr($payment_modules->selected_module, 0, 6) == 'paypal') { This would catch any of the modules that start 'paypal', e.g. PayPal Standard, PayPal Express, etc. If you just want to catch Standard if ($payment_modules->selected_module == 'paypal_standard') { This is from memory, so if it doesn't work, try echoing the value to the screen. Note that you have to do this after the payment modules object is created. It won't work at the top of the file. // load the selected payment module require(DIR_WS_CLASSES . 'payment.php'); $payment_modules = new payment($payment);
  4. Try function tep_image($src, $alt = '', $width = '', $height = '', $parameters = '') { if ($request_type != 'SSL'){ $src = str_replace(DIR_WS_HTTP_CATALOG . DIR_WS_IMAGES, 'http://www.store.xxx.com' . DIR_WS_HTTP_CATALOG . DIR_WS_IMAGES, $src); } If that doesn't work, you would need to post the relevant section of configure.php. I.e. the DIR_WS_ and HTTP_SERVER entries. You also might post more details about what you tried and what actually happened.
  5. If you need to POST to survey.php, the other functions that you need are probably tep_draw_form and tep_draw_hidden_field. You also may have to load the customer data to get the email and name. Hopefully that will give you a bit more with which to work.
  6. But then we'd have to have some way of deciding what data was required. So we'd need an extra level of database relations that represented whether page A requires a particular piece of configuration. Then we'd need to load both global configuration (required on every page) and page configuration (required for the current page) plus functional configuration (required for whatever we're doing at the time). And of course, we'd sometimes get it wrong. Plus, there are some pieces of configuration that one store uses only on a few pages while another store might use on every catalog page. Case in point: an add-on that shows shipping fees in the cart info box. That makes shipping configuration required on every catalog page. Yet the vanilla sites only require shipping configuration during the checkout process. So that add-on would have to alter a piece of configuration from being checkout specific to being globally available (at least in catalog). That change would need to persist through a site update. The big advantage of the current system is that it is very simple. Load everything all the time. We never have to worry about missing configuration unless it is actually missing from the database. If we change that, we make it harder for most add-on developers, as configuration that used to be globally available now has to be loaded specially.
  7. That column's already there (value): CREATE TABLE orders_total ( orders_total_id int unsigned NOT NULL auto_increment, orders_id int NOT NULL, title varchar(255) NOT NULL, text varchar(255) NOT NULL, value decimal(15,4) NOT NULL, class varchar(32) NOT NULL, sort_order int NOT NULL, PRIMARY KEY (orders_total_id), KEY idx_orders_total_orders_id (orders_id) ) CHARACTER SET utf8 COLLATE utf8_unicode_ci;Note that it doesn't make the mistake of limiting to just two digits after the decimal point. Four are required for some circumstances. In particular for currencies that have three digits after the decimal point and those times when an extra digit is needed. One reason why the text column exists is that we don't want the order total display to change if we make a change to how a currency displays or to how an order total displays. This makes the display static and consistent. This is common in orders database tables. It maintains consistency. Note also that this allows for displays that have both bold and standard text. If you pull the HTML tags out of the text field, then we lose the ability to set the display at order time as well as the ability to have different displays for different modules. You keep describing this as if it were a small change. It's not. You are talking about fundamentally changing orders_total displays from being generated at order time to being generated at display time. The current system is robust in the face of changes to currencies and to order total modules. Even if an order total module is deleted entirely, the entry will still display correctly. Under your system, you can never remove an order total module without messing up the displays of old orders. I'm sorry that you feel like the community is ignoring obvious ideas. The problem is that changes like this have consequences. Not all of the consequences are immediately obvious. Running manual commands in phpMyAdmin is not sufficient. An update needs to be in the form of an update script so that non-technical people can use it.
  8. In the list of advantages, I don't see any that don't work in the current situation. What osCommerce currently has is a setup where store owners can require cookies but do not have to do so. If we retain things as is, then a store owner can get by enabling cookies (and making any other relevant configuration changes). From a development standpoint, I think that the list of advantages is shorter. The only one that I can see is that it makes the code simpler. However, if we still have to support session IDs in the URL for the secure/insecure switch, then I'm not sure that it matters. The code stays complex (although we do save a configuration check). Obviously, the disadvantage is losing the option of allowing URL passed session IDs.
  9. It's not clear to me why the language would make a difference. None of the new SQL queries are language dependent. Also, if I try it on my test site, it works (at least in Spanish and German). Perhaps the problem would be more obvious if you posted a link to the page that is not working?
  10. The relevant section of code is if ($check_email['total'] > 0) { $error = true; $email_exists = true; $messageStack->add('checkout_address', sprintf(ENTRY_EMAIL_ADDRESS_EXISTS_ERROR, tep_href_link(FILENAME_PASSWORD_FORGOTTEN, '', 'SSL'))); } However, I don't know that there is a simple fix that preserves the advantages of the current system. One possibility would be to delete the previous row or change the email address in it so that the new row could be added. That's what the Purchase without Account contribution does. E.g. something like if ($check_email['total'] > 0) { tep_db_query("delete from " . TABLE_CUSTOMERS . " where customers_email_address = '" . tep_db_input($email_address) . "'"); } Note: I haven't tested this in any way.
  11. The name of the add on is Checkout Redux.
  12. As written, guests should not be able to see My Account, as they don't have an account and wouldn't be able to use any of the My Account links. No historical orders, no password to change, etc. The only thing that they could do would be to edit addresses, and there is already provision in checkout for that.
  13. For 1, you would change // charset for web pages and emails define('CHARSET', 'iso-8859-1'); to the appropriate charset in includes/languages/russian.php (or whatever language). Russian currently looks correct on your site, appearing in KOI-8. Maybe you fixed this. You also might need to make the same change in the admin languages file. For 2, if you were using the original template, the navigation would look like <td align="right" class="headerNavigation"><?php if (tep_session_is_registered('customer_id')) { ?><a href="<?php echo tep_href_link(FILENAME_LOGOFF, '', 'SSL'); ?>" class="headerNavigation"><?php echo HEADER_TITLE_LOGOFF; ?></a> | <?php } ?><a href="<?php echo tep_href_link(FILENAME_ACCOUNT, '', 'SSL'); ?>" class="headerNavigation"><?php echo HEADER_TITLE_MY_ACCOUNT; ?></a> | <a href="<?php echo tep_href_link(FILENAME_SHOPPING_CART); ?>" class="headerNavigation"><?php echo HEADER_TITLE_CART_CONTENTS; ?></a> | <a href="<?php echo tep_href_link(FILENAME_CHECKOUT_SHIPPING, '', 'SSL'); ?>" class="headerNavigation"><?php echo HEADER_TITLE_CHECKOUT; ?></a> </td> and would be localizable. If your template does not do this, then you would need to change it so that it does. It would be hard to explain further without seeing the code that your template uses to display the navigation, but the idea is that you should replace hard coded strings like Home with code like <?php echo HEADER_TITLE_TOP; ?>
  14. In admin >> Configuration >> My Store, there should be an option for "Template Switching Allowed". Set that to true, and the template switcher should appear at the top of the page in the included templates. If you need to add it to a new template, it's the following code: <?php // include template switcher in every template if ( bts_select('common', 'common_top.php') ) include (bts_select('common', 'common_top.php')); // BTSv1.5 ?>
  15. Are you using an option types contribution? The installation should show you where you need to make changes to pass a date rather than a MySQL ID. The simplest thing would be to install something like Option Types v2 and then use the text passing capability to pass the date value (rather than try to pass a MySQL date value). Date would simply be a new option type in that scenario, a new case in various switch statements.