Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Posts posted by ecartz

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

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

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

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

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

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

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

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

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

  10. 1 hour ago, Snarg said:

    2) Admin tools are telling me I need to change the permissions on configure.php, but it's not telling me what I need to change them to.

    The most likely to work setting is 444 (read only).  But 644, 640, or 400 might work.  This depends on how your host is set up. 

    1 hour ago, Snarg said:

    3) Are there directions that show me how to get HTTPS up and running.

    This is almost all outside osCommerce.  Ask your host how to enable SSL.  Again, that depends on how your host is set up.  This may be as simple as flipping a switch or it may be complicated. 

    With SSL enabled, CE Phoenix will automatically configure your store if you run the install procedure from the https URL.  I.e. if your store is https://www.example.com/ then going to https://www.example.com/install/install.php should handle the configuration for you.  Note that this will clear out any changes you already made to the database.  It's also possible to enable SSL by manually editing the two configure.php files to replace http: with https: if you don't want to reset your store.  In either case, you need to have the SSL working on the domain before you try to configure CE Phoenix. 

    Those notices will be gone in the next version.  If they are really bothering you, in the configure.php files change the error_reporting(E_ALL) to

    error_reporting(E_ALL & ~E_NOTICE);

    Or simply set display_errors to false.  Your host should offer a way for you to do this.  It's PHP configuration.  Again, the exact method is going to be different from host to host. 

  11. 2 minutes ago, Mikepo said:

    What I mean is, in the shop side orders are not shown in the customer account if this payment module is used.  However the order is shown in admin. 

    Might this be the visibility settings on the order status?  Try checking the settings for the status you are using for these orders at admin > Localization > Order Status. 

  12. 12 minutes ago, ejsolutions said:

    Given that I host/support a few clients with predominantly open-source sites, I'd come under the £30/month tariff.

    I don't want to get in the middle of this conversation, but I do want to point out that that's not how it works.  There is no minimum supporter level for anyone.  There is at least one person who qualifies for that program but still participates at the lower level. 

  13. 1 hour ago, nedragdnuos said:

    Warning: Use of undefined constant TABLE_TAX_CLASS

    In general, when you see errors of this form TABLE_SOMETHING in regards to SQL, the fix is to go through and replace

    " . TABLE_TAX_CLASS . "



    And yes, it is deliberate to remove the quotation marks and periods when doing that.  Before the code was concatenating the constant into the string.  Now the constant is gone and you just put the table name directly into the string. 

    "select tax_class_id, tax_class_title from tax_class order by tax_class_title"

    Note that this means that the App was last updated prior to the release.  So we're two .0 versions past the change being made that broke this.  And we're even further past the start of the change, which actually predates Phoenix.  I mention this because unless you have budget to get this updated professionally, you might find that there are other issues that are not current in the code.  This just being a particularly visible instance. 

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