requinix

You don't. MySQL wants YYYYMMDD format, with optional separators, and either a 2- or 4-digit year. Why can't you use that format?

Unfortunately I can't find enough information to track you down to a specific school, which means I won't be going out of my way to report your plagiarism.

I forgot a totally obvious way to test code: Hack it. Find the code that does the stream_socket_accept and modify it to show false instead. Then see what happens. //$variable = stream_socket_accept($args); $variable = false;

You don't need to worry about the lower-level interfaces as the callback guarantees that the object is of type ConnectionInterface. So look at classes that implement it, and subclasses of those. Apparently they're Streams? Looks like Stream does a two-argument callback, while ReadableStreamStub in the test code does just one...

You need to be really careful when typing code you see in a video because it's easy to misread something you see. Examples: if (empty($GET['page'])$GET is not a thing. This, and the other one, should be $_GET. $core_path = dirname(_FILE_);There are supposed to be two underscores on either side. I see some other aspects of the code that are not good, but they won't prevent the code from running so one thing at a time. It's great that you want to learn PHP, but the way you're doing it suggests you're just learning how to follow instructions and not how to actually program in the language. I recommend you find a different set of videos for your initial foray into PHP - you can come back to these when you know more about PHP and only need to learn how to do a messaging system itself.

Since their documentation doesn't, you know, document this - at least not unambiguously - you'd have to look at the code. Start off with your code: $socket->on('connection', function (\React\Socket\ConnectionInterface $stream){That looks for events on $socket, so you'd look at Server for places it does an emit (if you wanted to listen for errors on it). $stream->on('error', function($error, $stream) {That's on ConnectionInterface, which is obviously an interface so the classes that matter are the ones that implement it. Check them for emits.

Please just post your code (the stuff containing the header()) so we don't have to download it. When you do, put [code][/code] tags around it.

Expected. You'd have to unplug during the accept() sequence, which only takes microseconds to complete. I must have seen the lower-level error being emit()ed on the buffer. So it looks like the callback you're using does take two: an Exception and a Stream.

According to the docs, $error will be an Exception. According to the code (Server.php), it will be a RuntimeException. And there's only one argument to the callback, not two. The error happens when stream_socket_accept() returns false. Following the rabbit hole, it boils down to accept(2) failing, which could be due to reasons including - Connection was aborted between the initial connection and the server accepting the connection (hard to test) - Interrupt before the connection was accepted (hard to test) - Reached the limit of open file handles in the process and/or system (don't want to test) - Out of memory (don't want to test) - Invalid socket (probably can't test) - Firewall does not allow connection (awkward but probably possible to test) So basically it's not really testable and it's unlikely to happen anyways.

Well there's a problem: you have PHP 5.3 installed on the system. Get rid of it.

Step 1: stop using regular expressions to parse XML. There are better alternatives. There is no step 2. The CDATA stuff won't be a problem because libraries that can parse XML know how to handle it.

Putting stuff into variables doesn't matter. You have $json_ary - use that. Why do you think you need variables?

Looks like you're trying to bypass something?

You cannot foreach over it just because it is an array. It doesn't make sense to do that with this data. If you want specific data then you need to get it specifically. For example, the temperature is at $json_ary["properties"]["temperature"]["value"]

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.