Redirecting

[shadowayex]

Is there anyway, in any language, PHP or otherwise, that I can redirect a user, besides the header() function. The header() function keeps annoying me because I always run into the dreaded "Headers already sent" error and a lot of the time because of the way the code is written, I can't move the header() function. Is there anything I can replace it with?

[Synook]

You can use the output buffer to delay output until all headers have been sent:http://static.php.net/manual/en/book.outcontrol.phpOr you can use meta tags or JS to redirect

<meta http-equiv="refresh" content="0; page.html" /><script type="text/javascript">window.location = "page.html";</script>

[boen_robot]

To show an example of what Synook means, you can use

ob_implicit_flush(false);

at the beginning of your code to prevent "echo" calls resulting in output, and thus the header() function not working. Once you're ready to output the page, you can use

flush();

to output the output buffer. Thus, you can have:

<?phpob_implicit_flush(false);//Rest of your codeflush();?>

Beware that this means your page will seem to render a bit slowly (if you take notes of the time, you'll see it's the same... it's just that all of the content appears at the end rather than partly appearing at the start). If you want to avoid that, use flush() at the moment you know you won't have any more header() calls.

[shadowayex]

Using a JavaScript method, it works now. I tried the JavaScript method before, but I must've mistyped it because it works now. Thanks for your responses and help.

[Praetorian]

I still wish php had another alternative. The javascript method is clunky because it's not instant. It allows the other page to load before redirecting.

[Synook]

Whats wrong with output buffering?

[shadowayex]

The JavaScript redirect isn't so bad... which is better, the whole flush thing or the JavaScript redirect? I mean, yeah the PHP method might be better in case JavaScript isn't enabled. But in my case, a lot of JavaScript is used on the site I'm building. So if JavaScript isn't enabled, the user is going to want to enable it, or he/she isn't going to have a very good experience.

[Wander]

i think just ob_start() is fine (dont need all that flush stuff in my opinion, works fine without here), with javascript someone has to load that page first, and then the next one, waste of bandwith

[shadowayex]

Ok, well, what if a header("location: ") function is within an if statement. Will it wait until the statement is true for the case that includes the header to redirect, or will it just be dumb and redirect right then and there?

[alexnofue]

Hi, I have used the header("location: something.php") with a rather relative url and always worked fine, inside the if statement will not execute unless the condition is fulfill so i guess is safe to use it there.

[shadowayex]

I mean if you add the output buffer.

[Wander]

yes, it will still act normalwithout output buffering php sends output and headers and cookies right away, when output buffering is on it will save everything till the end of the script (or till u flush it) and then sends them, so you wont have problems with headers

[midnite]

Hi all,FYI,1) try not to use Windows Notepad to edit unicode pages. it adds 3 bytes of something (forgot the technical term) in front of your <?php that ruins your header() functions. You will always get "header already sent" error with no clue. You may use hex editor so you will have a totally clear picture of it. (but i guess u guys dont have this problem as no one is complaining )2) always add die (); or exit (""); after header (); because the lines following header (); will still be executed after the header is sent. (if we understand the whole networking mechanism, we won't feel it's weird)i guess u may know all these juz FYI

[midnite]

Hi there,if you want to TOTALLY save bandwidth (header, though small, is something we still need to send, what we save is only the page contents), TOTALLY dont let your cliients know what is happening (header can be easily captured), or you simply not pleasant with header ();, try replacing header ('location: another.php'); by include 'another.php'; die ();http://hk2.php.net/manual/en/function.include.phpcheers

[shadowayex]

Well, most of my redirects that are giving me problems are there to take me back to the same page, for the purpose of clearing the URL of ?get stuff. For example, lets say someone deletes a message from their inbox on my messages.php page. The end of the URL will look like this:

messages.php?mode=deletemsg&id=3*Note, the id is actually set by PHP depending on the id in the database, that is just an example.

The purpose of all the headers giving me trouble redirect back the page, without the ?stuff. So in this case it'd look like this:

header('location: messages.php');

I don't really need anything fancy, just something that will do that. I'm going to try the output buffer and see if it suits my needs. If there's a better way, let me know.

[midnite]

Hi Ragae,i am sorry that i dont really understand what's your situation. You have a page message.php like this?

