MrPhil

Are "googletags" related to a Google advertising offering, such as Adsense, Adwords, etc.? If so, how do you monitor (and control) the quality of what Google is sending you for on-page advertising? I bring this up because on a couple of technology-oriented sites I visit from time to time, there are banner ads (constantly changing) that are often absurd. They are pure clickbait that I won't even waste a second on, but I'm sure they appeal to someone. An example: an obviously photoshopped, hideous picture of Hillary Clinton with a caption promising a look at her "hit list". Now, I understand that some people just hate her guts and are anxious to click to get the latest dirt on the Hildebeast, but I'm guessing it's something totally different from what was promised (including drive-by malware downloads). Other examples: breathless "doctors astounded by _____", "scientists amazed by _____", a picture of two helicopters lifting a supertanker off a beach, a 40-storey high cruise liner (that looks unstable enough that the tiniest ripple would capsize it), a 777 airliner with the two engines replaced by passenger cabins and the central fuselage replaced by a huge jet engine,... well, you get the picture. These things are funny to look at, but I wouldn't want them despoiling my site. I assume that Google is involved somewhere because the page is loaded with "googletag" in the source. So, how does one keep control over the quality of ads being run on their site? Do reputable ad providers guarantee a certain level of quality and truthfulness, or is it the Wild West out there? Do any let you vet what they intend to run, before they run the ads?

You piqued my curiosity, so I found this: https://www.thesawguy.com/sabre-saw-vs-jigsaw/., https://www.thesprucecrafts.com/jigsaws-and-sabre-saws-the-difference-3536880, and https://www.luxuryhomestuff.com/saber-saw-vs-jigsaw/. And even https://woodworking.stackexchange.com/questions/1423/what-is-the-difference-between-a-sabre-saw-and-a-jig-saw. Anyway, it looks like the definition has changed over time (and regions, and manufacturers) and what I was taught in jr High shop is now considered "old school". Peace out.

Don't show it to the US Department of Defense. They'll think $1000 for a sabre saw is cheap. Really. They pay $600 for hammers and $800 for coffee pots. P.S. That's a sabre saw. A jigsaw is a non-portable saw with a reciprocating blade.

If it's commented out, you can safely delete it, as it's not being used. The only reason to keep something around would be if some time in the future you might want to use it again. php_value and php_flag are things you'll never use again in an .htaccess file, so go ahead and trash them. If civilization comes crashing down and you have to revert to PHP 3, you can always recreate those lines.

Well, that's a whole 'nuther animal. If you give them store credit towards the canceled order, and they pay any extra towards the new order at the time of the reorder, they never owe a balance. They don't have an outstanding balance (owed to the store) at any time, which was the original problem to be solved.

But, but,... the customer isn't owed money by the business -- they owe money to the business. If you can monkey the credit/voucher module to accept a negative balance, that might be added to the next order. However, if the customer wants to settle up now (might not order something for a while), they still need some sort of dummy transaction that the voucher could be added to. If this were an uncommon event, I would just handle it manually (charging their credit card), but it sounds like it's common enough to warrant an automated method.

