ManiacDan

Then you were adding a space at the end of the string too. I can only work with what I was given. Your string ended in a comma, not a space or a <br>

You put a <br> at the end of the string. Don't do that.

I'm afraid you're going to have to rephrase this problem so it's easier to understand.

$theString = trim(preg_replace("/\s*,\s*/", ", ", $theString), ',');

MEMORY table types are faster, yes. They only exist in RAM (unless swapped to the disk) and will be destroyed entirely when you shut down mysql. Memcache is still faster.

1) not quite. This is correct: This is not correct: They would see nothing, and/or an entire encrypted data stream. The cookies are transmitted along with the page itself, not as separate documents, so the entire page request contains headers, which may or may not contain cookies. Since the entire transmission is encrypted due to the secure flag, they can only tell "some data is being sent." 2) You can pass flags along with all setcookie calls. I don't know if there's a php.ini setting for it.

So he did! Then it should be as easy as doing the house number math to see if it's within a few blocks (or whatever)

Mine handled several orders of magnitude more! Shame it never went into production. Haha did you really? I actually wrote some of the message-passing stuff for a really big social network (100,000+ clicks per second), so I wasn't just randomly saying things. How did you write yours? What did you use?

What's a "tick"? How often are you expecting them to chat? The chat system I wrote handled 20,000,000 messages a day. Yours, probably less than that. If there's fewer than 5 messages per second, you'll be fine with MySQL. I don't know enough about the rest of your infrastructure to be more accurate.

There are 30 days in most months. Divide by 30.

Yep, that's how chat works. Your "storage" area for incoming chats needs to be as fast as possible. Message queues are the fastest possible medium for this, but MySQL should be fine since I doubt you'll have more than 10 people on this service. Remember to periodically wipe the table, clearing out any chats older than a few hours.

there's a few ways to do this, maybe it would be easiest to simply hit the google maps API for driving directions. Any more than 20 minutes, and you're out of luck.

Did you not write index.php? We cannot possibly help you with some script we cannot see.

There was most likely a "because" in whatever you were reading. You should be using memcache if this is a chat system. Flat files are slower than databases, not faster. What it will lead to is either: A) Two people opening it at the same time B) The second person waiting for the first person to be done using it Either one is bad. Look into something like rabbitmq for passing small messages between scripts.

Yes, that's why the database was invented.

The most useful script I've ever written was a helper function called print_pre function print_pre($a, $r = false ) { $d = '<textarea rows="50" cols="300" disabled="disabled">' . print_r($a, true) . '</textarea>'; if ( $r ) return $d; echo $d; } I always make it globally available in any project I work on, it's perfect for debugging. So much cleaner and easier than print_r. Aside from that, I use the CLI. I run linux and have a button on my sidebar that drops me right into php -a.

No, it's not magic. I'm assuming you have a PHP page which draws the registration form in some way. On that page, if $_GET['id'] is set, perform the necessary database queries to fetch the referral information. When you print the referral bits of the form, check to see if you have data to put into those fields. If you do, pre-fill the form fields with the data you fetched from the database.

Ok...do that. On the PHP page that prints the registration form, if $_GET['id'] is set, pre-fill the referral information.

Location of the images: realpath(__FILE__)).'/images/' Location you're trying to serve them from: admin/img/uploads/ Why do you think /images/ is going to be the same folder as /admin/img/uploads?

You think joomla is manually serving a 404 error for a file that does, in fact, exist? You didn't make us angry, what you're saying makes no sense. Why would a CMS just declare a file as invisible? Why would it incorrectly serve a 404 when that's not the proper header response for "file exists but you cannot see it"? If you think the file really does exist, prove it. Find where joomla is serving the 404 and paste it here. Or comment it out and see what happens. Or show us any information other than "I pinky swear the URL is right but the server says it's not." All you've given us is "I hate joomla. Joomla says I'm wrong. Well I'm not. So there." All we can say is, despite joomla being pretty terrible, we still trust it to know whether the files are there.

The coloring indicates that your quotes are misplaced, so the auto-coloring function "breaks" because your code is broken. This code will not even run due to the extra quote.

Clearly it's not. 404 errors mean 'this is not pointing to the right location'

echo "<a href='edit.php?id={$row['id']}'> edit</a>"; // this is the edit link that should be linked to the rows Also, note that your code is colored wrong, you have an errant double quote in your second echo inside the loop. You're also going to have to actually write an edit page.

OP is receiving help elsewhere

Black Widow, you've posted your database connection information in public. Change all your passwords immediately.