Jump to content
Latest News: (loading..)

ecartz

♥Ambassador
  • Content count

    2,002
  • Joined

  • Last visited

  • Days Won

    3

ecartz last won the day on November 26 2018

ecartz had the most liked content!

7 Followers

Profile Information

Recent Profile Visitors

38,173 profile views
  1. ecartz

    Payment Modules Issues

    Some things to try: 1. Does Authorize.net work? I.e. at least let you get to the confirmation page (as I understand it, you're stuck on the payment page). If not, this might be a PHP 5.6 issue, as that's what changed. 2. Have you tried using a diff program like ExamDiff or Kdiff3 to check if the core payment files have been changed? I would try this before trying an update or fresh install. 3. Have you checked compatibility of the payment modules? I.e. are they supposed to work with 2.3.3? I notice that there are modules for Stripe and Authorize.net that are currently part of the distribution. Are you using the Stripe module from 2.3.3? Or a different one? It's possible that 2.3.3 did not have Stripe included. You'd have to download it and check. 4. Have you found that error message in the source files? What sends it? Why? If you have an if statement with multiple clauses, break it up into smaller pieces with different error messages (for debugging; plan to restore the original file later). 5. Make a copy of the site on another domain name and with a separate database. Then try to update that. Then you can see how difficult that is. When I see "edited core", I think of systems like Drupal which use hooks instead of direct code edits. The osCommerce system has relatively few hooks. So "editing core" is often the only way that people can change functionality at all.
  2. The biggest thing that you can do to help voice search is look at what search criteria are actually being used on your site and optimize for them. For example, if you have a lot of searches for blew dresses or fresh meet, make sure that those searches find things listed as blue dresses and fresh meat respectively. You should be doing this kind of thing anyway. But it would currently be focused on typos, like blu dresses or fresh met rather than homophones. Homophones are much more of a problem with voice search, as the voice parser may not always figure out what word is meant. The basic idea is that you track what searches returned no results. Look at them and understand why they failed. For example, if you sell clothes and get a search for fresh meat, that's simple user error that you can ignore. But an empty search for blew or blu dresses when you do have blue dresses is something that should be fixed. You can see this on Amazon and Google. They say something like "Showing results for blew dresses, but did you really mean blue dresses perhaps?" They link to the possible alternative and sometimes they show both results mixed together. When they mix them, they often link both alternatives.
  3. ecartz

    Product image upside down

    That's in the language file (the main one). For example, from includes/languages/english.php, it says: define('HTML_PARAMS', ''); From admin/includes/languages/english.php , it has define('HTML_PARAMS','dir="ltr" lang="en"'); That's left to right. To change to right to left, replace ltr with rtl. Also change the lang to the two letter code for your language. I.e. replace the en with whatever is appropriate. You can read more about the dir parameter to the html tag at https://www.w3.org/International/questions/qa-html-dir There should be a .css file in your catalog directory. Change your fonts in that. It used to be called stylesheet.css but may have been renamed, e.g. to user.css.
  4. ecartz

    product Quantity

    Can you try making just one change at a time? I'd try the language files first. If you get error messages just with the language file changes, please post those errors, the code that you added, and some of the surrounding code for context. If those go through fine, then add the image files. Change admin/categories.php last. And just to be sure we are both on the same page, where it says LANGUAGE, you should be writing something like english, e.g. /admin/includes/languages/english/categories.php
  5. ecartz

    Cokies in backend and configure

    Cookie domain should be just a domain like .oscommerce.com or forums.oscommerce.com A cookie path of / is probably correct. Sometimes it might be something like /catalog or similar. In general, / is enough so long as you aren't running other web software on the same domain. The problem that you would see then would be the two software applications confusing each other by stomping on each other's cookies. That's when you might want to restrict the cookies to just the /catalog path. If you force cookies, that means that people who have cookies turned off won't work with your site. It can occasionally fix things if the software is diagnosing cookies as disabled but they really exist. But it is more likely to break things. Similar problem:
  6. ecartz

    tep_draw_file_field

    Which version of osCommerce are you using? And with what Add-ons? Traditionally image upload has been separate from basic osCommerce, and when I look at https://github.com/gburton/Responsive-osCommerce/blob/master/includes/functions/html_output.php it's not there. I would expect to find it either in https://github.com/gburton/Responsive-osCommerce/blob/master/includes/languages/english.php or https://github.com/gburton/Responsive-osCommerce/blob/master/includes/languages/english/product_info.php But it really depends on where the Add-on might have put it. And of course it depends on how German is stored in your languages. German? Deutsch?
  7. According to Mozilla at https://developer.mozilla.org/en-US/docs/Web/API/Storage/getItem You can say instead: // HeadScroll save checkbox state to session $(function(){ $('#scroll').each(function() { var $el = $(this); var $checked = sessionStorage.getItem($el.prop('id')); if ($checked === null) { sessionStorage.setItem($el.prop('id'), 'true'); } $el.prop('checked', sessionStorage[$el.prop('id')] === 'true'); }); $('#scroll').on('change', function() { var $el = $(this); sessionStorage[$el.prop('id')] = $el.is(':checked'); }); }); I haven't tried this. This is just from looking at docs.
  8. ecartz

    Keeping Error Logs Clean

    The first warning seems to be telling you that $cPath_array is not an array. This usually means that it is missing a $cPath_array = array(); That may need to appear much higher in the file (or even in a different file) though, as it needs to appear before anything is put in the variable. Perhaps put it above the application_top.php include in index.php. You could also surround this line with if (is_array($cPath_array)) { } But that may just shift or delay the problem. The second warning seems to be saying that the delivery country is a string, not an array. Either change it to $dest_country = $order->delivery['country']; Or set $order-delivery to be an array. This may be a sign that an add-on was installed incorrectly. It seems to be getting set the old way but the module is querying it the new way. If you used an order.php file from an older add-on, it may set it the old way. The third warning is telling you that either $shipping_weight is set to a non-numeric value or SHIPPING_BOX_WEIGHT is or is not defined at all. An add-on may be missing a database change that should have been made. You could hard code something like define(SHIPPING_BOX_WEIGHT, 3); and the error might disappear. But then you won't be able to edit the value without changing this code. Better would be to make the change in the database. Also, make sure that you don't have it configured as something like "3 lbs". That value should be purely numeric. No units. So just 3 or whatever number is appropriate. The fourth warning is telling you that $$link is not set properly. This should probably be fatal but seems to be happening only in the admin area, possibly intermittently. If you can make it happen consistently under some circumstances, that would be easier to diagnose.
  9. ecartz

    Shipping/CCGV/PayPal

    It sounds like one of your shipping module or CCGV made changes to checkout_process.php directly rather than via module. You would need to figure out what those changes were and make equivalent changes in paypal_express.php or whatever the name is. I believe the file that you need to modify is under the ext directory, but it's been a while since I've played with it. I believe this is what Tim was suggesting. The short version is that the PayPal files duplicate some of the functionality from checkout_process.php, so add-ons that modify checkout_process.php also require changes to other PayPal files. This is beyond just copying files. You almost certainly have to edit files manually. In the past, I've used a tool called KDiff3 to help me with these kinds of tasks. I leave it up to you whether you want to try to figure out how to make such manual edits or not. Depending on how you value your time and frustration, it may be time to pay someone to do it.
  10. ecartz

    Forum Software Update (31st July 2018)

    It looks like the report post link is in a color that is close to the background color. But if you hover over it, it shows up. It also might show up if you used it recently and it shows the visited color. I didn't try that. I tend to browse with Javascript off, so that might change things too.
  11. ecartz

    Excel Populate for Oscommerce

    This is the wrong forum for add-on questions, but two quick comments: return ord($data[$pos]) | (ord($data[$pos+1]) << 8) | // line 27 (ord($data[$pos+2]) << 16) | (ord($data[$pos+3]) << 24); This probably doesn't parse properly. Consider return ord($data[$pos]) | (ord($data[$pos+1]) << 8) | (ord($data[$pos+2]) << 16) | (ord($data[$pos+3]) << 24); For the other line, try a smaller file. It seems to be complaining that things are too big.
  12. 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.
  13. 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.
  14. ecartz

    Proposal: Cookies Required

    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.
  15. ecartz

    DHTML State Selection

    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?
×