requinix

Nooo... URL rewriting Rewrite /memberID URLs to a script, such as with a RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule .* script.php?memberID=$0 [L]

I could see someone taking their "I have to do it with

CGI dictates that the REMOTE_ADDR is always set. If it is not then either (a) it's not a CGI request, like through the command line or (b) whatever is invoking PHP isn't doing so according to standards.

If you have an array already, shuffle it and pull the first N items from it.

There will always be a REMOTE_ADDR but gethostbyaddr() may fail.

Sounds like the CI_Model class isn't setting up $db as/when you expect it to. Look into that.

If you're getting no results then there aren't any records being "captured". Try running your query using some tool like phpMyAdmin or MySQL Workbench.

Nope.

Unless there's someone here that's familiar with that thing (which Google doesn't seem to know about) then you'll be pretty much on your own. You'll have to find the place that handles logins and extend it to add to the database when it does so. Maybe there's some online support you can find?

...With code? Exactly what don't you know how to do? New to PHP maybe? Where'd the stuff you have now come from?

Well, the obvious thing would be to add "insert a row into that table" code in the login code...

You can't join databases across servers.

It'd be easier if you checked friend1 vs. friend2 in code. Get them both with SELECT * FROM table WHERE friend1 = whatever OR friend2 = whatever then $other = ($friend1 == $whatever ? $friend2 : $friend1);

You don't have to "change it" to make it work with passwords. It already does. If it doesn't like the password then it's MySQL that doesn't like it, not mysql_pconnect(). Either a) You're not setting the password on the right user/host combination, or b) The password change hasn't been applied (like through a restart or a FLUSH PRIVILEGES)

Did you set a password on the account? And due diligence: are you sure you need a persistent connection? You've looked into what it entails?

That error does not come from PHP. Your script is making it. So find out why your script is making it and fix the problem. If you need help doing that then post the code.

No. If you don't feel like changing your table structure to consistently use one type of date field or another, convert between the two using UNIX_TIMESTAMP() or FROM_UNIXTIME().

Use the PCRE functions instead, such as preg_match. But you can't just use the same expressions for both (though they are generally almost identical). To make that particular expression valid for PCRE functions, add a "/" at the beginning and end.

DATE_SUB is a good place to start.

I prefer that. If it's outside the PHP tags then the IDE can analyze the HTML (syntax highlighting, errors and warnings, autocomplete, etc). Personally I'd even put that one you echo as HTML too. </pre> <dt> 2) { ?> [Edit]

Do you have the register_globals option enabled? That would be why they aren't null. The option tells PHP to automatically create $X variables for every $_SESSION["X"] (and some of the other superglobal arrays). By the way, it is a bad thing and you should never rely on it.

And then it would sort by bump first and most recent post second. It'd be nice if you had one field with the most recent action, be that bump or post, but that might not be a good option. So SELECT ..., IF(lastbump > lastpost, lastbump, lastpost) AS lastaction ... ORDER BY sticky DESC, lastaction DESC

Don't even ask the question. Always protect yourself against it, regardless of how easy you think it could be. Regardless of whether you think it's even possible. Unless you're serving a static website then there will be user input somewhere. Radio buttons qualify as user input. Assume someone very smart will try. Rule of thumb: users are malicious, smart, and have plenty of time and patience. You can never trust them.

It's easy to make sure you don't know who voted for what. I mean knowing who has voted at all. If there shouldn't be a way for you to know that then it's still possible but exactly how depends on what kind of data you have available. But if that's fine then all you need is a record of who has voted. Like a table of which user and which election. If they've voted on the election already then don't let them do it again.

Can you ensure that every person can have one and only one account somewhere? Then you can track who's voted that way. Do you care about the possibility of knowing whether a specific person has voted or not?