Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Posts posted by ecartz

  1. 1 hour ago, SolidAmerica said:

    Warning: Cannot modify header information - headers already sent by (output started at /home/www/mysellingstoreexample.com/.com/stores/includes/system/versioned/ in /home/www/mysellingstoreexample.com/.com/stores/includes/functions/general.php on line 36

    This says that you have display_errors turned on.  You can add

    ini_set('display_errors', '0');

    to includes/configure.php to turn it off.  Or turn it off in your hosting account if they allow you to do that. 

    You should not have display_errors turned on in your live store. 

    The warning and notices will be fixed in the release. 

  2. 19 minutes ago, marokech said:

    while keeping the same USU5 module (language class removed in

    The language class may have been moved, but it is unlikely it was removed.  If that were the one and only problem, it could presumably be fixed if you explained what the actual problem was. 

    If it's that there is code that you used to add immediately after the language code, then you can just move it into the i() function.  Change

         if ( !self::$_singleton instanceof Usu_Main ) {
           self::$_singleton = new self;


         if ( !self::$_singleton instanceof Usu_Main ) {
           self::$_singleton = new self();
           global $lng;
           self::$_singleton->setVar( 'languages_id', $_SESSION['languages_id'] )
                   ->setVar( 'request_type', $GLOBALS['request_type'] ) 
                   ->setVar( 'session_started', $GLOBALS['session_started'] ) 
                   ->setVar( 'sid', $GLOBALS['SID'] ) 
                   ->setVar( 'language', $_SESSION['language'] )
                   ->setVar( 'filename', $GLOBALS['PHP_SELF'] )
                   ->initiate( ( isset( $lng ) && ( $lng instanceof language ) ) ? $lng : [], $_SESSION['languages_id'], $_SESSION['language'] );

    And you can add the other change to includes/classes/application.php -- find


    and add after it

      if (USU5_MULTI_LANGUAGE_SEO_SUPPORT == 'true') {
        include_once 'includes/modules/ultimate_seo_urls5/includes/hreflang.php';
        global $lng;
        $GLOBALS['usu5_multi'] = new FWR_hreflang( $_SESSION['navigation'],  $_SESSION['language'],  (isset( $lng ) && ( $lng instanceof language ) ) ? $lng : [], $GLOBALS['session_started'] );

    That's not the ideal solution, but it should get you around your immediate problem. 

    A better solution would rename the file and/or class so that the autoloader would load it (no more include_once).  And create a no-arg factory method for it that could be called from a hook.  Then you wouldn't need to make a core edit.  But if the only thing keeping you from using this App is that you can't find the code to edit in application_top.php, there it is.  Presumably something like this is part of what piernas needs to test. 

  3. 10 minutes ago, SolidAmerica said:

    Warning: Cannot modify header information - headers already sent by (output started at /home/www/mysite.com/stores/includes/system/versioned/ in /home/www/mysite.com/stores/includes/functions/general.php on line 36

    To fix this, turn off display_errors in the PHP configuration.  Then the notices will not be displayed on the screen and won't break redirects. 

    I do not know why you are getting these notices though.  It seems to be saying that no payment module has been selected. 


  4. That sounds like you are using a very old version of PHP.  5.3 maybe?  If you can't update PHP, perhaps try an older version of Stripe SCA. 

    You could try replacing the [ on that line with array( and the ] with ).  Not sure how many times you'd have to do that in the file though. 

  5. There is a forum for PayPal questions:  https://forums.oscommerce.com/forum/54-paypal/

    There are several recent topics that say that PayPal made a change that requires an updated certificate.  If you made no coding changes and it just stopped working, that seems the most likely explanation.  The up-to-date version is at https://github.com/gburton/CE-Phoenix/blob/master/ext/modules/payment/paypal/paypal.com.crt

    If that is not it, it is barely possible that your host updated PHP in a way that broke your site.  But the certificate is both more likely and an easier fix, so I would check that before talking to your host. 

  6. 4 hours ago, mendoh said:

    Save this email.php file in a directory named includes/system/override (which you will probably have to create) and see if it starts working.

    OK.  But what actual error was that file causing?  It's possible that someone might be able to help you with that. 

    Note that while Stewart has not gotten it working by following those instructions, he has gotten it working by jamming the contents of the file in a different location.  It does still require installing PHPMailer and configuring it.  I know nothing about configuring PHPMailer, so I can't give you any guidance with that.  But still, someone else might be able to do so.  For example, Stewart did apparently get that part of it working. 

    4 hours ago, mendoh said:

    How can any customer registering on the shop with a hotmail or gmail address get an email confirmation for their order if non-SMTP authenticated emails get blocked before being delivered to hotmail/gmail addresses?

    This seems more like a hosting problem.  I have certainly sent emails to my gmail address through a sendmail executable.  If your host doesn't support that, I would recommend switching hosts to one that does.  Note that talking about non-SMTP emails is simply nonsense.  All emails are SMTP.  The difference is the three kinds of access to SMTP.  The sendmail kind is a local executable on the PHP server.  The "SMTP" kind is a local SMTP server on the PHP server (primarily for Windows).  The authenticated kind is a remote SMTP server.  So what your host is saying is that rather than handling the authentication for you, they want you to authenticate manually.  Because that's less work for them.  I'd suggest saving them even more work and switching to a different host.  Note that two of the certified developers are associated with hosting services. 

    Eventually, I'm sure that someone is going to have to spend resources to get authenticated SMTP working.  There seems to be a hope that "someone" will be either me or Burt.  But even if it was, then I can tell you, that it would be released as a supporters' code rather than in core.  So it might be better to approach one of the certified developers about it.  As they are more likely to simply update the existing authenticated SMTP App with PHPMailer to work with Phoenix.  It shouldn't even be that difficult, as I already rewrote and posted the code to do it.  So what's left is essentially writing the instructions for installing and configuring PHPMailer and bundling the files properly. 

    Rainer supports a large number of legacy Apps that are no longer supported by their writers.  John has experience with custom email configuration.  Preston likes to write Javascript package installers.  It's possible that any or all of them might be interested in that kind of project. 

    Another alternative would be filing a feature request with PHP.  There is of course no reason why they couldn't implement authenticated SMTP in PHP itself.  Then you would just have to configure it properly and you'd be able to use the mail function normally with a remote SMTP server.  That would fix not just this software but PHP software in general. 

  7. Note that these notices have been there all along.  The update would only have revealed them.  Most likely by defaulting display_errors to on.  It should never be set on in production.  So you should get that turned off regardless. 

    In general, replacing



    (isset($variable) ? $variable : null)

    will get rid of the notices.  However, this is essentially the same as just turning down the error reporting, as null is the default value of an undeclared variable.  The notice is basically telling you that it is doing this for you. The real fix is often to code the add-ons differently.  E.g. in

    if (false) {
      $variable = 'value';
    if ('value' == $variable) {

    If those are the only two occurrences, you could fix this by

    $variable = null;
    if (false) {
      $variable = 'value';
    if ('value' == $variable) {

    But watch out that it isn't really

    if (true) {
      $variable = 'default';
    // doing $variable = null here would overwrite the previous value
    if (false) {
      $variable = 'value';
    if ('value' == $variable) {

    Note that these statements do not have to be in the same file. 

    There isn't a strictly mechanical solution.  Removing the notices properly requires understanding why they are shown and changing appropriately to that particular situation.  There isn't a simple rule to apply that would be better than turning down the error reporting. 

    Sometimes the notice may be telling you that something is wrong.  E.g.

    $typo = true;
    if ($tyop) {

    Which can be fixed by correcting the spelling in the second line. 

  8. Shop version?

    Edit the error_reporting in includes/application_top.php in older versions.  Or in the configure.php files in the latest Phoenix.  Adding & ~E_NOTICE should suppress those messages.  If it is already there, this may require a conversation with your host. 

    Turn off display_errors in php.ini or however your host does it.  This may require talking to your host, although some allow you to configure this yourself.  It may help to refer your host to https://stackoverflow.com/a/54215956

  9. More constructively, if you want to exchange money to get a template implemented, there are resources in the Phoenix Club to get a quote or you could post in the Commercial Inquiries forum. 

    I don't know of anyone creating an off-the-shelf template for Phoenix that you can just install.  Phoenix has the capacity for drop-in templates.  But no one is currently using it. 

  10. That is a bad use of array_key_exists.  Replacing it with

    if (isset($GLOBALS['customer']) && $GLOBALS['customer'] instanceof customer) {

    will always return the same answer and be faster.  Because isset is faster than array_key_exists and because it saves the instanceof check in a circumstance when it always fails.  The only time to use array_key_exists is when you need to know the difference between never set and defined but set to null.  Which you don't here.  Because if it is null, it is not an instance of customer.  So the expression will return false whenever isset and array_key_exists return different results regardless of which is used. 

    It is pretty rare to be in a situation where one should use array_key_exists.  It gets recommended by people who are offended that PHP traditionally treated all undeclared variables as having a value of null.  But the truth is that there are very few situations where one wants to know if something was not declared versus declared with a null value.  And of course most of those situations can be fixed by simply setting explicitly to false rather than null.  So it's pretty much only when interacting with someone else's code that one has any reason to use array_key_exists over isset. 

    In this particular case, array_key_exists is itself slower and in addition, whenever it returns true and isset false, the instanceof will be false.  So it will be even slower (because it does the instanceof check after getting a true from array_key_exists) to return the exact same result as isset.  Note that

    (isset($GLOBALS['customer']) || array_key_exists('customer', $GLOBALS))

    is faster (on average) than using array_key_exists alone.  But as I said, in this particular case, you want a false result when the two differ anyway.  So it's both easier and faster to just use isset. 

  11. Or to be more precise, replace




    The change of case and removal of quotes is intentional.  In this particular example, it would probably end up looking like

    tep_db_query("select configuration_value from configuration where configuration_key = 'MODULE_PAYMENT_ZAAKPAY_STATUS'");

    There's probably more stuff on the same line that you would need to keep. 

  12. 2 hours ago, ce7 said:

    Warning: array_merge(): Expected parameter 3 to be an array, null given in /admin/reviews.php on line 309

    This is telling you that there is no entry for the given product and language in the products_description table. 

    Either switch to a language that does have an entry in the table or add an entry for your current language. 

  13. It occurs to me that it might need to be

        $banners_query = tep_db_query("SELECT banners_id, date_scheduled FROM banners WHERE date_scheduled > '2000-01-01' AND date_scheduled < NOW()");

    Since you want to mask out zero dates.  It's possible that

        $banners_query = tep_db_query("SELECT banners_id, date_scheduled FROM banners WHERE date_scheduled IS NOT NULL AND date_scheduled < NOW()");

    would work.  And considering what the function does, replacing the contents with

        tep_db_query("UPDATE banners SET status = 1, date_status_change = NOW(), date_scheduled = NULL WHERE date_scheduled IS NOT NULL AND date_scheduled < NOW()");

    would most likely work and be simpler. 

  14. It seems almost certain it is this line:  https://github.com/gburton/CE-Phoenix/blob/880761995f11435e4909a3aa734b0b4ee1f4ba4c/includes/functions/banner.php#L28

    Which was in every release of osCommerce for fifteen years but has been gone from CE Phoenix since at least version 

    Simple fix:  switch from whatever version of osCommerce to the latest CE Phoenix.  If you haven't gotten too far in your process, this may be simplest. 

    More complicated fix:  change the banner code to check against NULL rather than an empty string. 

    Alternative fix:  change the line to

        $banners_query = tep_db_query("SELECT banners_id, date_scheduled FROM banners WHERE date_scheduled < NOW()");

    This will also produce fewer results and would allow you to simplify the PHP code. 

  15. It's inadvisable to add more columns to cart->contents, as it is stored in the session.  That's why price and other characteristics are loaded by get_products rather than stored in the cart. 

    If you are making custom attributes, consider changing the products ID.  That's how that has typically been implemented in the past.  Or consider doing something like product bundles where the user sees one product but behind the scenes there is more than one. 

    The quantity is set in includes/actions.