PHP in the backend: what happens after a form is submitted?
Between clicking "Submit" and getting a response there are several steps that nobody sees. Anyone who knows them understands why input is validated twice, where error messages come from and why a form is more work than a form.
What you will learn
Six steps, every time
A submitted form input typically goes through the same chain on the server. For interfaces with token authentication, the origin check of the form does not apply; instead, the token check comes first. The order is not arbitrary: each step assumes that the previous one succeeded.
- 1ReceiveThe request is assigned to the right part of the program.
- 2Check originDoes the form really come from this application?
- 3Check permissionsIs this logged-in person allowed to do this at all?
- 4Validate inputRequired fields, formats, business rules.
- 5ProcessSave, calculate, pass on.
- 6RespondSuccess message, new state or error notice.
Validating twice is no oversight
Many forms point out a missing entry while you are still typing. That is a convenience feature and runs in the browser. It is not binding: a browser is a program on a device you do not control, and a request can also be sent without one.
That is why the server checks the same rules again — and only that result decides. When you commission an application, this is a good point to check: if a required field can be bypassed by switching off the browser help, the actual validation is missing.
A special case is business rules that only the server can know: whether a period is still free, whether a balance is sufficient, whether a number already exists. These checks cannot take place in the browser at all, because the answer depends on data that is not there.
The error case is part of the function
A form is judged not by how it behaves with correct input, but with incorrect input. Three things should work reliably:
The last point is the most important and the most expensive. When an operation touches several records, such as an order and its line items, an abort in the middle must be rolled back cleanly. Otherwise you end up with data that nobody can explain.
An example from practice
A request that arrives twice
A visitor clicks "Submit", the response takes a while, and they click again. Without precautions, two identical transactions are created — and someone calls back twice. The remedy is a unique identifier for each submission, a check for identical content received shortly before, and an interface that disables the button after the first click.
Technically this is a small addition. It is only noticed when it is missing — and then at the customer, not in testing.
What happens after saving
Saving is rarely the end of the process. Notifications, transfers to other systems and log entries follow. These follow-up tasks have a property you have to plan for: they can fail without the user noticing.
That is why every such step needs an answer to what happens on failure — try again, inform someone or deliberately skip it. An email that does not arrive is not a technical detail but an unprocessed request.
How to recognise good work
Common misconceptions
Further sources
- PHP manual: form handling basics from the official documentation
- PHP manual: filtering and validating input the built-in validation functions
About the author
Fabian Lücker is the managing partner of PHP-Schmiede KG in Rheine and has worked in software development since 2007. He is responsible for development and concept design, and here he writes about decisions that arise in real projects.
A form that has to do more?
Describe the process in your own words — we will clarify the technical rules behind it together.