Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by ecartz

  1. It looks like you are doing something custom to differentiate your products. The osC way would be for you to create attributes for the sizes. Then there would be multiple product IDs. E.g. product_info1.php?products_id=666{1} and product_info1.php?products_id=666{2} They would have the same base product ID, but the cart would show different extended ones. The tep_get_prid function takes the long form and trims off the attributes to get the base ID. The tep_get_uprid function adds the attributes to the base product ID to produce the long form. Your shop is customized enough that I can't say concretely how you would have to do things differently. But that's how things are intended to work in this situation. Hopefully that at least gives you an idea of where to look in your modifications.
  2. ecartz

    Add Mr. or Ms. to order process/web orders

    In what version? This would be very different in Phoenix from even much less or older.
  3. What is the part of the product URL after the domain? I.e. something like product_info.php?products_id=blah{blah} I looked at your site, but I don't see how to generate that cart. Perhaps this is something from a test store?
  4. You could reduce (but not eliminate) the danger by removing the r from rm -rf find change_to_your_own_directory/ -type f -name '*.mx' -exec rm -f {} \; The r stands for recursive and is what allows rm to delete directories. Without it, rm will only delete files. Better might be to do something like find change_to_your_own_directory/ -type f -name '*.mx' -print find change_to_your_own_directory/ -type f -name '*.mx' -delete Where you check the files printed by the first line before running the second line. Two possibilities that come to mind: 1. This is caused by some IDE. E.g. Dreamweaver MX. 2. This is a hack attempt of some sort. Similar problem reported at https://stackoverflow.com/questions/61875526/mx-files-found-in-wordpress-core-files-with-the-same-core-code -- perhaps that will get a relevant answer.
  5. ecartz

    Displaying orders (list)

    In Phoenix, this would be based on MAX_DISPLAY_SEARCH_RESULTS which affects catalog and admin. That's under admin > Configuration > Maximum Values To change to not use MAX_DISPLAY_SEARCH_RESULTS, you would edit admin/orders.php $orders_split = new splitPageResults($_GET['page'], MAX_DISPLAY_SEARCH_RESULTS, $orders_query_raw, $orders_query_numrows); I don't know if your version is the same or not. But it might be worth checking.
  6. ecartz

    Lost with version to use

    No. It's often better to start a new site for that migration. So your stays on 5.3 while you work on Phoenix on 7. Some hosts can do that in subdirectories but most will prefer separate domains. You might be able to use a subdomain like shop.mysite.com rather than www.mysite.com
  7. ecartz

    Lost with version to use

    Yes. Phoenix requires PHP 7. That particular line requires PHP 5.4 or newer. If you go directly to www.mysite.com/myshop/install/index.php, you'll get a page that tells you that you need PHP 7.
  8. ecartz

    Lost with version to use

    You should not use Frozen if you are starting today. Version will not work with newer versions of PHP. So if you use it, you should make sure that you stay on PHP 5 and not 7. Your host may not like to continue running PHP 5. Phoenix is current, responsive, and under active development. It is the successor to Frozen. I would recommend this over
  9. The message says, "invalid offset". A string is (by definition) a valid offset. So what the message is telling you is that $payment is not a string (nor a number). With the check, it no longer gets to the point where it tries to use $payment as an array offset. Because if it's not a string, PHP doesn't bother checking the rest of the expression. This is called short circuit evaluation.
  10. Wait. He hasn't released his compatible version yet. This particular App is more impacted by the changes than most and will require more than just a few tweaks at the edges.
  11. If you just want to get rid of the error, try changing line 241 to if (is_string($payment) && isset($GLOBALS[$payment]) && is_object($GLOBALS[$payment])) { As I said previously, the real problem is almost certainly in code that is setting payment somewhere.
  12. ecartz

    Report of specific product sole and to whom

    SELECT o.*, op.* FROM orders o INNER JOIN orders_products op ON o.orders_id = op.orders_id WHERE op.products_id = 1 Replace 1 with the correct product ID. The product ID will be visible on the product page, e.g. product_info?products_id=1 You'd put that query into phpMyAdmin (SQL tab) or similar. Note that you might be better off taking the generated list and viewing the orders individually in your admin. This is probably more work than Burt's solution, but it is also more likely to work. So try his first and then if it doesn't do what you want, you can try this.
  13. ecartz


    The Community Edition (Phoenix) is mobile ready out of the box. So the easiest way is to pick a hosting company that already supports Phoenix.
  14. ecartz


    Everywhere in the file where it says " . TABLE_CONFIGURATION . " replace it with just configuration
  15. ecartz


    $check_query = tep_db_query("SELECT configuration_value FROM configuration WHERE configuration_key = 'MODULE_ORDER_TOTAL_TAXRATES_STATUS'"); It needs to be lower cased and should be inside the quotes, not outside.
  16. is_object($GLOBALS[$payment]) That checks to see if there is a global object named $$payment. If it was checking for a global object named $payment, it would say is_object($GLOBALS['payment']) The warning is saying that $payment, which should be a string, is instead an object. Because an object is not a valid array index key (in PHP), it complains when it attempts to dereference $GLOBALS (an array) with it. Where dereference is just a fancy word for doing $GLOBALS[$payment]. Meaning to find the entry in $GLOBALS for the key $payment. It's also possible that the code is going down a weird path when there is an error. It seems like something is doing $payment = new payment(); while $payment is bound to the session value. If this is a bug in, it won't get fixed now, as we've moved on to So any fixes would occur in or later.
  17. https://github.com/gburton/CE-Phoenix/commit/ed074660e9c1b2c30200f8e5006fce1a53c08416#diff-8b27695473c9fdb061fe2a0d1f3d59d6 Which is just a fancy way of saying, not in https://github.com/gburton/CE-Phoenix/commit/ccee9f7b75a9392325e10c4025360b7f0c630a92#diff-8b27695473c9fdb061fe2a0d1f3d59d6 In, you would probably put it right after tep_db_perform('orders_status_history', $sql_data_array); Or perhaps just before // lets start with the email confirmation If there are instructions for older versions of Phoenix or the BS edition, they are probably correct for The big changes to that file occurred in With some tweaks at
  18. __ PHP_Incomplete_Class is what happens when the session is loaded before the class. This should not happen if you use a version of Phoenix with the autoloader and the payment module is in includes/modules/payment. So one solution would be to update from to or That should get rid of the __ PHP_Incomplete_Class. Another issue though is that $payment should be a string, not an object. $$payment should be the object. So it is likely that there is a bug in the module where it sets $payment equal to something where it should have set $$payment (or $GLOBALS[$_SESSION['payment']]) to something.
  19. tep_redirect(tep_href_link('checkout_confirmation.php', 'error_message=Kies+uw+bank!', 'SSL')); Maybe? Typo in the page name and unescaped spaces in the error message. A side issue is that it often redirects to either checkout shipping or payment rather than confirmation. What does "Kies uw bank" actually mean in this context? Google thinks it is "Choose your bank". But who is supposed to choose? You? The buyer? Where does that happen?
  20. ecartz

    Product Attributes Random Order Problem

    Assuming the latest osCommerce is CE Phoenix, the order is set in https://github.com/gburton/CE-Phoenix/blob/master/includes/modules/content/product_info/cm_pi_options_attributes.php It orders by name. So to get a different order, make the names have a definite order. E.g. 1. Small 2. Medium 3. Large 4. Xtra Large 5. 2XL Where the initial number is part of the option name. Note that this only supports up to nine choices per option. It's possible that a different version might have a different order, e.g. by order of entry in the database. I mention this because I think that your order would be difficult to achieve in CE Phoenix. Perhaps 2XL, Small, Xtra large, large, medium would do it (mixed casing intentional). I would expect with consistent casing, it would be 2XL, Large, Medium, Small, Xtra Large.
  21. ecartz

    Wrong redirect after add to cart

    The most likely problem is that $PHP_SELF is set incorrectly. Check any mod_rewrite rules or the original link. I.e. I don't think the problem is in the code that you posted but somewhere else.
  22. ecartz

    Error with manufacturers.php

    It says that the cache was corrupted and not reloading. There may have been a PHP update on your host that changed how count handled things in that case. I have a sort of vague recall that something used to be a zero that may now be a one. But since that code doesn't set the cache block, there's no way to fix it there. You might be able to fix it in whatever the $cache thing is, but I don't believe that's standard. I think that's an App you added. Because I recall the core caching as working differently. Of course, that's old enough that perhaps my recall is wrong. You commented out the code that checks if the cache is working and falls back to a database query. So it just always does the database query. Because the cache was returning that it was working even though it didn't seem to be.
  23. ecartz

    Add download filename to admin orders

    I think that we should put the orders_products_id in the products array in the order. Then it wouldn't be necessary to override the order file for this customization or redo the orders_products part of the query. It could just load the data for the downloads directly and add it to the order object. SELECT * FROM orders_products_download WHERE orders_id = while ($download = tep_db_fetch_array($downloads_query)) { foreach ($order->products as &$product) { if ($download['orders_products_id'] === $product['orders_products_id']) { $product['download_filename'] = $download['orders_products_filename']; } } unset($product); } And that could be done in a hook with no core modification (other than the one that we'd make to pull in the orders_products_id).
  24. When I try editing the corrupted version of the file, I get either CRLFCRLF or LFLF depending on whether I do the replace before saving. A better replacement might be $file_contents = preg_replace("{\r+\n}", "\n", stripslashes($_POST['file_contents'])); But I can't really test it, as I believe that the CRCRLF is getting converted to CRLFCRLF prior to that point. I'll let @burt make the decision about whether it is better to push to core or not. And which version and when.
  25. I checked it with vim -b and xxd which showed me one CR per LF. But as described, I shouldn't have had to do so to get the result that you did. Because it should have showed me extra blank lines. So even without any further checking, it should have been visible. I checked on Apache/2.4.29 (Ubuntu) PHP 7.2.30, which seems similar enough to yours that it should have shown. Have you tried it in a different browser or in safe mode (without extensions) Firefox? Or from a different computer? How do you get the file to Notepad++? Does it load the file for you? I wonder if you have it set in such a way that it tries to convert the file from Unix to Windows line endings, even if the file is already in Windows format. You might try it on the Unix command line with something like xxd, which shows me The 0d of course is the carriage return and the 0a the line feed. If you want me to verify that I can view the doubled carriage returns, email me a copy of one of the corrupted files. Or you could try changing $file_contents = stripslashes($_POST['file_contents']); to $file_contents = str_replace("\r\n", "\n", stripslashes($_POST['file_contents'])); I tried that on mine and it left things as Unix line endings. Perhaps yours would leave it as Windows line endings.