MrPhil

"Advanced Search", as shipped, would of course search through all the products. It sounds like your Retail Locator is still searching the product tables, rather than your retailers table(s). Do you not yet have the retailer table(s)? With no keywords, and still looking at product information, I wouldn't be surprised if Advanced Search matched everything. I think you need to do a little more thinking about the subject, and get some more code and data in place, before you ask for help.
 
Most stores which offer a "Find your nearest store" locator function carry the same goods in all stores. Do your stores carry different goods? I suppose that it is possible that your site is an umbrella for a number of  related, but not identical, brick and mortar physical stores. A visitor would want to find the nearest store which carries the particular goods they're looking for. The first thing would be to geolocate your potential customer, either through their IP address, or asking for a Postal Code (ZIP Code in US). Depending on how geographically dispersed your stores are, you might use something like Google Maps' geolocation to get a latitude/longitude, and from there, calculate the shortest "as the crow flies" distance from the customer to a suitable store. For stores in the same city, you might want to get a more precise customer location, and calculate street routes for shortest distance. Keep in mind that a potential customer might be reluctant to give their street address, so don't push the issue. Don't forget to actually show a map, rather than just showing an address, and show several nearest matching stores, not just the one you think is closest. A customer might find it more convenient to visit a more distant store that is close to their workplace, for example.
 
Assuming your stores carry different goods, you could use products, manufacturers, etc. to narrow down the list of stores, and then find the closest store(s). Are the stores different enough to make this effort worthwhile? What do you intend to do if the potential customer wants some goods found only in one store, and other goods found only in another store? Can stores ship goods to each other so the customer only has to pick up in one place? They would appreciate that service.

IIRC, 5.010 is indeed the last full installation, and there are a number of incremental updates following it, up to 5.018. I haven't looked to see if all the updates will be applied in one "update" click, or if you have to update several times to get to 5.018, but you might want to keep an eye on what it's doing. I recall that there are gaps in the sequence (i.e., there are not 8 updates to get to 5.018).
There have been some recent changes to PayPal (e.g., Connect vs Login), so 5.018 isn't the last word, but I think Harald has to manually do some code changes to bring it up to date. I don't know what his plans are there.

If the code only looks at the time of day, and doesn't keep track of the day on which it was last run, it's not very good code. Anyway, if you can't run a proper "cron" job, look at "poor man's cron" examples that do track when the last time something was run was, and kick off the run if enough time has passed. Such code would be started from some place in osC such as application_top.php. I think there may be a poor man's cron in one of the mass mailing add-ons, where you don't want to dump an avalanche of emails on the system, but just dribble out a few at a time, then wait for the next run of osC that's a few minutes later. I don't know if anyone has generalized a PMC to run arbitrary modules at arbitrary times/dates, but that would be a great feature for osC.
Perhaps you would be better off if you worked with your host to understand what their limitations are on cron jobs. It's understandable that they want to keep out-of-control scripts off their servers, but cron is a necessary part of any non-trivial website. You got burned once by not understanding what they allowed, but that doesn't mean you can't craft a cron job that they will allow.

Does your host actually not let you run cron (on a Linux server), or do they restrict the kinds of things you can run, such as PHP scripts using 'php'? Mine does the latter, but they allow using cURL to run PHP scripts.

Pete, "Frozen" has PayPal Pro built in -- it doesn't use the paypal-app you linked to. However, it's at 5.010, so my concern is whether you need to install, configure, upgrade, and then apply the patches above, or if the Frozen files could be updated ahead of time (via my Frozen patch). The best would be to update Frozen (via patches) to PayPal 5.018 so that when installed, it's there (along with the patches above). No further manual operations for the store owner. I will try to find a Frozen implementation that's been updated to 5.018, and compare files, and see if I can first update my Frozen patches to 5.018, then apply the patches found above. That would be the most desirable thing for anyone using Frozen.
Update: I've started looking at the PayPal app vs. what's in Frozen. A lot of the differences in Frozen are trivial stuff -- use of $_GET/$_POST, __construct, hard coded file and table names, etc. However, it looks like Frozen is still at PayPal 4.039 while the app is 5.010. There are a lot of non-trivial differences between the two that will take some thinking about (which one is correct to use). Then, there is still the issue of various fixes proposed in this and other threads, and whether they can be applied to 5.010, and whether it's possible to upgrade Frozen to have 5.018 out of the box. (does the "upgrade" change the PHP files?) This is not going to be quick.

Since Google+ has mostly gone away, should we be thinking about removing it from stores? I never used it, but my understanding is that it's only available for "G Suite", whatever that is. Do the Google+ functions on osC still do anything, or are they just an embarrassment that osC hasn't been updated in ages? If it should go away, I can add that to my Frozen patch set. It will be up to others to fix Edge and the official product.

Keep in mind that it's more than just changing function names mysql_ to mysqli_. Some parameter lists in the calls will also be changed, so you need to check those.

