PFMaBiSmAd

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?

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.