Jump to content

ecartz

♥Ambassador
  • Content count

    3,864
  • Joined

  • Last visited

  • Days Won

    69

Posts posted by ecartz


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


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


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


  4. <script>$(document).ready(function() { $('button[name="wishlist"]').bind('click', function() {
        let input = document.createElement('input');
    
        input.setAttribute('type', 'hidden');
        input.setAttribute('name', 'wishlist');
        input.setAttribute('value', 'wishlist');
    
        let form = $(this).closest('form');
        form.unbind('submit');
        form.append(input);
        form.submit();
    
        return false;
      });});
    </script>

     


  5. The problem that LeeFoster identified was a conflict with another App.  If he turned off the header_tag module from the other App, he could get the Wishlist to work.  That App has a header_tag module. 

    The ideal would be to add this as its own header_tag module that adds to footer_scripts but for testing purposes, anything that adds to footer_scripts would probably work.  For testing purposes (to verify that it works), you could add it to template_bottom.  But that would put it on every page even though it's only needed on the product_info page. 


  6. If it is traversable, then replacing line 313 with

    $cost = (reset($rateReply->RatedShipmentDetails)->ShipmentRateDetail->TotalNetCharge->Amount)/MODULE_SHIPPING_FEDEX_WEB_SERVICES_CURRENCY;

    might work. 

    Setting it to List and explicitly casting to array might work. 

                 foreach ((array)$rateReply->RatedShipmentDetails as $ShipmentRateDetail)

    I'm not sure what line that is, but it is before 313 and I just added (array) to it. 

    In a test store (not a live store, as it would break it), you could add

    var_dump($rateReply->RatedShipmentDetails);
    exit();

    just before line 313 and see what it says.  Try twice, once each for domestic and international. 

     


  7. Can't you just change the text that you send to PayPal?  That would be a coding change, but that's the only way that you can change just what PayPal gets. 

    Note that the "bug" is that PayPal doesn't accept values more than 256 characters (a character is a letter or other mark).  So to fix that, you'd have to fix PayPal.  It's a limitation in PayPal, not in osCommerce. 


  8. <script>$(document).ready(function(){ $('button[name="wishlist"]').bind('click', function() {
        let input = document.createElement('input');
    
        input.setAttribute('type', 'hidden');
        input.setAttribute('name', 'wishlist');
        input.setAttribute('value', 'wishlist');
    
        let form = $(this).parents('form:first');
        form.appendChild(input);
        form.submit();
    
        return false;
      }});
    </script>

    I think that this would fix it. 

    To test it, you could add this into the existing header tag module with which you are having trouble, as that already adds scripts to the footer.  But you might then want to move it into its own module or hook after establishing that it works. 

    The problem is that the AJAX submission is not passing which button was clicked to submit the form.  Which makes sense because there is only one button in the default install.  So  if Javascript is running, this adds a form input to the form when that button is clicked. 


  9. 5 hours ago, burt said:

    Give the wishlist button a href that links to the wishlist action. 

    The problem is that it needs to submit the form to get the attributes.  I.e. submitting the form is the correct behavior here.  The issue is that it needs to submit the form differently when it is a wishlist from when it is adding to cart. 

    Note that if people are already using AJAX to submit the form, then they can use Javascript to change the form submission URL or to add a "Wishlist" input that is only posted with the Wishlist.  Then the current behavior would be a fall back for the non-Javascript case. 


  10. Which line is 313? 

    Perhaps try changing

              if(MODULE_SHIPPING_FEDEX_WEB_SERVICES_RATES == 'LIST') // For LIST/FULL Rates, calculate the cost as below
              {

    to

              if (('LIST' === MODULE_SHIPPING_FEDEX_WEB_SERVICES_RATES) && (is_countable($rateReply->RatedShipmentDetails))) {
               // For LIST/FULL Rates, calculate the cost as below

     


  11. 49 minutes ago, discxpress said:

    Also note that when you click save to favorites, an item is added to shopping cart. Thanks

    I'm pretty sure that this only happens in some browsers.  You may want to find out where @kgtee has this installed and check the behavior there. 

    Or post what browser you're using so people trying to debug can use the same one. 


  12. function CheckCountryState($state, $country) {
        if (MODULE_HEADER_TAGS_HONEYPOT_VERIFY_STATE_COUNTRY_MATCH == 'True') {
            $has_zone_query = tep_db_query("SELECT COUNT(*) AS zone_count FROM zones WHERE zone_country_id = " . (int)$country);
            $has_zone = tep_db_fetch_array($has_zone_query);
            if (0 < $has_zone['zone_count']) {
                $db_query = tep_db_query("select 1 from zones where zone_country_id = " . (int)$country . " and (zone_code = '" . tep_db_input($state) . "' or zone_name = '" . tep_db_input($state) . "')");
                return !tep_db_num_rows($db_query);
            }
        }
    
        return false;    
    }

     


  13. 52 minutes ago, BrockleyJohn said:

    @dculley stable releases for Phoenix are the .0 releases eg. 1.0.5.0 and 1.0.6.0

    Even addons that are actively maintained are unlikely to keep step with every increment.

    The problem is not that it needs to be updated with every increment.  The problem is that the current version of this module requires a core change (to admin/modules.php ).  So every time that the modules.php file gets updated, it wipes out the core change which then needs to be reapplied. 

    This could be fixed by adding a hook file or database defined hook to replace the core change.  The hook point was added in this commit.  But no one has updated the package with that.  @greasemonkey uses that hookpoint for another module requiring the same change. 

    Someone could also modify the module to use the standard form:  https://github.com/gburton/CE-Phoenix/blob/master/admin/modules.php#L40..L42.  That might avoid the need for a hook.  But again, no one has updated the module to to do that. 


  14. 1 hour ago, mrsmarter said:

    if this might have unforeseen consequences

    You're bebopping along the internet.  You find an HTTP link to a site.  But you want HTTPS, what do you do?  The typical response is going to be to find another site.  Because the typical user won't think to add an s to the http in the URL to see if it works.  Particularly as browsers often hide the protocol, just showing a lock or not. 

    There are far more users who you will lose from search engine rankings or simple browsing than by not having an up-to-date browser.  Elderly browsers mostly appear in intranets with no internet access. 

    And beyond that, this would be a core change.  Each time the html_output.php file is updated, you'd have to reapply it. 


  15. 1 hour ago, mrsmarter said:

    isn't there a reason why we have HTTP_SERVER and HTTPS_SERVER? Besides, once HTTPS works as it should, I would like to re-enable normal HTTP on the server so https-impaired users are not locked out.

    That wasn't the reason.  Traditionally it was more expensive to serve HTTPS pages (in terms of server resources).  So servers were configured to avoid it. 

    Also, shared hosting would often share the SSL across sites.  So the HTTPS_SERVER might have been a different domain than the HTTP_SERVER. 

    Now the standard is to make the whole site HTTPS, but osCommerce still has the original configuration.  Eliminating that is on the list of things to do for Phoenix, but I'm not working on it yet. 

    Setting the HTTP_SERVER to match the HTTPS_SERVER is the near term workaround. 

    I don't know of any client circumstance where HTTP works but HTTPS does not.  Client browsers can all handle HTTPS as far as I know.  And if one couldn't, the user would not be able to register, log in, or check out.  Because all of those tasks require HTTPS_SERVER.  So unless you are willing to make the whole site http, you can't support an "https-impaired" user anyway. 

     


  16. 1.0.5.2 does not change how the tep_session functions work.  But if you want to write them out, the code would look like

             if (!isset($_SESSION['wishList']) || !($wishList instanceof wishlist)) {
                     $_SESSION['wishList'] = new wishlist();
                     $wishList =& $_SESSION['wishlist'];
             }

    But I don't think that has anything to do with the issue.  Note that the part that prevents the add to cart action is

       if (isset($_POST['wishlist'])) {

    If that condition is true, then it redirects the page.  If it is not true, it keeps going until it reaches the add to cart action.  So there's really only two things that can be going wrong.  One, that condition is not being set.  Two, the redirect is failing in some fashion without showing an error.  The first is far more likely and suggests some kind of browser issue.  For example, Lee may be using a different browser than you.  Or have different browser settings.  Or perhaps some other issue unrelated to the browser. 

    For example, if Lee is using Internet Explorer, perhaps you are hitting https://stackoverflow.com/a/1903505


  17. 1 hour ago, dculley said:

    I tried to rename the line took out the $vars just left the ();  and same error.

    I would just delete the entire line 107.  It's complaining that it can't find do_magic_quotes_gpc.  I'm not sure that line actually does anything necessary even with Search-Engine Safe URLs turned on.  So just delete it.  And I would turn Search-Engine Safe URLs off, as that never left the experimental stage and has long since been obsolete.  Search engines have been able to handle GET parameters for at least fifteen years. 

    The 1.0.5.2 version of includes/application_top.php is going to be preferable to the 1.0.5.0 version.  Things have moved.  New things have been added.  It would be difficult to get it working with 1.0.5.2.  The problem with the hooks class is only the beginning. 


  18. 49 minutes ago, dculley said:

    when I go to includes/application_top.php on line 107 it says;       do_magic_quotes_gpc($vars);

    Turn off Search-Engine Safe URLs.  Or delete that line.  Or copy do_magic_quotes_gpc() from an older version (e.g. 1.0.5.0).  It would be in includes/functions/compatibility.php


  19. Try

    <td class="main"><?php echo tep_draw_input_field('stores_title', ($cInfo->stores_title ?? null), 'maxlength="255" required="required" aria-required="true"'); ?></td>

    The default could also be an empty string or something else.  But I think that null works there and that pattern can be used to keep the current behavior and suppress the notice.  You're essentially saying, "Yes, I know it's sometimes not set.  But I don't care when that happens." 

    The true is an argument that used to exist but has been removed from core, so delete it and add to the input parameters as shown.  In general, if your admin tep_draw_input_field call has more than three arguments, you should probably post it so it can be rewritten. 


  20. 14 minutes ago, LeeFoster said:

    Just upgraded to Phoenix 1.0.5.2 and getting the following errors -

    Notice: Undefined index: sID in C:\xampp\htdocs\360v3\admin\stores.php on line 339

    Notice: Undefined variable: cInfo in C:\xampp\htdocs\360v3\admin\stores.php on line 339

    Notice: Undefined index: sID in C:\xampp\htdocs\360v3\admin\stores.php on line 339

        $stores_query = tep_db_query($stores_query_raw);
        while ($stores = tep_db_fetch_array($stores_query)) {
          if (!isset($cInfo) && (!isset($_GET['sID']) || ($_GET['sID'] == $stores['stores_id']))) {
            $cInfo = new objectInfo($stores);
          }

     


  21. 32 minutes ago, Bordersbloke said:

    I have the same issue.

    Replaced the certificate - DID NOT solve it.

    Also the same problem with Paypal Website Payments Pro.

    Express Checkout works, but ignores shipping options and discount vouchers.

    Paypal on my site is now virtually unusable.

    What version of osCommerce are you using? 

×