The method used to send mail (mail function or SMTP) has no direct bearing on spamming. The spammer was using some function (Contact form) further up the food chain to generate the spam. It is irrelevant whether PHP mail() or SMTP was used to send it out, unless your host has some sort of spam-blocking implemented for one but not the other. That could be why they asked you to switch to SMTP, or it could be for some entirely different reason (you should ask, just to know what's going on). Anyway, the spam-blocking (some sort of CAPTCHA or other anti-bot challenge) needs to take place in your application where the spammer is operating, such as at the Contact form, before it gets to the mailer. Simply changing the mailing method from mail() to SMTP will do nothing to control spam from your Contact form (although your host may then be able to intercept spam). And as mentioned before, reCAPTCHA is a specific, widely-used anti-bot CAPTCHA, but it's not the only game in town. If your host demands reCAPTCHA specifically, they're idiots and you need to find a new host.
By the way, it's well known that CAPTCHAs are almost useless today, as bots have gotten so good at using them, so don't expect miracles (especially with any widely-used one such as reCAPTCHA, which hordes of bots can crack). Also, you may notice that reCAPTCHA images are heavy on recognizing vehicles, traffic signals and signs/markings, street signs, crosswalks, pedestrians, and the like -- it's widely suspected that Google is using reCAPTCHA to train its AI  for self-driving cars (and you're not being paid for your participation).

You could certainly set up a processor on your PC to take the incoming .csv or .txt file and write a new .csv file back out, ready for either manual database import or through Easy Populate. There would be several data configuration files associated with it: markup per category, markup for specific products (override per category), and category per product. You would manually maintain these configuration files with an ordinary editor. When you run the new .csv or .txt file through the processor, it would tell you if any products are missing a category (likely new products) and you would update the category file and rerun the processor. A bonus feature would be to compare the new output to the previous one (saved from the previous time it was run) and only write new and changed entries, in order to run the update faster (dozens or hundreds of updates rather than tens-of-thousands each time).

Why are you going into Excel (or any other spreadsheet) to add columns and calculate prices? You should be able to read the CSV file with a scripting language such as Perl, and write it back out with new columns with prices and such. How many manual decisions do you need to make for each product? Can it all be reduced to a formula? What about categorizing new products -- is that manually done? You should only have to do it once, for a product or manufacturer, and keep that information around in a file. For routine functions, you should be able to take an incoming CSV or txt file and convert it to something useful to read in either manually or via Easy Populate, without any human intervention.

There are some "Easy Populate" modules floating around, that let you update product information from a CSV (text) file. Take a look at that and see if any do the job.

