requinix

That's right, and I don't know. It's quite possible - likely, even - that I don't know the full story behind what the number is and how it works. Only when debugging. Right. Nope.

You put the... "codes"... into a file inside XAMPP's htdocs directory. It can be called whatever but it needs to have the .php extension. You run it by going to http://localhost/whatever.php (if you're using port 80) or http://localhost:81/whatever.php (for any other port). Substitute whatever.php for the name of the file.

It's a counter PHP manages for object instances - no two that exist at the same time will have the same number.

"codes" Do you have any idea what PHP is?

I see you're doing users/$username/files/$file in that one if condition, then again when you get $content. That's the full path to the file, right? You aren't doing that with the readfile... There's a much, much more significant problem with your code: I can use it to download any file I want from your server, and all I have to do is change the ?file= in the URL. Consider what would happen if I did ?file=../../../script.phpThat means your code would look for users/$username/files/../../../script.php -> script.php?file isn't the only part that's risky, either. Cookies can be edited by the user, so when you put the username in one I can change it to whatever value I want. Besides using that to mess around with the file path, I bet I could use it to any username I wanted. Here's what you need to do: 1. Fix the username problem. Store your data in sessions instead of in cookies, because session data cannot be edited by the user. You'll need to fix this on the rest of your site too. 2. Make sure that the ?file is a safe value. For example, you can make sure that it's just a filename by using basename. This is also something that you'll probably have to change in other places. 3. You also need to make sure that the ?file is even present in the first place. If not your code will do some odd things. Use isset for that. Unrelated, 4. You should not need to change error_reporting in your scripts. Set it globally with your PHP configuration (however that works) and you'll never have to think about it again. After all those changes, your script should look more like <?php session_start(); // required to use session data if (isset($_GET['file'])) { // make sure ?file is present $file = basename($_GET['file']); // strip everything except the final filename portion $path = 'users/' . $_SESSION['username'] . '/files/' . $file; // create a variable for this instead of repeating it everywhere if (is_file($path)) { // file_exists checks if the $path exists *even if it's not a file*. use is_file instead header('Content-Type: text/plain'); header('Content-Disposition: attachment; filename="' . $file '"'); readfile($path); exit; // stop executing code. header + readfile + exit often come as a trio with download scripts } else { echo 'File does not exist!'; } } else { echo 'File name missing!'; }

Okay, so, I guess with that cleared up, there's the issue of orientation still maybe needing some clarification. Yes, resizing with GD will destroy EXIF data. So you check the orientation before resizing, load up the image, fix the orientation if needed, and finally resize and save to wherever.

You can't. You're the one who talked about resizing before the upload, which I took to mean you were doing something manually. It doesn't make sense but that's the only logical conclusion I could make. That resize class runs in PHP, which is on the server, which means you would have to use it to resize after the upload. And by "upload" I mean the technical mechanism of a user using their browser to submit a form containing a file-type input, wherein the file data gets sent to your server and processed by your PHP code.

Depends how you're doing the resizing. I'd expect decent image editing software would let you keep EXIF data from the original. But... if you're resizing before the upload, why not fix the orientation at the same time? So I guess it boils down to how you're doing this resizing before the upload? You could always change that limit, of course. Unless you're using a shared hosting service, then they might not let you do that.

Yeah, the Age is a custom field we added in case people want to show their (approximate) age without telling their birthday too. But that means it's just a plain field you have to manage yourself.

You can't modify the file before it's uploaded. You could display the image to the user and let them indicate the proper orientation, eg. by giving them arrows to rotate. don't understand why you can't just use the exif data after the upload though...

$this will be available if the file is being include()d from within a class. Apparently home.php is being included that way but your new promo_test.php is not.

Yeah, their choice to not actually rotate the image data but to indicate it in EXIF data is baffling. If anything the EXIF should tell the original orientation of the device - acting as supplemental data, not required information.

If you're in there looking at the EXIF data anyways you might as well do the right thing and check the orientation. [edit] Oh, and there's a more significant issue: just because the photo was taken was an iPhone (a) doesn't mean that it is rotated at all, or if it was (b) tell you which way it is rotated.

Have you tried a, you know, comparison? With >?

Would have to know all the FastraxNetwork code too. But don't expect someone to do this for you for free.

Variables defined outside functions are not available inside functions. Pass $db as an argument to the method.

If you have code that deals with superglobals (eg, a "Request" class) then use it. Otherwise it's not a crime to use them - just don't make changes.

Is this another one of your abstract questions that would be better answered if it wasn't abstract? What is the relationship between the IDs and the animals? The normal answer to "how do I get a thing based on ID" is "do a query for the information from the database and construct the object appropriately", but that doesn't seem right here.

Why do you think you need a class for this? And for what, exactly?

Y-m-d is the normal format, but MySQL understands Ymd too. But I don't think MySQL is involved here.

A helpful resource.

$unique_coupon_code only exists in the create_coupon() function (and only after it gets defined). Variables in one function do not magically appear in other functions - it would create havoc. To get the value, call the function and use its return value. $coupon = create_coupon(); echo $coupon; // or simply echo create_coupon();

The ID is being included in $attributes but doesn't have a valid value. Don't include it. Or if you must, set it to null.

Could be caused by recursion. Install Xdebug, set a stack limit of 100 (default), and see if you can get a stack trace of it failing.