Antonio Conte

What's the use case here?

No problem, and thank you very much.

Picking up this. Did you include anything on MongoDB? I'm strongly considering using NoSQL for a new project.

Download other plugins an look at that code. It's a lot of aweful WP plugin code out there, but at least you might be able to understand what to do. I would recommend you to read about hooks. Maybe the most important thing for understanding how to develope plugins.

I agree with those that say the mobile version could be improved a little. Very much white space in the header. Also took me a long time to locate the navigation. Maybe some text along with the icon would help? Not really sure how to improve that. Besides that, I think it looks great. Even better on a PC.

Documtation is pretty bad. I jumped between sources until I'd found what I needed. My suggestions would be to use native code when possible. That'll make it easier to update, port to other solutions etc. I don't think you'll gain much from looking at my plugin as it not integrated into WP per se. All it does is working as a gate keeper for new comments. Good luck.

One thing: sure you need login here? A lot of these free upload sites don't require it. Check out bildr.no.

Nice work

Just a little trick I've learned in Java. If you don't need to work with numbers, use Strings as they tend to be more reliable. Using a char type might be a good enough solution here. If you can't find any problems saving them as char, I'd say stick to it.

Assign the result of get_password_hash($p) to a new variable before the query. Right now, you are just passing in a string. $hash = get_password_hash($p); .... mysqli_stmt_bind_param($stmt, 'sssssiiss', $fn, $ln, $sa, $c, $st, $z, $ph, $e, $hash);

Build it on github. Would be cool to be able to take a look and maybe fork it, offering push comits.

I'm guessing YII allow you to add your own helpers/libraries? Why not find some code/develop and implement it into YII? I think you are over-thinking this one. Without having used YII before, I see they have helpers, modules and some other stuff. I don't know what's recommended, but building a static helper class (helper) might be the best thing here. Pass on a user avatar, possibly save the changed one, then return it back to you. Changing the avatar could possibly also be a module that allow a user to change their own avatar using some kind of settings. That way, you don't tie the changing of images too your system to much. I have really never worked with YII, but these are solutions I would've considered myself.

Very interesting. Bookmarked. Also looks like my guess about email tokens was pretty good. One argument though. The importance of keeping the data safe should affect your choice of hashing algorithm. I see some of these hashing functions has some many round times per hash creation that a page will take 4-5 (someone up to 20) seconds to render. Those won't make it for most people.

No limits to the nesting of categories? Read about recursion. It's the perfect match for that job. It's a little hard to grasp, but not very tricky once you get it. It's also seriously powerful compared to array solutions for those kind of jobs. The best thing about writing your own framework is realizing what you like and dislike. The feeling of developing "the perfect class" that follow you from project to project is very good. I think my MySQLi wrapper is pretty damn solid myself, but that's because I hate how the standard MySQLi class works. I also love to have some static classes hanging around for the dirty jobs. Things like filtering, validation and error messages. This is very common in Java, but I don't see it used a lot in PHP. Because of this, I like some parts of my framework good while other parts are genuinly crap compared to frameworks like CodeIgniter or Yii. There's really no problem extending core functionality in eighter though, so I like being able to get things how I want. The experience you get is invaluable, though, so even if you sweat some blood, you know much more than when you started. Good luck. Keep us posted.

I want to make a joke about the bug monster here, but I'm way to mature... Just to contribute a little bit, a lot of bugs occur because your logical checks are not strong enough. Notice how Jon used "ajax.readyState === 4" here? The last equal sign tells JS to perform a test on type too. It's those sort of things you need to be careful about. A lot of PHP functions might also return a VALUE equal to false, true or null. That's why you see some of the documentation tells you to use the === check for those. Both PHP and JS are weakly typed, so it's our job to make sure we get the type right.

Inside XAMPP. I use it as a development server and upload to a normal server when I'm satisfied and sure the code is working as expeced.

The image is probably saved as a normal file, while only the path to the image is stored in the db. This solution will allow you to link to a thumbnail too. (another column for thumbnail path) Another possiblity is storing the thumbnail with something like a "t" (for thumbnail) at the end of the name. For example 3453432t.jpg. (thumbnail of 3453432.jpg) The last version is very good if you also create thumbnails of an uploaded image automaticly or through an user interface.

You can use a shorter syntax called the ternary operator. It has three parts. The expression, the true value and the false value. The expression is the if-statement, the value/variable after the question mark is used if the expression is true, and the value/variable after ':' is used when the expression is false. // Basic $var = isset($_GET['var']) ? $_GET['var'] : false; // Validation is also fine $var = isset($_GET['var']) ? mysqli_real_escape_string($_GET['var']) : false; // You can use several expressions too $var = ( isset($_GET['var']) && is_numeric($_GET['var']) ) ? 'This is a numeric value' : 'Not a numeric value'; You can even develop a function for this. Let's take an example with Integers. $var = get_intval($_GET['var']; // Returns value if it's not null, else false function get_intval( $var ) { return ( $var != null && is_numeric($var) ) ? (int) $var : false; }

