PFMaBiSmAd

I'll second that. The subject line is a header that is part of the underlying mail structure.

Because your existing format is a valid date value, you can (this worked with a literal value and should work with values in a column) use the mysql DATE_FORMAT() function directly in your queries - SELECT DATE_FORMAT(existing_column_name, '%d/%m/%Y') Also, since the existing format is a valid date format it would INSERT directly into a DATE data type and you would use the same DATE_FORMAT code I just posted to retrieve values. So, there are no disadvantage in converting to a DATE data type. The advantages would be reduced storage requirements (your existing format uses 9 bytes and a DATE is 3 bytes) and faster database operation for every query that references your date values.

I'm not going to ask, but it is never too late to fix the problem. You can simply (backup your database first) create a new DATE column, populate the new column from the values in the existing column using a single UPDATE query and the mysql STR_TO_DATE() function to convert between the existing format and a DATE, change and test the existing queries to use the new DATE column, then remove the old column. For your current question, you haven't indicated what the current format is and what format you want, so it will be a little hard to directly help with the best way to accomplish the conversion.

For debugging purposes, add the following two lines of code immediately after the first opening <?php tag to show all php errors (i.e to see if there are any errors produced by the mail() function) - ini_set("display_errors", "1"); error_reporting(E_ALL); The comments in the php.ini are incorrect. The SMTP and smtp_port settings are used whenever you are using the mail() function and are interfacing with the sending mail server using the SMTP protocol. The sendmail_path setting is used anytime you are interfacing with the sending mail server (even on Windows) using the command-line/API of the sending mail server.

We could probably see the problem easier as well if you actually posted the error message(s.) However, I'll guess it is a php parse error because your array syntax is incorrect. Arrays use [] around the index. You also need to put {} around an array variable when it is inside of a double-quoted string (I also recommend only using full opening <?php tags) - $dateSQL = "SELECT arrival_date, departure_date FROM bookings WHERE client_id = {$clientresults['client_id']} Order BY id DESC LIMIT 1"; $dateResults = $db->query($dateSQL); ?> <td><?php echo $dateresults['arrival_date']; ?></td> <td><?php echo $dateresults['departure_date'];?></td>

If you are on shared web hosting and are using the default/common session.save_path setting, the shortest session.gc_maxlifetime of all the scripts running on the server will 'win' and you must set the session.save_path to point to a 'private' folder within your account's folder tree so that your session settings apply only to your session data files. The session.save_path and session.gc_maxlifetime settings must be set before every session_start() statement so it is best to globally set them in a .htaccess file (when php is running as an Apache Module) or in a local php.ini (when php is running as a CGI application.) Check that the settings are actually set correctly using a phpinfo(); statement. Changing session.gc_probability and session.gc_divisor to 1 will cause a directory scan of all the session data files on every session_start() statement and should not be done on a site that has a lot of active session data files.

Your if(){}else logic is incorrect. Your if(){} statement is empty and because you are not using {} around the code in the else part of that, only the first line after the else is part of the else statement.

echo "$_SESSION['name']"; produces a fatal parse error, having nothing to do with the register_globals setting and therefore cannot be your actual code. It would take seeing your actual code to be able to tell you why it is not working when register_globals are off.

Either escape them with \ or change them to single-quotes.

use str_pad

