Albright

That's eight characters too long. MD5 hashes are only 32 characters long. But you should set it to varchar(40) anyway. SHA1 hashes (made using the sha1() function in the same way as the md5() one) are 40 characters long. And unless there's some special reason (intercompatibility with some other system), you should always use the SHA1 algorithm for hashing passwords instead of MD5, as it is more secure. Also, consider using PDO for your database access, as it is more secure and results in more portable code.

By the way, the execute call expects an array, so the code looked more like… <?php $stmnt->execute(array(implode(',', $ids))); It looks like trying to extend PDOStatement will require extending PDO and so on and so forth… and be more trouble than it's worth. What I guess I'll do instead is something like… <?php $qmarks = ""; $until = count($ids) - 1; if ($until > -1) { for ($x = 0; $x < $until; $x++) { $qmarks .= "?,"; } $qmarks .= "?"; } $stmnt = $db->prepare("SELECT * FROM table WHERE id IN ({$qmarks})"); $stmnt->execute($ids);

Sorry for the late reply, but I took a day off from this project and there was a bit of work I had to get through before I could check if that worked. Which, by the way, it doesn't… I'm guessing it's because PDO is being too smart and seeing that implode(',', $ids) is returning a string, and therefore escaping the string -- so the query that's hitting the database server is "SELECT * FROM table WHERE id IN ('1,2,3')". That ain't gonna work! Hmm. I'm going to see if I can maybe extend PDOStatement and add a bindArray() function or something. Hopefully that won't be too difficult. It would be great if this functionality were built in, though.

Using PDO's prepare() and bindParam() functions, is it possible to execute a SQL query using IN? For example: SELECT * FROM table WHERE id IN (0, 1, 2); Now of course this is simple if the number of values in the parentheses is constant, but it won't always be. In other words, I want to know the best way to do something like… $query = "SELECT * FROM table WHERE id IN (" . implode(',', $ids) . ")"; …but sticking to PDO conventions.

Okay, interesting. Thanks for the info. So this also holds true for passing vars by reference into functions as well as assigning them linearly as in your and that link's examples? And it's great that PHP is trying to save on overhead by handling all this for us, but I still don't see where the slowness will come in by explicitly passing by reference.

I appreciate your feedback, but if that is true, could you at least explain why? It is counter-intuitive.

I've recently taken a new job working on a pre-existing site for a financial services company which already has a lot of code and a massive database. In addition to writing new code, I've also been going through some of the pre-existing stuff and tweaking it for performance or convenience. Whoever wrote the bulk of the existing code apparently wasn't familiar with references; none of the function declarations that I've come across so far had any ampersands in them, even when things like database handlers were being passed. So I've been going through and fixing that as I've come across it. My boss has noticed as he has been looking through diffs. He didn't explicitly tell me to stop, but he told me he heard that explicitly using references in PHP, though it may save RAM, actually causes more computational overhead than passing copies and that PHP will actually be smart enough to pass variables to functions by reference anyway if they're not going to be modified -- or something like that. I was skeptical, but conceded that perhaps PHP differs from other languages in regards to referencing and that I would investigate the matter over the weekend. I've looked through References Explained in the PHP manual, and it doesn't seem to align with what he was talking about. But I want to make sure I'm not missing something, since the current site has some slowness issues (though it's really more due to the massive database full of seventeen years' worth of data on mutual funds than the PHP code). So does anyone know for certain if my boss's concern in this matter is justified, or can I go on using ampersands with impunity? Thanks in advance for any light you can shed on this.

"Reins" is not misspelled if you're talking about the ropes used to control beasts of burden. If you're talking about a period of rule of, say, a king, it's "reign" as a noun, "to reign" as a verb, and "reigns" as conjugated in the present progressive. Your dictionary of choice will back me up on this.

Actually, in that context, the correct spelling of "reins" is "reigns." [quote]PHP allows web servers to render more than just static HTML, it facilitates dynamic content and interaction.[/quote] Run-on sentence [quote]PHP is often associated as a web server script interpreter; but that is like calling a battleship a canoe.[/quote] Poor usage of "associated" [quote]Only Rasmus Lerdorf himself could truely tell you[/quote] You need "truly"

It probably means that they want the navigation elements (menus and such) on the left side of the screen. However, you'd probably be best off contacting the client and asking them to clarify if you're unsure.

Layout appearance = :) Color choices = :) Table-based layout = :( Copy littered with spelling, grammar and punctuation mistakes = :( The same terms and words linked to the same web pages multiple times in a page, or even a sentence = :(

Hypnos, your answer doesn't seem to be relevant to the questions... All elements $_POST (excluding file uploads, where things start to get funky) are string variables. This includes things you'd expect to be only boolean, such as check boxes; when checked, the data will look like $_POST['checkbox']=="on". if($var) is functionally equivalent to if($var==true) (though I believe the latter actually consumes more processor cycles, because the computer has to make two boolean checks instead of one... first it checks if $var is true, then it checks if it's true that $var is true, if that makes any sense). isset($var) returns true if a variable exists that is named $var. [code] <?php error_reporting(E_ALL); //Let's turn on error reporting because we are smart if(isset($var)){ echo("Set"); } else{ echo("Not Set"); } //Will output "Set" $var=false; if(isset($var)){ echo("Set"); } else{ echo("Not Set"); } //Will output "Not Set" if($var){ echo("True"); } else{ echo("False"); } //Will output "false" unset($var); if($var){ echo("True"); } else{ echo("False"); } /*Will cause an "Undefined Variable" error... but would print "False" if we were dumb and didn't turn on full error reporting*/ ?>[/code]

HUUUUUUUUUUUUUUUUUUUUUUUUUUUUGE SECURITY ISSUES HERE! If you're not careful, you could make it so anyone could edit [i]any file[/i] on your server. I would strongly [i]not[/i] recommend ever implementing something like this. Anyway... Your edit form is probably blank because it looks like you're trying to insert the contents of an invalid file; that is, a directory, just named "news/". Try setting $fn equal to a valid file. Or better yet, never implement something like this in the first place.

Methinks you kinda skimmed my original post, including the part where I acknowledge that you seem to have come up with the same idea. =P SigFeeder doesn't work by peeking into databases; it uses RSS or Atom feeds from blogs instead. Your blog doesn't seem to be offering a feed, so you might not be able to test it... Did you roll your own blog script? With regards to it being skinnable, I'm all over that! Check out [url=http://sigfeeder.com/Blog/index.php?/archives/XML-SigFeed-layouts-now-working.html]this[/url] for an idea of the wide variety of different looks you can achieve with SigFeeder.

The heck? Why are you using a switch when there's only two possibilities? Also, your code will trigger a false positive if the substring is somewhere in the string besides the first four letters. [code]<?php $array1 = array('med:1','med:2','med:3','temp','start'); foreach($array1 as $item){ if(strpos($item,"med:")===0){ //Note we used === instead of ==. false==0, but false!==0. //Also note that using strpos instead of regular expressions is faster for simple searches like this. //Do something } else{ //Do something else } } ?>[/code]