Ofarchades

His proposed schema would not be scalable, but it's by no means "incorrect" or broken. In any case, in the previous two replies we already discussed the addition of a pivot table as you subsequently suggested in your post.

I could be wrong, but I think you need to change if (($username == $db_username) && (password_verify($db_password, $hash))) { to if (($username == $db_username) && (password_verify($password, $db_password))) { Where $password is the plain text password as posted from the login form - and $db_password is the hash stored in the database.

More RAM would be redundant because any decent text editor/searcher(?) will load the file in chunks. Glad you found one that does so. Out of pure curiosity, what are these files that are so large? Especially source code files. That seems unusual.

I've only skimmed the code as I'm exhausted and about to go to bed, but is it possible that the code which updates the quantity comes after the code where the quantity is displayed? Try moving the update logic to the top of the script.

The comparison is weird because it evaluates as true despite the hashes being different. This actually works for any string beginning with "0e" due to the fact that PHP will convert them to 0 internally. There's also the fact that the integer 0 will return true when compared to most* strings (e.g. 'test' == 0) because PHP turns this into an integer comparison and typecasts the string to an integer (which results in 0). * I say "most" strings because some strings will be typecast to different ints e.g. '2test' would become 2 and therefore '2test' == 2. I'll use == myself in cases where security isn't a concern or I can be certain of what the values can and can't be, but otherwise it's probably better to just not gamble with PHP's bizarre internal magic.

You're right about the foreach - and as I mentioned in my reply, he shouldn't be doing any sort of string comparison between two hashes. However, you can never trust PHP's == string comparison to work as you'd expect; there are plenty of documented cases where it will return crazy results (such as the famous "md5('240610708') == md5('QNKCDZO')" scenario).

Are you sure? I can't see any obvious reason why it would do that. Would you be able to post all of the code for that file, in case there's a problem elsewhere? Other than that, I have a couple of advisory notes regarding how you've approached password hashing. 1) Your salt isn't very strong. Check the PHP documentation on how to create a bcrypt salt, for example. 2) "$cryptPass === $db_password" is vulnerable to a timing attack. If you're able, it may be better to check out the password_hash and password_verify functions added in PHP 5.5. Otherwise, strengthen the salt and look for a time-constant method of comparing the hashes (e.g. hash_equals).

You probably won't have much of a career if you refuse to change with the times. Of course it's important to know the difference between trends that are practical and those that are just fashionable and corrosive, but frameworks and CMS and code reuse are all pretty important if you want to be an effective programmer. Laravel has definitely become quite bloated, but you don't need to use the whole framework; you can pick and choose which components you want to use in your project, much like Symfony. There's even now a Laravel-based microframework called Lumen. Maybe give it a try.

Using military time is a nice idea. You could have a pivot table linking the users to their groups instead of having the group_id column on the user table. It might look like: pkid (unsigned int, primary key, auto increment), user_id (unsigned int), group_id (unsigned int) Index user_id and/or group_id depending on what sort of lookups you'll be doing. So far this is a fairly standard relational database design. The idea of these databases is to link related information. As long as you don't make any crazy mistakes with the queries, it should be fine.

I just tested it. Like I said, change if (file_get_contents($site_a) !== FALSE) $image = $site_a; else if (file_get_contents($site_b) !== FALSE) $image = $site_b; to if (@file_get_contents($site_a) !== FALSE) $image = $site_a; else if (@file_get_contents($site_b) !== FALSE) $image = $site_b; and it works. Also the code I posted earlier would have worked, but it was missing an opening brace that I wasn't able to see because I wrote it in this site's edit box. You should have easily seen it in your code editor, though. You are using a code editor... aren't you? Anyway, as mentioned before, you don't really want to call both file_get_contents and imagecreatefrompng because that means the image will be downloaded twice from the remote server. Instead, try: <?php //// BEGIN CONSTANTS //// // coordinates for the skin's face $face_x = 8; $face_y = 8; $face_width = 8; $face_height = 8; // coordinates for the skin's "mask", i.e. the layer that is overlaid // on top of the face $mask_x = 40; $mask_y = 8; $mask_width = 8; $mask_height = 8; // size of the output image $avatar_width = 96; $avatar_height = 96; // The default skin. All hail Steve! $default_skin_url = 'http://halcyon-pvp.fr/dl/img/char.png'; //// END CONSTANTS //// if (isset($_GET['user'])) { $user = $_GET['user']; $skin = @imagecreatefrompng("http://halcyon-pvp.fr/skins/$user.png"); if (!$skin) { $skin = @imagecreatefrompng("http://skins.minecraft.net/MinecraftSkins/$user.png"); } } if (!isset($skin) || !$skin) { // If skin could not be retrieved, display Steve $skin = imagecreatefrompng($default_skin_url); } // Set up a blank image to write to $avatar = imagecreatetruecolor($avatar_width, $avatar_height); // Resize and overlay the face region, as defined by the constants above imagecopyresized($avatar, $skin, 0, 0, $face_x, $face_y, $avatar_width, $avatar_height, $face_width, $face_height); // Resize and overlay the mask region imagecopyresized($avatar, $skin, 0, 0, $mask_x, $mask_y, $avatar_width, $avatar_height, $mask_width, $mask_height); // Finally, return the processed image as a png header('Content-Type: image/png'); imagepng($avatar); imagedestroy($avatar); ?> Alternatively, you could keep the existing file_get_contents code, but save the result to a variable and pass it to imagecreatefromstring. The only problem with that is that imagecreatefromstring uses more memory.

If you're able to install it on your server, I find wkhtmltopdf to be a good solution.

Would you be able to post all the code you currently have? I can't see any reason why the code we've posted here wouldn't work; there has to be something else going on.

Ideally once we've established what he's trying to achieve, we'd want to get him to change it so that the image doesn't need to be downloaded twice (once for the file_get_contents/whatever and then again for the imagecreatefrompng) i.e. store the result in a variable and pass it to imagecreatefromstring. At this stage, I fear that may just cause more confusion than there is already.

What do you mean by this? With the other code, the warning is being thrown by the first file_get_contents not finding the file. Try adding @ before the function calls, I guess.

I'm going to guess that what you're trying to do is something like... if (isset($_GET['user'])) { $user = $_GET['user']; $skin = @imagecreatefrompng("http://halcyon-pvp.fr/skins/$user.png"); if (!$skin) { $skin = @imagecreatefrompng("http://skins.minecraft.net/MinecraftSkins/$user.png"); } } if (!isset($skin) || !$skin) // If skin could not be retrieved, display Steve $skin = imagecreatefrompng($default_skin_url); } ? (I feel like there's so much wrong with all of this code, but I'm just going to let it slide )

It may be beneficial to identify what it's not doing that you'd like it to be doing?

Learn both? If you're already working in the web domain, there's a chance you'll come up against Java in some form or another e.g. Android, applets (they still exist), Java-based web services such as Solr, Tomcat, etc. C/++ will give you a feel for lower-level system mechanics and contribute to your overall technical understanding (which is in itself useful, albeit rarely). The only likely practical application of C for a PHP programmer would be extensions for or modifications to the PHP engine itself. If you're thinking of branching out to another career entirely, C and especially C++ will require a lot more commitment to reach a stage of proficiency where you could hold your own in a professional environment. Java slightly less so.

Why? Sincere question. This sounds like the beginnings of a programmer getting stuck in a rut, refusing to adapt to the evolving ecosystem and workflow. Sincere statement.

Definitely don't create a table for each day of the week. Without knowing the specifics of what you're trying to do, try something more along the lines of: users: user_id (unsigned int, primary key, auto increment), [everything else] availability: availability_id (unsigned int, primary key, auto increment), user_id (unsigned int, indexed), day (unsigned small int), hour (unsigned small int), preference (unsigned small int) (Alternatively, the availability table could have an "hour_from" and "hour_to" column instead of just "hour") ((Feel free to add more indexes depending on your query requirements)) Then for each day and hour (or hour range) the user is available, create a row in the "availability" table. In the future, you could perhaps change the "hour" column from an integer to a decimal to allow for quarter or half hour measurements. Do you think this would work for your purposes - or have I missed something?

Does your 15-digit ID really need to be the ID - or can it just represent the ID e.g. when displayed on screen? It's generally advised (for all sorts of reasons) that IDs should be numeric and incremental. For example, some storage engines (such as MySQL's InnoDB) will physically organise the table such that primary keys are sorted in order. This means that if you're using non-sequential primary keys (which a base36 string would be), the table needs to be reorganised every time you enter a record - which could be a performance concern. If I were you, I'd just have the ID be a regular integer in the database and have some logic in the code convert between the integer and your desired base36 format. Regarding rollbacks: I don't think any DBMS will rollback incremental IDs. For example, if you create a row in MySQL and it's given an ID of 3, then rollback and create a new row, the new row will have an ID of 4, not 3.