Jump to content

ecartz

♥Ambassador
  • Content count

    3,580
  • Joined

  • Last visited

  • Days Won

    61

Posts posted by ecartz


  1. That says that no payment module is selected.  So I don't think that the problem is on checkout_confirmation but checkout_payment.  Something is going wrong with the selection code.  Perhaps post that.  How are you setting $_SESSION['payment'] to be 'free'? 


  2. 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)) ) {
    var_dump($payment_modules);
    var_dump(!is_object($$payment));
    var_dump($$payment);
    exit();
        tep_redirect(tep_href_link(FILENAME_CHECKOUT_PAYMENT, 'error_message=' . urlencode(ERROR_NO_PAYMENT_MODULE_SELECTED), 'SSL'));
      }

    what do you get? 


  3. 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. 


  4. 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. 


  5. 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');

    Try

    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). 


  6. 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. 

     


  7. 13 minutes ago, ArtcoInc said:

    It seems to work. Did I do that right?

    If that is what you wanted to do:  remove the Catalog link and change the home icon to point where Catalog did previously. 

    1 hour ago, ArtcoInc said:

    In the good old days, this was a simple edit to the application_top.php file ...

    ITYM:  in the bad old days, this required an edit to a core application file.  In the good new days, this only requires a simple edit to a language file. 


  8. In core, ignoring the payment module, the order is only inserted after payment is completed. 

    So if you are seeing a behavior where the order is inserted prior to payment being made, then the payment module is doing that.  And it would be the payment module's responsibility to delete the order if modifications are made.  That needs to be done in addition to the core processes, because, as I said, the core solution is to not insert the order until after payment is made.  In PayPal Standard, that is done in the confirmation method:  https://github.com/gburton/CE-Phoenix/blob/b7bfcaccc3e2cd9641b9d0c8db2be1cecf250a11/includes/modules/payment/paypal_standard.php#L154

    Note how it deletes and then reinserts the order under some circumstances.  Without any knowledge of the Quickpay module's code, my guess would be that it is not doing that at some times (perhaps all times) when it should. 


  9. 28 minutes ago, 14steve14 said:

    Turning off the payment modules may be an easier way.

    I think that if you do that, it assumes that you want to allow paymentless checkout.  I.e. that enables checkout rather than blocking it. 


  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. 30 minutes ago, RAC said:

    How can I find out what is being loaded after the user.css?

    If you view the page source, it shows

    <style>
          
          .navbar-header  {
        background-color: #12343B ;
        background-image: url() !important;
        color: #EFCA64 ;
    } 
    
    .navbar-light .navbar-nav .nav-link {
        /*background-image: url() !important;*/
        color: #EFCA64;
    }
    .bg-light {
        background-color: #12343B !important;
        background-image: url() !important;
        color: #EFCA64 ;
    } 
    
    .navbar-light .navbar-brand {
        color: #EFCA64 ;
    }
    .breadcrumb {
        background-color: #C5CCCB ; 
        
    }   
    .breadcrumb a {
          color:#12343B !important;
    }
    .alert-info  {
        background-color: #F1DEAC ; 
        color:#3b5998 ;
        border-color: #F1DEAC;
    }   
    .card-header {
        background-color: #dfe3ee ; 
        background-image: url() !important;
        color: #297bfe ; 
    }
    
    .card-body {
        background-color: #fff ; 
        color: #297bfe ; 
    }
    
    .card-footer {
        background-color: #dfe3ee ; 
        color: #297bfe ; 
    }
    
    .btn-view {
        
        background-color: #dfe3ee ; 
        color: #297bfe ; 
        border-color:#dfe3ee ;
        
    }
    
    .btn-view:hover {
        background-color: #8b9dc3 ; 
        color: #fff ; 
        border-color:#8b9dc3 ;
        
    }
    
    
    
    .btn-success {
        background-color: #3b5998 ; 
        color: #fff ; 
        border-color:#3b5998 ;
    }
    
    .btn-success:hover {
        background-color: #dfe3ee ; 
        color: #3b5998 ; 
        border-color:#dfe3ee ;
    }
    
    .btn-secondary {
        background-color:  ; 
        color:  ; 
        border-color: ;
    }
    
    .btn-secondary:hover {
        background-color:  ; 
        color:  ; 
        border-color: ;
    }
    
    .btn-primary {
        background-color:  ; 
        color:  ; 
        border-color: ;
    }
    
    .btn-primary:hover {
        background-color:  ; 
        color:  ; 
        border-color: ;
    }
    
    .btn-danger {
        background-color:  ; 
        color:  ; 
        border-color: ;
    }
    
    .btn-danger:hover {
        background-color:  ; 
        color:  ; 
        border-color: ;
    }
    
    .btn-warning {
        background-color:  ; 
        color:  ; 
        border-color: ;
    }
    
    .btn-warning:hover {
        background-color:  ; 
        color:  ; 
        border-color: ;
    }
    
    .btn-info {
        background-color: #EFCA64 ; 
        color: #12343B ; 
        border-color:#EFCA64 ;
    }
    
    .btn-info:hover {
        background-color: #F1DEAC ; 
        color: #12343B ; 
        border-color:#F1DEAC ;
    }
    
    .bm-categories .list-group-item{
        background-color: #EFCA64 ; 
        color: #12343B;
    }
    
    .bm-categories .list-group-item:hover {
        background-color:#F1DEAC ; 
        color: #12343B;
    }
    .bm-best-sellers .list-group-item{
        background-color:  ; 
        color: ;
    }
    
    .bm-best-sellers .list-group-item:hover {
        background-color: ; 
        color: ;
    }
    
    
    
    .jumbotron {
        background-color: #f7f7f7 ; 
        background-image: url() !important;
        color: #EFCA64;
    }
    
    .footer a, h4 {
         
        color: #EFCA64;
    }
    
    .footer-extra  {
        background-color: #EFCA64 ; 
        background-image: url() !important;
        
        color: #12343B !important;
    }   
    </style>

    Note that that includes CSS for card-body, which is what you're trying to change.  That's not core, so it most likely comes from the App that you installed.  You can either remove it and pursue supported paths or try to get support from other users of the App in its support thread. 


  13. 9 minutes ago, RAC said:

    When I examined the developer tools again, as well as the above code, below it I find my new code and colours, but this text has a line through it!

     

    .card-header {

    1.      background-color: #F1DEAC;

    2.      /* background-image: url() !important; */

    3.      color: #12343B;

    }

     

    Can anyone throw me a lifeline?

    This suggests to me that something is loaded after user.css, overriding it.  I would try to confirm this by looking at your site, but you have it password protected. 


  14. 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. 


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


  16. 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 1.0.7.9, 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. 


  17. I think that a "non-consecutive numerical sort order" is probably the best solution.  Note that it doesn't need to be a database entry.  A hook file in includes/hooks/system would work as well. 

    The closest thing to documentation is the commit notes (and the commit itself):  https://github.com/gburton/CE-Phoenix/commit/ae01e0d4d91b2e4a561735168ef4fbe6ba8e6899

    Related commit:  https://github.com/gburton/CE-Phoenix/commit/d2adabebe2efbdcd28513c6057758cd25ed48fc4

    I don't think that it is very complicated.  HTTP_SERVER . DIR_WS_CATALOG should always be used now, where previously it was only sometimes used (in the ENABLE_SSL false case).  For the most part, this is just simpler.  Because instead of having to check various things to determine the correct link, the code can just consistently use one thing.  The old system was complicated, as it had to try to mix SSL and non-SSL pages.  But this always uses whatever the HTTP_SERVER is configured to provide. 

×