Your First PHP Script

Write <?php echo date('H:i'); ?> into a file, request it, and a time appears. The question nobody answers at first is when the code ran. PHP executes on the server, per request, before any of the file's HTML reaches the browser. Trace that once and most "why did my variable disappear" confusion never happens.

Follow one request end to end:

1. The browser sends GET /hello.php to the server.
2. The web SAPI — the built-in server, php-fpm, or Apache — maps the URL to hello.php on disk and hands it to PHP.
3. PHP reads the entire file and parses it into opcodes. One syntax error aborts here, before a single byte of output. This is why a parse error kills the whole page, while a runtime error mid-script can leave a half-rendered page.
4. The engine executes the opcodes top to bottom. Every echo appends bytes to the response body.
5. The SAPI sends headers (200 OK, Content-Type: text/html; charset=UTF-8) followed by the accumulated body.
6. The worker is done. Nothing from this run — no variable, no function definition — is kept for the next request.

Everything in the file that sits outside <?php ... ?> is passed through untouched. That is the whole trick of the language: a .php file is mostly HTML with executable islands.

<!DOCTYPE html>
<html lang="en">
<body>
  <h1>Status board</h1>
  <?php
  $hour = (int) date('G');
  $open = $hour >= 9 && $hour < 18;
  ?>
  <p>Generated at <?= date('Y-m-d H:i') ?></p>
  <p>The office is <?= $open ? 'open' : 'closed' ?></p>
</body>
</html>

Open view-source in the browser: you will see rendered HTML and not one character of PHP. $hour and $open existed for a few milliseconds inside the worker and are gone now. That server-side execution boundary is the security model of the language — credentials, queries, and business rules live in the islands and never ship — and it is also why leaking PHP source (a .php file served as a download or opened via file:// instead of through a SAPI) is treated as an incident.

Seeing the parse step fail is instructive. Delete a semicolon or a brace and request the page with development settings:

PHP Parse error: syntax error, unexpected '}' in hello.php on line 9

Nothing runs — not even the <h1> above the error — because step 3 happens before step 4.

The last piece of the cycle is speed. Parsing and compiling to opcodes happens on every request; OPcache (enabled by default in most production configs since PHP 7) keeps the compiled opcodes in shared memory keyed by file path and modification time, so steady-state requests skip straight to execution. When a deploy edits a file, the timestamp changes and OPcache recompiles it — which is why "I deployed but the old behavior persists" usually means a stale cache rather than a stale file.

Installing PHP and a Local Server gave you the server; now you have the timing model to match it. Next: how output actually gets written.

PHP has two output constructs, one formatting function family, and one rule that has caused more production incidents than any of them.

echo is a language construct with no return value that accepts a comma-separated list, evaluated left to right:

echo "Order #", $id, " for ", $name, "\n";

It is the same as concatenating with . except no intermediate strings are built, which is why hand-rolled HTML templates use it: the pieces of markup stream out directly.

print takes exactly one expression and — the detail interviews probe — it returns 1:

$written = print "saving...\n";   // $written === 1

That return value is the only difference that matters in practice: echo is a statement, print is an expression, so print can legally appear where an expression is required and echo cannot. Nobody writes $x = print ... in real code, but the fact explains the language's asymmetry and shows up in one-liner puzzles.

printf and sprintf do C-style formatting; printf writes, sprintf returns the string:

printf("Order %s: %d units, total %.2f\n", $id, $qty, $total);
// Order A-1042: 3 units, total 12.75

%s string, %d integer, %f float with %.2f precision, %05d zero-padded. Use sprintf when building a string you will pass on rather than print.

The rule: PHP does not escape HTML.

echo "<p>" . $_GET['comment'] . "</p>";   // XSS if comment contains <script>

Anything echoed into markup must pass through htmlspecialchars($value, ENT_QUOTES, 'UTF-8') at the boundary. Unescaped output is historically the most exploited PHP vulnerability class, and a reviewer who sees raw interpolation into markup stops the review there.

Headers and buffering. The first byte of output commits the response headers. After that, changing the status or sending a redirect produces the classic warning:

Warning: Cannot modify header information - headers already sent by
(output started at hello.php:3) in hello.php on line 7

So session_start() and header('Location: /login') must run before any output — including stray whitespace. When you must compute before deciding on output, wrap the work in ob_start() / ob_get_clean() to buffer it silently.

For inspection there is var_dump($x), which prints type and value (string(5) "hello", int(42)), print_r for readable structure (print_r($x, true) returns the string instead of printing it — handy for logging into a file), and var_export for output that is itself valid PHP, which matters when generating config files or test fixtures. Locally you run with display_errors=On; in production that setting belongs to the log, not the page.

Two output targets beyond the response body round out the picture. In CLI scripts you write to the standard streams directly — fwrite(STDERR, "failed: $reason\n") — so a CI log can separate your diagnostics from the data your script prints to STDOUT. And for large payloads you do not have to build a string at all: readfile($path), fpassthru($fh), and echo json_encode($rows, JSON_PRETTY_PRINT) all stream bytes to the response without an intermediate variable, which is how PHP serves a 200 MB export without exhausting memory_limit.

A common first script:

<?php
$visits = ($visits ?? 0) + 1;
echo "You are visitor number $visits";

It always prints 1. Not because the arithmetic is wrong, but because no variable survives the request. Each hit starts a brand-new execution with a fresh symbol table; $visits never existed before line 1 and is discarded after the echo.

Real state lives in places that outlive a request:

And each request arrives with its inputs already assembled in superglobals — $_GET (query string), $_POST (form body), $_COOKIE, $_SERVER (method, path, headers). They are populated by the SAPI before your first line runs, which is why there is no "load the request" step in PHP: the data is simply there. A few $_SERVER keys earn permanent residency in your muscle memory:

$_SESSION deserves one extra note because it looks like an exception: it is not. session_start() reads the session id from the PHPSESSID cookie, loads that id's stored data (a file by default) into $_SESSION, and writes it back at shutdown. The data still lives outside the process — the superglobal is only the per-request window onto it.

The other half of the per-request model is the statement terminator. A semicolon ends a statement, not a line. Two statements on one line are legal; one statement across three lines is legal until the ;. Omit it and the parser stops at the next token:

PHP Parse error: syntax error, unexpected 'echo' in hello.php on line 3

Because parsing happens for the whole file before execution, that error means nothing in the file ran — unlike languages with line-by-line evaluation, there is no partial state to clean up. PHP ships a command that checks exactly this without running anything:

php -l hello.php    # No syntax errors detected in hello.php

Teams wire php -l into pre-commit hooks and CI so a parse error fails the build in seconds instead of taking down a page in production.

One more habit separates PHP files from PHP templates. In a file that is pure PHP (a class, a config, a library), omit the closing ?> tag. Everything after it — including the newline your editor adds — is output bytes. If such a file is ever required before headers are sent, that invisible newline triggers the headers-already-sent warning from the previous chapter. Templates that are mostly HTML do close their tags; code files do not.

By the time you move to Embedding PHP Inside HTML you should be able to predict, for any snippet, what bytes the browser will receive and when the code ran.