scootstah

I don't think this is doing what you think it is. That comparison is going to be interpreted as a string, and you can't compare strings that way.

use empty() instead.

Read: http://www.sitepoint.com/hierarchical-data-database/

First Google result

How/why would you have database credentials IN a database? I usually make a simple function that has a static array of settings. On the first call it will load the settings from the database, and on subsequent calls it will just return it. It would look something like... function settings($setting) { static $settings = array(); if (empty($settings)) { // get settings from the database } return isset($settings[$setting]) ? $settings[$setting] : null; }

I was watching the live feed for the development of Coffee Break Hero back a while ago. They had a couple different guys doing different things. One guy was a programmer, one guy was a graphic artist, etc. The graphic artist was probably the most fun to watch, mostly because he completely blew my mind watching how fast he was doing things.

A form with no method attribute will default to GET, so you can access it with $_GET. $_REQUEST is generally frowned upon because it lacks specificity. To check if it is blank you can use isset() or empty().

I'm not sure why you want to give an external site access to your user's cookies. That doesn't seem right. You should be giving user information server side so it is more reliable. Then you'll probably want to output some JSON or XML or something for the external site to scrape and get the necessary information.

If you don't want the account number to actually be changed by the form, you can just use a hidden field.

So why can't you put it in a form element then?

It would probably be more effective to actually contact 1and1, not us.

Really depends what genre I am craving for the day/week. I like pretty much everything that's not country and hip-hop.

I hope you are aware that ALL POST (and GET) data can be tampered with by the client. It doesn't matter if it is in hidden fields, readonly fields, or disabled fields. It all has to be sent by the browser and can therefore be modified first. If you don't want the ID to be in a form element, you could try making it apart of the form action. So instead of action="process.php" you would have action="process.php?id=24"

It could be due to the fact that your code is going to open a ton of table rows and cells but close none of them.

Take a look at system() or exec()

Because it isn't encryption, it is hashing. It is one way and not reversible.

From the manual,

You shouldn't be encrypting passwords.

How do you plan on changing the URL without changing the URL? That doesn't make sense.

No. What are you trying to do?

Convert the input to a UNIX timestamp and then convert it again into the MySQL DATE format. $input = '02/16/2012'; $unix_timestamp = strtotime($input); Then use the FROM_UNIXTIME() function in your MySQL query to change it to DATETIME. INSERT INTO table (record_date) VALUES (FROM_UNIXTIME($unix_timestamp));

Can you post the output of : echo '<pre>' . print_r($_FILES, true) . '</pre>';

Please post code in [ code][ /code] tags. Also I don't see a question anywhere. What is the problem?

Here, I've added some comments to (hopefully) help // start a for loop to increment an integer // $i will start at 0 and end at 11 (so 12 increments) for($i = 0; $i <= 11; $i++) { // $timestamp will contain the UNIX timestamp returned by strtotime // by default, strtotime works off the current time // so in this case we are adding X months to the current month // the amount of months is determined by $i which will be // incremented with each pass of the for loop, starting with 0 $timestamp = strtotime('+' . $i . ' month'); // here we are just getting the different formats of the date // from the UNIX timestamp that we got above $month_text = date('F', $timestamp); $month_num = date('n', $timestamp); $year = date('Y', $timestamp); // and finally, we append a formatted string to $option $option .= sprintf('<option value="%d-%d">%s</option>', $year, $month_num, $month_text); }

It is possible that the query could be run at the same time. This means that your last_insert_id() might not be for a different query. For example, if you run "insert into emp" it might create an ID of 7. If, before you run the second insert, the first query is run again you would get an ID of 8. So the second query would have an ID of 8 and not 7. Using transactions you can prevent this problem. When you use transactions you sort of create temporary data. The data is only saved permanently once you commit. So the ID would always be accurate using transactions.