Jump to content
Latest News: (loading..)


  • Content count

  • Joined

  • Last visited

  • Days Won


MrPhil last won the day on July 13

MrPhil had the most liked content!

Profile Information

Recent Profile Visitors

104,621 profile views
  1. It's not laziness on the store owners' part if add-ons are required to enable basic functionality that almost everyone is going to need to use. I'm anticipating that legal stuff like GDPR/CCPA are doing to become widely required (or desired), and therefore ought to be built into the basic product rather than being add-ons a new store owner needs to search for. Of course, I still think it's overkill in the first place, but it does have the force of law. Anyway, it appears that Steve and Gary don't mind taking possession of their new cars on concrete blocks, and having to go to a tire store to buy the wheels and tires so the cars can roll. To each his own. A GDPR/CCPA module could be replaceable by an add-on with something lighter or offering different function, but still ought to come with the kit, so that a working store can be had right out of the box. At the very, very least, offer to download and install it (as an add-on) during installation, so a store owner isn't left wondering why their new store is out of legal compliance (i.e., osC is a piece of crap). There are a bunch of other widely useful add-ons that might be suggested at installation time, so a new store owner at least knows where to find the goodies at a later date.
  2. favicon.ico error

    Not a "comment about favicon.ico" in robots.txt, but just a comment, like # this is a dummy robots.txt. I'll put real directives in it later The idea is it's a placeholder, to have a robots.txt file that search engines can pull in (even though it does nothing, yet) and so stops the 404 errors logged every time a search engine requests /robots.txt. Putting together a real robots.txt is pretty simple, so you can go ahead and start on it right away if you wish.
  3. Optimizing db query to speed up orders.php

    I'm sorry to hear that you spent so much time and effort to upgrade to PHP 7, when the work was already done for you in Edge/CE. It sounds like you probably hit most everything -- from your previous post it sounded like you had done little beyond changing to MySQLi, which as I said is a small part of it. Offhand I can't think of any place else to work on (for PHP 7), but even Edge/CE is occasionally finding something that Gary missed. Regarding the lack of osC pros, and its declining use, it seems that any platform can be the darling of ecommerce, and within a year or two it's in steep decline (for example, Magento). I think you're going to run into that problem with any platform, so once you're established on one you might want to stick with it rather than jumping to the latest crowd favorite. Maybe even you can become a professional familiar with it! Good developers keep written notes on every change they make, including add-ons installed, so that they can be replicated on an upgrade or even a switch to a new platform. It sounds like unfortunately your system is now a black box, where you really don't know what's going on inside it. All I can suggest is that you install an Edge/CE test store, migrate a copy of your data to it, and see what function you seem to be missing. It will take some slogging, but with luck and perseverance you can figure out what add-ons are needed, what custom coding is needed (where those notes would have come in handy), and what modules simply need to be turned on and configured (former add-ons now built in). I'll bet it will still be less work than moving to an entirely new platform. Many add-ons in the osC library have been reported to have been made to run on Edge/CE, without major pain, unless they're heavily User Interface. You won't know until you look at it. In the end, you have the latest and greatest (for osC) with PHP 7.2 compatibility, mobile friendly (responsive), and lots of feature updates. You will be well positioned for whatever comes after, be it 2.4 or a project fork based on 2.4 or 3.0. Presumably it wasn't your fault, but your company let its copy of osC fall way too far behind. You can't do that with software -- the underlying PHP etc. is constantly being upgraded, and will eventually break your site. It's hard to persuade people to keep up to date with new releases, until they find themselves in a pickle with an ancient version that will no longer run. The same applies to any other ecommerce package -- they need to be frequently updated to stay current. Admittedly, osC, with its requirements for heavy code editing for add-ons, has discouraged keeping current, but Edge/CE is much better behaved in this area.
  4. Does DIR_WS_LANGUAGES still exist? If not, you'll have to hard code it. Can you print out what the whole thing DIR...alt="' is outputting, to see if DIR_WS_LANGUAGES or $language is missing or bad? Is the directory structure still the same? (the file is found in the same place and name)
  5. Optimizing db query to speed up orders.php

    That's actually a very small part of the upgrade to PHP 7. It's not even really a PHP issue, just that MySQL is no longer supported and MySQLi is the up to date library. Anyway, there are probably numerous PHP hits you're going to come across over time, if you haven't been lucky finding them already. More work for you. A word of advice on changing to Woocommerce, Magento, or some other shop. These desires to change are frequently driven by consultants, coworkers, bosses, and others who extol PlatformX as the greatest thing since sliced bread, when in truth they like it because they're most familiar with it. You're going to have the same hill to climb becoming familiar with it as you did with osC, so don't discard osC on promises that PlatformX will be absolutely effortless -- it won't be. Go in with your eyes wide open.
  6. favicon.ico error

    That is necessary only if your favicon file is not named favicon.ico, or is not in root. A browser will look in /favicon.ico by default. Note that ".ico" is a specific image format. I don't know what @Hotclutch meant by "do one or the other". favicon and robots.txt are two completely independent things. A robots.txt doesn't need more than a comment in it, but you can add all sorts of other useful things, including a pointer to your sitemap. Google "robots.txt" for tutorials on it.
  7. favicon.ico error

    Every browser requests /favicon.ico, unless you have a meta tag to specify a different location or name. You will get a 404 logged if you don't have one. Every site should have a favicon so that it looks good, and you don't get these error messages logged. They're very easy to create. Likewise you should have a /robots.txt so that the constant requests for it won't fill up your error log.
  8. I NEVER SAID that it had to be somehow baked into the "core", just that it should NOT be an external "extra" (add-on) that a store owner has to decide they need, go hunt down, and install. It should come with osC in some form, and at most require "turning on" and configuration. Other stores will include GDPR/CCPA support in their base, and it will be a great selling point against osC. It's possible to carry a fetish for "lean, mean, customizable product" too far. Imagine if wheels were an extra-cost option on your new car! It's an unwritten assumption that wheels come with any car. You can specify more expensive ones when you place your order, but at least the car is usable as-delivered. It's not dropped off in front of your home on four cinder blocks. If everyone doing business with the EU, or California, has to have certain data privacy features (we can certainly argue over what's reasonable), those features will be so widely needed that they should come in the box and not require 1) realization that they're missing, 2) a search for an add-on to implement them, 3) download and installation of this add-on. That's all I'm saying!
  9. Optimizing db query to speed up orders.php

    It's quite true that much of even Edge/CE/Frozen's internals (other than User Interface and PHP-related upgrades) are not much different than even 2.2 MS2, and any SQL optimizations that can be applied almost across the entire version line. That said, I must agree with Malcolm and question the value of putting so much effort into an ancient code base (including upgrading to PHP 7), rather than starting your optimizations with the current latest and greatest. The expression "throwing good money after bad" comes to mind. I hope you're not investing any effort in making the store responsive, on top of everything else. Clinging to a very old release simply because you've invested so much in it to date may be false economy, if you step back and look at it coldly and rationally. However, to each his own... If you are actually experiencing a database deadlock, that would be quite serious. As I don't recall ever hearing about anyone else having such problems (slowness, yes; deadlock, no), I would suspect that either some other change you've made along the way is causing the problem, or worse, there is a bug in the MySQL version you're using. Note also that the current (Edge) osC uses MySQLi as its interface.
  10. favicon.ico error

    Where exactly is your favicon.ico file? By default, the browser will request it from the site / directory. Do you have any <meta> tags on the pages in question, specifying a different place? Or conversely, those pages are missing <meta> tags specifying some non-default place and/or name? I don't think the three font errors have any influence on the favicon issue, but at some point you should deal with them.
  11. There are certain things which any ecommerce package is going to have to support right out of the box, if we hope to attract and retain a lot of users: PHP 7-ready, mobile-friendly (responsive), SEO, etc. They can not be separate add-ons, although an add-on that replaces a simpler and more basic out-of-the-box function would be acceptable. To this list, I think we need to add a pan-GDPR/CCPA/etc. customer data privacy module that doesn't have to be added separately (although it could require turning on and/or configuring). Without these things as selling points, very few people will give osC a second look. OK, so I'm going to do business in dozens of countries. I'm certainly not going to install country packages for each one. Perhaps some things like taxes/VAT etc. might be done that way, if I only have to follow the rules for my own country, but for everything else I think you're going to have to build in universal customer data protection, and other such legal requirements -- worldwide a superset of all the state, country, and union rules. I just hope there's nothing that would be contradictory enough to force separate packages! That's a general problem with osC. Harald is gone (I'm assuming, for good) and no one else has the Keys to the Kingdom. I wouldn't even be terribly surprised if domain registration and hosting expire at some point! Before long there may not be an oscommerce.com or this forum. A fork of osC is looking better and better.
  12. As soon as someone teaches a computer to lie convincingly... The human mind will never get "more exact" results. Its virtue is that it is creative and can jump off onto tangents and come up with insights that a computer might never, if it is confined to crunching numbers according to precise algorithms. As long as you expect human results to be fuzzy and imprecise, but useful as a starting point, both humans and computers (AI) will complement each other nicely. Use computers and AI to relieve humans of massive, rote number crunching (e.g., discovering trends in Big Data), and let people concentrate on being creative.
  13. I don't care what form it takes, so long as it's not something that a store owner has to go looking for and install separately. Turning it on manually is OK, but it has to be built in. Any store software that has it built in is going to have a major advantage over all others where it's an "extra" afterthought, because almost everyone is going to have to use it.
  14. products model: box width

    I no longer have 2.3.4 to look at, but you should be able to find the PHP code to create the form text field in question. See if there is a size= attribute output to HTML to set the displayed width, and increase the size (I don't know if the value is fixed or a variable). There may also be a maxlength= attribute for the maximum number of characters that can be typed in; it may have to be increased accordingly.
  15. Well then, applications such as osCommerce should be GDPR/CCPA ready right out of the box, with all the places explaining what the site does with your data ready to be filled in (or customized), and all the tools in place for customers to make requests and manage their data. Not add-ons -- built right in, as it will be needed almost everywhere.