requinix

Since I don't know if there's a good MySQL solution, write a quick script that imports the data. $results = mysql_query("SELECT id field, model FROM table"); while($row = mysql_fetch_array($results)) { if ($row['model']) { $query = "INSERT INTO new table (product id, model id) VALUES ({$row['id field']}, '" . implode("'), ({$row['id field']}, '", explode(',', $row['model'])) . "')"; mysql_query($query); } }

When accessing member variables and methods you do not include a $ with the variable name. $this->link=mysql_connect($hostname,$dbusername,$dbpass); $this->thisquery=$query;

You've triggered a pet peeve of mine so I'll make a quick point about something: Phone numbers are not actually numbers. They are numeric but you can't, say, do math on them: 1112223333 + 1 is nonsensical, let alone something like division or modulus. It's blind luck that there aren't any 0XX or 00X area codes, otherwise that would screw things up. They are strings which consist of numbers. Store them as strings.

BZZZT! There's your problem. Don't store multiple values in one column because it'll only cause you headaches later. Use a second table with (at least) two columns: one is for the product ID and the other is a "model". One product+model pair per row: if a product has three models then there will be three rows for it.

Yeah, that's it. Expires Fri, 06 Jul 2012 20:11:10 GMT That tells your browser it doesn't have to re-request the thing (HTML page) for two hours. So it won't unless you specifically tell it to with a Ctrl+F5. You're already using ETags and Last-Modifieds which, IMO, are superior to Expires. I say to get rid of all the Expires stuff in that second bit of .htaccess code you posted. The Cache-Controls can stay though.

PDO treats null values in PHP as NULL values in MySQL. Apparently the third column in that table doesn't allow for NULLs. (Or maybe there's a uniqueness constraint.) And yes, null. Because unless you defined a $GET array (coughunderscore) then $sid2 is null.

if (isset($switch_array[(string)$_POST['posted_people']])) { $email = $switch_array[(string)$_POST['posted_people']]; // send to $email } else { // not found }

You are either (a) using the wrong server, (b) using the wrong database, © looking at the wrong file and code, and/or (d) running the wrong query.

Haven't the foggiest. I'm a Chrome user myself. Here's a start.

download.php cannot show any HTML when it does the download. The download page and the downloading code have to be completely separate: either you show the page or you do a download. In other words, if (do a download) { do the download; exit; } show the download page

What error?

Your "login" process has to check for a cookie and, if present and valid, use that to populate information in the session. Besides that code you don't really have to care about cookies.

Google is always a good place to start looking. Look for articles and tutorials and stuff too. And you probably don't want to focus on the whole "like Facebook does" thing: it has nothing to do with that.

Nah. Using Firebug, what headers is Firefox receiving when it loads the image? You might have to Ctrl+F5 to see them.

Echo your queries and make sure they are what you think they are. And wtf is with your table structure? Columns for each day of the week? That screams of an unnormalized database.

Two most common options: 1. Put it in a file outside the web root. 2. Put it in a PHP file wherever. $config = array( "db" => array( "username" => "foo", "password" => "bar" ) ); ?> include "config.php"; $config["db"]["username"] = "new value"; file_put_contents("config.php", ''); Remember to chmod(0600) the file so no one else can read it. Why would it be? It's something you want people to configure using an easy UI tool? Not a one-time thing?

That's the first problem you have to solve. What if you kept the files on the server and put links to them in the email? It would mean you'd need a more sophisticated upload system (there are potential gotchas to worry about) and some access control (because I don't think you'd want just anybody accessing any files).

would be to not use regular expressions. What's your code now? I bet it's better than the equivalent preg_match() calls.

// This will never fire!! If the code is as simple as you posted then yes that most certainly will fire: when there is no "slug" in the URL. On that note, there's no need to get Apache involved: your article.php can very easily redirect, as you apparently had once before.

If, on the other hand, you're wondering not what the code does but what the code is about, Your original problem was "if I destroy the session then I can't put the redirect code in it". I'm saying you don't have to destroy the entire session per se - just the user information and whatever else may be in there. Same session and same session ID but you get rid of everything that is in it. [edit] For the record, $_SESSION = array(); might work. Don't think I've ever tried it.

It's perfectly reasonable to destroy whatever is in the current session and start another one anew. foreach (array_keys($_SESSION) as $key) unset($_SESSION[$key]); $_SESSION['resultsCode'] = 'LOGOUT_SUCCEEDED_3475'; // and redirect

titles is just one element. Because you're inside an each(). $('.main ul li h3').each(function(index, value){ document.write(index); });

And now I'm wondering if you have both installations properly separated from each other. The one command "./apachectl stop" will only affect one instance. I couldn't tell you which. Running it a second time won't affect the other instance. You don't mean to say that you ran kill -TERM 8090 right? A simple netstat -lp | egrep '8090|http' should show you something, even if not the full process information (for which you'd need su/sudo).

Saying "xxxx" suggests it isn't localhost. Might there be firewalls between you and the server? What if you tried reversing the ports on the two installations?

General strategy is to redirect someplace after you've handled the form. 1. a.php shows the form 2. Form POSTS to b.php 3. b.php does whatever 4. b.php redirects wherever, like back to a.php or some completely different c.php