message.php<?phpif (isset ($_GET['mode']) && $_GET['mode'] == 'deletemsg') {  // perform delete $_GET['id']}<html>message 03 <a href="messages.php?mode=deletemsg&id=3">delete</a></html>

it calls itself for the operation?

[shadowayex]

Each message has a delete link that is set when the database gets it. The code for the link looks like:

<a href="messages.php?mode=deletemsg&id=<?php echo $row['MsgId']; ?>">Delete</a>

Which is generated inside a while statement that looks like:

while(row = mysql_fetch_array($messages)) {//code that displays the messages}

The whole system works fine. It's just when they delete a message, it'll delete the message just fine, but it leaves all the stuff in the URL, so if they refresh, it could try to do it again. Which could be a bad thing, if another message were to appear before the refresh and happen to take the empty ID. Understand? That's why I wanted to put something that'll bring the users back to the messages.php page, or something just to clear the URL of all the PHP stuff. Output buffering seems to be working good enough, so since that's the best solution I've seen, I'll stick with it, until someone suggests something better.

[midnite]

Hi Ragae,It's good to hear that you have solved your problem. Yes, i think using header () redirect with output buffering is the best choice. A kindly reminder that be aware of infinite recursively redirecting to itself.Another suggestion (that i will use) is using a different page to perform the delete process. Thing likes <a href="delmsg.php?mode=deletemsg&id=<?= $row['MsgId']; ?>">Delete</a> and having header ('Location: messages.php'); at the end of delmsg.php. In this solution, we need not to care about output buffering as delmsg.php wont output anything.cheers

[shadowayex]

Thanks for the suggestion, I was considering that, but output buffering suits better in this case, because I'm considering adding a couple things that will cause output. But I'll keep the alternate solution in mind when I come across a similar problem.

[justsomeguy]

There is always a way to structure your PHP code so that you don't need to use output buffering. Your code should be structured so that all PHP processing happens before any output is sent to the page. Then you can redirect at any point during pre-processing because you haven't started the output yet. You only start sending output once pre-processing is finished and you know that you want to display the current page. Even though you can mix PHP and HTML wherever you want, it's not a good practice to have a PHP page that starts with a bunch of HTML code, then some PHP, then more HTML, more PHP, etc. Ideally your PHP file contains *only* PHP code, you want to try to separate the logic from the presentation as much as possible. In the thread about PHP mastery in the general forum I posted a file that displays a big form (30 or so fields), processes it, validates it, checks for errors and displays them if necessary, keeps the values sticky, redirects to another page if everything is fine, etc, and it does it all in under 100 lines with no HTML at all in the source code. There's always a way to structure your code so that all PHP processing is finished before you decide what (if anything) to display.

[redwall_hp]

As justsomeguy said, "There is always a way to structure your PHP code so that you don't need to use output buffering."If you plan your code out carefully, you can generally handle redirects before any output is written. I rarely run into problems of the "headers already sent" sort. It just takes planning.

[shadowayex]

As justsomeguy said, "There is always a way to structure your PHP code so that you don't need to use output buffering."If you plan your code out carefully, you can generally handle redirects before any output is written. I rarely run into problems of the "headers already sent" sort. It just takes planning.

The problem is that most of my code looks something like this:if(!$query) { die('There was an error')}else { header('location: page');}and stuff like that, where the die() statement has to be shown in a certain place. It's usually more complex than that of course, but that's an example of why I have imited space to put it.

[justsomeguy]

You save the message to a variable, and show the variable where you want it. You don't need to put the query where you want a message to be printed, think about it, they really don't have anything to do with each other (run a query vs. print a message). Run the query first, set a variable if it fails, and print the variable later on wherever you want it.That's just a small example, but I'm serious when I say that you can structure literally any piece of code to not send any output before you redirect. It doesn't make sense to redirect in the middle of a page, if you're redirecting then there's no point to all of the output you just sent, or alternately, there's no point to sending a bunch of output if you're just going to redirect. Process the data first, then figure out how you want to display the page, you won't have problems like this, and your code will be easier to maintain.

[shadowayex]

I see. I'm working on trying to convert my site into a cleanly and effectively coded site and any tips like that help a lot. I was originally under the impression it was bad to write extra lines to help keep the code separate because you want to keep the file size as small as possible. But with a lot of the new things I'm learning, I see that extra lines don't make as much of a difference in loading time as if you keep the PHP away from the HTML. Thanks for the tips.

[justsomeguy]

It doesn't matter how big the PHP file is. The only thing the browser sees is the output. It might take the server a couple microseconds longer to load the PHP file into memory to execute it, but that's about it.