777 is NOT correct on many servers. They will give a 500 error because this is a security exposure ("world writable files"). You start with the minimum permissions on any file (typically 644) and add "write" permissions (664, then 666) until you get it working. Very few servers now require PHP files to be marked "executable" (755, 775, 777). This applies to files that PHP needs to write to, and depends on how PHP is configured (especially, what user group it's running under).
777 was safe to do back in ancient times, when you could trust everyone sharing your Unix computer. You can't anymore, especially on a server shared with hundreds or even thousands of strangers. Giving them "world write" access to your files is asking for trouble. If someone blithely tells you to "chmod 777 your files", they're an idiot. Don't listen to them.

First of all, make sure you are installing a current version of osCommerce, one that is PHP 7-ready, secure, mobile-friendly, and up to date with many new features. That would be osCommerce 2.3.4.1BS "Edge" or "Frozen". As you are not experienced with osC, I would recommend "Frozen" (see my signature below for the link), even though it is not PHP 7.2-ready and has a list of patches. Under no circumstances should you even think about installing the "official" version downloadable from this site. It's obsolete, even though it's also called "2.3.4.1".
via Google Translate:
 

No harm done with responding to a 13 year old post, if the problem and solution given might still be relevant to someone. Since the thread would have been so deeply buried, I would assume that Jack would be aware of its age. Likely the OP is long gone, but in case there are others in this boat...
As long as we're having a pleasant chat about unusual shipping requirements, is there anything built-in to restrict certain products to certain geographic zones (such as countries)? For example, physically shipping goods only within the USA, but digital downloads anywhere not embargoed? I'm sure I could code up something, but if someone has already done the work... the key is to alert the customer well in advance before they load up their cart with a mixture of physical and virtual goods and then try to check out.

If the ads that Google is serving you use http in their addresses, such as for images or Javascript, many browsers will suppress their appearance ("mixed content") due to http (non-SSL) content on an SSL (https) page. You should be able to see this by the icon shown next to your address in the browser address bar. The proper solution is to specify that you want SSL content in your ads, so that everything on the page will be shown by all browsers. I don't use Adsense, so I can't tell you how to do this.

What's this "Blu-ray" thing you old geezers keep prattling on about? Don't you watch a movie like everyone else does, by swallowing a pill? Oh wait, there's now a topical cream containing nanoflash chips, but it's facing stiff competition from the clip-on movie earring.

Phil, ...agreed, ..and that's pretty much what I always try to do. Though as for the tables and nested tables, this is legacy osC code and we will likely be poking fun the same way at divs and nested divs at some point in the near future. :)
The issues I brought up are minor and do not affect the functionality of Jack's code and his fantastic contribution.

It's always more useful to the community if you can tell us what fixed the problem. That way, people searching around for a solution to a similar problem won't be wasting their time by finding this thread and coming here only to find "fixed". Even if it's just "I found I had accidentally deleted the last 10 lines of file X, and had to restore them from backup", that's somewhat useful. The only lower life form is someone who posts a question, gets solutions from the community, and then erases their original question (deliberately, so it won't be of help to potential competitors).

What character encoding is your Thai text in? A ?-in-black-diamond glyph normally means you're trying to display your page in UTF-8, but the text being supplied is encoded in something other than UTF-8 (and thus, invalid characters). Most likely you'll have to change your Thai text to UTF-8, or else change the page encoding from UTF-8 to whatever encoding is in use. What other languages are you supporting, and in what encodings? What osC version?

Are you looking to modify the page text or the layout of the page? The text is defined in various language files that can be edited with any text editor (never use Dreamweaver, Expression Web, or any other HTML page editor on PHP files). If the text includes HTML tags to format the display, that could be a problem if you want WYSIWYG. You could try cutting and pasting the text (including HTML markup) into a scratch .html file. Go through and unescape all escaped apostrophes (\' --> '). Use any WYSIWYG HTML editor (such as Dreamweaver, Expression Web, Nvu, etc.) to edit this file. Go through and escape all apostrophes (' --> \'). Cut and paste it back into the language file. You really should be somewhat familiar with HTML if you're going to do this; otherwise HTML editors may insert extra code such as <!doctype>, <html>, and <body> tags that you don't want. Also note that without the standard CSS files being included, you won't get quite the same final appearance.
 
What osC really needs is an "Edit" button that shows up on each page just for the administrator, and allows some sort of WYSIWYG editing of a segment of text defined in a language file (and of course, writing it back to the language file within the correct "define"). It would be a big project, but would really make osC easy to modify. Anyone up for this?
 
If you're looking to change the layout of the page, you'll need to directly edit the PHP code with a plain text (file) editor. There is no foolproof WYSIWYG editor for PHP pages.

Do NOT directly import XLS or CSV files into the database. Adding a product ("goodie") requires updating multiple tables. If you want to bulk import or update products (more than one at a time), install the "Easy Populate" add-on, which allows you to use a CSV (Comma Separated Values) file as your source.
 
Or are you already using Easy Populate, and gave it the wrong name? What osCommerce version are you using? What PHP version?

If it's just a matter of displaying fixed background images rather than colors, that should be possible by manually editing the CSS file(s) being used, to add a background-image property. If you're looking to have a background image that changes with the product, or whatever, that would require some coding.
 
 
"Regular" osCommerce 2.3.4 (you shouldn't be starting with anything older) is a nonresponsive, nonadaptive layout. It's more or less fixed in layout, positions, sizes, etc. There is a community-supported "Bootstrap" version available which uses CSS and Javascript to adapt itself (layout, sizes) to various display sizes (from smartphone up to desktop) and input capabilities (mouse versus swipe, etc.). While "unofficial", Bootstrap is expected to be the basis of the official 2.4 (there might be a 2.3.5 first, but no word on whether it will be responsive).

I think there would be a lesson learned here is that you don't simply delete a product, but set up something to send any old incoming link to either a similar product or to a product category. In either case, there should be some message to the visitor that the original product is no longer available, but here is something similar/here is a useful category. I suppose it's possible that there could be nothing appropriate to send a customer to, but they should still get a message of some sort explaining the situation, and making suggestions for alternatives. Hopefully this can be done in a way that Google doesn't ding you for duplicate content, or whatever.

Per UrbanDictionary.com: HTH = Hope This Helps
G = Geoffrey Walton (signature)

Besides restricting shipping choices for various products, would this be a good base for other restrictions on a product? For example, some cities or states may not allow certain "weapons" (e.g., knives or swords) to be shipped to addresses within them, or require an affidavit that the purchaser is of a certain age. Some products might be subject to national export (or import) controls, and thus can't be shipped to certain countries. Some products may be considered hazardous, and refused by certain shippers, but this is probably already handled. So, given a shipping address (and/or age), some products might have no shipping method at all, and would have to be deleted from the order, while others would have a restricted choice of shippers (you might choose to bundle the entire order together, even at a less attractive rate, rather than ship part by one shipper and part by another.
 
Finally, it would be good to have icons indicating shipping restrictions, to appear on a product listing page (wherever a customer could add it to the cart). For example, if FedEx won't handle it, you could have red-circle-slash "FedEx", or if you must be 21 to purchase, red-circle-slash "under 21" (or green-circle "over 21"). That sort of thing. They could trigger the "signing" of an affidavit that the purchaser is over some minimum age, although I don't know how much legal protection that would give you (it might be worthwhile to consult a lawyer, if you're selling such things). It's worth considering, rather than having all sorts of different ways to restrict shipping for various reasons.