Jump to content

ecartz

♥Ambassador
  • Content count

    3,864
  • Joined

  • Last visited

  • Days Won

    69

ecartz last won the day on February 10

ecartz had the most liked content!

Internal Fields

  • Interview
    ecartz

Recent Profile Visitors

45,504 profile views
  1. ecartz

    Order Confirmation Email Text

    This is very new, so it may be that your version of Phoenix is older than this change. Also, it probably isn't incorporated in Gustavo, as Burt doesn't normally update until a .0 release.
  2. ecartz

    osCommerce 2.3.4-1 EDGE

    And yet, off the top of my head, I find https://www.nazzalstraumhochzeit.de/ https://honda4parts.nl/ In the EU and using Phoenix. It may not be for you. You'll have to make your own decision on that. But other EU shop owners seem to be using it just fine. Not to mention EU-adjacent shops in the UK, Switzerland, Russia, etc.
  3. ecartz

    Order Confirmation Email Text

    Note that modules are also an exception in the default template. Everything else (except language files) is stored in the template. But the module templates are stored with the modules.
  4. ecartz

    Order Confirmation Email Text

    Yes. It's just like any other template.
  5. ecartz

    Order Confirmation Email Text

    Note that in Phoenix, looking for the text might be misleading. If you just want to change the wording slightly, then yes, that will find the language file. If you want to change the structure, you would then have to find where the language constant is being used. In this case, that would be includes/modules/notifications/templates/tpl_n_checkout.php
  6. Does it have an IPN-like functionality? With IPN, it wouldn't matter which browser. Because IPN does not rely on session authentication. PayPal, RBS WorldPay, and Sage Pay use IPN. I don't know what payment module you use. But you might check with the payment processor.
  7. ecartz

    Copy Script Issues

    That line says, "Select only rows from the temp table where the category ID is $id." Those lines say, "Only insert if the category ID is not $id." Those two things are never simultaneously true, so the insert is never called. The logic would make more sense if the first line was $sql = "select parent_id, categories_id from categories where (categories_id='$id')";// check id is already copied But even then, I don't think it would work without changing more of the logic. The else should be on mysqli_num_rows not inside it. Note that if you dumped PHP and just did this in phpMyAdmin, the whole thing could just be INSERT INTO categories SELECT t.* FROM categories c RIGHT JOIN tbl_temp_categories t ON c.categories_id = t.categories_id WHERE c.categories_id = NULL AND t.categories_id = 3 replace 3 with whatever category ID. That line does nothing if either the row already exists in categories or does not exist tbl_temp_categories. If it does not exist in categories but does exist in tbl_temp_categories, it copies. And if you got rid of the AND clause, you'd just have INSERT INTO categories SELECT t.* FROM categories c RIGHT JOIN tbl_temp_categories t ON c.categories_id = t.categories_id WHERE c.categories_id = NULL which would copy everything at once. I.e. all rows that are in tbl_temp_categories but not categories.
  8. ecartz

    How to install SSL on OSC

    No. 1.0.7.14 will ignore it entirely. While there are reasons to prefer const, it doesn't make a functional difference.
  9. I would far prefer this than adding something to core. If we modify core to make it flexible, then it is entirely in your power to determine how important something is to you and how you want the store to behave. Whereas if we modify core to work in a certain way that happens to support you, it will likely break some other store owner. So I (and I think I speak for Burt as well) would very much prefer to make core flexible rather than try to use core to meet each individual need. It's more generally useful. It doesn't exclude some people to help others. And it doesn't get us bogged down in long discussions about whether or not the majority of shop owners want things to work one way or the other. Everyone wants to be the store owner for whom core caters every need. But no one wants to be the store owner left outside when we cater to someone else's needs. Note in this specific topic, there is a straight-forward way to make things work. Just apply for a VAT ID in each country to which you ship. Then there's no difference between the way you charge small and large orders. You always charge and remit VAT (sometimes to the taxing agency and sometimes to customs). Alternately, don't ship to countries where you don't have a VAT ID. Neither of those solutions requires a core change. Many stores will find that they can do one or the other (unfortunately, not shipping may often be the easier choice). I understand why store owners don't want to get VAT IDs for each country. It's extra work. But it's also extra work to create a module. If you are profiting from that module, then you should be able to pay for that extra work. If you are not profiting from the module enough to pay for extra work, then you should stop shipping to the country that is making things difficult. A simple business level solution that would be extra work for someone else: have UPS (or whatever shipper) remit the VAT. You collect it on their behalf. They take payment, along with the shipping price. And they remit to the relevant government. Note that shippers are highly incented to encourage these shipments, as they make money from them. As opposed to modifying core, which costs Burt's time (even if I make the actual modification, he still has to process it and maintain it) and profits no-one. If you can't convince a shipper to do this to get your business, why do you expect someone to do it for you for free? Note that the actual code to do this would be relatively small and trivial. What would be complicated would be making it work correctly for your needs. That's exactly what the certified developers do. You give them money and they make code that fits your needs.
  10. ecartz

    Contribution Issue

    Your PHP version was updated to at least 7.2. This changed what used to be a Notice into a Warning. It was always wrong; it's just that your error reporting was hiding the notice until 7.2. To fix it, go to line 33 of that file. Look for something like [pages_html_text] and change it to ['pages_html_text'] If the code doesn't match, you can always post line 33 (and perhaps some context) for more review.
  11. ecartz

    Spanish translation osC Phoenix

    In the thread right below yours at the moment: which links to https://apps.oscommerce.com/f8hiQ&espanol-para-osc-ce
  12. ecartz

    XSS & SQL Vulnerabilities

    Then there isn't a problem. The problem would be if the page displayed a separate alert box that would just say SAINT.
  13. ecartz

    XSS & SQL Vulnerabilities

    Try allowing it (once) with NoScript. Since NoScript blocks the request before it is made, that's purely a test of NoScript so far.
  14. ecartz

    XSS & SQL Vulnerabilities

    They are almost certainly false positives. The first one is simple. Try it. If it shows the alert, then there is a problem. Find out where it displays and add the call to htmlspecialchars. The second is more difficult, but less likely to be a problem. Because the software already sanitizes all input before use. It's barely possible that you have installed something that doesn't (probably not Ultimate SEO URLs). But certainly core already does that. This is not the approach that osCommerce takes. Instead, it sanitizes all parameters before using them in a SQL query. In the case of a product ID, this would typically happen via a cast to int. For strings (including the extended product IDs used with attributes), it uses mysqli_real_escape_string and a charset of UTF-8 when communicating with the database. In general, checking for illegal characters is a bad approach, as it leads to cleverer exploits. It is conceivable that you are using an older version that has a bug in it. You should update to the latest to pick up all the security fixes. The most recent change was to always use UTF-8, which is required for mysqli_real_escape_string to work consistently (other character sets are also safe but some are unsafe). Before that was the switch to casting to int and mysqli_real_escape_string (I forget which was more recent--both are really old).
  15. ecartz

    Shipping forms

    I read this (with difficulty, considering the nonstandard font) as needing to remove the shipping order total module. I.e. the thing that messages the shipping cost.
×