When a user logs in, it sets a session called "user_id". In config.php there is $scrap_cars variable, this is set to either true or false.
As you'll see the basic idea of the code is, if you're not logged in then redirect to "Not logged in page" but if you are logged in and $scrap_cars variable is set to false then redirect to "You don't have access page".
I have checked for whitespace everywhere, removed all the content so the erroneous page mimics (test.php) but all to no avail.
either something is causing output in this page before the start of headers(), or this page has probably a BOM element on top of it to mark it as utf-8 encoded page. Check tat your php code does not echo/print anything before the headers() Check with your ftp client that your file begins with the php tags and not with some strange characters.
If I copy the code into a new file (test.php) it works perfectly, just like the other pages.
The entire code? Not just the if/else bit?
or this page has probably a BOM element on top of it
I'll be darned. I would not have thought of the BOM-- except that another thread linked to w3c's discussion of it.* If your code works fine in a new document, an invisible character may well be the problem. Does it work if you paste the entire page text into a new page and give it the name of the old one? If so, the problem has fixed itself :)
:: memo to self: remember BOM the next time a page displays inexplicably ::
If you open the page locally in a browser and manually set the encoding to Latin-1-- or anything other than UTF-8 or -16 --any nasty invisible characters should jump out loud and clear.
* At long last I understand why the same character is both the BOM and the Zero-Width Nonbreaking Space. It's because it is the same character; it's just been repurposed.
I've just copied the entire code into a new page called (test2.php) and accessed it. How strange that it works just as it should. I have cleared temporary internet files etc etc and tried again, the original page still plays up, the test2.php works perfect.
I think omoutop may well have nailed it with the BOM. Do you have a text editor that allows you to reinterpret (not convert) text encoding? Or, as I suggested above, try opening the original page in a browser. If the problem is indeed a BOM, then it won't matter that the php doesn't execute; you should still see the character. You may even see it if you open Page Source from within the browser.
A BOM can be inserted and made invisible by your (text) editor. Make sure to chose the one you use so that it doesn't do that, or at least know how to configure it not to do that.
As far as PHP code is concerned: you're better off without a BOM in the source code when dealing with UTF-8. I've far too little experience myself with UTF-16, so I'll refrain from generalizing there, but even if you want/need it in the output, you can always output it yourself as opposed to it being forced upon you by your editor.