Antonio Conte

Make a script of this. It will allow you to see hash lengths for all hashes. <?php $data = "password"; foreach (hash_algos() as $v) { $r = hash($v, $data, false); printf("%-12s %3d %s\n", $v, strlen($r), $r); } ?> sha512 requires 512 chars for hashes. You may notice this is the double of sha256. 32 chars for sha256 is simply not enough as it produces larger hashes. More than that, I don't know.

Looks like it should work, but you are forgetting to escape data again. All queries that includes input from a user MUST have it escaped. The problem is SQL injection, which is a serious security hole. Right now, I can easily delete your user table.

Looks good now. Good work. Btw. mysqli_escape_string is just an alias of mysqli_real_escape_string(). I would learn to use the one with "real". Just a general suggestion.

Move mysql_real_escape_string() before the first query. You have an injection security hole there.

You must use selected="selected", not just selected.

Did not now what. You learn something every day.

Looks good. Escape $email before the first query instead, though.

My post was merely meant to help you. Sorry if you feel stepped on. The problem is; how does this thread spark discussion? How does it enable me to be a participant in the conversation? Good threads always makes this possible. They have a defined topic that lets users discuss and exchange experiences. You can share your experiences, but broaden the topic and let others contribute to the thread. You'll see you'll get much more replies on your threads this way. And that's kind of the point, right? Creating discussions? Just my two cents.

Dude. Stop making new threads like these. A thread should have discussion potential, or at least be a question, not just stating information. If you asked for other peoples tricks/secrets/etc, there would be discussion potential, but there's really non here. This would be a viable post in a general DB/mysql thread, but not a thread in itself.

Save passwords as Char(64), not Varbinary(64). Also, I hate regular expressions. Use the filter extension or other validation functions like the ctype class when possible. (My own view, others might not agree) The main reason is that writing good regular expressions are hard. Using other functions will make your code cleaner and also not that case-dependent. Your regular expressions are only good for a single use, while a function like validate_string_length($string, $min, $max); will be usable also other places.

I would just try exporting the DB and try to import it at the other host. If everything worked ok, move on to coying files over. When everything is working correctly, you make the switch. ( Permanent redirect through .htaccess for example) It's possible to remote connect at my host at least. (I connect to that server from localhost when developing) I would guess this is possible also elsewhere. Just make sure you get the hostname correct as "localhost" obviously won't work when connection remotely.

Done is better. I absolutely agree on that. I'm a little too much of a perfectionist myself, which is why a lot of the things I start on doesn't get finished. I therefor started to ask "What's good enough" instead "what would be perfect" some time ago. Compromizing is important. Build something that works, then improve. Keeping todo-list or adding something like @TODO-comments in your code is good for this. About usernames. Use strlen() to check for a minimum value. Performing checks against curse words is a lost cause. I wouldn't implement that simple because it's a pretty tricky thing to do. Simple time-waster. You should also check passwords to make sure they are of a certain strength. (at least one number and one caps is pretty usual for example) I see you build something in OOP and something procedural. To keep code redudancy to a minimum, develop simple functions that suit together and place them in files that you include. These files could easily be transformed to OOP code later on, too. Developing some static classes for Validation/filtering is also a good thing that will reduce a lot of code. I would wait a bit with a framework. Looks like this is starting to go somewhere. Don't waste a lot of time moving into YII. Finalize something before you do that, then begin on Version 2.0 Super Improved. Good read. Keep up the good work. I'm guessing most people are here to ask about problems. You might consider starting a blog instead to increase the number of readers. Just a thought.

First time? Really? Good code. I'll keep reading. Keep up the good work.

You are right. There's only three types. Integers, Doubles, Strings and Blobs. Most types, except numbers, are really String. Both null values "" (empty string) and "Now()" are Strings.

This is cool, Edward. Enjoy reading your thoughts along the way of development.

Thanks, Jaepee. Have done some redesigns on those sites over the years, and I can tell you now, they weren't that nice in the beginning. I'm not really much of a designer. The best thing I've done is the logo at juvenorge.com. Really proud of that one. Looking forward to see your projects.

I would get all rows. (assuming you don't have a huge amount to select for ) I would then store all rows in a session array, and randomly select from that. Only my two cents.

It's because you only allow letters from a-z in your preg_match() regular expression. As a general suggestion, filter more than do validation on Strings. You can't really force how the user should write input except when there's a strict pattern (and that's rare). Things like short names for states "NY (new york) might be possible, but still tricky. Using mysql_real_escape_string(), strip_tags(), trim() and other filter functions to prevent injection of script tags and prevent SQL injection is really the best thing to do on strings. Other than that, leave the user free to send in something silly, simple because it's impossible to guard against. If you really need to force certain charachters, I would suggest something more like the ctype functions. http://www.php.net/manual/en/ref.ctype.php

Just one general suggestion, Marie. I see you use preg_match() for pretty much everything, even for things like currency, etc. It would be better to deploy some other functions for validation there, like is_numeric() and checkdate() for dates. There's really not much point in using preg_match() on regular strings like location either. What happens if I try to type "Lillestrøm", my home town, in there? As a general tip, validate against data that will break your application. Just make sure it's safe to use in the right context. (For example in a db) Not data submitted by an idiot. There is not really any way to screen away foolish input from a user.

Could possibly be a cache thing if it works now. Make sure to delete your cache before testing again. Use CMD + SHFT + R on Mac, and CTRL + F5 on Windows. This will in most cases bypass the cache and let you see load the update script.

As long as you are able to include a file, it's usable even though unreachable from a browser. It's more normal to place the configuration details outside the web root than a connection script. Non of this is really "insecure". I would just make sure error messages are not displayed on the server.

Search on YouTube. Some good videos about using jquery validate there.

This CSS inside a stylesheet/style element on the page, should give you the largest map possible. It will fill the screen vertically, but only about 70-80% horizontally. (At least at my setup) It might have something to do with your input element. I don't know. #map { display: block; min-width: 100%; width: 100%; min-height: 100%; height: 100%; }

CSS and PHP are generally divided into the loose categories front-end and back-end programming. They are usually done by people with different jobs, following that each job generally is done by different sides of the brain. The ones with a more active left-sided, logical parts, is generally the programmer. The right sided, creative ones is more often doing design and therefor also CSS. This is a very general statements on my part. (And I don't mean to offend, only explain) While many do both, they are not related per se. This is also the reason while patterns like MVC is generally preferred inside larges companies. It allows programmers, designers and database experts to develop alongside each other. Because each job requires different skills, and specialization is preferred in each field, it allows you to dive the parts in development. This is also why you see little CSS/design in programming books. They are different fields, and books have limited space. I would instead recommend you to find books about CSS/Html to learn about this. Hope that makes sense. It's hard for me to explain such topics in English and keep track of the nuances. As I said, I only mean to explain.

Sorry. English is not my first language. Sometimes I mix up words. Object Aggregation is more what I should describe what I'm thinking. A User handles authentication to the system, access levels, and other privileges. Each Member must have a User. The Member is not an extended version of the User. This is because the User should be able to continue to function and exist even if we remove the Member data associated with it. Being a Member, in our setting, does not affect access levels or other privileges. They will only allow you to edit personal information and apply for match tickets. In part, they are both valid entities. In our setup though - a Member cannot exist without a User. The Member makes no sense alone, as login (aka a User) is required for changing personal Member data. Should a User decide not to be a Member, other parts of the system should still be available to them. Taking all this info into account, (hope you makes sense of it) do you feel I'm correct when I want Member data as an aggregation to the User object? If this was Java, I would definitely go for a static private inner class. Does that sound right to you?