Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Reputation Activity

  1. Thanks
    ecartz got a reaction from raiwa in Purchase without account for 2.3.4 and BS2334   
    Are you sure?  Isn't there a PWA customer data module that runs on the regular create account page to set the is_guest to false? 
    There are no calls to tep_guarantee_subarray in core, so it would have to be an App.  The message is basically saying that tep_guarantee_subarray should be replaced with Guarantor::guarantee_subarray instead. 
    I agree that turning display_errors to 0 would get rid of
    That is the obvious short term solution to it breaking the store.  Production stores should not have display_errors on in general. 
  2. Thanks
    ecartz got a reaction from Mikepo in Purchase without account for 2.3.4 and BS2334   
    TY.  https://github.com/gburton/CE-Phoenix/commit/2214e53a6fce23bd6e3953149b4d0e2d48e1fb82
  3. Like
    ecartz got a reaction from yeno in Fix special price based on percentage   
    This would not be a small change. 
    It might be easier to add a categories.preAction hook that checked if the product price changed and updated the specials price appropriately.  This could involve a new column that would be a boolean for update or not.  Or it could happen always.  Then the catalog code would not need to change, only the admin behavior. 
  4. Like
    ecartz got a reaction from Fredi in SOAP Error   
    Tell them that you can connect to https://api.globalgatewaye4.firstdata.com/transaction/v12/wsdl in your browser but not from the site. 
  5. Thanks
    ecartz got a reaction from ArtcoInc in How to edit the breadcrumb in Phoenix   
    If that is what you wanted to do:  remove the Catalog link and change the home icon to point where Catalog did previously. 
    ITYM:  in the bad old days, this required an edit to a core application file.  In the good new days, this only requires a simple edit to a language file. 
  6. Thanks
    ecartz got a reaction from Kofod in Orders altered by customers not showing correctly   
    In core, ignoring the payment module, the order is only inserted after payment is completed. 
    So if you are seeing a behavior where the order is inserted prior to payment being made, then the payment module is doing that.  And it would be the payment module's responsibility to delete the order if modifications are made.  That needs to be done in addition to the core processes, because, as I said, the core solution is to not insert the order until after payment is made.  In PayPal Standard, that is done in the confirmation method:  https://github.com/gburton/CE-Phoenix/blob/b7bfcaccc3e2cd9641b9d0c8db2be1cecf250a11/includes/modules/payment/paypal_standard.php#L154
    Note how it deletes and then reinserts the order under some circumstances.  Without any knowledge of the Quickpay module's code, my guess would be that it is not doing that at some times (perhaps all times) when it should. 
  7. Thanks
    ecartz got a reaction from Dnj1964 in Admin -> Tools -> Define Languages   
    This is probably telling you that the file is not writable by the web server. 
    Info Pages edits database entries, not files. 
  8. Like
    ecartz got a reaction from radhavallabh in ULTIMATE Seo Urls 5 - by FWR Media   
    I think that a "non-consecutive numerical sort order" is probably the best solution.  Note that it doesn't need to be a database entry.  A hook file in includes/hooks/system would work as well. 
    The closest thing to documentation is the commit notes (and the commit itself):  https://github.com/gburton/CE-Phoenix/commit/ae01e0d4d91b2e4a561735168ef4fbe6ba8e6899
    Related commit:  https://github.com/gburton/CE-Phoenix/commit/d2adabebe2efbdcd28513c6057758cd25ed48fc4
    I don't think that it is very complicated.  HTTP_SERVER . DIR_WS_CATALOG should always be used now, where previously it was only sometimes used (in the ENABLE_SSL false case).  For the most part, this is just simpler.  Because instead of having to check various things to determine the correct link, the code can just consistently use one thing.  The old system was complicated, as it had to try to mix SSL and non-SSL pages.  But this always uses whatever the HTTP_SERVER is configured to provide. 
  9. Thanks
    ecartz got a reaction from burt in Error In Admin   
    It's in his other thread: 
  10. Like
    ecartz got a reaction from Omar_one in Allow_url_fopen Fresh Phoenix Install   
    Never mind.  Burt already did:  https://github.com/gburton/CE-Phoenix/commit/84812c63fc854d405b023b48064a96df47c85b1c
  11. Thanks
    ecartz got a reaction from raiwa in Featured Products BS   
    In PHP 7.4, the actual problematic line is
    $cat_name = $category['categories_name']; which makes more sense with the error (dereferencing of null).  It's saying that there is no global variable named $category.  Perhaps this code predated the category_tree change.  I think it should be
    $cat_name = $GLOBALS['OSCOM_category']->getData($GLOBALS['current_category_id'], 'name'); in the cm_in_featured_products.php file.  And in cm_i_featured_products.php, I think that line and all references to $cat_name in the template file should be removed.  Because the root category doesn't have a name. 
  12. Like
    ecartz got a reaction from ArtcoInc in Installation oscommerce   
  13. Like
    ecartz got a reaction from ce7 in Wholesale (SPPC lite)   
    This has nothing to do with Rainer's Wholesale App (so this really isn't the right place to ask), but you should copy the latest version into includes/system/override (which you may have to create) and modify it there. 
  14. Thanks
    ecartz got a reaction from raiwa in Wholesale (SPPC lite)   
    I think that removing the line is the correct response.  The class should be autoloaded in any newer version, so it shouldn't break anything.  It should not be necessary to manually require/include anything under includes/system/versioned.  Nor for that matter under includes/classes, includes/system/override, includes/modules, or includes/hooks. 
  15. Like
    ecartz got a reaction from burt in Order missing after paypal payment received   
    It might be easier just to remove the requirement that the order status exist. 
    LEFT JOIN orders_status s ON o.orders_status = s.orders_status_id AND s.language_id = " . (int)$languages_id . " WHERE Also consider the case where the missing order status is not 0. 
  16. Thanks
    ecartz got a reaction from CGIFTER in Admin Dashboard Display of Customers & Orders   
    Those are modules.  You can configure them at admin > Modules > Dashboard.  Select the appropriate module and edit the configuration. 
  17. Like
    ecartz got a reaction from valquiria23 in Remove Buy Now / Add to Cart button so only showcase website   
    admin > Modules > Content; look for Buy Button and Price under product_info. 
    For the product listing, there is no getting around editing code manually to remove the price and buy button.  https://github.com/gburton/CE-Phoenix/blob/master/templates/default/includes/components/product_listing.php
  18. Like
    ecartz got a reaction from bodhizatfa in SMTP with authentication on Phoenix   
    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. 
    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. 
  19. Thanks
    ecartz got a reaction from mendoh in SMTP with authentication on Phoenix   
    A 500 error is simply telling you that there was an error on the server.  Check the error logs for a more precise error. 
  20. Like
    ecartz got a reaction from raiwa in Converting Points and Rewards system for osC BS   
  21. Like
    ecartz got a reaction from raiwa in Converting Points and Rewards system for osC BS   
  22. Like
    ecartz got a reaction from Psytanium in Notice: Undefined variable allover the website after unknown server update   
    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
    $variable with
    (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. 
  23. Like
    ecartz got a reaction from Mikepo in Notice: Undefined index: customer in /srv/disk2/2305237/www/shop.winterparkstampshop.com/includes/modules/navbar/nb_account.php on line 22   
    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. 
  24. Like
    ecartz got a reaction from ce7 in admin/reviews.php   
    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. 
  25. Like
    ecartz got a reaction from Snarg in Installed, now what...?   
    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. 
    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.