Jump to content

ecartz

♥Ambassador
  • Content count

    2,685
  • Joined

  • Last visited

  • Days Won

    18

Posts posted by ecartz


  1. 1 hour ago, NateNg said:

    I just installed the new KissIT image thumbnailer 3.2.1  and I got this error. Please advise. 

    AH01071: Got error 'PHP message: PHP Fatal error:  Uncaught Error: Class 'abstract_executable_module' not found in /home/xxx/xxx/xxxxxxx/xxx/xxxx/includes/modules/content/product_info/cm_pi_gallery_kissit.php:13\nStack trace:\n#0 

    Are you running OSCOM CE Phoenix 1.0.5.1 or later?  If not, you should probably use the older version. 


  2. 45 minutes ago, Dr. Mary Calaveris said:

    Is there a different way to express the year without having to change the  const MATC_PRIVACY_MODAL_TEXT = '      to      define('MATC_PRIVACY_MODAL_TEXT'

    Not the current year.  Not without changing how the constant is used.  The alternatives are

    1.  Add the year after the const is defined (e.g. with sprintf). 

    2.  Define a constant to hold the year and use that. 

    define('CURRENT_YEAR', date('Y'));
    // in a different file
    const WHATEVER = 'Blah ' . CURRENT_YEAR . ' blah';

    3.  Hard code the year rather than produce it automatically. 

    4.  Change the const to define. 

    I think that #2 will work, although I haven't used it that way.  But note that both #2 and #4 use a define.  I'm not sure that one is necessarily better than the other. 

    59 minutes ago, Dr. Mary Calaveris said:

    Also, do you know what may be causing the  /create_account.php?language=fr    to render the page incorrectly as the following fields are not shown:

    Are you sure that Your Personal Information, etc. is localized properly at admin > Localization > Customer Data Groups? 


  3. Line 21 in the original: 

    const MATC_PRIVACY_MODAL_TEXT = '<p>Put here your Privacy Text...</p>';

    I would not expect that to give that error.  That error is more the kind of thing that you'd get if that line were something like

    const MATC_PRIVACY_MODAL_TEXT = 'Blah ' . tep_href_link('privacy.php') . ' blah';

    Is that your actual text for that line?  A workaround for that would be to change the line to something like

    define('MATC_PRIVACY_MODAL_TEXT', 'Blah ' . tep_href_link('privacy.php') . ' blah');

     


  4. Apparently you have to set an onInvalid event handler in Javascript:  https://stackoverflow.com/questions/25015912/how-to-change-required-msg-for-dropdown-list

    Note that that question was closed as a duplicate.  So you may want to click through to the other question to see more discussion. 

    If it's not clear, that message is set by the browser.  So you would be overloading the browser behavior with the Javascript. 


  5.     $add_to_cart = false;
        if (is_email_for_quote($product_info['products_price'])) {
          $products_price = show_email_for_quote($product_info);
        } elseif (($new_price = tep_get_products_special_price($product_info['products_id'])) && is_email_for_quote($product_info['specials_new_products_price'])) {
          $specials_price =show_email_for_quote($product_info['specials_new_products_price']);
        } else {
          $add_to_cart = tep_draw_button(MODULE_CONTENT_PI_BUY_BUTTON_TEXT, 'fas fa-shopping-cart', null, 'primary', array('params' => 'data-has-attributes="' . (($products_attributes['total'] > 0) ? '1' : '0') . '" data-in-stock="' . (int)$product_info['products_quantity'] . '" data-product-id="' . (int)$product_info['products_id'] . '"'), 'btn-success btn-block btn-lg btn-product-info btn-buy')
                      . tep_draw_hidden_field('products_id', (int)$product_info['products_id']);
        }

    And then later, replace the add to cart code with

        if ($add_to_cart) {
          echo $add_to_cart;
        }

     


  6. 15 minutes ago, artfulweb said:

    In fact, tpl_n_checkout.php is only called for the extra order email which is not in HTML format so the above changes blitzes the products in the email to the owner.

    The two aren't separate that way.  A more correct way to put it would be that the output from tpl_n_checkout.php is only used by the extra order email.  To fix that, you can add

    echo $products_ordered;

    either before or after the

    //------insert customer chosen option eof ----

     


  7. From where you are, the easiest way would probably be to change line 28 of tpl_n_checkout_.php from

        echo "\n" . $product['qty']

    to

        $products_ordered .= "\n" . $product['qty']

    and line 35 from

          $products_ordered_attributes .= "\n\t" . $attributes_values['option'] . ' ' . $attributes_values['value'];

    to

          $products_ordered .= "\n\t" . $attributes_values['option'] . ' ' . $attributes_values['value'];

    Although overall I think that copying n_checkout.php to n_checkout_mm.php, renaming the class and constants accordingly, and moving order-confirm into the module and template files would be better. 

    The two times where the code says $order->customer['firstname'] . ' ' . $order->customer['lastname'] would be better as just $order->customer['name']. 


  8. Perhaps

      if ( (!isset($_GET['sort'])) || (!preg_match('/^[1-8][ad]$/', $_GET['sort'])) || (substr($_GET['sort'], 0, 1) > count($column_list)) ) {
        $listing_sql .= " ORDER BY RAND()";
        for ($i=0, $n=count($column_list); $i<$n; $i++) {
          if ($column_list[$i] == 'PRODUCT_LIST_ID') {
            $_GET['sort'] = $i+1 . 'RANDOM';

    Note that it is relatively easy to overwhelm this form of random ordering.  I think the limit is somewhere in the range of a hundred products (total in the store).  And of course paging won't work so well.  Because the second page will have a different random order from the first.  You can fix the paging issue with something like

        if (!isset($_SESSION['RANDOM_SEED'])) {
          $_SESSION['RANDOM_SEED'] = mt_rand();
        }
        $listing_sql .= " ORDER BY RAND(" . (int)$_SESSION['RANDOM_SEED'] . ")";

    That will give a consistent ordering.  

    Beyond that would need development.  There isn't a quick solution by editing a few lines. 

     


  9. 11 minutes ago, Fredi said:

    In another great version of Phoenix, an error appeared: 1054 - Unknown column 'categories_htc_description' in 'field list'

    What does this mean? What did I do wrong?

    Apparently something is using code from the Header Tag Controller App but you don't have it installed.  This is presumably from some modification that you made to your store. 


  10. The line that sends the email is

          $mimemessage->send($customer_data->get('name', $mail), $customer_data->get('email_address', $mail), $from_name, $from_address, $subject);

    And changing it to

          $mimemessage->send($customer_data->get('name', $mail), $customer_data->get('email_address', $mail), $from_name, $from_address, sprintf($subject, $customer_data->get('name')));

    If you set the subject to be

              <?php echo tep_draw_input_field('subject', 'Thank you %s for calling our clinic, it is presently closed due to our fellow Healthcare workers extreme fear of the coronavirus as they are at higher risk due to safety gear shortage.', 'id="Subject" required="required" aria-required="true"'); ?>

    But the tool is not really designed to be used that way. 


  11. I would also point out that the original question was not if people should stop updating when they test an update and find it breaks an App (what most of the discussion suggests) but whether, starting now, someone should install 1.0.5.5 or some older version.  It is certainly possible that there are Apps that are broken in 1.0.5.5 that are not broken in 1.0.5.0, but it is not definite that the (unknown) Apps that the asker needs are more broken in 1.0.5.5 than in 1.0.5.0.  And it may be that some of things that that particular shop needs are easier to do in 1.0.5.5 than 1.0.5.0. 

    In my opinion, it would be better to start with 1.0.5.5 first and figure out what is and is not possible with that rather than start with the assumption that 1.0.5.0 (or some other version) would be better. 


  12. It depends on who owns the file.  Sometimes 644 will work.  Sometimes you need 444. 

    If it's your server (not a host), you could chown the file instead of chmod to 444.  But if a shared host, the simplest thing is to just change it to 444 or 400 or whatever. 


  13. 9 minutes ago, nedragdnuos said:

    If I jump to the latest version 1.0.5.5 would that be sensible or go for a lower version ie: 1.0.4.0 or 1.0.5.0 etc?

    Phoenix updates are designed to be small and easy to apply.  So it is reasonable to start with 1.0.5.5 and plan on updating as you go.  One of the goals of Phoenix is for people to stop halting at specific versions and instead add the security, bugfix, and feature updates as they release. 

    I see no benefit to 1.0.4.5 or lower or 1.0.5.1 through 1.0.5.4.  The argument in favor of 1.0.5.0 would be that it has better App support.  But if you aren't expecting to go live until after 1.0.6.0 releases anyway, then there's little reason to stick with the older release. 

    If you want to customize the fields in customer registration, then you should install 1.0.5.5.  If you want to override the template display, you should plan on updating to 1.0.6.1 when it releases. 


  14. If you go to https://www.oscommerce.com/Products you will see two versions listed.  The v2.3.4.1 has the problem that you describe.  The Phoenix Edition v1.0.5.0 is more recent and does not. 

    In terms of the specific error that you are encountering, rename a function class_name to __construct.  Phoenix mostly did that in https://github.com/gburton/CE-Phoenix/commit/f059ed430ad632133e43e50111ee5021d41cd10a#diff-b25c7caa707e98de8d250a9375b5c710


  15. MySQL also has cache settings in mysql.conf or whatever. 

    Have you tried turning on query logging and testing the queries in phpMyAdmin?  The logging tells you what queries the page is generating.  Then run the queries in phpMyAdmin to see which are slow. 

    With a large products_to_categories table, you might add a UNIQUE index on categories_id, products_id (in that order).  Because the categories page queries from a category usually.  So the primary key is backwards for its needs.  That usually won't matter, but it might in your circumstance. 


  16. My guess would be that USPS changed something.  This surfaced intermittently because they only changed it on some servers at first.  It is now always wrong because they've updated everything. 

    7 hours ago, TomB01 said:

    I guess it's going through the foreach loop 12 times, which is why the error message prints out that many times.

    No, that error means that it isn't looping through that foreach at all.  It may be reaching that section of code twelve times. 

    The simplest thing that you could try would be to change 126 to

    foreach (($Package['ExtraServices']['ExtraService'] ?? []) as $key => $val) {

    That will probably suppress the error.  If it doesn't, try wrapping the entire loop in

    if (is_array($Package['ExtraServices']['ExtraService'] ?? null)) {
      //foreach here
      //} end of foreach
    }

    That should suppress the error but something may still not be working. 


  17. 3 hours ago, Jack_mcs said:

    I also tested it in 1.0.5.4 and Honey Pot will not work in that version, at least as far as create account checks are concerned since the customer handling code has changed in that version. I haven't had time to figure out how to check for failures but will eventually. Until then, this addon will only fully work with 1.0.5.3 or before.

    Any checking that worked in 1.0.5.3 will work in 1.0.5.4.  All 1.0.5.4 did was provide an easier way to block failures.  So if it won't work in 1.0.5.4, it won't work in 1.0.5.1 through 1.0.5.3 either.  To make something that would work with the change from 1.0.5.4 work in 1.0.5.1 through 1.0.5.3, someone could add the tep_block_form_processing function from 1.0.5.5 (the one from 1.0.5.4 had a typo for create_account).  Or just duplicate the functionality of that function. 

    I would say that the correct way to implement form verification in 1.0.5.1 or later would be to write replacement customer_data modules.  But that's another conversation.  My point here is that it is extremely unlikely that something that doesn't work in 1.0.5.4 will work in 1.0.5.1 through 1.0.5.3. 

×