Fatal parse errors are not displayed unless the error_reporting/display_errors settings are in effect before your script is parsed. When they are set in your script they only display runtime errors, warnings, and notices. Your script has the following fatal parse errors - Parse error: syntax error, unexpected T_LNUMBER, expecting ',' or ';' in .... because of double-quotes contained within a double-quoted string in all the following lines of code - echo "<table border="1" cellspacing="2" cellpadding="2" class='tableborder'>"; echo "<th><font face="Arial, Helvetica, sans-serif">Player ID</font></th>"; echo "<th><font face="Arial, Helvetica, sans-serif">Login</font></th>"; echo "<th><font face="Arial, Helvetica, sans-serif">Password</font></th>"; echo "<th><font face="Arial, Helvetica, sans-serif">Email</font></th>"; echo "<th><font face="Arial, Helvetica, sans-serif">IP</font></th>"; echo "<th><font face="Arial, Helvetica, sans-serif">Avatar</font></th>"; echo "<th><font face="Arial, Helvetica, sans-serif">Group</font></th>"; echo "<th><font face="Arial, Helvetica, sans-serif">Skin</font></th>"; echo "<th><font face="Arial, Helvetica, sans-serif">Settings</font></th>"; echo "<th><font face="Arial, Helvetica, sans-serif">Tournaments</font></th>"; You also have a typo in the following line (the $1 should be $i) - $ipaddress=mysql_result($result,$1,"ipaddress");

If you want to send the action value as a $_GET variable, you will need to put it on the end of the URL in the form's action="home.php" attribute - action="home.php?action=actualswitch"

Edit to the above: that is the output from a web server/php. So, is the Loaded Configuration File, which is what I asked about, the one that you are changing?

What does a phpinfo() statement show for the session.cookie_path setting?

Edit: A slightly different angle - your main file should include things it needs to make up the application. A function.ini.php file should contain functions only. A config.php file should contain config information only and the function file should not be responsible for including the config file. Nope. That implies that you have not written the functions to be general purpose. It should not matter WHERE you include functions from, they should be able to use the existing config information that was included by the main file. Main file: index.php (specific to each client/subdomain) - <?php include config.php; // include specific config information include $absolute_file_path_to_core_files . "/function.inc.php"; include $absolute_file_path_to_core_files . "/header.php"; include $absolute_file_path_to_core_files . "/content.php"; include $absolute_file_path_to_core_files . "/footer.php"; ?>

I'm going to guess that either the LIMIT term is causing this or your code that is retrieving and displaying the results is causing this. Call me skeptical, but you haven't exactly provided any evidence of what you are getting vs what your data is that should be producing more results. When you echo $query and then execute that query directly in your favorite database management tool, what do you get? What IS your php code that displays the result of the query? For all we know it has a logic error in it that causes it to stop after two entries have been displayed. Have you done a 'view source' of the output in your browser so that you know there are only two entries? Perhaps there is a HTML markup error that is preventing the remainder of the entries from being displayed.

You apparently arrived at that output using the command line interpreter (CLI.) The php.ini that the CLI uses is not necessarily the same one that the web server/php uses. You would need to put the phpinof(); statement into a file that is invoked via the web server in order to find the Loaded Configuration File that is being used.

The link you posted contains a significant number of markup and css errors - markup: 82 Errors, 27 warning(s) - http://validator.w3.org/check?uri=http%3A%2F%2Fwww.urbanfishingshow.com%2Fphoto%2Fphotos%2F269&charset=%28detect+automatically%29&doctype=Inline&group=0 css: 37 errors - http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fwww.urbanfishingshow.com%2Fphoto%2Fphotos%2F269&profile=css21&usermedium=all&warning=1&lang=en

in_array

It's actually FIND_IN_SET, not FIELD_IN_SET and the first parameter needs to be enclosed in single-quotes.

Are you doing any URL rewriting because some incorrect rules cause a page to be requested twice and which browser are you using because FF with some of the debugging plug-ins cause a page to be requested twice?

When you have a comparison that is failing, echo (or use var_dump(), if you need to see the type and length as well) on the value right before the comparison to make sure it contains what you expect.

Have you checked if the php.ini that you changing is the one that php is using? What does a phpinfo(); statement show for the Loaded Configuration File?

Several pieces of helpful advice have been posted in this thread that would shorten this process -

Boy is it affected, badly. Under the latest php5.3.x on Windows (this could be a php/Apache under Windows problem, again), magic_quotes_gpc being ON truncates everything up to and including the single quote in an uploaded filename. With magic_quotes_gpc OFF, the same file name is passed correctly. Confirmed using var_dump($_FILES[...]['name']);