requinix

Without looking at your code, if you're getting that date it means that the "timestamp" value you gave to some date function (like date() or strtotime()) is invalid. Or very small. Like date("Y-m-d H:i:s", "September 4th 2012, 12:30 am") // 1969-12-31 HH:00:00

Ooh, they greatly improved it in 5.3. I'll have to check it out again.

You can put FORMs outside TABLES and inside TDs/THs. You can't put them (directly) inside THEADs/TBODYs/TFOOTs or TRs.

I've written a couple command-line-parsing functions, none of which I have on hand to demonstrate. If you want to write one it depends how much support you need from it (because there are a few possible styles to choose from - I want to say GNU, POSIX, and BSD?). At a minimum all you need is if (in_array("-h", $argv) || in_array("--help", $argv)) {

Two teams: the developers and the database administrators. - Developers tend to keep them as actual files and store information (like path and type) in the database. Makes things easier for them and less strenuous on the database. Files can easily be served by the webserver too, which means caching and typing and all that additional work is done automatically. - DBAs tend to keep everything in the database. Backups are easy because all you have to do is replicate the database - which you should be doing anyway. I'm not good at presenting the advantages of this because I don't subscribe to it.

I'll bet you a fair amount of money that's not a SELECT but rather a DIV/OL/UL styled to look like a drop-down list.

It's fine that you're learning PHP but at some point you have to try to figure things out yourself. It takes like, what, 5 seconds to make a change and test it out? I've told you what you're missing and PHP has told you that it found something unexpected. Any guesses as to what it was expecting?

You're missing a closing parenthesis.

Uh... Yes? POST, GET, some stuff in SERVER, COOKIE, raw posted data, third-party API calls... To name a few. Basically anything you didn't generate yourself.

Both input and output escaping are about making sure that the data doesn't conflict with surrounding syntax or markup: - SQL injection is when input data mixes with query syntax - XSS is when output data mixes with HTML markup - (Email) header injection is when data mixes with email headers In between input and output (after you've cleaned up the input and before you've outputted it) the data should be exactly what was provided. You should not be escaping stuff until the moment you need to. Example: $name = $_POST["name"]; // O"Reilly $name = htmlentities(mysql_real_escape_string($name)); // O\&Reilly $email = $_POST["email"]; // user@example.com $email = htmlentities(mysql_real_escape_string($email)); // user@example.com mysql_query("INSERT INTO users (name) VALUES ('{$name}');"); // O&Reilly $message = "Thank you for registering on our site, {$name}!"; // Thank you for registering on our site, O\"Reilly! echo $message; // Thank you for registering on our site, O\&Reilly! mail($email, "Welcome to our site", $message); What you should be doing is something along the lines of $name = $_POST["name"]; // O"Reilly $email = $_POST["email"]; // user@example.com mysql_query("INSERT INTO users (name) VALUES ('" . mysql_real_escape_string($name) . "')"); // O"Reilly $message = "Thank you for registering on our site, %s!"; // Thank you for registering on our site, O"Reilly! printf($message, htmlentities($message)); // Thank you for registering on our site, O"Reilly! mail($email, "Welcome to our site", sprintf($message, $name));

Make it only rewrite if the requested file doesn't exist. Before the RewriteRule put RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d

Depending on the page there could be easier ways of doing it. If it's well-formed HTML then you can read it through DOMDocument. For instance, with Server Status: Server is currently up and private you could do a getElementById("server-status") to get that TD node. More complicated would be a getElementsByTagName, and worse would be manually traversing the hierarchy (ie, through childNodes and such). But IMO all three are preferable to regular expressions.

execute does not take any arguments. You have to call bind_param first. Problem is bind_param() needs values by reference so you can't just call_user_func_array() it. Needs a little more: function prepareQuery($statement, array $array = array()) { $dbConnectTrue = $this->dbLink(); $dbqueryPrepare = $dbConnectTrue->prepare($statement); if ($array) { $copy = array(); foreach ($array as $key => $value) { $copy[] =& $array[$key]; } call_user_func_array(array($dbqueryPrepare, "bind_param"), $copy); } $dbqueryPrepare->execute(); $queryFetch = $dbqueryPrepare->fetch(PDO::FETCH_ASSOC); return $queryFetch; }

Sure: they're not special either.

1. All of them except the hyphen can go in directly without anything special (except having to escape the quote for PHP). The hyphen needs to go in a place where it can't act as a range separator; easiest way is to put it at the beginning or end of the set. 2. \w includes letters, numbers, and underscores. [^\w?'"-]

Right. My point was that you can use that subdomain just fine so long as it resolves to and ends up at a second installation of Apache (of whatever version you want). Don't need to bring in something else.

You can keep the same name - you just need a different installation of Apache.

Unless you have SNI enabled in Apache and have a browser modern enough to support it (which I believe almost all of them do by now), there can be only one website served through HTTPS. In your case that would be your "root domain". Best option is to get SNI working, but you need Apache 2.2.12+ and control of the server and/or software. Otherwise you'll have to emulate the subdomain through mod_rewrite.

If it's your framework... well, even if it wasn't... then debug through it as it tries to serve one of those URLs. Figure out why it thinks they're valid and fix it.

What framework does the site run on? Did you make it yourself? Can you find out where the spider is getting those URLs from (ie, the referring page)?

Just like how they'll never remove magic_quotes or register_globals because doing so would break a lot of code too. Oh wait. Number of bytes. That big difference there is what confuses people the most.

There is one case when you should use htmlspecialchars(): in XML. htmlentities() will create strings that are invalid for XML without you jumping through hoops. Meanwhile htmlspecialchars() will escape exactly the right characters that should be escaped.

And?

In your database track (1) the last time they did something (eg, browsed a page, sent a chat message) and (2) whether they have specifically logged in or logged out. To see who is still logged in do a search based on those two fields. Decide how long it takes before a user is automatically "logged out"; for example, if a user is logged out after 15 minutes of inactivity then query for: ...WHERE last activity field -- if you named the fields "last_activity" and "is_logged_in" then maybe ...WHERE last_activity Usual disclaimer: there are many ways to do this and the above is just one of them (though most of the others are very similar to it).

You can't really. AJAX and a normal browser visit are more or less indistinguishable from each other. The most you can hope for is to make it harder but before you head down that path you really need to think about whether this is actually a problem you need to fix or not. What if someone sees the page without AJAX? It's not like they're seeing something they otherwise couldn't.