Jump to content
Latest News: (loading..)


  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by MrPhil

  1. In any case, ask your host if/how it can be done. Usually it can, even though you may have to manually edit the test directory's .htaccess file. Assuming, of course, that your hosting service supports several PHP versions (the better ones do).
  2. Be careful with "the latest" (Edge) -- I'm not sure that the BS4 portion is considered production-ready (i.e., to use in a real shop with real customers). "Frozen" is BS3 but is quite stable. Yes, most people use a "remote server" (a live production server that they'll be running the real site on). My experience has been that people developing on *AMPP PCs have to put in a lot of effort to convert the finished site to the server's PHP and MySQL levels.
  3. I will strongly second the suggestion to upgrade to the latest osC ("Frozen"). You can even go bleeding edge with "Edge", but don't do that unless you're a competent programmer. Either will require at least PHP 5.6 (better yet, 7.1). Remember that PHP 7.1 is the oldest supported PHP. I also suggest that you not use any *AMPP for development or testing, unless you fall into one of the following two categories: 1) you don't have a real commercial server account and domain yet, and want to play a bit before committing to buying such, or 2) your host does not offer the PHP or MySQL level you need for development work. Never run a real website (especially involving real money) on your PC -- hackers will eat you alive. You really don't save much by developing and testing on your own PC, because usually the differences in PHP, MySQL, Apache, etc. will mean a lot of rework when you transfer your "working" site to a real server. If you can, set up a "test" or "development" directory on your real server (password protect it if you want). A blank screen ("White Screen of Death") usually means a severe PHP code error. You might get lucky and find an error message or partial code in "view page source", or an error message logged somewhere on your system.
  4. MrPhil

    Can anyone help this situation

    If the site is fine on another computer, perhaps something in the browser cache is messed up. Try clearing your browser cache and try again. Or, you can press Ctrl+F5 on a bad page, but you might have to do this for a number of pages.
  5. No language support is going to magically appear all by itself, just because you need it. Someone (perhaps you) will have to sit down and manually translate all the language files, and package them up into an "add-on", and put it in the library. Of course, it needs to be thoroughly tested. Make sure you start out with at least the "Frozen" version, and not waste your time translating for obsolete versions of osC. osC is UTF-8, but I don't know if it handles bidirectional languages (including Arabic) properly. Be sure to check here: https://apps.oscommerce.com/q=arabic for earlier translation work that might be a useful start. It doesn't look like there's a full translation for the current version.
  6. MrPhil

    Moving from HTTP to HTTPS

    I would try RewriteEngine On RewriteCond %{HTTPS} !on [OR] RewriteCond %{HTTP_HOST} !^www\. RewriteRule ^(.*)$ https://www.datalogger-shop.eu/shop/$1 [R=301,L] This should change http: to https: and add www. to the domain name if it's missing. Sometimes %{HTTPS} acts a little weird, and you may need to test =off or 0 instead of !on. Your host should know for sure. Also, sometimes they add a couple lines to exclude some SSL identification stuff.
  7. MrPhil

    Moving from HTTP to HTTPS

    This redirect will not work correctly. If the incoming URL is http://domain.com..., it will rewrite to https://domain.com..., when the OP wants https://www.domain.com... Or, if the incoming URL is https://www.domain.com, it will redirect to... https://www.domain.com...! (probably a 500 error loop) This is why you never use HTTP_HOST in the rewrite -- you always hard code the domain name (with or without the www, as the version you are trying to use). %{HTTP_HOST} is not some canonical form. It is what the visitor typed in as the address, and could have (at a minimum) www or be missing it.
  8. MrPhil

    SEO friendly URL Issue

    Perhaps if the administrator has not filled in the Title Tag - URL, Ultimate SEO should ignore the order to use the "alternate setting"? Either that, or force the administrator to fill in that field. It sounds like the code is not robust enough.
  9. MrPhil

    Removing fake customers

    Then either the wrong "JOIN" is being used for the purpose, or the resulting data needs to be validated (fixed) in some manner before being used (e.g., creating dummy array). It's still not robust code. Unfortunately, it's probably not trivial to fix it.
  10. MrPhil

    Removing fake customers

    If simply missing data will blow up osC, that's a code error. I'm guessing that this is a very old (2.3.4) version of osC, and it might have been fixed in Frozen.
  11. MrPhil

    Removing fake customers

    Just be careful that if it's a blind person using a screen reader that they don't get blocked by your anti-bot measures. That could even be illegal. You might want to label the input field "anti-spambot measure, leave empty" or something like that, until the spammers wise up and catch on to it! (looking for "leave empty", "leave blank", "don't fill in", "for office use only", etc.) Then you might need to use Javascript to scramble the label so bots can't see it without processing the JS (like email hiding can be done), but a screen reader can still speak it. Or maybe the prompt/label could say "enter 735 here:", where the number is randomly generated. It's a never-ending war...
  12. MrPhil

    os crashed when switched to https

    HOW did you switch to https (SSL)? How did you update BOTH configure.php files? Did you update .htaccess to redirect all incoming http: to https: (R=301)?
  13. MrPhil

    Can't log into Admin

    If you're still having trouble with logging in to admin account, follow these instructions: to wipe out the old administrator(s) and allow you to enter a new one (and its password). If you're still trying to run an old osC on a newer PHP, you may run into problems. Also, go over both your admin files with a fine-toothed comb to see if you have any changes to file paths, domain name, SSL usage, cookies, or anything else that you forgot to update when you moved over to the new server. If you have .htaccess password protection on the admin directory, that's a different issue. You should remove any osC password protection files and use your host's "password protect a directory" function. Or did you already get past that point? As for being unable to install "Frozen", that should probably go in a different thread, in the Community Edition area.
  14. MrPhil

    Removing fake customers

    I presume that's the "official" osC 2.3.4? I'm not sure it will properly run at PHP 5.6. The community-supported osC "Frozen" (see link in my signature) will go to at least PHP 7.1, so you should strongly consider upgrading your shop. As for why only "fake" accounts exhibit this behavior, I have never heard of this behavior. I suppose it's somewhat possible that there is some fishy data stored with these accounts, but offhand I can't think of what it could be. Maybe you could go into phpMyAdmin and take a look at one of these problem-causing fake accounts, and compare them with a normal real account, and see if there is anything in the customer data that looks like a script (HTML tags) or something else odd. Are you sure it's only fake accounts, or are those the only ones you tried this operation on? This is only selecting the account, and you haven't pressed Delete yet?
  15. MrPhil

    Removing fake customers

    Exactly what osC version? What PHP version? Yes, you should worry about such errors.
  16. This might have something to do with an old problem about MySQL changing precedence of certain operations, so that 'p' is unknown at that point (search this forum for 1054). That might be a fairly simple Band-Aid fix you could do (it was years ago... I don't remember the particulars). Anyway, I agree with Jack that you're wasting your time trying to patch up such an old version of osC to work with (more) current MySQL (and PHP) versions. You'd be much better off biting the bullet and moving to osC "Frozen". Unfortunately, if you have a lot of code customization, you'll have quite a bit of work ahead of you, but in the long run it will be worth it. Converting even an ancient osC database to run on Frozen isn't a terrible amount of work, but you will then have a vanilla shop.
  17. MrPhil

    Removing fake customers

    Well, the idea is that if the spammer knows that you will be previewing their mailings and weeding out spam (for a while, anyway), hopefully they won't sign up in the first place.
  18. MrPhil

    Removing fake customers

    Fake accounts are usually opened for the purpose of either spamming you, or using the store as a platform for spamming others via tell-a-friend, messaging, etc. Thus, it is good to keep them under control. I don't know if removing a country from the list will do any good -- they'll simply pick another country. In the (presumably made up?) example, they would just pick some other random country than Angola. That would be like playing whack-a-mole until you're down to one last country. I suppose you could do something to publish a list of countries you will (or won't) sell to, and silently automatically trash any account signed up for the banned countries. The fake account will simply vanish into the memory hole. Something more productive might be to put new accounts' outputs (tell-a-friend, etc.) on preview of some sort, where nothing actually goes out until you've reviewed it. That's more work for you, of course. To avoid running afoul of privacy laws, you'd probably have to tell the "customer" that you're reading their posts and mailings, and even then, there might be trouble. However, it might be enough to discourage those looking to abuse your system (unless you simply turn off t-a-f etc.). Forums and blogs face the same problem. If you can't stop them at the border (CAPTCHAs, etc. on signup to stop bots), you have to monitor what they're outputting to others and clamp down if they appear to be abusive. At least, on a forum or blog posting no one can claim a right to privacy in their communications. Almost anything you can do to stop spamming is going to create more work for you or more work for a real customer. Welcome to the Real World. Can tell-a-friend, etc. be disabled until a customer has purchased something? Can tell-a-friend mailings be checked that they have a legitimate link to one of your products or categories, otherwise they're silently trashed? Just some ideas.
  19. First of all, you installed the official osCommerce, which is way obsolete and won't run on modern systems. Your system does not have the MySQL library for PHP use (actually, it's deprecated and therefore almost unusable), but will have the MySQLi library. The only usable osC, Frozen (a.k.a. CE), is available on GitHub (see links below). I would avoid "Edge" unless you're a skilled programmer and like working on the bleeding edge.
  20. MrPhil

    Display map to track shipment progress

    How much package location information does a shipper provide (for free), and do they have limits on how frequently a given package may be queried, or an IP address (your store) can do any query? I wouldn't be surprised if any shipper has limits to prevent abuse (e.g., live tracking of your package, with your phone hitting their server every second). Latitude/longitude is nice, but city/state + delivery status would do. Even if the shipper's site is not set up for a map, as long as information is consistently presented it should be possible to scrape it off their site and present it to a mapping app. An alert (text or voice) to the customer phone that the package has been left at the address might prove very useful in this age of increasing thefts from the doorstep. If a shipper charges extra for advanced tracking, and the customer requests it, that fee could be passed on to the customer at checkout.
  21. MrPhil

    Cart loses products seemingly randomly

    Yeah, I'd check if current versions use a wider database field for session information than your (old) code does. If you've been keeping up on changes for new PHP levels and security issues, you can keep running as you are, although the fact that you're having this cart problem suggests that you may be overlooking some changes. It may be time to step back and consider whether this is a good approach, as opposed to moving to the current release and building something resembling a template over it. Let others do the work of keeping up with the basics, while you concentrate on code to make your store stand out and improve the UX. It could well be less work overall to copy your changes to a new release than to constantly patch an old base. For example, did you do a lot for Responsive/Mobile-friendly? That's built right into "Frozen". What you have to keep in mind is that the longer you stay with an old, old base, the less help you can get from this forum and the more you're on your own. You've essentially made your own fork of the product. Whichever way you choose to go, good luck and best wishes.
  22. MrPhil

    mutliple domain names? redirects?

    If it's possible one way or another to have several names pointing to the same site, where %{HTTP_HOST} is various strings, it might be interesting to feed %{HTTP_HOST} to the program (as URL Query String). The value would be used to override the domain name used in configure.php settings, making it look like a number of domains are hosting this store. Has anyone seen something like that? Offerings might be adjusted depending on "who" is hosting the store. I would be worried that some bad actor could point a random domain to your store and somehow hijack it. That might be prevented by having a hard coded whitelist of domains allowed to do this.
  23. MrPhil

    mutliple domain names? redirects?

    The domain names in the configure.php files are used for generating outbound links from the store, and perhaps a few miscellaneous items such as canonical tags. They do not change what name the server it's running on sees or uses. If you have a store running under a given domain name, and you want to change that domain, you need not only to change the configure.php entries to the new domain, but also register the new domain and point it to the server (it could be on a new server). If you are looking to redirect (point) another domain to this cart (as an alias?), you can certainly do a redirect from wherever the other domain is hosted (a redirect within .htaccess is one way). However, you will have some problems, as the store will still be hard coded to the first domain's name, and produce links, etc. under that name. If you are looking to change the name of the store, but allow it to be accessed under an old name, that can be done, too. Perhaps you could explain in detail what effect you're looking to achieve here?
  24. MrPhil

    Hack attempt - is there a way to prevent this?

    This is only appearing in this one order's data, and is not in everyone's (or in your osC code)? They are definitely trying to provoke your server into running what's presumably some nasty script code, but it's being disabled by osC. If it's just this one guy, cancel any payment made (so you're not in legal trouble for keeping payment and not delivering) and cancel the order, and fuhgettaboudit. Unless you want to jump through the hoops of reporting them to the payment processor. If everyone is seeing this, you've got some cleanup to do and security holes to patch. They're trying to inject and run some script code that creates more script, invisible images, and input field elements on your page. Some server in Guyana (they have computers there???) is involved (perhaps to load more malicious code). I haven't dived more deeply into it, but it looks like something you don't want running. Just be thankful it was (apparently) disabled before it could do the nasty.
  25. MrPhil

    Cart loses products seemingly randomly

    13 years? If you're still using a 2005 vintage osCommerce (probably osC 2.2 MS2), it wouldn't be surprising if your host has upgraded PHP or made some other change that is making an old store unstable. What version are you using, and what is your host's PHP version? The current (and only supported) version of osC is "Frozen". Note that the official osC release does not work with current PHP releases.