I think that fits under "all that other info", Jon. That's how I understood it. I agree, though. Look at Spotify/iTunes etc so you don't miss anything, TS. It's really alot you can chose to save. Albums, track number, related artist, similar albums, song ratings. Pretty endless.

When you should use enum? If you ask me, almost never. They can be great if you have a fixed number of items. A traffic light is therefor a good Enum. Gender, as you describe is also perfect. Another thing is cardinal directions. Enum stands for Enumeration. It means that every possibility inside an enum will have a number associated with it. It's basically a static, non-changing reference table internally. (enum_number, enum_choice) If your choices can ever change, enum is bad in my thoughts. Why do you want enums anyway? What's so great about them? By alternative four, I was thinking this: songs ( song_id, name, main_genre ) genres ( genre_id, name ) song_genres ( song_id*, genre_id* ) This makes "genres" a reference table. It's in my head a better solution than Enum because the choices are not fixed. A have taken several database courses in my programming education, so just trust me on it when I tell you it's the best solution. I can't really force you down this road, but it'll make your life easier in the long run... (This is "the correct way" if you look up normalization rules. Larry writes about it in some of his books. Maybe the one for this forum.) ... If you for any reason just HATE my solution, save genres as a JSON String or another CSV String in the songs table, then parse it with json_decode when using it. This will create an array in PHP you can manage normally. When you save again, use json_encode on the array to get a JSON String. It could be a viable solution as it's flexible, but I don't recommend it. If you want users to search songs by category f. eks, this might give you some problem. ("Rock&Roll", Rock and Roll, Rock 'n Roll", etc - Same category, different spelling) Everything in table design is compromise and picking the solution that best suits your need. Take your pick, but think about the fallpits first if you don't choose "alternative four".

It really depends on what you're after. Songs can definitely be in more that one music category, but most of the time, you can call it X. What really depends is what you like to do. One music genre per song or possibility of several genres per song? Regarding your question, the first possibility to rule out is number 3. This is because an Enum is to hard to maintain during development. What defines a genre? Music is vague, and genres are often discussable. Some song even makes new genres. What then? It's definitely possible, but It's not a good solution in my mind. Number 1 and 2 are better solutions. What you pick is really dependent on how you want your system to be. Number one only allows one genre per song. Number two allows several, but may be harder to write queries to. Once you got the query down though, it's really only a question of preference. (And they shouldn't be THAT hard to write.) I would personally go for number two or number four, witch I will state here. Create a main genre per song. This genre will be stored inside the song table along other info. You then make both a genre table (you called them styles) and a song_genre table. (which will store song_id and genre_id) This way, you'll be able to display a main genre, several genres (including the one in the song table) altogether. What you choose is really up to you. I think both solution one and two are good. Read my post and determine what your needs are first. Number fire (mine) is of course a combination of your solution one and two. Good job, btw. This table design sounds well planned.

Jon, I often miss things when it comes to JS, but I need to ask this: Secure login and cookies? How does that make sense? Do you validate the cookies against sessions, a query result or something else per request? I ask because it may be a security hole you didn't think about there, or something I need to learn learn. Again...

Yes, that should do the trick. I see no problems there. Maybe a strip_tags() should be applied though. I recommend you to read up on XSS attacks when possible, but at least your DB is secure now. (The problem being that inserting HTML tags like <script> is possible) One step at the time. Prepared statements are generally preferred as they make SQL injection impossible. They are a bit tricky in the beginning, but you should really get the hang of it pretty quickly. With proper validation, like you have applied here, prepared statements and normal queries are pretty much equally secure. The benefit of prepared statements is that they won't work without a comparable validation to what you've applied here. That's really the strength of it. I think Larry does prepared statements in some of his books. There should be more than enough examples online to learn it though. I wouldn't rate it as a priority, but it could definitely be learned pretty quick if you wanted to.

I missed your hash question. I don't think that part of the URL is a password hash. I think it's more of a token the site should look for. When a user is requesting a new password, a random value is generated and the username, random value and probable a datetime "now" is inserted into a different table. The link is emailed to the user, and if the reset_password token is 01b304a2-cb8d-4c4f-9468-8d3fbda3c0fe (as in the link, the username is "exampleusername" (as in the link) and the current datetime is less than 10 minutes larger than the datime in the table, A match is found in the reset password token table. If this match is found, the user is allowed to change their password. This makes it more unlikely that someone should be able to change the password. NOTICE that I'm just guessing now. I don't really know if this is a good approach or not. Mind giving us your thoughts, Larry? After all, I'm working on the exact same thing myself.

You should just generate a random clear text password first. I would then mail this to the user. When this is done, run the hash function on the text password and save the hash to the DB. I'm working on creating this functionality for my own site right now.