At 8/2/16 09:22 PM, egg82 wrote:
Why did you have to post this a day before my vacation D:
That's how I roll.
At 8/2/16 09:22 PM, egg82 wrote:
The reason for the encryption is to make a database dump just that much harder to muddle through. Obviously the keys are still there (actually I'm now thinking about setting the keys to some hashed form of the user's password. That sounds like a fantastic idea. Can't hurt, anyway.)
My point was that it's already difficult to muddle through due to the hashes. Encrypting a hash is just not really accomplishing anything.
At 8/2/16 09:22 PM, egg82 wrote:
I'll look into more openssl functions for encryption. I'l also look into turning the backend database file into more of a wrapper for PDO than anything else. When I originally created it I wanted it to work exactly like the old mysql functions for easier migration. Now that's passed it makes more sense for it to be its own thing.
I'd try not to go overboard with making a PDO wrapper. By itself, it can do pretty much anything you would need it to. It can take some getting used to if you're accustomed to the mysql_ functions, but it makes life a lot easier. Most ways you're likely to fetch data can be done with a single line. Such as returning a single value, not an array:
$stmt = $pdo->query("SELECT Username FROM Users WHERE id = '5' LIMIT 1;");
$username = $stmt->fetch(PDO::FETCH_COLUMN, 0);
Or, if you want to fetch multiple rows and have the value of one of the fields be the array key:
$stmt = $pdo->query("SELECT Username, Email, Name FROM Users;");
$users = $stmt->fetchAll(PDO::FETCH_ASSOC | PDO::FETCH_GROUP);
foreach ($users as $username => $info) {
echo "$username's email is {$info[0]["Email"]} and their name is {$info[0]["Name"]}.<br>";
}
Whatever the first column being selected is, that will be the key. Having a column with repeated values will just append the array that the index refers to, which also means that a column with just one value will have a one-length array. You coul add PDO::FETCH_UNIQUE to the fetch type if you had multiple values but only want one of them. (It will end up selecting the last row with the repeated value.) Using PDO::FETCH_UNIQUE will also mean you don't need to fart around with two-dimensional arrays:
$stmt = $pdo->query("SELECT Username, Email, Name FROM Users;");
$users = $stmt->fetchAll(PDO::FETCH_ASSOC | PDO::FETCH_GROUP | PDO::FETCH_UNIQUE);
foreach ($users as $username => $info) {
echo "$username's email is $info[Email] and their name is $info[Name].<br>";
}
A lot of PHP is utter shit, but PDOs are actually pretty good. Definitely worth reading up on them.
At 8/2/16 09:22 PM, egg82 wrote:
Sadly MVC isn't really my thing. If anyone wants to help turn it into MVC once I'm done modifying it later, that would be really great?
MVC is pretty simple when you get down to it: just separate your application into three components (i.e. the models, views, and controllers) that have their own specific purpose.
Your controller is basically the brains of the operation; it is where requests get sent, and it decides what to do with them, and validates them; it's also what communicates with the models and views, as models and views should never communicate with each other, only ever with the controller.
The model is where your SQL operations go; so, if you want to log a user in, you would have the controller receive the login request, validate that a username/email and password has been sent and that they don't appear to contain malicious data, send that off to the model, which will respond to the controller if the login succeeded, and the controller will pass that result off to the view. Pretty much any reading or writing operation, regardless of where it is reading from or writing to, goes in the model.
The view is just a representation of the current state for the user to see. Sometimes having a view by itself is not necessary and can be put directly in the controller. (But it's still generally a good idea to not be lazy and put them together, especially for something being used in production, lest you create more work for yourself down the road.) So, if you were using a template engine, such as Twig—and you really should always be using a template engine for web development—your view would handle rendering the correct template and passing it the correct parameters. (The parameters would be given to the view by the controller.)
Just break things down so you're not mixing operations together. It makes it far easier to work with and change. Having your reading/writing operations in the model means that those bits of code don't care what that information is being used for; it just does it's thing and returns the result. It makes re-using code a hell of a lot easier.
