requinix

Sounds good. A transaction is only necessary if you have to run multiple queries and the database is not in a consistent state until they've all executed.

It's off by two hours, right? Because PHP is normally set to UTC time. date_default_timezone_set Or if you're based in that timezone and want everything to always be according to that, change the date.timezone value in your php.ini to say Africa/Johannesburg. (And restart your web server and/or PHP.)

- System takes Shopping Cart details associated with PHPSessionID and links them to the new Member record Do you care about storing shopping carts with an account? Some sites do, some sites don't. If you don't care then you don't have to do that step. Look at your process this way: If a worst case scenario was to happen between any two steps, would your process be able to recover gracefully from the failure? Will you lose any information? Will the data in your database be incomplete or otherwise corrupted? For example, - System runs the payment - System hopefully gets back a "success" message from Payment Processor One potential worst case here is that you submit a request to your payment gateway but the system blows up before it can receive the successful response. What would happen with the plan you've described? What should happen? But be careful: I've chosen a particularly devious scenario for you to consider. The answer may surprise you.

So do what I said: deprecate the old endpoint, but keep it working until the DLL can be updated. Ideally you would keep everything working instead of redirecting because there are other nuances to consider, but at a minimum keep the non-GET/HEADs up. If it's something distributed to customers then you'll have to keep this going for however long you support your software. If it's something internal then, you know, update the DLL.

Are you using someone's blog as your reference? https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.8

There is no mechanism in HTTP to tell a client that it should submit POST requests to a new URL. The industry handles this in a fairly standard way: deprecate the old endpoint before taking it down. Continue supporting it for some period of time and give a warning to consumers that it will move.

What kicken said ^ Have your function take an optional argument for the current/default/selected/whatever you want to call it, value. In the while loop, mark the <option> as selected if it matches. Then your script calls the function with whatever value came from the form - if there was one.

Pretty much. The columns represent discrete identifiers that have no intrinsic numerical properties, meaning there's no reason you should ever do anything based on an order or product ID range, therefore all your queries will be straight equality - whether the row is or is not for a particular order and/or product. As such there are no benefits to having dual indexes on both columns.

More precisely, the query analyzer will only use an index if the first N columns in it are included in the query. Given indexes (columnA), (columnB), and (columnA, columnB), SELECT * FROM table WHERE columnA = 123 could use the (columnA) or (columnA, columnB) indexes. SELECT * FROM table WHERE columnA = 123 AND columnB = 456 could use the (columnA) or (columnB) or (columnA, columnB) indexes - and the last one is probably best. Note that (columnA) and (columnA, columnB) are redundant: anything that can use the first one could also use the second one. There's more to it than just about being "common", but that's a decent starting point. If you wanted to query for products across all orders. Point #1: An index takes up disk space to store the data. Point #2: Each index slightly reduces performance when making changes to table data because the system has to update its indexes. Point #3: (order_id, product_id) and (product_id, order_id) are mostly redundant. Conclusion: I don't think there's enough reason to create both. Addendum: Actually it kinda depends on the data. But mostly I'm trying to discourage the "moar indexes moar columns" mentality.

I like XHTML. At least the principles behind it. Bit out of date, now. Hell may freeze over, pigs may fly, and our Tangerine-in-Chief may suddenly become a reasonable and intelligent man overnight, but register_globals will never come back.

What fields do you think should go in which tables, and what fields are you not sure about?

What if I told you that you don't need a loop?

HTTP/1 is all text. You can totally run requests and get responses yourself. SSL makes the tooling a little harder because you have to connect using an SSL client, but still not too hard. GET / HTTP/1.1 Host: forums.phpfreaks.com Connection: close HTTP/1.1 301 Moved Permanently Server: nginx/1.16.0 Date: Sun, 26 Jul 2020 18:35:57 GMT Content-Type: text/html Content-Length: 169 Connection: close Location: https://forums.phpfreaks.com/ <html> <head><title>301 Moved Permanently</title></head> <body> <center><h1>301 Moved Permanently</h1></center> <hr><center>nginx/1.16.0</center> </body> </html> HTTP/2 uses binary, but otherwise the structure is about the same so I assume there are clients that can convert to it for you.

The client must send the slash at a minimum. Not submitting anything is a gross violation of the HTTP standard. "Forging a request" is as simple as 1. Typing the request out into some editor, then copying it all 2. Using telnet to connect to the web server 3. Pasting the request, remembering to include two newlines at the end if you're sending a request without a body The copy/paste is because web servers want requests quickly and you won't be able to type it out yourself fast enough before they close the connection. Forge a request that starts with "GET HTTP/1.1" (ie, the first line without the resource URI) to any website and you'll get a 400. Should not. But search engines are generally smart enough to recognize the difference between a site's branding H1 and some sidebar's H1 and the content H1. So the guideline is more about not using multiple H1s for a distinct section of the page. Google basically picks what is most popular, not necessarily what is correct. But if you have multiple URLs to the same page with the same content then you will be penalized for it. So deal with it sooner rather than later. Trailing slashes on files are dumb. Fortunately it's rare to see anyone do that. Trailing slashes on everything else is up to personal/business preference. (Personally, I don't like slashes on pages either. With exceptions.)

+1 to the full contents. Does each line have a specific meaning? Is the textarea just an easy way to enter all of them at once? Is the user copy/pasting stuff? In general, unless you have to come up with a particularly efficient solution, DELETEing everything and then INSERTing it (preferably with a prepared statement) all anew is easiest.

Ah okay, that makes sense.

I'm still kinda skeptical but okay. What you want is AJAX. fetch() can do that for you. Make a PHP script that gets the time from the database and outputs it. Or if you're feeling up to it, put that code into some existing file where you feel it makes sense. Either way you need to end up with a URL that you can visit (in your browser) to see the time value. No HTML or anything. Just the value. Then play around with the fetch() examples and whatever else about it you want to read. If you fetch() that URL with the time then you'll get the time. Then you do stuff with Javascript. I don't know what because you've been pretty vague about everything.

I don't understand what the database has to do with this. Is the time constantly changing? It's one value when you load the page and the potentially another value sometime later?

CSS cannot target something that happened earlier in the document. If you have a div + h2 and you want to style the div during h2:hover, that won't work. You either have to use :hover of the parent element, or move the two around so it's h2 + div, or restructure your markup in some other way.

Most common programming languages use ^ for exclusive or. In PHP's case, ** is actually a relatively recent addition.

Take a look at the logic here. 1. if the "login" button (?) was clicked, 2. Else if $ret>0 or userlvl is 1, 3. Else if $ret>0 or userlvl is 2, 4. Else Do those all make sense together? Not really. What you want is 1. If the "login" button was clicked and that's it. The stuff about $ret and userlvl happens inside the if. Which means you need another if.

See those red arrows? They point out the different pieces of your if statement. See how they aren't all indented the same way? Fix the indentation so that they all line up. That makes it much easier to see that they're all related. See the red circles? They show the {s and }s that you're using in the if. Every { used in the if statement needs to match up with a } used in another branch (else if or else) of the if statement. Your second screenshot shows that you're counting the braces, which is good, but you're not thinking about what each "opening" and "closing" means. You see how #2 opens and closes before #3? And how #3 opens and closes before #4?

Can you post a screenshot of what your editor looks like with the code in it? Your post has all the code on one line and I can only assume it looks better in the editor.

It took me about 10 seconds to see it. I'm not going to tell you where the problem is. I'm trying to teach you how to find the problem on your own. What editor or IDE are you using to write code?

Make sure the code in your editor is correctly indented. Pay attention to where your {s and }s are.