Almost. It says to associate .php files (and .php7 and .phtml, which you don't use) with PHP 7.2. Removing or commenting out this line would drop you back to the default version of PHP. Yeah, anything starting with # is commented out and can be ignored. If you uncomment them, you'll probably get a 500 error since they're obsolete. As written, it might well work OK, but I'll give a caution: for best SEO, you want to be consistently mydomain.com or www.mydomain.com. You should add a test for domain name and combine the HTTPS test into the same rewrite, so there's only one 301 redirect happening. Something like: RewriteEngine On RewriteCond %{HTTPS} !on [OR] RewriteCond %{HTTP_HOST} !^www\. [NC] RewriteRule ^(.*)$ https://www.mydomain.com/$1 [R=301,L] Note that your domain is hard coded (this is the "with www" way) because HTTP_HOST can be mydomain.com or www.mydomain.com, and you can't simply shove a www. in front of it. If you want to use the "without www" form, you would take the ! off the HTTP_HOST line and remove www. from the rewrite. The R=301 tells search engines to index this revised URL instead of what they had before. The ETag business I don't quite understand, but if your host put it there, presumably it's OK. The cached file expiration stuff is to cut down on files being fetched from the server (performance improvement), ranging from 2 days to a year (depending on how quickly a file is expected to change). Yeah, f***king script kiddies trying to find vulnerable WordPress sites and break into them. "Throw it against the wall and see what sticks". I wish I could slit their bellies open and throw them into a shark tank... at least that could provide some amusement. At least you found that your database somehow got corrupted and your PayPal entries removed. It would be a good idea to figure out how that happened, to avoid a repeat. At the very least, learn to keep file and database backups on your PC so you don't have to keep going back to your host to do it for you. And learn how to restore files and database!

!on and off should be equivalent, unless you have a very strange server setup. ^(.*)$ and (.*) should both capture the entire REQUEST_URI (sans initial /) into $1, but the first form (with anchors) may be a bit more reliable in capturing the entire string. Since you're using %{REQUEST_URI} instead of /$1 in the rewrite, the $1 capture is ignored anyway. Do you have any subdomains or add-on domains in play here? %{HTTP_HOST} is what the visitor entered, not some canonical form of your domain name. For best SEO results, you really should pick "with www" or "without www" and stick with it, adding the test to this redirect (with [OR]) so that you end up sending only ONE redirect request (search engines penalize you for multiple redirects, say, one to change http to https and another to add or drop www). An explicit R=301 tells search engines that the resource has been permanently moved, and the new URL should be used from now on. The first one gives an implicit R=302, which is a temporary move, and should not be remembered. The [L] flag is a convention to tell .htaccess processing to leave and come back in (start over from the beginning). Whether it makes any real difference depends on what other URL rewrites/redirects you have in your .htaccess. A "500" (Internal server) error can be caused by a lot of things, including a botched .htaccess or php.ini file, or sometimes PHP code errors. Do you have any php_value or php_flag entries left in your .htaccess? They belong in a php.ini file (or equivalent). Your host should be able to tell you how to turn on enough error logging to find the problem, and what files (e.g., "error_log") to look for.

You can install "grep" on Windows, or the built-in "findstr" command does almost the same thing.

Don't wait for a new official release of osCommerce. It's likely to never come (quite literally). Use the 2.3.4.1BS Edge/CE/Frozen for any new system, and if you're running anything older, be thinking about upgrading to this one. Regarding the errors you reported, the new version (Edge) now hard codes a lot of file names and table names, rather than using defined constants. If you try to mix in old add-on code, you'll have to modify it manually to either define the constants (there is a "compatibility" add-on for that), or hard code the names. I don't know if that will fix the phplot.php error. The "headers already sent" message will probably go away when you fix the other errors -- it's caused by an error message being sent to the browser "too early", before all the headers have been defined.

Hackers are constantly looking for things that can be exploited to break into a system. An example would be a buffer overflow, where you cram 10 pounds of shit into a 5 pound sack, and something can overwrite code with your data when the sack bursts. Trust me, such things do happen. Just because you're totally unaware means nothing -- ignorance is not bliss. A new PHP system does have new code which might be exploited, but it's also being continuously patched. An old system (like pre-5.6) is no longer being patched, and any security holes that are still there, are there forever. Hackers know about them, they know the code being run on them (such as osC), and sometimes can figure out data or usage of osC that will exploit that hole.

Now you're asking for something totally different. The best way to handle sequential numbers is to have a table holding the tickets, with an autoincrement key field for that ID. Presumably there's a table already involved here, somewhere. You could also do it with a file holding the ID, which would be incremented and written back, but that's a lot more complicated coding to ensure atomic operations. By the way, the solutions given already in this thread are not safe. There's no guarantee that two tickets can't end up with the same "random" ID number, unless you check it against all existing ticket numbers. You would be better off using an autoincremented field value -- at least, you could guarantee that it's unique. A hash of some unique string (such as the customer name and address) might also be suitable.

Well, comment out the echo statement I had you add, and see if you're back to where you were. See if you have any error_log or similar files floating around that might detail what the error is. There might also be a server error log under your account control panel that might say something. I don't think I've ever seen a host that didn't permit you to add PHP settings somewhere. On very old systems, they might be php_value or php_flag settings in your .htaccess. Others might have something similar to php.ini, but called something different. As a last resort, ini_set() calls can be added, but that's the sign of a bogus host if that's the only way.

Some server accounts permit you to define a php.ini file for yourself. Ask your host if there is something like that you can use. The alternative would be to put ini_set() in application_top.php so every page gets it. Assuming you or I didn't make a syntax error, is there any page source in the browser (Ctrl+U, usually)? If completely empty, there must be something wrong with the new statement. Or, if the server choked with millions of lines of output, that would suggest an endless loop on that page.

I think the master value is the server-wide max value, and the local value is what is set for your account/page. 128MB is usually enough in most cases, but since you probably have some headroom (768MB), you could see if something larger in your php.ini or with an ini_set() makes any difference. If increasing to, say, 192MB cures the problem, you might leave it at that, but generally it's better to understand what's going on than to simply raise limits until it stops breaking. At least, it could buy you some time to figure out what's eating up so much memory. $result .= str_repeat($this->spacer_string, $this->spacer_multiplier * $level); Any chance of temporarily inserting the following diagnostic just before that line: echo "str_repeat('".$this->spacer_string."', ".$this->spacer_multiplier." * ".$level.")\n"; and seeing if the string is absurdly long, or the multiplier or level is huge? 159744 bytes is awfully large for a string temporary. The problem could also be that $result is caught in an endless loop and building up until it crashes the system (it wasn't the str_repeat that is the problem).