It's an interesting exercise, although the first downside I noticed of the "one file" mantra is that all of the CSS is served inline in every response.<p>Also, you may want to consider handling MySQL errors in a manner other than just printing it to screen along with the query. At the very least, log them somewhere where you'll be alerted of the error. As a user, seeing "MySQLi Error: [...]" doesn't help me or you.<p>It'll be interesting to see if you continue the project and how far you take its functionality. Some of my co-workers were just today discussing the tendency to want to rewrite a system from scratch in order to simplify it and avoid any problems with backwards compatibility, only to slowly find yourself rewriting the "unnecessary" features from which you were trying to escape.
Your brute-force protection is:<p>a) bypassable (by simply not sending a session cookie), and<p>b) exploitable to DOS your server (PHP processes are single-threaded so sleep() is basically just a blocking call) - I could just bombard your server with a bunch of login requests to eat up all of the connection slots that end up sleeping for a very long time. You can't serve legit traffic when all of your PHP workers are off sleeping for six hours.
This is scary. All in one file. PHP. CSS/HTML/PHP all in one file.<p>I don't mean to be a jerk, but what problem does this solve, or was it simply a personal challenge/adventure?<p>edit: Some of this is answered on the GitHub page. I guess I'm going to be concerned if someone is worried about how to unzip a file on a server...