It’s bad bad bad when you use form method="post" and your user hits the back-arrow afterwards…

… unless you use an approach I knew was possible, but never tried before a project I’m doing now.

Goes roughly like this:

————– someform.html —–
<form action="action.php" method="post">
<input type="hidden" name="action" value="delete" />
<input type="hidden" name="id" value="12345" />
<input type="submit" name="submit" value="delete this" />
</form>
—————————————–

————– action.php ———
switch($_POST[’action’]) {
case ‘delete’:
$id = intval($_POST[’id’]);
$db->query("DELETE FROM something WHERE id=$id");
header(’Location: menu.php’);
break;
case ‘add’:
# blah blah - your "add" actions stuff here
header(’Location: newentry.php’);
break;
}
—————————————–

Have *ALL* forms on all pages all posting to the same action.php page, which has a switch/case looking for the correct action, then using HTTP header-location to send them off to the next page. If they use their back-arrow now, no problem! It will never re-post the form.

(As a variation on this, I guess you could have lots of little PHP pages catching lots of form-post actions, then header-redirecting, but I was just trying to keep them all in one place.)

Only problem I had with this approach is that I like to alert the person who did some action that the action has been done! I added an Alert class with just two public methods: add and show. (Private methods are load and save, used at __construct and __destruct, respectively.) Now your action.php file can add an alert to the Alert class, then header-redirect off to any page you’d like, as long as the destination page has Alert::show where you want the saved alert to appear.

Anyway - I’ll bet this approach has been done before in a way I hadn’t thought of, but this is how I’m doing it for now, and I like the way it works so far. I’d love to hear from anyone else with a different approach to solving the form-post back-arrow conflict.

different approach to solving the form-post back-arrow conflict?