PHP открывает другую веб-страницу с данными POST

Надеюсь, я правильно понял ваш вопрос. Вы можете попробовать это:

1. Измените форму, чтобы она выглядела так:

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

2. Затем вы создаете файл process_data.php, который неожиданно обрабатывает данные. И в этом файле вы используете заголовок:
Например:

$ head = sprintf ("page.php? data1 =% d? data2 =% d", $ data1, $ data2);
заголовок ($ head);

Я надеюсь, что смогу помочь.

Вы можете сохранить эти данные в сеансе, например. в первом файле, который обрабатывает сообщение

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

тогда вы можете прочитать это на следующей странице, например

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

или вы можете передать его через GET: (но, согласно комментариям, это плохая идея)

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

Если вы это сделаете, убедитесь, что вы выполняете дополнительную обработку / проверку на page.php, поскольку злоумышленник может изменить переменные. также вам может не понадобиться перенос всего сообщения на следующую страницу

Редактировать

Я должен прояснить, что я думаю, что второй вариант, возможно, хуже, поскольку вы ограничены размером данных, которые вы можете отправить через get, и, возможно, он менее безопасен, поскольку пользователи могут более очевидно манипулировать данными.

Невозможно перенаправить браузер пользователя на произвольную страницу и отправить запрос POST. Это было бы небольшим риском для безопасности, когда любая ссылка могла бы заставить вас отправить любую форму на произвольный сайт, не имея ни малейшего представления о том, что должно произойти.

Короче, это невозможно

AFAIK, как правило, это двухэтапный процесс:

1. На form.php отправьте данные POST в скрипт process.php.
2. Сценарий process.php обрабатывает данные, но никогда ничего не выводит сам, он всегда вызывает заголовок («Location: asdasd») для перенаправления на страницу success.php или failure.php (если применимо).

Вы можете использовать JavaScript как грязный обходной путь:

<form id = "redirect_form" method = "post" action = "http://someserver.com/somepage.php">
    <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>

(скрипт должен быть под формой)

Действительно ли необходимо после обработки вызывать другую страницу? Я бы, наверное, сделал следующее:

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

display.php:

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

с process.php, содержащим код, необходимый для обработки почтового запроса.

В качестве альтернативы вы можете использовать что-то вроде библиотеки cURL для передачи результатов обработки на страницу, указанную вами. Не знаю, действительно ли это то, что вам нужно.

Сделайте все это в одном скрипте и просто выведите разные HTML для результатов.

<?php  if ($doingForm)  {   ?>

html for form here

<?php } else { ?>

html for results

<? } ?>

Эта проблема беспокоила меня какое-то время. Моя пользовательская CMS выполняет довольно сложную обработку, загрузку и манипулирование, поэтому иногда выдает довольно длинные сообщения об ошибках и информационные сообщения, которые не подходят для преобразования в данные GET, и я всегда хотел избежать проблемы перезагрузки данных INSERT, но пока не нашел адекватного решения.

Я считаю, что правильный способ сделать это - создать массивы сообщений для каждого возможного состояния - каждое сообщение или ошибку, которые вы могли бы отобразить, а затем вам нужно только отправить номера ошибок / сообщений, которые намного проще обрабатывать, чем длинные. строки данных, но я всегда избегал этого лично, поскольку считаю это немного утомительным и громоздким. Честно говоря, это, наверное, просто лень с моей стороны.

Мне очень нравится решение для хранения переменных SESSION, но возникает вопрос, как обеспечить правильное уничтожение данных SESSION? Пока вы гарантируете, что отправляете только информацию (сообщения / ошибки), а не данные, которые должны / могут быть сохранены (и, следовательно, потенциально конфиденциальные), этой проблемы можно избежать.