requinix

If you have problem getting your code to work then a good first step would be to post said code.

Sounds like what you really need is to use the cookie when deciding what list of deals to show...

It's a little more than just changing the code. Right now your site is basically the same for all countries. That's fine, but it doesn't really lend itself to there being multiple URLs for the variations. If you were to significantly change parts of the page, then new URLs would make sense. Honestly, I think what you have now is fine: use a cookie to track the localization being applied to the page. Why do you want to have different URLs?

echo $row->$a['currency']['available']['reserved']; I don't know where you're getting "$a" from but it doesn't belong there. If you print_r($row) you'll see what the value is. It's an object with "currency", "available", and "reserved" properties. Like any other object, you access them like ->currency.

We won't slap your wrist, but we'd prefer you didn't post it and would remove it if you did. To help not spread those things around, you know? It does sound like malware, but it's possible it is merely obfuscated code (like if it came with a paid license and the author didn't want anyone to mess with it). Does the file say anything about eval or base64_decode or gunzip/deflate? Does it look the slightest bit readable? You can PM it to me if you'd like me to confirm. If it is malware then obviously you need to contact your client so they can begin damage control. Hopefully the file hasn't been there for long. It would help them if you could check webserver access logs for requests to that file so see if/how often it ran.

If you changed the footer, how about posting what it was before when everything worked and what it is now that it isn't working. And a more precise description about exactly what isn't working would be nice. We aren't as familiar with your site as you are.

May I ask how long you've been trying to figure this out? And whether you've actually read Barand's post?

Note that is for the fixed-width fonts that GD supports out of the box. With TTF fonts, character widths vary so calculating the right offset is a bit harder.

The coordinates are pixel offsets. 0,0 is the top-left corner, then you count pixels towards the right and bottom. Not magic. So the answer to what the coordinates are for the bottom-right is to find out the dimensions of the image. When you figure that out and try to write the text, you'll probably find out that it didn't write. Except it did. You just can't see it. Try moving the offset something like 20 pixels up and right from the corner and see what happens.

+1. But for me it's just the design that's extremely reliant on magic behavior and mixins at runtime and class aliases and all sorts of other crap that IDEs can't follow.

Note that they're talking about changing default settings. Make the recommended changes on your server and see what happens. Really. That's going to be the most effective way to gauge the impact.

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.