MrPhil

Frankly, you need to fully understand what your various .htaccess files are doing, and why. They cannot be treated as sacred totems that are kept without change, or something to be discarded without a second thought. If you don't understand what parts of which ones to keep, find someone (and pay them) to help you. I think there is an add-on or two to show shop status (open, closed, down for repairs, etc.), but that would have to be installed into the old shop, and may not be worth the effort. You can always make an index.php file that just says "Sorry, we're down for a few minutes while we transfer to new shop software. Come back in about 15 minutes!". Save your old store's index.php file first, in case you need to come back to it (the whole site should be backed up first, for that matter). Address bar. These are the addresses that search engines would provide to send people to your site. If they change between the old and new versions of your store (e.g., new SEO code), you will take a search results hit while your site is reindexed, and for some time after (unless your old URLs are 301 redirected to the new ones).

Certainly, adjusting colors, fonts, text sizes, etc. can be fairly easily done in user.css, to more-or-less match the appearance of the rest of the site. Even adjusting box sizes and placement can be done, to an extent. If the owner wants some picture related to a certain artist to be shown in the osC header area, that might even be possible (look at banner add-ons, or hard code changes to certain files). A full-screen store is not necessarily going to look just like the rest of the site, but you can harmonize its appearance so that it looks fairly well integrated. Once a customer has checked out, you could add a button in osC to send them back to some point on the main site (rather than having to hit "Back" multiple times). Just keep in mind that if the customer leaves osC early to jump to some other point on the main site, they may lose their session (shopping cart contents and logged-in status). If their cart is not empty when they press a button to leave the store, perhaps there could be a pop-up to confirm that they really want to do that. Also, don't write a fixed-name file with contents specifying which artist's work is to be displayed, as the most recent visitor's choice will wipe out earlier selections -- you'll need to work that into the session, or carry it along in the URL Query String. I think that jumping to an osC store as owning the entire screen, rather than trying to bend things into an iframe, modal pop-up, or whatever; will end up being easier to deal with for everyone concerned, so long as there's an easy way to jump back to the main site (navigation within osC). Per Jack's note, as normal site pages they should be properly indexed by search engines. Note that osC (Frozen) will be mobile-friendly -- does the current site use Bootstrap to behave in a similar mobile-friendly way?

Just exactly what are you trying to end up with here? From the viewpoint of someone using the "outer" website, what is the intended experience? Do you want to have a complete, functioning store running in another browser tab, as a replacement for the original page, as a pop-up, or something else? Is the store to appear within the other site (think: iframe), or is its contents are to remain accessible while in the store, or what? Where are you trying to get to? I'm not sure that you or your client have completely thought this through. Keep in mind, osCommerce, like most other applications, was not written to play nicely with other applications. It thinks it owns the whole thing. There may be session conflicts and other such problems. If your client really needs a smooth seamless interaction between a shop and the rest of the site, you may need to go to a Content Management System.

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.

If your version has a filenames.php (and it came with the installation and is actually used), you can add missing file names. Otherwise, names get hard coded now, and you will have to find any place FILENAME_MODULES is used and replace it by the string 'modules.php'. That should not happen in base code, but it's quite likely in add-ons.

Do you mean "the DEFAULT change to TIMESTAMP"? datetime should still be a valid field type, shouldn't it? CURRENT_TIMESTAMP appears to be a more recent addition to MySQL -- is the failing database a much older version? I think the intent is that it acts like INSERT INTO with a now() value, but it can now be defaulted to do that. For older MySQL versions, it won't work, and you may have to explicitly give a now() in the VALUES list. That, or declare a minimum MySQL version number.

As PHP 7.2 is now fairly well established (and PHP 7.3 is starting to show up), any thoughts on how "Frozen" could be upgraded to work on 7.2 and up? If there are a lot of changes to make, perhaps general guidelines would be in order, rather than an exhaustive list of fixes (or even an add-on!). This would still leave a lot of work to be done by shop owners, but it may be the best we can do. Add-ons will be yet another issue. I presume that Edge is/will be PHP-7.2 ready out of the box, but there are still a lot of people on Frozen just because it's nice and stable. That's the one that I install for clients. Once Slushee comes out (next freeze of Edge), that is at least PHP-7.2 ready, I would assume that any further work on Frozen would cease. And oh, how about calling the next one osC 2.3.5? It's obvious that HPDL is never going to accept any of Gary's work as the official product, and he's probably never going to release another osC, so why not ease the confusion?

If you're really trying to install on a PHP 7.3 system, you aren't going to find any version of osCommerce that will work at that level. It's unlikely you'll find any other e-store that will, either. I presume you're trying to install on a PC with *AMPP stack, which often have absolute bleeding edge versions on them. If you must install on your PC, you'll need to back off to PHP 7.1. Do not, repeat, do not, try to run a real store with real customers and real money on your own PC. Hackers know far more about security issues than you ever will, and will eat you alive. Such a setup is OK for playing around to see if you want to get into running a site, or to experiment with more advanced software levels than your host supplies. But for a real site, stick with a commercial hosting service who can devote the necessary time and energy to maintaining security.

My client carries items that weigh anything from a few grams to several kilograms. They prefer to work with grams rather than kilograms, and with weights in kg, they would need at least another decimal place or two (5,2 -> 7,4). Why was this field done in decimal rather than a real/float in the first place? It might be too much bother this far down the road, but maybe it would be/have been nice to have a weight unit for each product (oz or lb, g or kg). Just another products table field. The messy code comes when combining product weights for a shipping total, but it could be done.

In oscommerce.sql (or via phpMyAdmin after installation), consider increasing the size of products.products_weight from decimal(5,2) to something like decimal(9,3). At 5,2 the maximum weight is 999.99 units, which is a bit small if you're working with grams, or even possibly with ounces. I just had this setting up a shop for a client, who couldn't figure out why he was limited to 999.99 grams for a 3300 gram item!

Is "slow ass Magento" the new "slow as molasses" way to describe pokey things?

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.

The first time I read it, I thought he was just using Black Slang (bad = good, get down = get frisky/get busy). Now I'm wondering. Not having to create an account seems to be widely popular, as people fear their information will be used to harass them (marketing emails, sale of personal information, etc.). I too, would like to hear his reasoning.

An interesting (and concerning) article: https://arstechnica.com/information-technology/2019/03/a-new-rash-of-highly-covert-card-skimming-malware-infects-ecommerce-sites/?comments=1 . It seems there are ways to inject encoded Javascript credit card skimmers into shops (Magento, so far, has been hit hard). One of the comments brought up Content Security Policies to control where Javascript comes from on your site.

It's telling you that something on line 1 of turkish.php is outputting to the browser. Should the first line be nothing but <?php ? That's the usual case. Did something get added to it, such as a Byte Order Mark (3 odd characters)? Use a good editor to remove any BOM, and check that it didn't add it back in!