PFMaBiSmAd

order is a reserved mysql keyword. You should rename your table to something else.

filesize() does not work for HTTP/HTTPS. It does work for FTP. get_headers() is php5 only. What php version are you using?

$a_date = "$yr-$mon-$dy"; $query = "SELECT * FROM your_table WHERE your_date_column BETWEEN '$sdate' AND '$edate'"; BETWEEN is inclusive of the end points. If you want to exclude one of both end point(s), you would need to use greater-than/less-than comparison operators.

$query ="SELECT comps_id FROM (SELECT comps_id, MAX(headldate) as hldate FROM headl WHERE headlnoshow='N' GROUP BY comps_id) a ORDER BY hldate DESC LIMIT 5";

And since you can only do greater-than/less-than date comparisons when the field making up the date are ordered left-right, MDS (most significant digit - year) to LDS (least sugnficant digit - day), the only way you will accomplish what you are trying to do will be to get your dates into a format like YYYY-MM-DD and using a DATE data type is the most efficient way of doing that.

Whatever programmer told you that php5 was less forgiving does not know what he is saying. There are very few incompatible changes going from php4 to php5 that are due to actual language changes. Most problems with old code are due to programmers not following recommend php.ini settings, in some cases using depreciated features that were turned off over 7 years ago.

The problem has absolutely nothing to do with the php version. Your old web hosting had output_buffering turned on in the php.ini, which allowed you write some code that managed to function. A quick fix, while you are rewriting the code to be correct, would be to turn output_buffering on in a local php.ini (when php is running as a CGI application) or in a .htaccess file (when php is running as an Apache module.) By the way, your web host should have published exactly which php.ini settings they were going to change between the old and new hosting they were offering so that someone would know before hand what they would need to be updating in their scripts.

You also need to put an exit; statement right after the header() redirect to prevent the remainder of the code on the page from being executed while the browser preforms the redirect. The current code won't protect the content on the page if a hacker ignores the header() redirect.

Confirm the settings you have been making using a phpinfo() statement. If the php.ini that you are changing is not the one that php is using or you are not stopping and starting the IIS service to get the changes to take effect, it won't matter what you put into the php.ini.

Yes, except that since you are dealing with a log in script, that makes it possible for a hacker to bypass the security and set the session variables so that he can appear to be a logged in visitor. Register_globals have also been completely removed in php6, so the code will eventually need to be fixed or replaced.

That is exactly the same as what can happen to the session ID. If I get one of your user's session ID (being passed back and forth between his browser and your server, say over an unencrypted wireless Internet connection), I can visit your site and supply that session id and appear to be the actual visitor. If you truly expect a login to be secure, within the scope of what you have control over, you must use HTTPS/SSL to encrypt the connection all the way between the browser and the server. However, this does not protect against a virus on or someone with physical access to the user's computer getting the session id or value in the cookie and impersonating the user. You can protect against someone impersonating the user when the user has logged out by depending on a value stored in the user table that indicates the logged in/out status. If upon logout, the value in the user table is changed to logged out, even if someone gets a hold of the session id/cookie value and impersonates the visitor, they cannot log in unless they also supply the correct username and password. Too many people depend solely on the existence of a value in a session or a value from a cookie to determine that someone is logged in. The existence of a value in session or in a cookie should only identify someone. You then take that identifying piece of information and lookup in your user table if they are logged in and determine any other permissions they have on your site. You must also record and check the USER AGENT and IP address information (they won't change during a single login period) and either of them does change due to the visitor switching browsers or doing something that would cause his computer to get a different IP address, he will just need to log in again.

Generate an md5() hash of a uniqid for each user and store that in the cookie and in a column in your user table - http://us3.php.net/manual/en/function.uniqid.php This is essentially what a session ID is, except the value in the cookie will point to the correct row in the user table instead of pointing to the correct session data file.

To extend the lifetime of a session, you must both set the session.cookie_lifetime and the session.gc_maxlifetime to the longer value. However, you must also set the session.save_path to be to a private folder so that only your session settings will affect your session data files. All these settings must be set before every session_start() statement, so it is best to set them globally in the master php.ini. A session is designed to last for one browser session (hence the name.) A remember me feature is usually done using a regular $_COOKIE instead of modifying how sessions work.

The "Invalid file" message implies that the following statemet is FALSE - if ((($_FILES["file"]["type"] == "application/msword ")) && ($_FILES["file"]["size"] < 500000)) Since the ["size"] of the actual file is clearly < 500000, that would mean that the ["type"] of the actual file does not match the value in the conditional test. The value in the conditional test is "application/msword\n" and the value form the uploaded file is "application/msword". Those are not the same and an == comparison between them will be false. It matters if there is an extra \n on the end of a value that you copy/paste into code.

PEAR is essentially a php framework made up of a base installer/core and separately installed php scripts. The phpinfo() output only contains an include path entry that does not necessarily indicate that any portion of the PEAR scripts are present. You can in fact install your own copy of PEAR, including the Mail package. The instructions are on the pear.php.net web site. There are other mailer classes, such as phpmailer and SwiftMailer that don't require the installation of as much code.

Actually, a checked checkbox will be set and it will have the value in the value="..." attribute (if present and a default value of on if is there is no value="..." attribute.) An unchecked checkbox won't be set.

The tutorial you found is using a specific mailer class - and in the code - require_once "Mail.php";

The variables $UserName and $Password need to be set from the corresponding $_POST variables $_POST['UserName'] and $_POST['Password'] Unfortunately, once you fix that one small piece of code, you will probably find that all the rest of the code that makes up the application that is dependent on any POST/GET/COOKIE/SESSION/SERVER variable will need to be fixed as well. There is simply no excuses for code to still be posted around on the Internet that has not had any dependency on register_globals corrected at this point in time. Since it is unlikely that the original author is around or is willing to correct the code, you will need to do this or find a different script that does work.

The code is likely dependent on register_globals being ON (they were turned off over 7 years ago because they allow hackers to set session variables.) You would need to post the relevant code in order to allow anyone to see what it might be doing that would cause the symptom.

Cannot specifically help with the code producing that symptom without seeing the code. Best guess is that you did not assign the output from the msyql_real_escape_string() function call to the variables being used in the query.

The name="..." attribute of the form field does not match anything your code is checking.

Browsers only send cookies that match the requested URL. Any chance that the cookie path or cookie domain setting has been changed or that the actual path or domain where the script is being executed at no longer matches the path or domain being set for the cookie?

I'm guessing that the data path from draft to final table (you should actually just use your final table but with a status column that indicates it is a draft and then just change the status to 'final' when you are done) does not pass through $_POST variables. Short answer - all string data put into any query, no matter where that data comes from, must be escaped if it could contain any special sql characters.

For debugging, add the following code immediately after your first opening <?php tag in your form processing code so that you can see exactly what you are getting from the form and what errors might be occurring - ini_set("display_errors", "1"); error_reporting(E_ALL); echo "<pre>"; echo "POST:"; print_r($_POST); echo "FILES:"; print_r($_FILES); echo "</pre>";

How about echoing it to see what it contains.