Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

MrPhil

Members
  • Posts

    8,167
  • Joined

  • Last visited

  • Days Won

    112

Everything posted by MrPhil

  1. You now have "french" language files (no missing files, but might still have English text in them), and you're still getting exactly the same error messages about missing files? Very strange. Does your server have some sort of cache that hasn't been updated yet? Are the permissions on the new files valid (644 is typical)? And of course, you copied them to the right place on the right live server? You didn't edit any of these files and have the editor leave a Byte Order Mark in them?
  2. Yes, Frozen's PayPal (it appears to be an earlier version of the PP app built right in) has a working Update button. I'm still looking at the differences, and where the code will come from upon pressing the Update button. I'm also concerned about a future update (say, beyond 5.018) regressing to incompatible code (e.g., expecting $HTTP_POST_VARS, etc.). If it's code maintained by HPDL, that's a very real possibility. If it's from PayPal, it still might happen. "best not to use naked $_POST/$_GET" could you offer some justification for that? It's been generally agreed upon that maintaining the old HTTP_ arrays is a bad thing, and one of the things @burt has been doing in the "BS" versions is changing all of them to the modern $_POST and $_GET forms. It would be stunning to discover that was a bad move!
  3. I would strongly advise you to start debugging with the first error message (the possibly missing "french" language files). There's no telling what sort of cascade of effects are coming from that -- if you're quite fortunate, all your problems might go away with fixing that! Besides, it's an easy fix (just copy in "english" files for the time being, until you find or make a French translation). Might as well attack easy things first.
  4. It says that includes/classes/payment.php is trying to use some file in includes/languages/french/modules/payment/. The first thing I'd check is whether includes/languages/french/modules/payment/ has French versions of all the modules that you want to use that are found in the "english" version, as shipped (includes/languages/english/modules/payment/). There will be some English text in those files that will (eventually) need translating. With luck, that will be your problem. At least, you can see if just copying the "english" files you need for your payment method(s) gets you past the current problem. There may be other empty "french" directories that need similar treatment.
  5. Pete, "Frozen" has PayPal Pro built in -- it doesn't use the paypal-app you linked to. However, it's at 5.010, so my concern is whether you need to install, configure, upgrade, and then apply the patches above, or if the Frozen files could be updated ahead of time (via my Frozen patch). The best would be to update Frozen (via patches) to PayPal 5.018 so that when installed, it's there (along with the patches above). No further manual operations for the store owner. I will try to find a Frozen implementation that's been updated to 5.018, and compare files, and see if I can first update my Frozen patches to 5.018, then apply the patches found above. That would be the most desirable thing for anyone using Frozen. Update: I've started looking at the PayPal app vs. what's in Frozen. A lot of the differences in Frozen are trivial stuff -- use of $_GET/$_POST, __construct, hard coded file and table names, etc. However, it looks like Frozen is still at PayPal 4.039 while the app is 5.010. There are a lot of non-trivial differences between the two that will take some thinking about (which one is correct to use). Then, there is still the issue of various fixes proposed in this and other threads, and whether they can be applied to 5.010, and whether it's possible to upgrade Frozen to have 5.018 out of the box. (does the "upgrade" change the PHP files?) This is not going to be quick.
  6. I am looking at this patch and considering whether to include it with the Frozen patch set I maintain. The first file may have had a name change (to tpl_cm_paypal_login.php) and the code now starts 3 lines later (21 instead of 18), but other than that, it's only a hard-coded file name ('login.php' instead of FILENAME_LOGIN) that's the difference (as expected). The second file seems to match up OK. As Frozen still ships with PayPal 5.010, does anyone know if it's safe to put this patch in? Do you need to update to 5.018 first? Perhaps I should wait until someone figures out the changes needed for Frozen patches to be PayPal 5.018 as-installed, and then add in these fixes, unless someone can state for sure that it works for 5.010 (and won't interfere with upgrading to 5.018). Does Edge ship with PayPal 5.018? If it does, I could compare files between Frozen and Edge and generate a patch for that.
  7. Uh, which distribution? If you're talking about the "official" 2.3.4* stream, it ain't gonna happen. As far as anyone can tell, it's dead. If you're talking about @burt's BS/CE stream, hopefully he'll see this discussion and take any appropriate action. He would probably find it helpful if you could give pointers to where to find the latest certificates, etc. It would be good to ship with PayPal 5.18 pre-installed, and any PHP 7 glitches fixed, and I'm sure he'd appreciate any help he can get on updating Edge. "Frozen" will not be updated by Gary, but if you can provide pointers to the appropriate changes needed, I can add them to my public patch collection. It would be good to post the code changes in the Frozen patches discussion thread, so others can look them over too, and bless them.
  8. The method used to send mail (mail function or SMTP) has no direct bearing on spamming. The spammer was using some function (Contact form) further up the food chain to generate the spam. It is irrelevant whether PHP mail() or SMTP was used to send it out, unless your host has some sort of spam-blocking implemented for one but not the other. That could be why they asked you to switch to SMTP, or it could be for some entirely different reason (you should ask, just to know what's going on). Anyway, the spam-blocking (some sort of CAPTCHA or other anti-bot challenge) needs to take place in your application where the spammer is operating, such as at the Contact form, before it gets to the mailer. Simply changing the mailing method from mail() to SMTP will do nothing to control spam from your Contact form (although your host may then be able to intercept spam). And as mentioned before, reCAPTCHA is a specific, widely-used anti-bot CAPTCHA, but it's not the only game in town. If your host demands reCAPTCHA specifically, they're idiots and you need to find a new host. By the way, it's well known that CAPTCHAs are almost useless today, as bots have gotten so good at using them, so don't expect miracles (especially with any widely-used one such as reCAPTCHA, which hordes of bots can crack). Also, you may notice that reCAPTCHA images are heavy on recognizing vehicles, traffic signals and signs/markings, street signs, crosswalks, pedestrians, and the like -- it's widely suspected that Google is using reCAPTCHA to train its AI for self-driving cars (and you're not being paid for your participation).
  9. Well, when you make any changes to an off-the-shelf application, it behooves you to keep careful track of what exactly you did, and why. This helps you to re-implement these things in the future, when you need to switch to a new version (such as Frozen). You can also decide whether you even need a set of changes now (e.g., make it responsive or PHP 7 ready -- that's now built in). You have my sympathies if you didn't keep track of what you did over the years. Perhaps you can grab a vanilla copy of your base osC and do a "diff" against it to at least see what you changed (it's a start).
  10. Will "Slide to Submit" work with a screen reader, or someone with dexterity problems who can't use a mouse? There are all sorts of visual puzzles and whatnot meant to confound a bot, but many of them exclude handicapped users, too. In some situations that will actually be illegal discrimination! So, be careful using such CAPTCHAs.
  11. The latest official release, 2.3.4.1, is seriously obsolete. The last time I looked, it was merely 2.3.4 with the PHP "deprecated" warnings turned off. If you want actual PHP 7.1 compatibility, and Bootstrap responsiveness, as well as a bunch of other updates, you have to go with one of Gary's releases. See my signature below for either Frozen (and patches) or Edge. Both are on GitHub, and not official distributions. Frozen is nice and stable and quite usable, while Edge is developmental ("bleeding edge") and changes from day-to-day (its principal changes are Bootstrap v4 and responsive admin). If you're not sure, go with Frozen. osC 2.4.x is experimental and should not be used for a production store, unless you are willing to put in a lot of time and effort into patching and maintaining it. To be blunt, Frozen and Edge are the only games in town. Don't get a hangup on "official release or bust". The official release stream is dead. I have no idea if PayPal's latest versions are compatible with official osC releases. They themselves may need some patching to be PHP 7 compatible (__construct, etc.). At the very least, you should install a test version of Frozen and see if it satisfies your needs -- it probably will, and you may be pleasantly surprised at how up to date it is.
  12. Be sure to google site:www.oscommerce.com/forums paypal view update and read about update issues, especially the View Update button not working and use of TLS 1.2. You say you have a 2.3.4 (very old) osC updated for Bootstrap and PHP 7.0 -- is there some reason that you haven't switched over to Frozen (or even, Edge), which gives you that stuff (and more) without any effort? I suppose that if you have a lot of custom code changes, that could be a legitimate issue, but otherwise, Frozen is the way to go. At least, you could see if the update itself is behind the times, or it's something in the base code that you missed.
  13. You could certainly set up a processor on your PC to take the incoming .csv or .txt file and write a new .csv file back out, ready for either manual database import or through Easy Populate. There would be several data configuration files associated with it: markup per category, markup for specific products (override per category), and category per product. You would manually maintain these configuration files with an ordinary editor. When you run the new .csv or .txt file through the processor, it would tell you if any products are missing a category (likely new products) and you would update the category file and rerun the processor. A bonus feature would be to compare the new output to the previous one (saved from the previous time it was run) and only write new and changed entries, in order to run the update faster (dozens or hundreds of updates rather than tens-of-thousands each time).
  14. Why are you going into Excel (or any other spreadsheet) to add columns and calculate prices? You should be able to read the CSV file with a scripting language such as Perl, and write it back out with new columns with prices and such. How many manual decisions do you need to make for each product? Can it all be reduced to a formula? What about categorizing new products -- is that manually done? You should only have to do it once, for a product or manufacturer, and keep that information around in a file. For routine functions, you should be able to take an incoming CSV or txt file and convert it to something useful to read in either manually or via Easy Populate, without any human intervention.
  15. There are some "Easy Populate" modules floating around, that let you update product information from a CSV (text) file. Take a look at that and see if any do the job.
  16. GDPR or the like? Maybe IP tracking violates some privacy laws.
  17. Was this site working for a while with the Amazon checkout, and suddenly failed, or did it never work? osC 2.2 is very old and obsolete -- did your host just make any upgrades, such as the PHP version? I would expect even more problems with your store if PHP was upgraded to something approaching current (7.1) levels. If this module never worked, did you check if it is compatible with such an old version of osC, and with the old PHP version you're using? Anyway, you should be thinking about moving to the current osCommerce (2.3.4.1BS "Frozen"), rather than trying to patch up an old store. You'll get PHP 7.1 capability and it's mobile-friendly (responsive), among other things.
  18. 777 is NOT correct on many servers. They will give a 500 error because this is a security exposure ("world writable files"). You start with the minimum permissions on any file (typically 644) and add "write" permissions (664, then 666) until you get it working. Very few servers now require PHP files to be marked "executable" (755, 775, 777). This applies to files that PHP needs to write to, and depends on how PHP is configured (especially, what user group it's running under). 777 was safe to do back in ancient times, when you could trust everyone sharing your Unix computer. You can't anymore, especially on a server shared with hundreds or even thousands of strangers. Giving them "world write" access to your files is asking for trouble. If someone blithely tells you to "chmod 777 your files", they're an idiot. Don't listen to them.
  19. 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.
  20. 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.
  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. No harm done with responding to a 13 year old post, if the problem and solution given might still be relevant to someone. Since the thread would have been so deeply buried, I would assume that Jack would be aware of its age. Likely the OP is long gone, but in case there are others in this boat... As long as we're having a pleasant chat about unusual shipping requirements, is there anything built-in to restrict certain products to certain geographic zones (such as countries)? For example, physically shipping goods only within the USA, but digital downloads anywhere not embargoed? I'm sure I could code up something, but if someone has already done the work... the key is to alert the customer well in advance before they load up their cart with a mixture of physical and virtual goods and then try to check out.
  23. First of all, make sure you are installing a current version of osCommerce, one that is PHP 7-ready, secure, mobile-friendly, and up to date with many new features. That would be osCommerce 2.3.4.1BS "Edge" or "Frozen". As you are not experienced with osC, I would recommend "Frozen" (see my signature below for the link), even though it is not PHP 7.2-ready and has a list of patches. Under no circumstances should you even think about installing the "official" version downloadable from this site. It's obsolete, even though it's also called "2.3.4.1". via Google Translate:
  24. You might want to read this article on CAPTCHAs: https://www.theverge.com/2019/2/1/18205610/google-captcha-ai-robot-human-difficult-artificial-intelligence . It states that AI is expected to improve to the point that it will solve any CAPTCHA puzzle much better than humans can. It's just about there, already. The emphasis will have to shift from how perfectly the "user" can solve a problem to watching how very human imperfections and randomness in the interaction betray who is human. Also, rather than relying on a one-time hard-shell defense against bots, we will have to watch users in their interactions with a site and see if they're doing bot-like things. Big Brother, anyone? The article points out that Third World CAPTCHA farms use people to sign up for forums and blogs, etc., which then can be handed over to bots to do the spamming. This would require monitoring of the user interactions beyond just the signup, such as an occasional CAPTCHA challenge from time to time. If most spammers crap on your forum just once (or use your tell-a-friend function for one mass mailing) and then never come back, that may be more annoying than useful. The comments are rather interesting too. Several people pointed out that the reCAPTCHA emphasis on traffic lights and street signs and vehicle recognition suggests that we are being used to train Google's self-driving cars -- for free.
×
×
  • Create New...