PFMaBiSmAd

A setcookie() statement must exactly match the parameters (name, path, domain, secure, and httponly) of an existing cookie, otherwise you are actually trying to set a different cookie. For the record, the only way to actually 'delete' a cookie is to physically delete the cookie file on the client computer (for cookies that were set with a non-zero expire time) or to close all instances of the browser (for a cookie that was set with a zero expire time.) Once a cookie has been set, the only thing a web-server-side script or client-side javascript can do to it is to change the value or change the expire time, by setting the same cookie again with a new value or expire time. To 'delete' a cookie in this way, you are actually either setting the value to something that will cause the cookie to be 'ignored' by code using that value or to an expire time in the past so that the browser won't send the cookie to the server with the page request. @Nosbod, if your session id cookie was originally set without a domain parameter, the setcookie() statement that matches that cookie would also need to have no domain parameter.

Unsetting php variables has nothing to do with the question "How to delete session cookies?"

Any chance you have a $_COOKIE['test'] that only matches your root folder AND register_globals are on so that the cookie is overwriting your session variable with the same name 'test'? All indications are that your $_SESSION variable is getting overwritten. Have you tried using a different name than test?

Any .htaccess files in either or both the admin and root folder that could be affecting the session settings? I recommend that you echo session_id(); after the session_start() statements so that you can see if/when the session id is changing.

Add the following three lines of code after your first opening <?php tag and before your session_start() statement on both pages - ini_set("display_startup_errors", "1"); ini_set("display_errors", "1"); error_reporting(E_ALL);

A url with the www. on it and a url without the www. on it is not switching domains, but sessions won't match both unless you set the session cookie parameters correctly. It sounds like your code on the page in the root folder is clearing the session variables. You would need to post your code if you want help with what it is doing.

Are you switching back and forth between url's that have and don't have the www. on them and/or what does a phpinfo(); statement show for the session.cookie_path setting?

Web servers are not designed to do what you are trying to do. Even if you get it to work on your current web server/php/browser combination, there is a good chance that it will stop working when either of those three things are changed, due to all the buffering and compression that goes on (your current problem could be due to something at your end of the connection, such as a proxy server your ISP is using on your connection.) If you want to output discrete pieces of information and have each of them displayed 'real time', you must use AJAX to periodically make http requests to a web page and have that page output the current information.

Sounds to me like the From: address you are using is not hosted at the sending mail server so the mail server thinks you are trying to relay email through it and it is requiring that SMTP Authentication be used. Is the From: address hosted at the sending mail server? It should be, which will also likely eliminate the need to use SMTP Authentication.

That's only the code that is checking the session variables. What about the code that is setting them or the code somewhere on your page that could be clearing them. Because you did not get errors about the whole $_SESSION not existing or an Undefined index error for $_SESSION['logged_in'], that implies that your code is setting 'logged_in' but is not setting 'accesslevel'. Best guess is that the part of your log in code that gets data from the database is not working and is not telling you what it is doing when it does not work. You could also have some code that either relies on register_globals to set same name session/cookie/program variables and your web host finally turned register_globals off (8 years too late) or you have some same name session/cookie/program variables and your web host managed to turn register_globals on and your variables are getting overwritten. Frankly, you are asking us what your code is doing without seeing your code. The quickest solutions come in help forums when you present all the relevant information and code so that someone can directly see the big picture and/or duplicate the problem.

For debugging, add the following immediately after the first opening <?php tag on the main pages involved in the problem (both where you log in and where you are being told access denied) - ini_set("display_startup_errors", "1"); ini_set("display_errors", "1"); error_reporting(E_ALL); And while your code might not have changed, seeing what method you are using in your code generally narrows down and suggests what could have been changed on the server that could cause the symptoms.

You probably have links/redirects that are switching between www. and no www. on the URL's and your need to setup the session.cookie_domain to match both versions of your domain or you need to force any non-www. request to redirect to the corresponding www. address.

How do you know other mysql_ functions are working? You could for example have the mysql_connect and mysql_select_db in an include file that is not being included, so there is no fatal error associated with them. What's your complete code?

The setcookie() section in the php manual shows how to delete a cookie.

Deleting a cookie or a session cookie is huge waste of effort. A cookie or a session should only identify who a visitor is. To log someone out you should depend on a value stored on your server (ideally in the user table in a database.)

Hmm. I just added a basic form in your code I was testing with and the upload still works. I would say that your login form is missing a closing </form> tag.

There are literally 100's of thousands of web sites uploading files using the method you are trying. Since you are getting consistent results (failure), something has remained the same. In my testing, I commented out the include files and faked out the login since I did not have those pieces of code. At this point, I would say that either the code in include('sqlConnection.php'); or include("login.php"); is clearing or overwriting the $_FILES array and is setting [userpic] in the $_POST array. Posting those two files would help (perhaps there is some foreach loop that is attempting to sanitize form data.) I would also recommend making a simple file with just your form and then doing a print_r($_FILES) on the page it submits to in order to see if just the basic code will work will work. Another thing that could overwrite variables is register_globals. I hope that you don't have them turned on.

[userpic] is showing up in your $_POST array. For the code/form you posted, that is impossible. Either your form, your browser, or your web server/php is not processing the type="file" input field correctly. I just went back and tested your form with both FF and IE and it submits the expected $_FILES array, so there is not a problem with the html. Is there a chance that an earlier version of the code had a type="input" and somehow a cached version of that is getting used? Clear your browser cache and see what happens. Try a different browser if you have one available. Basically, something with your browser or server/php is causing this.

Your form code works (tested) and the $_FILES array is set on a system where uploads are known to work. Both the $_POST and $_FILES arrays would be empty if the post maximum size is exceeded. You don't actually state if the code using isset($_POST['subpic']) is executed. What exactly do your get for output from the print_r() statement? Your php.ini settings only matter if php is actually reading and using them. Using a phpinfo(); statement what are the actual runtime values of the following - Loaded Configuration File file_uploads post_max_size upload_max_filesize upload_tmp_dir Put these two lines immediately after your first opening <?php tag - ini_set ("display_errors", "1"); error_reporting(E_ALL); Lastly, while this has nothing to do with the current problem, the global keyword only has meaning inside of a function definition. The following line (two separate places in your file) in your code has no effect and should be removed - global $sql;

Either your form is incorrect or the size of the upload file exceeds the post_max_size setting.

Change your [i]or die()[/i] statement to the following to get mysql to tell you why the connection failed - [code]or die("Unable to connect to MySQL: " . mysql_error());[/code]