Embedding PHP Inside HTML

The defining move of PHP is that a file can be mostly HTML with executable islands. The server executes the islands and streams the rest verbatim, so a designer can read the file as markup and a developer can see exactly which three lines are dynamic. Here is a complete product template receiving $product and $related:

<?php // templates/product.php ?>
<!DOCTYPE html>
<html lang="en">
<head><title><?= htmlspecialchars($product['name']) ?></title></head>
<body>
  <h1><?= htmlspecialchars($product['name']) ?></h1>
  <p class="price">$<?= number_format($product['price'], 2) ?></p>

  <?php if ($product['stock'] > 0): ?>
    <button data-id="<?= (int) $product['id'] ?>">Add to cart</button>
  <?php else: ?>
    <p class="sold-out">Out of stock — try again later</p>
  <?php endif; ?>

  <?php if ($related !== []): ?>
    <h2>You may also like</h2>
    <ul>
      <?php foreach ($related as $item): ?>
        <li><a href="/product/<?= (int) $item['id'] ?>">
          <?= htmlspecialchars($item['name']) ?>
        </a></li>
      <?php endforeach; ?>
    </ul>
  <?php endif; ?>
</body>
</html>

Notice two structural choices.

Control structures use the alternative syntax in templates. if (...): ... endif; and foreach (...): ... endforeach; are not a different language feature — they compile to the same opcodes as braces — but they exist precisely because a template interleaves PHP with indented HTML. A } floating between </li> and </ul> is unreadable; endforeach; marks the block where the markup's indentation ends. The parser has no trouble with a statement that spans an HTML island, because it parses the complete construct before executing anything:

<?php foreach ($rows as $row): ?>
  <tr><td><?= htmlspecialchars($row['name']) ?></td></tr>
<?php endforeach; ?>

Templates compose with require. A layout is not a framework invention — splitting a page into partials/header.php, partials/footer.php and requiring them works fine:

<?php require __DIR__ . '/partials/header.php'; ?>
<main>…</main>
<?php require __DIR__ . '/partials/footer.php'; ?>

Because require executes the included file in the current scope, $title assigned before the header include is visible inside it. That shared scope is convenient for partials and dangerous for everything else, which the next topics address. The four include functions differ only in what happens when the file is missing: require and require_once raise a fatal error and stop the page, include and include_once raise a warning and continue — so anything the page cannot render without (a layout, a config) is required, and the _once variants guard against double-rendering when a template is pulled in from two places.

A slightly richer layout pattern captures sections with output buffering and lets the page fill them in any order:

<?php // layouts/base.php ?>
<header><h1><?= htmlspecialchars($pageTitle) ?></h1></header>
<main><?= $content ?></main>
<aside><?= $sidebar ?? '' ?></aside>

<?php // page code builds each section, then renders the layout ?>
<?php ob_start(); ?>
  <p>Hero paragraph</p>
<?php $content = ob_get_clean(); ?>

<?php require __DIR__ . '/layouts/base.php'; ?>

This is exactly the machinery frameworks hide from you — a "layout engine" is buffering plus require, nothing more. Once you recognize it, Twig's {% extends %} and Blade's @section stop being magic and become conventions around these two constructs.

One consequence of interleaving: every byte outside the islands — including indentation and the newline after ?> — is output. In a template that is exactly what you want (it is the markup), which is why the "omit the closing tag" rule from Your First PHP Script applies to code files but not to template files. Templates close their tags; libraries do not.

Inside a template, <?= $name ?> is the workhorse, and one fact about it is worth pinning down: <?= has been available unconditionally since PHP 5.4 — it works even on hosts where short_open_tag=Off. It compiles to a plain echo, accepts any expression, and never depends on an ini setting. Use it freely.

Its sibling, the true short tag <? ... ?>, does depend on short_open_tag, and when it is off the parser treats the island as literal text — the browser receives <?php-less source fragments and the page looks scrambled rather than erroring. That failure mode is why <? is banned from most style guides, along with its historical cousin the ASP tag <% %>, removed outright in PHP 7.0. There is also a historical reason short tags lost: in files that are mostly XML or SVG, <?xml ... ?> at the top of the file gets mangled when short tags are enabled.

The tag you use constantly is the one most often misused, because echo performs no escaping:

<meta name="author" content="<?= $author ?>">          <!-- attribute breakout -->
<a href="/search?q=<?= $q ?>">results</a>              <!-- URL needs encoding -->
<p><?= $bio ?></p>                                      <!-- HTML injection -->

Each context wants a different encoder:

<meta name="author" content="<?= htmlspecialchars($author) ?>">
<a href="/search?q=<?= urlencode($q) ?>">results</a>
<p><?= htmlspecialchars($bio) ?></p>

