Jump to content
Latest News: (loading..)

MrPhil

Members
  • Content count

    7,930
  • Joined

  • Last visited

  • Days Won

    102

Everything posted by MrPhil

  1. 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?
  2. 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.
  3. 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 2.3.4.1BS "Frozen". Note that the official osC 2.3.4.1 release does not work with current PHP releases.
  4. Sorry, I'm not familiar with the UPS add-on. Now, why are they sending the address to UPS in the first place? I assume that it's to get a rate quote. If the address is only off a little, the error in the rate charged may be small, but if the customer gave the wrong state by accident, that could be catastrophic. What if they want the package sent to Carlsbad, NM instead of Carlsbad, CA? Watch out for auto-completion giving a wrong state! If UPS returns a flag that such-and-such a field in the shipping address appears to be in error, and the customer is still there in checkout, it should be possible for osC to present the shipping address and ask the customer to check/update it. I'd be surprised if it didn't do that already, but if it doesn't, it should be possible to add that to osC. If you managed to turn off the address verification, what would be the expected results? You would still manually fix the address before shipping out the package, but would you have quoted the wrong shipping rate? I think you may be fixated on the wrong thing (turning off verification, rather than letting the customer fix an incorrect address).
  5. MrPhil

    New UPS XML Shipping Module available

    Hope this isn't too late... it sounds like you may have the CE/Edge/Frozen version installed. This is GOOD. However, the code has been updated, replacing $HTTP_POST_VARS by $_POST and module name defines (FILENAME_MODULES) with hard-coded strings. The code is functionally identical (works the same way). If you are installing this into an older osC, you may need to back out those updates (change $_POST back to $HTTP_POST_VARS... you may be able to leave the hard-coded module name). Be careful if installing older add-ons into a new osC or vice-versa. By the way, PHP 5.3 is terribly ancient. Any up-to-date system should be at PHP 7.1 by now (the earliest supported PHP version). 5.6 and 7.0 are somewhat tolerable (they went out of support a week ago) but should be planned for replacement soon. Incidentally, the CE/Edge/Frozen version will run on PHP 7.1 or below (PHP 7.2 may need a few fixes), while the "official" 2.3.4.1 won't run reliably at that level. I won't swear that CE/Edge/Frozen will still work properly on PHP 5.3 -- it might.
  6. Maybe a better approach would be to leave the UPS interface alone, but validate the address before you send it to UPS? Unfortunately, it sounds like a manual operation on your end right now. If it can be automated (USPS, Google Maps?) you could alert the customer right then and there that the address looks "off" -- please check your entry and update if necessary. As a bonus, a verified address might also make available additional address information such as county and inside/outside city limits, useful for determining sales tax jurisdictions and thus, rates. Does UPS bounce back the bad address right away, while the customer is still in the checkout process? At least, the customer could correct the address themselves at that point (new code needed on the osC end). I think that in general, address validation during checkout would be quite useful.
  7. Why would blocking the reading of PHP files have any effect on JS and CSS files? The point of that segment is to keep people from looking inside your PHP files. Hasn't Apache 2.4 been around for a long time now? I would have thought this would have been seen (and sorted out) long ago. Perhaps there were some outdated commands such as phpflag, phpvalue, or options?
  8. So what happens if you remove address validation, and UPS is unable to deliver? It seems like that would be a major inconvenience for all parties. What's the downside of having UPS verify that they can deliver to that address? They're going to know the customer's address anyway, so it's not like they're being let in on a secret.
  9. Is the admin side under SSL and the public side not? Is the admin side under password protection? I don't think either of those should bar access, but anything's possible. Are the problem .css and .js files on YOUR site or are they remote (e.g., the Bootstrap server)? Can you bring up some of the blocked files in your browser? That would be like on the shop side, so it may not tell you anything about the admin side problem. Usually it turns out to be a problem with incorrectly set paths in the configure.php files (you did update the admin copy, too, right? And be careful not to mix up the two -- they're different).
  10. MrPhil

    Product image upside down

    It was not renamed. You should put all your CSS changes into user.css, so that they're in one place and won't be wiped out when you update your files to a new version. user.css is brought in last, so it overrides everything.
  11. MrPhil

    Need Help

    There are also "merchant accounts with payment gateways" not involving PayPal, but allowing direct payment with a credit card. These tend to be more costly than PayPal at low volumes, and usually require PCI compliance (security audits)... more than just having SSL. Their chief advantage is that a customer never sees a Third Party in the payment system -- it looks like you all the way through. There are also credit card handlers that do some stuff to let you handle credit cards via your brick-and-mortar Point of Sale system, but at the very least you need to get your bank's permission to use this. I agree that having to go on to a Third Party site, and sign on there to complete a purchase, is a turn-off for many customers. Anything you can do to make the transaction more seamless and frictionless is going to help, but the more you're handling credit card numbers on your site, the more security hoops you have to jump through. And security doesn't come cheap and isn't easy -- just ask all the big name stores that have been hacked and credit card information stolen.
  12. It looks like it may not be picking up the CSS files. Look at the page source in the browser (usually Ctrl+U) and see where it's trying to pick up .css and .js files from. If they're from your own site, check the configure.php files' path settings. If they're from a central CDN server, make sure your server and browser aren't blocking them.
  13. What caused you to reinstall osC in the first place? If it was damaged by something, perhaps that damage (hacks, backdoors, etc.) is still there, or the server PHP version was increased and your installation isn't compatible? Were you just upgrading from an earlier osC version? By the way, if this is the official osC 2.3.4.1 (available on this site), it is way obsolete. It does not work well with modern PHPs. You should be installing the 2.3.4.1BS Community Edition (from GitHub -- choose "Frozen" unless you are adventurous and want to go with "Edge"). It is a complete install (not upgrade), and you need to migrate your data over. In the long run, it may be easier and cleaner than trying to clean up an older version.
  14. Do none of the existing SEO add-ons do this for you? Are you looking for one that simply has a name (product or category) without a product ID, etc. so you could give a URL of domain.com/transparent-bleems or domain.com/visual-weapons, and have it rewrite to the right place (without an explicit rewrite in .htaccess for each)? I'm sure it can be done, but I can't think of anything for osC that already does this. You would have to send the outgoing product ID, etc. to a PHP routine that looks up the name in the database (from the product ID), and produces a URL of the desired form. You would have to send an incoming SEF URL to a PHP routine that looks up the names in a database and maps it to the usual /showproduct.php?pid=12345 etc. format. And of course, you have to maintain this database, whenever products and categories are added, deleted, or changed. I've seen this done for other applications, so I'm sure it's possible, but it will be far from trivial. Don't get caught in the trap of producing a URL for every single possible use -- just confine it to mapping a product ID to/from a product name, mapping a category ID to/from a category name, etc., and tack on other actions and commands in the normal manner.
  15. MrPhil

    HTTP to HTTPS help?

    Even easier is to change the two configure.php files to tell them to use https: for everything, including HTTP_ entries. That way, everything using tep_href_link() automatically ends up with https: (SSL), with no code editing.
  16. MrPhil

    HTTP to HTTPS help?

    There are two configure.php files. Change all mention of "http:" to "https:" including the HTTP_ entries. If you have add-ons for banners, etc., you might have to change hard-coded "http:" to "https:". Note that this should be only for your site's links, not for other sites. The easiest way to search is to have a copy of your files on your PC (as a backup, if nothing else). On Linux, grep for http:, and on Windows, findstr for http:. Finally, once your site is producing nothing but https: internal links, your .htaccess (or the equivalent) should redirect incoming http: addresses to https:. An example: RewriteEngine On RewriteCond %{HTTPS} !on [OR] RewriteCond %{HTTP_HOST} !^www\. [NC] RewriteRule ^(.*)$ https://www.yoursite.com/$1 [R=301,L] This assumes you want "www." on your domain name, and that you're not using any subdomains. If either is not true, this code will have to be adjusted.
  17. MrPhil

    Can't log into Admin

    Yes, it is possible to migrate your old database and files (product images) from an old osC to a current one. I've done it for clients by manually editing a dump (.sql export, including the DB schema) of the old database to match the schema of the new one. Install Frozen, and overwrite the DB with the revised old one, and overwrite the image files (removing the sample store data). Some of the process can be done with .sql "update" scripts in various levels of new installs, but there is none for the final jump to Frozen, so it's just as easy to do it all manually. Note that if you want password protection on the admin directory (which, BTW, should be renamed during installation), it's usually better to use your hosting control panel's "password protect a directory" (or the equivalent, such as "directory security") rather than trying to install osC-supplied files. They often don't work on many servers. The downside is that the osC security audit tool often won't recognize that you in fact have password protection, and falsely reports that you don't. If you have to supply an extra ID and password to be let into the admin area, it's working.
  18. MrPhil

    countries query

    Maybe if you told us your starting point (what information you have), and what information you're trying to get, we could be of help. As it is, I can't tell what you're trying to do. Also, the phrase where countries_id and customers_id = is certainly incorrect SQL.
  19. MrPhil

    Can't log into Admin

    Besides updating your two configure.php files to reflect changed directory paths, and possibly new domain, you might have a problem with PHP levels and changes to how passwords are handled. You can look around for information on how to remove the current administrator (it may be as simple as truncating the administrator table in phpMyAdmin, but try to check first) and insert a new one. Your customers may also have trouble logging in if that's the cause. Your images look like perhaps you're not getting the CSS files. You can look at the page source (Ctrl+U on most browsers) to see where it's getting the osC .css and .js files from, and see if the address is wrong. If you're lucky, fixing the configure.php files may fix this. While you're at it, since you are apparently at a very old osC level, you should go ahead and install the latest, 2.3.4.1BS "Frozen" (see link in my signature below) and migrate your data to it. Then you can run on up to PHP 7.1, have a lot of fixes, a lot of new features, and be responsive (mobile-friendly). It's foolish to stay at any official osC release (which is obsolete and won't run on most systems), including the one offered on this very site.
  20. MrPhil

    Edge VS Frozen

    In other words, trash your "official" installation and start over with "Frozen". If you're adventurous, you could try "Edge", but it's somewhat unstable (i.e., still in development). "Frozen" would be best for you. Sorry to have to do that, but as Malcolm said, the only guy who can make "Frozen" official (download from this site) has been AWOL for a long time.
  21. Keep in mind the value of an established domain name and search engine rankings. If there is a good chance you'll go back into business in this field, you might want to keep the domain and site active. It's possible to disable the store so no one can place an order, or even clear it out (if you're definitely leaving the field). Just don't bail out completely, in a blind panic, because you're not sure what you're going to do at this moment.
  22. The "osc2nuke" appears to be a personal project. You are free to look at it, but be aware that it probably won't be supported here. Gary is continuing work on "Edge" (the semi-official current project) to implement Bootstrap v4 on both the store side and the admin side. It's still a work in progress.
  23. Shut down your shop in an orderly manner so that you don't overlook any last-minute orders placed by customers. You need to back up 1) your site files, and 2) your database. Your host should have tools to help with at least the database part. There may also be a tool to consolidate all your files together into one backup of some format. Then you can download the files via your hosting control panel or an FTP client, to your PC. When ready to restore on a new host, you reverse the process. You will need to adjust the path names, etc. in the configure.php files, and account for any other differences, such as a change of domain name.
  24. MrPhil

    Main page not loading

    It's certainly possible that your host upgraded MySQL to a more recent version that requires you to put all referenced fields (like products_ordered) in the SELECT list. Often one host's hand doesn't know what the other is doing, and word of system upgrades doesn't filter down to the support desk. You can run the following PHP script: <?php phpinfo(); ?> and see what it tells you you're running for PHP and MySQL levels. If you have no idea what you were running before, this may not be of much help, unless your host can confirm that they upgraded recently. If you did nothing, and your host swears up and down that they haven't touched anything (yeah, right!), that leaves only two alternatives: your server had a hardware failure that neatly snipped out a piece of code (very unusual), or a hacker has been messing around. For the latter situation, get a directory listing of your site and look for osC files with a recent "last modified" date that no one can explain. Then you compare those files against a known good backup (...oh wait, you don't keep backups, do you?). As you're running very old osC 2.3.4, it's quite likely that a recent system PHP/MySQL upgrade has broken something. I don't think it will run past PHP 5.4 (and the matching MySQL level, whatever that is). The current osC 2.3.4.1BS Frozen (or Edge), a.k.a. "CE", will handle up to PHP 7.1. For any of us to advise you to upgrade to it, we need to know what PHP and MySQL you're running on.
  25. Eh? You're talking about the same thing! Anyway, there are up to four layers of protection to keep bad guys out of your shop administration: Using SSL so they can't "snoop" on the admin traffic. The whole site should be under SSL (https) these days, so that's a moot point. Administrator ID and password -- not easily guessable, right? Unguessable admin directory name. The first thing every hacker tries is to get into your <domain>/admin area, so changing admin to something weird is good. Server "password protection" on admin and everything under it. This means having to "log in" a second time to get in. Of course, the ID and password you use is different from the Administrator ID and password, right? Number 4 is the issue at hand. You are much better off using your control panel's "password protect a directory" function than trying to install the files supplied with osCommerce. The former is guaranteed to work and is easy to install, while the latter is iffy and difficult to install. The only downside to using your control panel function is that osC's security check may not recognize that you did it, and report that there is no password protection, when there is. If you have to give two separate logins to get to your admin functions, it's working. Many sites choose not to do #4. It's less secure, but that's up to your comfort level.
×