Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Posts posted by ecartz

  1. Well, that warning literally tells you what the problem is.  There is no such directory as includes/languages/french/

    Either create the directory (with the necessary contents), or if the name is wrong, edit the language to point to the right directory.  The place to edit it is admin > Localization > Languages

    If that page won't allow you to edit it, you would have to edit it in something like phpMyAdmin.  It would be the directory column in the languages table. 

  2. 4 hours ago, NicolasW said:


    Delete that.  Or put a // in front to comment it out. 

    You should also restore line 286 to the original. 

    setlocale(LC_NUMERIC, $_system_locale_numeric); // Prevent LC_ALL from setting LC_NUMERIC to a locale with 1,0 float/decimal values instead of 1.0 (see bug #634)

    The way that you have it won't work correctly (bug #634).  But it's not causing your current problem. 

  3. 6 hours ago, cinolas said:
    if (($order->info['total'] - $total_deductions < 0) || ($payment == 'free' && ($order->info['total'] - $total_deductions > 0))) {


    This says that if the payment method is free, that the credit covers when the order total is less than the total deductions.  That wouldn't seem to be what you would want.  Perhaps replace that line with

    if (($payment == 'free') && ($order->info['total'] > $total_deductions)) {
      $payment = null;
    if ($order->info['total'] < $total_deductions) {

    Which instead says, if the the payment is invalid, unset it.  Then continues normally. 

    Note that I would actually expect that check to occur in the module.  If it's not working, that might be a sign of a bigger problem somewhere.  I.e. you might be better off figuring out why it isn't working rather than trying to make this particular circumstance work.  Because there may be another circumstance that you are not checking. 

  4. If you have a .htpasswd file, then you would change the password entirely outside osCommerce.  This may be done in cPanel or through some other, host-specific method.  Ask your host how to change the htpasswd for that directory.  In cPanel, this was called "Password Protect Directories". 

    If you are self-hosting (managing your own server), there are instructions at https://cwiki.apache.org/confluence/display/HTTPD/PasswordBasicAuth but if you are purchasing hosting, you may not have the necessary permissions to do those things in that way. 

    It is also barely possible that you are using an App (contribution) that handled the login.  But the more common way was basic authentication on the directory. 

  5. If you change that section of code to

      if ( ($payment_modules->selected_module != $payment) || ( is_array($payment_modules->modules) && (sizeof($payment_modules->modules) > 1) && !is_object($$payment) ) || (is_object($$payment) && ($$payment->enabled == false)) ) {
        tep_redirect(tep_href_link(FILENAME_CHECKOUT_PAYMENT, 'error_message=' . urlencode(ERROR_NO_PAYMENT_MODULE_SELECTED), 'SSL'));

    what do you get? 

  6. 2 hours ago, burt said:

    If he had logged off here...

    I don't think that would be necessary. 

    She would have to log in again to see his changes.  I don't think logging off matters *except* that it allows to log in again.  I.e. I don't think anything happens at log off.  It's all at log in.  It updates the saved cart immediately but it only reads from it at login.  I'm thinking about what would be involved to check for that situation, and it doesn't seem trivial.  It might be that the easiest solution would be to stop storing the cart products and quantities in the session.  If they were always read from the database, then just refreshing the page would work. 

  7. Compare it to the gift voucher balance available, not the amount applied.  If the balance is sufficient, you can show the payment module.  You may have to do more work if the user selects that module without applying the balance.  Because presumably you want to deduct the amount from the balance before processing the order.  But the question on the payment page is how someone is paying.  And the answer in that situation would be with the voucher balance. 

  8. 29 minutes ago, cinolas said:

    I tried changing line 75, which is a line that is added by the Gift Voucher contributio, from require(DIR_WS_CLASSES . 'order_total.php'); to require_once(DIR_WS_CLASSES . 'order_total.php');


    if (!class_exists('order_total')) {
      require 'includes/classes/order_total.php';

    Or just delete the line entirely. 

    If that doesn't work, you probably need to change the other place that has that line in one of the three ways (require_once, check if class exists, remove). 

  9. 30 minutes ago, Psytanium said:

    If I add new column to the specials table, storing the percentage

    This would not be a small change. 

    It might be easier to add a categories.preAction hook that checked if the product price changed and updated the specials price appropriately.  This could involve a new column that would be a boolean for update or not.  Or it could happen always.  Then the catalog code would not need to change, only the admin behavior. 


  10. MODULE_SHIPPING_ITEM_ would be the database configuration entries for the item shipping module.  It's basically saying that you are trying to load the module before installing it.  Which of course is what that page does.  It loads modules so that you can install them. 

    You could look at older versions of CE Phoenix to see how those warnings were handled:  https://github.com/gburton/CE-Phoenix/blob/e55fc1aa13cab513b7572eb32e73386a4cbdf2bc/includes/modules/shipping/item.php

    Or you could just switch to CE Phoenix and all that work would have already been done. 

  11. 17 minutes ago, dowser said:

    would prefer to hire someone to do it for me. Where should I look?

    For 2.3.4, you should look at https://forums.oscommerce.com/forum/79-commercial-support-inquiries/

    If you want to upgrade to Phoenix (which runs on PHP 7, including 7.2), you should join the Phoenix Club and use the resources there. 

    Note that the most common reason for PayPal to fail is an outdated certificate file, which is probably within your capabilities to fix. 


  12. 17 minutes ago, syscon said:

    If not I'll have to install an older version of php. 5.6 and hopefully it will run on debian-stable or Gentoo.

    Note that mysql_connect went in one of the PHP 5 versions -- I think 5.5 (look at the commit message that I linked previously).  So PHP 5.6 probably won't help with the specific problem that you're trying to work around now.  It would likely help you with other problems. 

    5 minutes ago, syscon said:

    I imported my database (in Debian stable) to  MariaDB so can I install the new Phoenix-osCommerce and point it to that database?

    Burt posted instructions for updating from osCommerce to Phoenix.  It's probably somewhere in the Phoenix Club if you join that.  I don't remember specifics, but I believe that he was suggesting to build the Phoenix store first and then import the data into the tables there (not attempt to point Phoenix at the osC database).  There's also a list of tables not to port over, e.g. address_format, configuration, and sessions. 

  13. Go back through the old versions of osCommerce until you find where they switched from mysql_connect to mysqli_connect and then apply that set of changes.  Note that this is just the first of many changes that you will have to make, even just in that file.  Because every mysql_ function was deprecated, not just mysql_connect.  And there are many other changes needed for PHP 7. 

    But anyway, the specific commit that you want is probably https://github.com/osCommerce/oscommerce2/commit/0064f6ce2208eaa972ebcc9e6772e45c7e3ee6fc#diff-611dd0e5f90ff998c01f8365dff385c1b0167b05eaf99d58fec24539b9a5b8fc

    It might be easier to update to a newer version of osCommerce than to patch that one.  In particular, CE Phoenix is already PHP 7 compatible. 

  14. 1 minute ago, Jack_mcs said:

    This isn't due to this addon

    That is incorrect. 

    This add-on rewrites the tep_href_link function to require specifying whether the connection is SSL or non-SSL.  Since that is not necessary in, there is a conflict.  The add-on should be revised to not require choosing a "connection method" and just ignore the third parameter to tep_href_link. 

    The expectation should be that more things will ignore the connection type in the future, further highlighting the difference between how this add-on handles it and how core does.