requinix

Having to maintain a mapping is cumbersome. Do you have any attachment to being able to separate the model from the form? Would it be so bad to consider the model (this model) as a "form model" and have form fields map directly to object properties?

You need to learn about HTTP. This thing seems a reasonable explanation of it. Once you know HTTP you can send requests and receive responses over that socket.

1. You can't session_start() if there has been any output. Move that to the very top of the script. 2. If you want to remember the values (and want to use the session for it) then you actually have to put the array into the session. The logic for #2 is simple: if there is an array in $_SESSION already then use that, otherwise use the default ABCDE array. Manipulate that array however you want, then put it back into $_SESSION. Give that a shot. If you have problems, post your new code.

Yup, that's it. You can still use debugging, but you cannot do anything that would cause the properties in the mysqli object to be evaluated.

It's possible that the act of dumping $db will reset the errno, as "all functions that have to ask the server for information reset [the errno] if they succeed", and the mysqli class has a number of dynamic properties. Try dumping just $db->errno.

It needs to be on. If it keeps turning off, I don't know, but it does have to be on for this to work.

Advice: any time you do a foreach by-reference, unset the variable after the loop. Or don't use references at all. Otherwise you might accidentally use the variable later in your code and create some really unusual bugs. And please, indent your code. foreach($_SESSION['golf_entrants'] as &$row) { if ($row['id_code'] == $id) { $row['entry_name'] = $name; $updated = true; } } unset($row);

I can't think of a single site, PHP or not, that has users and does not expose the user ID in some way. Picking basically the first link I can find on these sites: - StackOverflow: "Rana Ghosh" is #6162401 - MSDN Forums: "Imtiyazk" is 370588b4-fbbe-45a5-b066-bfb0fa31debf (that's a GUID) - Slashdot: "Aethedor" (first comment) is #973725 - Wikipedia: "Segehelmus" is #21621158 - Twitter: Rachel Maddow is #59437078 - Facebook: MrBean is #17774451468 Or maybe you would like to pick a site for me to check? The ID number (or GUID) is irrelevant. It doesn't matter if anyone knows it.

I've done that in a handful of cases where I needed sessions but wasn't sure if it had been started yet (and there wasn't anywhere that would authoritatively start them). It could be an indication of poor design, however.

Then that's the way you have to do it: unset whatever in $_SESSION directly. When you unset($msg) all you're doing is unsetting that variable.

You can't really do it. Not like that. What problem are you trying to solve? Why do you need to unset a value this way?

There is no 'B' anywhere in that part of the array so it is coming from somewhere else. Probably the array entry before the one you've shown. What does $selected_lender[36] look like?

Exceptions for invalid user input are your call. One way or another the API call will result in an error, and using exceptions to accomplish that is fine. Easy, even. I wouldn't use PDOException. That's an implementation detail that doesn't matter to the API, and has a (low) chance of changing in the future while not affecting the API. I would wrap it in a more generic exception, or else let it be caught by a general catch(Exception) block at the top of the call stack and have it cause a general 500 error. (Which implies that if you don't want a 500 for a certain database error then you shouldn't leave it as a PDOException.)

The issue is that file_get_contents doesn't work on directories - "Permission denied" is Windows' weird way of telling you that. If you want all files in a directory, and including the paths with the names, then use a simple * wildcard with glob(). glob($dir . "\\*")And note the escaped backslash since it's a double-quoted string. (Or use forward slashes.) The fact that "C:\php\Inventories\Json"worked without them is a coincidence: there are no \p \I \J metacharacters.

"C:\php\Inventories\Json" How many files or directories do you have matching that pattern? Exactly one.

Only if you have PHP 7.1. Since backtrace information is decided at instantiation and not when thrown (unlike other languages), you could do the less glamorous } catch (Exception $e) { if ($e instanceof PDOException || $e instanceof BarException) { $this->pdo->rollBack(); $rsp = $e->getMessage(); } else { throw $e; } }but for only two lines of code it's not worth the added complexity. That said, you should rollback the transaction for every exception, so I suggest changing your code regardless. Using a finally means you can skip the $rsp variable too. $e = null; try { $this->pdo->beginTransaction(); $this->doQuery(); return $this->doMethodWhichThrowsBarException(); } catch (PDOException $e) { return $e->getMessage(); } catch (BarException $e) { return $e->getMessage(); } finally { if ($e || !$this->pdo->commit()) { $this->pdo->rollBack(); } } Demonstration

I just realized: you included the form information in your post. You included it in your post. I've removed it because that level of naivete goes beyond our general "we don't edit posts" rules, but there's no guarantee (a) that someone hasn't already collected it or (b) that this page has been cached somewhere using a version before the edit. This is the time when you should sign up for an identity monitoring/protection service. And that is all I think we should say on this matter.

No, it's not an urgent matter. You can prioritize it below other things that are actively impacting your site. But next time you're in that code you should fix it. Actually, forget that last bit. It will take you seconds to fix (explode() for simple strings or preg_split() for regular expressions) so you might as well just do it now. And you don't get the warning in 5.3 because it wasn't deprecated in 5.3. :-\

Dude. That's the IRS. You don't bot the IRS. Good intentions or not.

Fix it now. If you don't you'll put it off until eventually you have to fix it, and that just means more work on top of what you'll already be forced to do. It also clutters your error log with warnings and you'll get in the habit of ignoring all warnings and that's really bad. Oh, and There are almost no warnings that can be ignored.

Unless you have a weird PHP configuration that's possible but one I've never actually seen anyone do (because it's so stupid) then data in $_SESSION is safe. But remember that sessions use cookies, so if a bad person gets a hold of a good person's session cookie then they could hijack their session. There's a lot written on the subject of session hijacking, but that's besides the point. Also consider that people using shared hosting are sharing the same machine with other hosting accounts, and since sessions are normally stored as files, it's possible (again, depends on the server configuration) for one of those other accounts to look at session data. Since it's safe, storing only the ID is fine. Storing the password is flat-out bad, regardless of hashing or encryption, and that applies to dedicated hosting as well. Speaking of, passwords should be hashed. Not encrypted. Hashing can't be reversed but encryption can be. Use PHP's password_hash/_verify functions for that. When a user wants to change their password, you should prompt them to enter their current one anyways - either through a secondary login screen (eg, "confirm your account") or through a confirmation box in the form. You should then change their session ID via session_regenerate_id(), which is actually something you should do on a regular basis anyways but is a bit more complicated than just that. As for catching the password change, that's a question for you. Do you want to boot a secondary session because the password changed on another one? I probably wouldn't. You can always give the user a sort of "log out all other devices"-type action; if that was in place then you would have to check the DB on every page load anyways.

Exceptions don't work well for a callback-oriented architecture (eg, using events) so making one for errors too is typical. However you can still use Exception objects as the callback arguments, then you can do the same sort of basic filtering that a catch allows: $object->on("error", function($e) { if ($e instanceof \FirstDesiredException) { // ... } }); $object->on("error", function($e) { if ($e instanceof \SecondDesiredException) { // ... } });

I would expect that it's typical to put objects into SplObjectStorage. With what you're doing now you're basically treating the class as a fancy type of array that allows using objects as keys.

Because phpBB was first created in the early 2000s?

The exception is thrown in parseBuffer, which is called during the socket's ondata event. Though that's defined in LengthPrefixStream's constructor, that's not when it actually executes. Instead that happens sometime during the run(). Rather than wrap the run() in a try/catch, which would necessarily terminate the run-ing in case of an error, have LengthPrefixStream emit an error event (instead of throwing the exception) and set up a callback for that.