Jump to content

ecartz

♥Ambassador
  • Content count

    3,604
  • Joined

  • Last visited

  • Days Won

    61

Posts posted by ecartz


  1. admin/includes/configure.php -- particularly the cookie settings.  You may want to post it, minus the DB_ settings at the bottom. 

    You also might check to see if your host allows you to see the error logs.  Sometimes there is something interesting in there. 


  2. It depends on your PHP version.  If less than 7.3, just change the COOKIE_PATH constants in your configure.php files.  7.3 or later, then yes, the place to change it is in start_session.php and application_top.php

    I'm changing this now, so I may make it so that you can always change it in the configure.php files. 


  3. 3 minutes ago, dculley said:

    Problem is  that when I go to add a regular customer or a guest  and click on continue it will not go any further. 

    The only add ones I have install is: reCapthcha, CK editor, Kissit catalog and admin, Stripe payment, USPS and Guest Checkout. 

    This is the KISS IT support thread.  It seems far more likely that the problem that you are experiencing is in one of Guest Checkout (Rainer supports Purchase without Account), reCaptcha, or conceivably CK Editor.  As those actually change the customer registration or form fields.  I would be rather surprised if any of KISS IT, Stripe, or USPS broke account creation on their own.  It's vaguely possible that KISS IT and reCaptcha are interacting in a problematic way. 

    As a process, there's nothing special about troubleshooting.  The initial process is the same for developers and non-developers.  Install a store with no Apps.  Test if it works.  If it does, pick an App.  Install just that App.  See if the thing that was broken works.  Do this for each App on a fresh store.  If you find that one of the Apps is breaking the page, then ask for help in the support thread for that App.  If not, now you have three to six store installations.  Back them up.  Install a second App on each and repeat the process. 

    Things I find most likely to break registration: 

    1.  Guest Checkout alone.

    2.  ReCaptcha alone. 

    3.  CK Editor alone.

    4.  Guest Checkout and ReCaptcha together.

    5.  ReCaptcha and KISS IT together. 

    6.  Guest Checkout and CK Editor together.

    7.  Guest Checkout, ReCaptcha, and KISS IT together.

    8.  Guest Checkout, ReCaptcha, KISS IT, and CK Editor together. 

    You can test this by installing three stores in subdirectories. 

    1.  Guest Checkout then ReCaptcha then KISS IT then CK Editor.

    2.  ReCaptcha then KISS IT.

    3.  CK Editor then Guest Checkout.

    Remember to test after each install.  When you find the broken combination, post in the support thread for one of the installed Apps on the broken install.  That could include here.  Or not, as it may turn out that KISS IT has nothing to do with it.  But don't be surprised if whichever developer tells you that they simply don't support that App combination.  But to really have any hope of a developer even considering this, you need to first figure out what Apps are actually causing the problem.  Guest Checkout and ReCaptcha seem the most likely, as they affect registration form processing.  CK Editor and KISS IT certainly work on their own, but it is conceivable that they cause some kind of interaction.  If you can show that adding just that to an existing set of working Apps breaks something, then an App maintainer might be willing to investigate.  But as is, you're essentially asking for someone to guess what might have gone wrong. 

    You currently have no reason to think that KISS IT is the one of those six Apps that is causing the problem.  It's more likely to be Guest Checkout or ReCaptcha.  If you want more help, you need to do some of the investigative work so that you can figure out who actually would be able to help you.  It may be that one of those Apps is breaking registration alone.  It may be that two (or more) are combining in a weird way.  It's conceivable that KISS IT is involved, but I can tell you that there are a number of people with KISS IT installed who are able to register on their websites.  And of course, KISS IT changes image handling not form handling nor registration.  So unless you combine it with something like ReCaptcha (which shows an image as part of form processing), I don't see how it could do anything.  And really, it's more likely that there is a problem with either Guest Checkout or ReCaptcha or both. 


  4. 2 minutes ago, LeeFoster said:

    The upgrade to 1.0.7.5 has caused issues with this add on, is any one interested in working together to get this fixed?

    1.0.7.5?  Or 1.0.7.4?  You should be able to just change the hook to run just before the shopping cart actions.  I did this recently, so I should probably be able to look up the new hook name/location later. 


  5. Perhaps post the code where you say tep_draw_form ?  E.g. for adding to cart: 

    
    <?php echo tep_draw_form('cart_quantity', tep_href_link('product_info.php', tep_get_all_get_params(['action']). 'action=add_product', 'NONSSL'), 'post', 'role="form"'); ?>

    I suspect that you need, but are not using, tep_get_all_get_params. 


  6. Note that the buy button can be shown either by a content module or by a PI module.  First check that you are editing the right one.  If you can't make any text appear when editing the template, you are probably editing the wrong one.  So either switch the location where you change the code or change which shows the buy button. 


  7. The easiest way is what the sample Shiny Red Apples does.  Make single and box attributes and let the customer choose between them. 

    A more complicated way would be to use an App that manages quantity-based pricing.  I note that there are three that claim to be Phoenix compatible in the Marketplace


  8. In your module, leave off the global $any_out_of_stock and replace all occurrences of $any_out_of_stock with $GLOBALS['any_out_of_stock']

    If that doesn't help, please post every line where you use any_out_of_stock. 

    The reason why it doesn't allow you to add/edit/delete is that all of those do redirects.  You can't emit any HTML until after you do redirects. 

    It's acting like something is causing it to emit output early -- see if you can figure out what is doing that.  It would probably be something gated by any_out_of_stock. 


  9. For anyone who's curious, Linux patch files are not the recommended way to request updates to projects that are on GitHub.  It is much easier for both sides to fork the repo.  Make the changes.  Commit them in some reasonable fashion (meaning changes in a commit should have some relation with each other).  Then, in the case of Phoenix, open an issue requesting to merge the changes.  Then if the two sides agree, do a pull request following the instructions given in the issue. 

    In general, there is no need to comment out code that is in source control.  That after all is what source control does:  track changes.  That just converts one change into two changes. 

    I would also point out that if you make your living from Phoenix and do not support it, Burt is not going to be terribly interested in changing comments and language files to support you.  From his perspective, he is already doing work for free for you in providing the functionality in the releases.  Now you want him to do more work in an area where he really doesn't care.  And other than your pedantic corrections, you're not willing to contribute anything.  Not even the time to learn how to make coding contributions in a format convenient to him. 

    I personally would oppose some of these changes, e.g. converting double spaces after periods to single spaces.  The only difference that makes is that it makes the underlying text match the display (because HTML eats multiple spaces).  And I'm not terribly excited at the idea of adding verbose comments to cover off-the-wall situations like Options -Indexes not working.  Nor do I favor adding cryptic comments like "(MINIMUM Tare Weight)" to the configuration description.  That may help you, after you've figured it out.  But it won't help the typical store owner understand it.  In part, because I'm not sure that most store owners know what "tare" is.  Which is probably why the current description doesn't say anything about tare weight. 

    Adding comments to the sample data SQL to talk about files in the images/sample directory is not productive.  Because only developers would ever look there and it's not generally developers who need to keep the images directory clean.  And of course, by the time that someone would notice that the files are there, they've already deleted the install directory--including the comment.  So it's basically a reminder to the rare developer who happens to read the sample data SQL.  Which the same developer would then have to remember anyway, because most people don't read the sample data SQL (ever, much less every install).  Burt's suggestion, which Phoenix supporters do not seem to value, as they haven't voted for it, was to add a new "security" module (not for security but simply as a reminder) which would remind people that they had sample artifacts on the server and might want to delete that.  The same way it currently prompts people to remove the .github directory.  The contents of which you apparently haven't read, as it explains the process to make pull requests.  Which goes back again to my point about a comment in the sample data SQL being unlikely to reach its intended audience. 

    I would agree with changing "setup" to "set up" and "checkout" to "check out" when used as a verb, but I really doubt that you can find a way to make that exciting to Burt.  I notice that you don't change login to log in.  Perhaps that means that I changed them all already.  But I wouldn't bet on it. 


  10. Two quick guesses: 

    1.  The disk partition containing /var/tmp is full.  Fix by deleting some older files.

    2.  The directory /var/tmp had its file permissions change.  Either change the permissions back or change to a new directory. 

    In either case, /var/tmp is outside the osCommerce directory structure, so you would probably need help from your host.  This seems more of a system administration thing than an osCommerce thing. 

    If you administer this server yourself, on the Linux command line, try running

    df -k
    ls -ld /var/tmp

    The results of one of those two commands might be informative. 

    Your error_log and access_ssl_log.processed are huge.  Consider downloading and truncating them.  If you have log rotation set up, perhaps run it manually. 


  11. 10 hours ago, Gary Tayman said:

    I've been using the table rate, and it sorta kinda works for some shipments, but when it charges $6 to ship auto parts to Switzerland there's a real problem

    If you want your shipping costs to be different by geographic region (zone), use zone shipping.  That comes with the latest community edition release.  You might try joining the Phoenix Club for more help with the community edition. 

    In terms of installing modules, you do that at admin > Modules > Shipping.  Click the Install button to see a list of available modules.  Note that you have to upload the files first if it's not one of the ones that come with core. 


  12. 1 hour ago, glamocanilaktasi said:

    My host told me that I am on shered hosting and thay can't remove TLS 1.0 and 1.1  becouse other users use this options.

    But TLS is configurable per VirtualHost.  So it can have multiple values on the same shared server.  I.e. they can have one setting for most everyone and then put just those sites that need the historical settings on a different VirtualHost. 

    If your host can't do that for you, then switching to one that can is highly advised.  I mean, the very fact that they didn't just fix it is an argument in favor of switching hosts. 


  13. 2 hours ago, anya2001 said:

    Is there any update on this?  Is osCommerce developing a new module?

    As far as I know, no one associated with osCommerce or Phoenix is working on a new module. 

    Note that there is no requirement that a payment module be provided by osCommerce or Phoenix.  Authorize.net or a third party could make a payment module.  Like all modules (including the old Authorize.net modules), it should be a drop-in install without any need to modify core. 


  14. The obvious place to put it would be in a hook or header tags module (as a footer script). 

    class hook_shop_checkout_confirmation_pending_order_email {
    
      public function listen_injectSiteEnd() {
        if ($GLOBALS['order']->info['payment_method'] === 'Paypal') {
          require 'includes/functions/pending_order_email.php';
        }
      }
    
    }

    That's probably the most literal translation of it.  You may have to move some of the contents of that file into the hook file instead.  E.g. the actual function declarations.  I presume that it's written to have some side effect.  Perhaps move the side effect into where the require is and move the function declarations after the hook class declaration. 


  15. 1 minute ago, discxpress said:

    Where do I place ---> }

    I keep getting an error on line 78 when I remove it.

    Leave it where you had it in your previously posted code.  The only change from your previously posted code should be to switch the order of the two lines that I posted. 

    You could also switch two of the } but since they are identical, there doesn't seem to be any point.  The positions where they are are correct enough (if I were doing the change, I'd indent them to match everything else; but that won't affect functionality). 


  16. @discxpress

    You have two lines in your code: 

    if ($GLOBALS['PHP_SELF'] == 'index.php') {
        function execute() {

    replace those two lines with

        function execute() {
            if ($GLOBALS['PHP_SELF'] == 'index.php') {

    I.e. swap the order of those two lines.

    The rest of the code can stay the same as in your previous post. 


  17. 3 minutes ago, Dj-Viper said:

    Nieuwe order is not send, that's is before the payment module will kick in.

    This is not the normal workflow.  Normally, when the order is first inserted in the database, the email is sent. 

    So two possibilities: 

    1.  Your payment module performs its own workflow where it inserts the order before processing the payment. 

    2.  You have order emails turned off. 

    If the latter, turn them on.  If the former, then the payment module would need to be modified. 

    It would be problematic to modify such a payment module to work the way that you describe.  Because payment modules that insert the order into the database before processing payment do not necessarily process the payment.  Because payment failures happen after the order is inserted. 

    Typically, if your payment module works that way, what you want to happen is for the email to be initiated in two ways. 

    1.  When the customer returns to the web site after paying, it sends the email.  This happens automatically on checkout_process in the normal flow. 

    2.  If the customer does not return to your web site, the payment processor sends a payment message which triggers sending the email.  PayPal calls this an IPN. 

    Perhaps your payment module is missing the latter portion.  Or it could be bypassing the former.  Or both. 

    Regardless, this isn't a matter of simple configuration (unless you have order emails turned off).  You need development on the payment module. 


  18. 10 hours ago, ce7 said:

    showSub($dir2, $sub)

    It's telling you that that function is not returning an array.  It would need to consistently return an array to be used that way. 

×