requinix

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.

Don't have PHP create the config file. It will create it owned by whatever user PHP is running as (eg, www-data or nobody) and if you chmod it to 0600 then the user won't be able to edit or view the file. The user should create the file first, give it 0666 permissions, have the script make changes, then chmod it back to 0644. Or better, tell the user what to put into the config file themselves so they don't have to deal with permissions. Or still better, put a template file into the installation package and let the user edit what they need to.

Arrays are by-val so yes: you'd have to get, update, and set separately.

Depends. What username and password? What database records? You're describing something that is basically a CRUD (create, read, update, delete) system and is pretty easy to do - once you know all the requirements.

Then it's already been decoded into $newInfo. Try doing ->status on that.

That output is JSON. Are you doing a json_decode somewhere? That's the first step. It will return to you an array or object. Once you have that you don't need individual variables because you can do either $variable["status"] $variable->statusdepending whether you had it decode as an array or object.

Did you look at that link?

There are a few ways you can do this. Take a look at each of them, try them out, and see which makes the most sense to you and which has the best performance for your database. Two versions of two versions: subquery vs. no query and JOIN vs. HAVING. Subquery + JOIN SELECT sub.date, a.username, a.provider FROM assessments a JOIN ( SELECT MAX(date) AS date, username FROM assessments GROUP BY username ) sub ON a.username = sub.username WHERE sub.date <= CURDATE() - INTERVAL 6 MONTH Subquery + HAVING SELECT (SELECT MAX(date) FROM assessments a2 WHERE a2.username = a1.username) AS date, a1.username, a1.provider FROM assessments a1 HAVING date <= CURDATE() - INTERVAL 6 MONTH No query + JOIN SELECT a1.date, a1.username, a1.provider FROM assessments a1 LEFT JOIN assessments a2 ON a1.username = a2.username AND a1.date < a2.date WHERE a2.username IS NULL AND a1.date <= CURDATE() - INTERVAL 6 MONTH No query + HAVING SELECT MAX(date) AS date, username, provider FROM assessments GROUP BY username HAVING date <= CURDATE() - INTERVAL 6 MONTH

Think about why it isn't working. When does the while loop end? Yes, I know, when there are no more messages in the result from the query, but technically speaking when will the loop end? That's why you can't use $message. And the $counter thing won't help because it does output up in the divs when you need the data down in the reply box. You're ordering the messages in chronological order so the last message processed will be the most recent and the one the user is logically replying to. Try changing your loop so that the problem with $message doesn't happen.

So notes is 0 or 1? Add it to the list of columns returned by the query and add it to the list of columns grouped by the query.

So many people have reported that behavior as a bug in PHP that we added a big red warning in the documentation. It still amazes me how many people don't RTFM.

You can't know who (or what domain) is accessing the file. You can give each site a unique key that they can put in the URL like /path/to/file.xml?key=abcd123then use URL rewriting to turn that into a PHP script RewriteRule ^/?path/to/file\.xml$ path/to/file.php [L]and use PHP to check the key and output the XML if it's allowed. <?php if (!isset($_GET["key"])) { header("403 Forbidden", true, 403); exit; } $key = $_GET["key"]; // validate $key if (/* valid */) { header("Content-Type: application/xml"); header("Content-Length: " . filesize("file.xml")); readfile("file.xml"); } else { header("403 Forbidden", true, 403); exit; }