requinix

Hidden inputs are all sent with the form when it's submitted. However submit buttons ( and ) and image buttons () will only send themselves when they are used to submit the form - and only one of those can happen at a time. So what you need to do is figure out what image button was clicked. 1. Remove the hidden inputs since they're not helping you. 2. Give names to the image buttons (eg, "toner"). 3. Look for each button to tell which was clicked. Note that there will not be a "toner" but instead "toner_x" and "toner_y" values.

Don't hijack threads. You saw the code in the other thread, I assume? Did you try modifying it? Do you have any code written yet?

It doesn't matter as long as you're consistent. I personally like the .NET approach of naming I*. I know some open-source projects use *Interface. I've even seen them named interface_*, thus putting them in their own directory at the top-level, but I think that's silly.

Get it from the HTTP_AUTHORIZATION header in $_SERVER, then do rudimentary string operations on it. if (isset($_SERVER["HTTP_AUTHORIZATION"])) { list($type, $data) = explode(" ", $_SERVER["HTTP_AUTHORIZATION"], 2); if (strcasecmp($type, "Bearer") == 0) { // use $data } else { // ??? } } else { // ??? }Bearer is a not yet official method of authorization that people made up a while back because Basic and Digest weren't working well enough. It just means that whatever token comes after is some special code that the server will recognize for authentication - what actually happens with it is up to you.

Brain farts are an acceptable excuse.

You don't know about backslashes? How do you not know about backslashes? echo "String with a " quote"; // nope echo "String with a \" quote"; // winner

For "rare edge cases" they sure get used a lot. If you find yourself almost never using abstract classes then either you've got more code duplication going on than you know about or your codebase is designed much more vertically (long inheritance hierarchies) than it is horizontally (using polymorphism). Classes that represent some sort of functionality, and then I'd say no more than 50% of the average codebase at an extreme. Throwing around interfaces for the sake of, what, dependency injection? is as much an anti-pattern as singletons and registries.

"Abstract" is an adjective. "Class" is a noun. "Interface" is a noun. An "abstract class" is a type of class. An "interface class" is nonsense. Abstract classes and interfaces have similar purposes, yes, but there's one big difference: whether you can put code in it. Use an interface if you want a class to look a certain way but don't care how it actually goes about doing that. The power of an abstract class comes when you want more than one class to look a certain way, they'll all behave a little differently from each other, but you know there will be some code that works the same in all of them and don't want to have to repeat it everywhere. // I don't care how these classes work, but they need do specific methods in them interface IBinaryMathOperator { public function __construct($a, $b); public function getOperandA(); public function getOperandB(); public function operate(); } // most classes will behave similarly so I want to put the common code in one place abstract class BinaryMathOperator implements IBinaryMathOperator { public function __construct($a, $b) { $this->a = $b; $this->b = $b; } public function getOperandA() { return $this->a; } public function getOperandB() { return $this->b; } // don't know about this one yet public abstract function operate(); } // this class is a lot like others but does have some differences that show up in here class AdditionMathOperator extends BinaryMathOperator { public function operate() { return $this->a + $this->b; } }IMO abstract classes that don't have any code don't make sense, so don't bother thinking about them: either do an interface or add some code in it somewhere (if sensible).

The one containing the code that isn't working properly, yes.

You aren't initializing the $node variable in that one if branch.

The developer sounds stupid. Yes, at some point there is a query for the users. Either it happened for all of them when the page first loaded, or each state's users are loaded using AJAX (Javascript with a separate request to the server) when you pick a state. Easy non-dev way to check: load the page, disconnect from the internet/network, and pick a state.

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"]