Latest News: (loading..)


  • Content count

  • Joined

  • Last visited

  • Days Won


MrPhil last won the day on July 1

MrPhil had the most liked content!

About MrPhil

Profile Information

  • Real Name
  • Gender

Recent Profile Visitors

101,114 profile views
  1. If in doubt, simply use your hosting control panel's "password protect a directory" function. If you use it correctly, you'll need to enter an extra ID and password to get to your admin. You can then ignore any warnings in the Administration Tool that you don't have this protection, as often it can't see the hosting method.
  2. People would have a better idea of what areas to work on if you told us what osCommerce version you're running, what PHP version, what database (MySQL) version, what add-ons you have installed, and any other helpful information (such as, your host recently upgraded something, or you were hacked, or there are error messages logged). There are a million things that can slow down a site, so you need to narrow it down a bit for us.
  3. I'm not aware of a rule that states what the form must surround. This sounds like a W3C error and is not a real issue, that I can see. My understanding of <form> rules is that a <form>...</form> is a single element that must be properly nested inside the rest of the page (nothing starting outside and ending inside, or vice-versa), and in turn, everything in the form is properly nested within <form>. Demitry should be able to examine the page HTML in his browser and see if these rules are violated. "Between two </tr> tags" -- huh? I don't think there's any way to directly nest table rows without a </table> and more between them. Maybe there's an error in the surrounding page code, and not the form itself.
  4. Just keep in mind that sites which review ecommerce offerings and recommend products don't pay any attention to GitHub or internal channels. The only thing that counts is what's on the download page as "the latest and greatest" release (and it has to be stable). That is also what Softaculous and other "one button installers" use as their source. It absolutely cannot be allowed to stagnate! If the release number doesn't increment at least every 12 months (preferably more often), it's declared DEAD. And never put development versions that are not production-ready on the download page. Keep them on a separate development page.
  5. There had better be a smooth upgrade path from 2.3.4BS Edge to 2.3.6 or a mob with pitchforks and torches will descend upon HPDL. I have no idea how automated it will be, but the differences between the two should be quite small. Given the length of time between promised versions and when they actually appear, I would not wait around for 2.3.6 -- it may appear soon, or it could be years. Go ahead and work with Edge and see what happens when and if 2.3.6 comes out.
  6. I trust you're not confusing 2.3.4BS Edge (available on GitHub) with the "official" 2.3.4 (available on download page). Edge started 3 or so years ago, but has been continuously developed and updated since then. Unfortunately, there's no release or version numbering with it to tell you how far behind you are with your version. Harald has promised that Edge will be officially released "real soon now" as 2.3.6 (2.3.5 is a patched 2.3.4), but given his past history on promised releases, I'm not holding my breath. You can either wait a bit to see when it appears, after seeing what work you will need to do on Edge, or just go ahead with Edge, and deal with 2.3.6 when it finally comes out (it should be a very small jump).
  7. Don't confuse people. Due to chronic abuse by SEO "experts", most search engines simply ignore the meta keywords tag, or at best, use it as an advisory to see what to pick out as keywords from other places on the page. You certainly do want to decide on some key words (terms that people will search for) to use in various places on the page, but don't confuse these with a list of keywords in a meta tag.
  8. Harald, thanks for all the effort you're putting in. HOWEVER, please, please, Please, PLEASE have a support plan in place to keep all "current" versions updated AT LEAST every 12 months! Otherwise, the ecommerce market declares osC dead, and it has to start all over gaining mind share. Leaving 2.2RC2a or 2.3.4 out there unfixed for literally years was a horrendous mistake and really killed osC, so please don't make that mistake again. It doesn't matter how great the follow-on is if it has to start over each time. It doesn't matter how good 3.0 or 2.4 or whatever is going to be -- what counts is what's on the download page RIGHT NOW. If you have to, delegate responsibility to a few trusted lieutenants to maintain existing offerings, while you concentrate on new stuff. And "maintain" doesn't mean major new features (like Responsive -- that should have been 2.4); it means cleaning up this MySQLi business and adding PHP 7 capability to 2.3.5 long ago, and whatever other bugs can be fixed.
  9. I think that your pain will only increase as time goes by and you have to keep patching this ancient code to keep up with the latest threats. It's time for you to take a long, hard look at whether you would be better off biting the bullet and converting to 2.3.4BS Edge, and re-implementing/porting whatever changes you find necessary. It might merely look a lot harder than it really is! Eventually, you will become solely responsible for maintaining what will become your own fork of osC, as no one around will still be running 2.2 and be able to help you. It's always a bad idea to stick with very old software (and try patching) it, rather than periodically moving up to the current level. And be sure to keep written track of every add-on you install (and its purpose) and every custom tweak you make (and its purpose) to make finding updates for the next install that much easier. Regarding securing the DB table, I think the first thing you need to do is find out how they got in and changed it. If someone has a backdoor, or Trojan code, or an SQL injection, or Query String PHP injection, you're simply closing the barn door after the horse got out. Could the hacker have gotten system passwords, perhaps through a password sniffer or keyboard logger? Scan your PC for malware, and then change every password you can think of, and preferably over a secure (https) link. Did you ever publicly expose your DB name and password? Don't forget to change at least the password.
  10. There are many possible ways that hosting could set up additional security on an account or directory, so it would be unreasonable for an application such as osC to try to check them all. If the additional security works (e.g., you need to enter an ID and password), you're golden. Just ignore osC's complaints. Now, certainly, osC could be greatly improved by simply adding to the security "error" message something like, You may have different or additional security measures installed and functioning. If you do, you can disregard this message.
  11. Did you have the non-SEO URLs around long enough to be indexed? Maybe the real complaint from Google is that you have two different URLs pointing to the same page. You might need to do something to manually remove the old (dynamic) URLs, or just simply let them age out of the index. Ordering a recrawl might help. Your SEO code (in .htaccess) should not be doing a 30x redirect from SEO form to old form. It should be a simple rewrite. Check that you're not implying a 302 redirect by giving http: or https: and the domain in the rewrite, just the directory.
  12. I seem to recall hearing about similar issues (seeing another user's cart or details) due to session problems. First of all, I think a lot of this has been fixed in recent versions of osC -- what version are you running, and on what PHP version? You really should be at osC 2.3.4BS Edge running on PHP 7 -- if you aren't, you're quite a bit behind the times. It could also be a configuration issue of some sort. I would search this forum for mention of cart, user, and session to make sure you don't have some major misconfiguration.
  13. You might have MySQLi installed (the more advanced version) rather than MySQL, or maybe neither is installed. I vaguely recall seeing reports that old versions of osC (such as 2.3.4) not being able to handle MySQLi-only PHP installations. If you're on XAMPP, you probably have a very recent level of PHP that may not even have MySQL. First things first. Do not install and use osC 2.3.4. It is thoroughly obsolete and won't even run on any up-to-date server. You need to install and use 2.3.4BS "Edge", which is the most up-to-date production-ready package. Do not install a public-facing store on your own PC server, using *AMPP. It's OK for testing the waters and playing around, and even testing PHP levels your real server doesn't offer, but don't do production work on such a server -- hackers will eat you for breakfast. Get a professionally managed commercial server account if you intend to set up a real store.
  14. These days, PHP 5.6 is considered the minimum. Note that it's mostly out of support by now. 7.0 and 7.1 are considered state of the art. The only production-ready osC that will run on PHP 5.6 or higher is 2.3.4BS Edge (see the discussion on where to get it and how to install it). You would install a new, fresh copy of Edge. Follow the instructions to copy over product image files, store logo, etc. Make a copy of your existing database and follow the instructions for running the MySQL scripts (.sql files to be imported) that modify the database schema. I think some of these scripts are normal osC upgrade scripts to get version-by-version upgrades, and the final one(s) are specific to Edge (from 2.3.4). Or, if you are comfortable around SQL and phpMyAdmin, you can manually get the "schema" (table layout) for both osC versions, and use phpMyAdmin to change and add tables and fields to get your existing database up to snuff. If your existing database has been modified by add-ons, you might have to go this route. You should end up with your data in a working, standard Edge store. Then you need to look at what add-ons you want, and any custom coding and CSS tweaks for appearance. I have no idea if those guys can do a migration from one osC to another. Be aware that they might pressure you into going to another cart, so stand your ground if they try. It's not at all hard to do, if you're capable of following instructions, so it would seem a waste of money to hire them.
  15. Uh, I certainly did give usable information. If you're actually trying to set permissions to 777, it means you don't understand anything about permissions. No modern server permits world-writable files and directories (and it's bad practice on those that do), and rather than giving a 500 error, it can easily masquerade as a failure to read or write those files. Plus, as Jim said, there are a number of ways to change permissions, but a server may reject some. For instance, in this day and age, many people still try to use FTP clients to change permissions, even though many servers silently ignore such requests. It's up to you to learn your system and how to do things, and when to ignore obsolete instructions such as "chmod everything to 777".