requinix

I'm done. Do whatever you want.

Unacceptable. If you were able to create the account then log them in right then and there. Automatically. That voids this scenario. Multiple steps. First step is to sign up. That has its own page. You can deal with duplicate emails and password requirements and even confirmation emails at that moment. Stop checkout until this is done. That should also include your second "step" of accepting the TOS. If they do not accept then they should not have an account. In other words, a little checkbox "[ ] I accept the Terms of Service" that's required. Then they are logged in and continue to the purchase step.

Please post your table structures and an example of the data you're working with, including the data you and do not want to include in the query.

Okay... I know you figured out the parameters because you posted what it should be, and now I know you have seen where those functions (which already have the "i" added) are in the code. So what's the problem?

Were you able to find the parts in your existing where you call those two functions?

I'm not concerned about it because it doesn't have to be. Like you said, you feel like it has to be a certain way. I'm telling you that no, it does not. It's something separate from this to consider doing, but one that I recommend. But if you do it then you'll simplify some of this problem. No, what you're doing is allow anonymous access. I'm saying allow authenticated but non-premium access. Give like 20% access for anonymous users to get people to the site. Allow 30-40% access, plus maybe a couple features, for authenticated users to get people to sign up. Allow 100% access for people who pay money. This here is some fairly basic economics about funnels. Let people ease into your site until they're comfortable with the idea of paying money; making it a single step of "30% access and you have to pay to do anything more" is a cut-off that is going to lose you customers. Allow unpaid access. Give people who are interested in your site another step they can take that doesn't require them to pull out their wallets. Because you're fixated on the whole "omg it's all at the same time" thing that I keep telling you it is, in fact, not the case. No. It's dumb, but it's not a sin. I don't see how what you're describing now is different from what you were talking about originally. Before you wanted to do everything "at once". Now you want to do everything "at once". It's the same thing, just different words. 10 concurrent users is nothing. It's unlikely to happen, of course, but when you have everything "at once" taking a long time then you have to care more. For varying definitions of the word "slim". Congratulations. But you're describing stuff that everybody does differently. And they do it differently for a good reason: because it works better. You aren't anywhere near a point where you can run A/B testing to discover for yourself what works better and what does not, so maybe set aside your own designs and take a look at what other websites do. Because they have done the testing.

You're thinking about this in terms of whether they happen during the same request. Sure, they happen in the same request. But they still happen in a specific order, and it's that order you need to be focusing on. You should separate the member from the payment. An account should be able to exist in a state where the user does not have access to all the content. Because the concept of a user existing on your site really is separate from whether they've paid money to access stuff. In fact you really should do this: restricting people from using your website at all until they've paid is not as good a business model as allowing people to sign up and then convincing them to pay money. It might sound counter-intuitive, but generally if people discover they have to pay money to create an account then they're not going to do either. Yeah, that's backwards. Don't do that. Member first, order second, payment third. Ooh, a whole 10 people checking out at once? Ha. The only reason creating a member should fail is due to duplicate information. Like duplicate email address. You can create a user atomically by attempting to create one and letting the database tell you if it failed. This concurrency problem is yet another reason to do each step in turn: so if there's a problem with one of them then you don't have to redo the whole thing all over. You asked for advice, I gave mine. You're free to ignore it. Not my business.

Create the order. Can't process a payment on an order that does not exist. It starts in a pending state. Process the payment. If successful, enter the successful payment and mark the order successful. If unsuccessful, enter the unsuccessful payment and give the user a chance to try again. Data is good. If you have any, store it. Doesn't matter what it is, store it. Whether it represents something successful or unsuccessful or even if you don't know whether it's successful or unsuccessful, store it.

Depending on your business needs, sure: you could do all of those at the same time. But you're approaching this like it's all-or-nothing. It isn't. You can create the user regardless of the transaction. You can record the order regardless of whether the payment goes through. Don't treat it like it's all one big operation that you have to rollback/cancel if any one step fails - make each part work in its own right, just like if the user was in control of each step.

https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html#option_mysqldump_result-file

Pretty sure we are not understanding each other. Exactly what are you trying to do and/or understand?

Then I was understanding you correctly. It is not possible. Not through PHP or Javascript or anything other than installing software on the user's computer.

Amendment to what I said: you probably got a DVD of LynxOS. Different thing. Going for Debian? Read the guide. I don't see where it says 32-bit.

It is not possible for some website on the internet to get the name of your computer. I don't know what you're doing or looking at.

By installing software.