views:

5558

answers:

9

I'm new to PHP and I'm trying to do something that may be bad practise and may well be impossible. I'm basically just hacking something together to test my knowledge and see what PHP can do.

I have one webpage with a form that collects data. That is submited to a PHP script that does a bunch of processing - but doesn't actually display anything important. What I want is that once the processing is done, the script then tells the browser to open another page, where the results are displayed.

I know I can use header('Location: page.php'); but I can't work out how to provide POST data with this. How can I do that? Alternatively, is there another way to tell the browser to open another page?

EDIT: What I'm taking from the responses is that it's possible to do this using various hacks but I'd be better off to just have the processing and the display code in one file. I'm happy with that; this was an experiment more than anything.

A: 

Hi there,
I hope i got your qestion right. You might try this:

  1. Adjust your form to look like this:

form method="POST" action="process_data.php"

2. Then you create the file process_data.php, wich surprisingly processes the data.
And in this file you use header:
For example:

$head = sprintf("page.php?data1=%d?data2=%d",$data1,$data2);
header($head);

I hope i could help.

Nick
hm... if you vote me down, maybe you could give me a reason?!?!
Nick
I didn't downvote you, but the code example you have given wouldn't work
Tom Haigh
header($head) should be header('Location: ' . $head); This example looks like a bad practice though....
alex
+5  A: 

You could store that data in the session e.g. in the first file that handles the post

session_start();
$_SESSION['formdata'] = $_POST; //or whatever

then you can read it on the next page like

session_start();
print_r($_SESSION['formdata']);

or you could pass it through GET: (but as per comments this is a bad idea)

header('Location: page.php?' . http_build_query($_POST));

If you do that make sure you do additional processing/validation on page.php as a malicious user could change the variables. also you may not need the whole post transmitted to the next page

Edit

I should make clear that I think the second option is worse, you are limited by the size of data you can send through get and it is possibly less secure as users can manipulate the data.

Tom Haigh
I'd upvote you for the session suggestion and downvote you for the get suggestion, so no vote for you.
Nouveau
@Nouveau: agreed, I just wanted to show that as a more stateless option, but i should have made it clear it was less preferable
Tom Haigh
I agree with Nouveau. The second suggestion really is bad practice
Cassy
A: 

There's no way to redirect the user's browser to an arbitary page and sent a POST request. That would be a bit security risk, where any link could cause you to make any form submission to an arbitrary site without you having any kind of clue about what was going to happen.

In short, it's not possible

Gareth
A: 

AFAIK this is usually done as a two-step process:

  1. On form.php, POST the data to script process.php
  2. The process.php script processes the data but never outputs anything itself, it always calls header("Location: asdasd") to redirect to a success.php or failure.php page (if applicable)
divideandconquer.se
A: 

You could use JavaScript as a dirty work-around:

<form id="redirect_form" method="post" action="http://someserver.com/somepage.php"&gt;
    <input type="hidden" name="field_1" value="<?php echo htmlentities($value_1); ?>">
    <input type="hidden" name="field_2" value="<?php echo htmlentities($value_2); ?>">
    <input type="hidden" name="field_3" value="<?php echo htmlentities($value_3); ?>">
</form>
<script type="text/javascript">
    document.getElementById('redirect_form').submit();
</script>

(the script should be below the form)

Tom
+1  A: 

Is it really necessary to call another page after the processing is done? I'd probably do the following:

<form method="post" action="display.php">
...
</form>

display.php:

if ($_POST) {
    require_once(process.php);
    process($_POST);
    display_results;
}

with process.php containing the code necessary for processing the post request.

Alternatively, you could use something like the cURL library to pass the results of the processing to a page specified by yourself. Don't know if that's really what you're after though.

Josh Smeaton
A: 

Do it all in one script and just output different HTML for the results.

<?php  if($doingForm)  {   ?>

html for form here

<?php } else { ?>

html for results

<? } ?>
Pushing refresh here after `$doinForm = true` will resubmit the form. This could cause undesired behaviour. See http://adamv.com/dev/articles/getafterpost
alex
A: 

This problem has vexed me for some time. My custom CMS does some quite complex processing, uploading and manipulation, and so sometimes ouputs quite lengthy error and information messages, which aren't suitable for converting to GET data, and I have always wanted to avoid the reload problem on data INSERT, but not yet found an adequate solution.

I believe the correct way to go about this, is to create message arrays for each possible state - each message or error you could want to display, and then you only need to send error/message numbers which are a lot easier to handle than long data strings, but it's something I have always shied away from personally as I find it a bit tedious and cumbersome. Frankly, this is probably just laziness on my part.

I quite like the SESSION variable storage solution, but this raises the question of how do you ensure the SESSION data is properly destroyed? As long as you ensure you are only sending information (messages/errors) and not data that should/could be stored (and thus potentially sensitive) this should be an avoidable problem.

DisasterMan