For attributes and element content, htmlspecialchars is the answer; for URL components, urlencode. On PHP 8.1 and later the default flags are ENT_QUOTES | ENT_SUBSTITUTE | ENT_HTML401, so both quote styles are escaped and invalid UTF-8 is replaced instead of producing an empty string — passing ENT_QUOTES explicitly is still good practice for readers on older runtimes.

The classic mistake on the other side of the coin is double encoding: escape on input and output, and Tom & Jerry arrives as Tom & Jerry on the page. The rule that avoids both errors is one-way: store and transport raw text, decode nothing at the boundary, escape exactly once, in the template, at the moment of output. Rich-text fields (sanitized HTML from a CMS) are the single exception — they are emitted with <?= $sanitizedHtml ?> only after an allowlist sanitizer such as HTML Purifier has run on them.

A quick context map keeps the right encoder attached to the right slot:

And one function that looks like an escaper but is not: strip_tags removes tags, it does not encode what remains — a tag stripped of its closing bracket can still carry an event handler. Encoding, not deletion, is the defense.

Templates that must not think about escaping at all exist: Twig autoescapes every {{ $var }} and Blade escapes {{ $name }} while requiring {!! $html !!} for deliberate raw output. Native PHP templates give you no such net — which is the honest trade-off: zero template-engine dependency and full speed, in exchange for one htmlspecialchars per interpolation point, every time.

A template answers one question: how does this data look? The moment it starts answering what does this data mean, the codebase starts rotting. Compare two ways to render an order summary.

<!-- In the template: queries, totals, and permission checks leaking in -->
<?php
$items = $pdo->query("SELECT * FROM order_items WHERE order_id = {$_GET['id']}")->fetchAll();
$total = 0;
foreach ($items as $i) { $total += $i['price'] * $i['qty']; }
if ($_SESSION['user']['role'] === 'admin' || $_SESSION['user']['id'] === $items[0]['owner']): ?>
  <p>Total: $<?= number_format($total, 2) ?></p>
<?php endif; ?>

The controller version moves every decision out and leaves the template formatting only:

// controller
$items = $orderService->itemsFor((int) $_GET['id']);
$total = $orderService->total($items);
$user  = $auth->user();
render('order_summary', [
    'items'     => $items,
    'total'     => $total,
    'showTotal' => $user->isAdmin() || $user->owns($order),
]);

<!-- templates/order_summary.php -->
<?php if ($showTotal): ?>
  <p>Total: $<?= number_format($total, 2) ?></p>
<?php endif; ?>

The separation buys three things that interviewers recognize immediately.

Testability. total() is a unit test with fixture arrays. The template version's total cannot be tested without a database and a session, so nobody tests it, so it breaks silently.

Handoff. A markup-dominant file can be edited by someone who does not write PHP — adjust classes, swap a <div> for a <section>, restyle the price block — with zero risk of touching business rules, because there are none in there.

One place per decision. A permission check that lives in a template is a permission check that will eventually be omitted from one template. Authorization belongs in the controller or a middleware; the template merely renders the flag it is handed.

How does data reach the template without globals? The pattern every framework uses is extraction into a function scope — Laravel's view() ultimately compiles a template into a plain PHP closure where the data array is extracted as local variables, which is why $total is simply there. A five-line homegrown version:

function render(string $template, array $data = []): void {
    extract($data, EXTR_SKIP);   // never overwrite local variables
    require __DIR__ . "/templates/$template.php";
}

Partials share that scope on purpose (a $title set by the page is read by partials/header.php), and section-capture for layouts is just buffering:

ob_start(); require 'partials/sidebar.php'; $sidebar = ob_get_clean();

The testing payoff is concrete. A template reduced to formatting can be exercised directly — render it with a fixture array and assert on substrings:

$html = renderToString('order_summary', ['total' => 12.75, 'showTotal' => true]);
assert(str_contains($html, 'Total: $12.75'));

$html = renderToString('order_summary', ['total' => 12.75, 'showTotal' => false]);
assert(!str_contains($html, 'Total:'));

No database, no session, no HTTP kernel: the test runs in milliseconds and fails precisely when the markup breaks. The same test against a view that queries and computes needs infrastructure scaffolding that most teams never build, which is why logic-laden views ship untested.

This whole chapter is the argument for template engines as well: Twig and Blade are this discipline made syntactic — autoescaping by default, no arbitrary PHP allowed in the template, explicit {!! !!} for raw output. Native templates run faster and carry zero dependencies, but every escaping call and every boundary decision is yours. Either way the line is the same: the template formats data it is given; it never fetches, computes, or authorizes.