Jump to content
Latest News: (loading..)

MrPhil

Members
  • Content count

    7,930
  • Joined

  • Last visited

  • Days Won

    103

Everything posted by MrPhil

  1. "200 transactions or $100,000 limit" what? What system is this in compliance for? There is no national requirement to collect sales tax in other states that you lack a nexus in, so just ignore them. I'm certainly not going to go crazy trying to keep on top of every other state's tax policies! Until they make in painless to comply (ZIP Code based, national tax classes, single point of remittance), I'm not doing anything. Even NY is only going to get my local (8%) rate. If they want me to apply the correct rates for 80-something tax jurisdictions, they'll have to come up with a sane system first.
  2. MrPhil

    Upgrade to v3

    Don't. v3 is only experimental, and you should not try to run a real store on it. The proper one to be running is osC 2.3.4.1BS "Frozen" (or, if you're adventurous and don't mind being on a constantly changing unstable distribution, "Edge"). XHTML 1.0 is obsolete. Why do you want to use it? HTML 5 is the current level. I believe that both Frozen and Edge are this level.
  3. Unless you changed something in the database setup, the encoding is UTF-8 and I think the collation is "utf8_unicode_ci", which is case-insensitive and ordered by Unicode number (don't quote me on that last part). I would think that accented characters would come after ASCII, so I'm a bit puzzled at your results. Ironically, the older osC releases used Swedish collation (on Latin-1) as the default! Anyway, I would first look at your database collation order to see if it's set to something weird, and then search around for information on what collations are available for MySQL. There may yet be a UTF-8 Swedish one.
  4. MrPhil

    Upgrading to the latest version

    Frankly, you need to fully understand what your various .htaccess files are doing, and why. They cannot be treated as sacred totems that are kept without change, or something to be discarded without a second thought. If you don't understand what parts of which ones to keep, find someone (and pay them) to help you. I think there is an add-on or two to show shop status (open, closed, down for repairs, etc.), but that would have to be installed into the old shop, and may not be worth the effort. You can always make an index.php file that just says "Sorry, we're down for a few minutes while we transfer to new shop software. Come back in about 15 minutes!". Save your old store's index.php file first, in case you need to come back to it (the whole site should be backed up first, for that matter). Address bar. These are the addresses that search engines would provide to send people to your site. If they change between the old and new versions of your store (e.g., new SEO code), you will take a search results hit while your site is reindexed, and for some time after (unless your old URLs are 301 redirected to the new ones).
  5. MrPhil

    A Question About Internal LInks?

    Certainly, adjusting colors, fonts, text sizes, etc. can be fairly easily done in user.css, to more-or-less match the appearance of the rest of the site. Even adjusting box sizes and placement can be done, to an extent. If the owner wants some picture related to a certain artist to be shown in the osC header area, that might even be possible (look at banner add-ons, or hard code changes to certain files). A full-screen store is not necessarily going to look just like the rest of the site, but you can harmonize its appearance so that it looks fairly well integrated. Once a customer has checked out, you could add a button in osC to send them back to some point on the main site (rather than having to hit "Back" multiple times). Just keep in mind that if the customer leaves osC early to jump to some other point on the main site, they may lose their session (shopping cart contents and logged-in status). If their cart is not empty when they press a button to leave the store, perhaps there could be a pop-up to confirm that they really want to do that. Also, don't write a fixed-name file with contents specifying which artist's work is to be displayed, as the most recent visitor's choice will wipe out earlier selections -- you'll need to work that into the session, or carry it along in the URL Query String. I think that jumping to an osC store as owning the entire screen, rather than trying to bend things into an iframe, modal pop-up, or whatever; will end up being easier to deal with for everyone concerned, so long as there's an easy way to jump back to the main site (navigation within osC). Per Jack's note, as normal site pages they should be properly indexed by search engines. Note that osC (Frozen) will be mobile-friendly -- does the current site use Bootstrap to behave in a similar mobile-friendly way?
  6. MrPhil

    A Question About Internal LInks?

    Just exactly what are you trying to end up with here? From the viewpoint of someone using the "outer" website, what is the intended experience? Do you want to have a complete, functioning store running in another browser tab, as a replacement for the original page, as a pop-up, or something else? Is the store to appear within the other site (think: iframe), or is its contents are to remain accessible while in the store, or what? Where are you trying to get to? I'm not sure that you or your client have completely thought this through. Keep in mind, osCommerce, like most other applications, was not written to play nicely with other applications. It thinks it owns the whole thing. There may be session conflicts and other such problems. If your client really needs a smooth seamless interaction between a shop and the rest of the site, you may need to go to a Content Management System.
  7. A starting point may well be to find a 2-dimensional system (add-on) that you can code in a third dimension to. Note that a 2D system is likely to have some constraints. For example, if you're selling cloth, it might come in rolls 1 yard (36 inches) by 100 feet (let's say). Two constraints would be that the smaller requested dimension must be no larger than 36 inches, and the larger requested dimension must be no larger than 100 feet (or whatever length you have left if it's the last roll). Even then, you may be unwilling to sell me a 2 inch by 30 foot piece, as that would severely reduce the value of the leftover 34 inch x 30 foot section (it might be hard to sell). For bulk materials (stone, dirt, mulch, etc.) sold by volume, you probably don't care how the dimensions are (above a reasonable minimum), but you probably will want to impose a constraint by rounding up to the next full cubic yard, cubic meter, etc., or packages are sold in fixed sizes (e.g., peat moss in 12 cubic foot bags, or cold patch in 60 pound bags). I take it this comes down to being for the convenience of customers too lazy or too non-mathematical to figure out the volume for themselves. I would have more sympathy for those looking for non-rectangular amounts (e.g., mulching around a tree, with outer diameter and thickness, and inner diameter and thickness; gravel to fill a 30 foot x 18 foot area, 3 inches thick on one side to 12 inches on the other, etc.). Depending on the material, offering special calculators for that might attract customers. Adding up several uses might be difficult for code, but each calculator might give an exact result, and it's up to the customer to add them all up and request the total. The store could then round up to the next full measure.
  8. If your version has a filenames.php (and it came with the installation and is actually used), you can add missing file names. Otherwise, names get hard coded now, and you will have to find any place FILENAME_MODULES is used and replace it by the string 'modules.php'. That should not happen in base code, but it's quite likely in add-ons.
  9. MrPhil

    Email queuing system

    Do you mean "the DEFAULT change to TIMESTAMP"? datetime should still be a valid field type, shouldn't it? CURRENT_TIMESTAMP appears to be a more recent addition to MySQL -- is the failing database a much older version? I think the intent is that it acts like INSERT INTO with a now() value, but it can now be defaulted to do that. For older MySQL versions, it won't work, and you may have to explicitly give a now() in the VALUES list. That, or declare a minimum MySQL version number.
  10. As PHP 7.2 is now fairly well established (and PHP 7.3 is starting to show up), any thoughts on how "Frozen" could be upgraded to work on 7.2 and up? If there are a lot of changes to make, perhaps general guidelines would be in order, rather than an exhaustive list of fixes (or even an add-on!). This would still leave a lot of work to be done by shop owners, but it may be the best we can do. Add-ons will be yet another issue. I presume that Edge is/will be PHP-7.2 ready out of the box, but there are still a lot of people on Frozen just because it's nice and stable. That's the one that I install for clients. Once Slushee comes out (next freeze of Edge), that is at least PHP-7.2 ready, I would assume that any further work on Frozen would cease. And oh, how about calling the next one osC 2.3.5? It's obvious that HPDL is never going to accept any of Gary's work as the official product, and he's probably never going to release another osC, so why not ease the confusion?
  11. If you're really trying to install on a PHP 7.3 system, you aren't going to find any version of osCommerce that will work at that level. It's unlikely you'll find any other e-store that will, either. I presume you're trying to install on a PC with *AMPP stack, which often have absolute bleeding edge versions on them. If you must install on your PC, you'll need to back off to PHP 7.1. Do not, repeat, do not, try to run a real store with real customers and real money on your own PC. Hackers know far more about security issues than you ever will, and will eat you alive. Such a setup is OK for playing around to see if you want to get into running a site, or to experiment with more advanced software levels than your host supplies. But for a real site, stick with a commercial hosting service who can devote the necessary time and energy to maintaining security.
  12. My client carries items that weigh anything from a few grams to several kilograms. They prefer to work with grams rather than kilograms, and with weights in kg, they would need at least another decimal place or two (5,2 -> 7,4). Why was this field done in decimal rather than a real/float in the first place? It might be too much bother this far down the road, but maybe it would be/have been nice to have a weight unit for each product (oz or lb, g or kg). Just another products table field. The messy code comes when combining product weights for a shipping total, but it could be done.
  13. MrPhil

    credit card skimmers (in JS)

    An interesting (and concerning) article: https://arstechnica.com/information-technology/2019/03/a-new-rash-of-highly-covert-card-skimming-malware-infects-ecommerce-sites/?comments=1 . It seems there are ways to inject encoded Javascript credit card skimmers into shops (Magento, so far, has been hit hard). One of the comments brought up Content Security Policies to control where Javascript comes from on your site.
  14. In oscommerce.sql (or via phpMyAdmin after installation), consider increasing the size of products.products_weight from decimal(5,2) to something like decimal(9,3). At 5,2 the maximum weight is 999.99 units, which is a bit small if you're working with grams, or even possibly with ounces. I just had this setting up a shop for a client, who couldn't figure out why he was limited to 999.99 grams for a 3300 gram item!
  15. MrPhil

    credit card skimmers (in JS)

    Is "slow ass Magento" the new "slow as molasses" way to describe pokey things?
  16. MrPhil

    reCAPTCHA addon recommendation

    It's not clear that CAPTCHAs or reCAPTCHA do more good than harm. Bots have gotten so good at processing them that you can say that a CAPTCHA is more likely to exclude a human than a bot! If such challenges are going to do any good, they will need to look at how the puzzle is solved (including timing and minor mistakes) to see that it's a human and not a perfect bot. Of course, bots will then be modified to look more like humans in how they work the puzzle... In the end, the behavior once "inside the gates" will have to be monitored to detect bots and/or spam content being sent, rather than trying to keep bots out.
  17. MrPhil

    Email queuing system

    The first time I read it, I thought he was just using Black Slang (bad = good, get down = get frisky/get busy). Now I'm wondering. Not having to create an account seems to be widely popular, as people fear their information will be used to harass them (marketing emails, sale of personal information, etc.). I too, would like to hear his reasoning.
  18. It's telling you that something on line 1 of turkish.php is outputting to the browser. Should the first line be nothing but <?php ? That's the usual case. Did something get added to it, such as a Byte Order Mark (3 odd characters)? Use a good editor to remove any BOM, and check that it didn't add it back in!
  19. It depends on how customized a site you're looking to do. Some of the things that Loic mentioned are geared specifically towards a store site. Others are more general Content Management Systems, which have a lot of prewritten modules for stores, blogs, galleries, etc. Still others are just the basic frameworks themselves, such as Zend, CakePHP, etc. There is no one "best" that can be recommended -- it depends on what depth you wish to get into, and your experience and skill level.
  20. MrPhil

    Email queuing system

    This is an interesting subject. It sounds like the desire is for ability to trigger sending an email on many different kinds of events (calendar, order shipped, shipment delay, abandoned cart, follow-up on order, merchandise return, no orders in the last X months, etc.) "slugs" of a template for the email (anything starting "Hey Phil" gets immediately deleted from my inbox! I had a credit card which used my initials, and I'd get mails "Dear P" from the issuer.) -- perhaps several different templates to choose from, based on customer specifics (e.g., a Valentines Day offer geared differently towards singles and couples)? ability to pull information from the database (customer name, order information, ship date, etc.) and put it in the email possibly updating the database, such as a coupon was issued on my birthday Without a lot of custom-written code, especially to read/write the database for all sorts of different things (and combinations of data), I don't think you can generalize this with one piece of code. However, specific modules could be supplied to do specific tasks (e.g., look up customer birthdays), maybe with a hook system so new ones can be added. The data found should influence the content of the email, so that it's appropriate and has the maximum impact. Be careful about queuing up so many emails that your host slaps you (is a rate limiting mechanism assumed? if so, do different messages have different priorities?). Also be careful about straying into actual marketing mails if the customer has not granted permission to send such to you.
  21. Free and Advanced? Is this in reference to the add-on, or to the base osCommerce? osC is only free. By the way, as you're new here, make sure you're building your site on the only supported and current version, which is osC 2.3.4.1BS "Frozen". See the link to it below in my signature. Do not use the official 2.3.4.1 release, as it's unsupported, unresponsive, and quite a few years behind the times (e.g., doesn't properly handle PHP 7).
  22. It's a fresh install of Frozen. There were some changes to parallel the "official" 2.3.4.1 patch, but there have been myriad other changes since 2.3.4BS. You will be able to migrate your database and product images, although I don't think there's any "one-button" process for that (you need to compare database schemas and upgrade your DB field by field and table by table). It should not be anywhere near as bad as migrating from the non-BS official versions. It will also bring you up to PHP 7.1 compatibility. Don't forget to go over the "bugs in Frozen" thread to fix a number of minor issues.
  23. So if a shopper already has Product A in their cart, you want the "Also Bought" box not to mention Product B, even though people did buy A and B together (then gave you grief about it)? What version of osC is this, and is "Also Bought" an add-on or built-in? A general solution would be to have a list of discouraged combinations (from the database) and see if B is on the list for any A in the cart, and refrain from mentioning B in "Also Bought" (and vice-versa, of course). It could also be a hard-coded (in a PHP file) list, I suppose, if you don't mind not having a smooth admin interface. The same data could be used to pop-up a reminder "This T-Stoff Product is incompatible with the C-Stoff Product you already have in your cart! Do you still wish to put it in the cart?" when adding Product B to the cart. I have doubts about the intelligence of your customers if they ignored product description warnings that Product B is incompatible with Product A, but it all depends on how good a job you did in trying to warn them.
  24. Someone might have bought that other product because they have a separate need for it, so you might be shooting yourself in the foot by removing it from the "also purchased" box. To protect customers who somehow think it's a recommendation, what if you add something in bold on both product listings: Product X is not compatible with Product Y and cannot be used together with it. Or, if there are multiple problem compatibility issues, Be sure to consult the Product Compatibility Chart to see whether this product can be used together with other products.
  25. MrPhil

    Removing fake customers

    Java and Javascript are two entirely different things. What Oracle does to strangle free Java (if anything) is unrelated to Javascript running on your browser. Unless honeypot is definitely using Java code in the background to do something (I haven't looked at the code), I wouldn't worry about it.
×