Login - Jit4All

A small app is split across separate files: one shows a list, another shows a form, and a third saves a new item and sends the visitor back to the list. Each one of these runs as its own, completely separate execution of PHP, with nothing shared in memory between them at all, the moment a link is clicked or a form is submitted. And yet the list correctly grows by one every single time. What is actually carrying that new item from one file's own separate run all the way over to another file's separate run, when nothing is shared directly between them?

Nothing is shared in memory at all between these independent script runs. The only things any of them can rely on are the durable, request-spanning tools already covered in this course: a stored value such as $_SESSION, or a file or database written by one script and read again by another, plus a header() redirect that simply tells the visitor's browser to make a brand-new request next, the same browser that already had a session connected from before. Each script's own ordinary variables vanish completely the moment that one script finishes. Only stored, request-spanning data genuinely persists, and a redirect only controls which request happens next, not what data moves with it.

A small app can be split across more than one file, where one file's job is to show something, and another file's job is to handle a submission and then send the visitor onward with header( "Location: ... " ).

exit;, placed right after a header() redirect, stops the rest of that script's own code from running. Without it, PHP keeps executing every line below the redirect, even though the visitor's browser has already been told to leave for another page.

Splitting a program across several files changes how many files exist. It does not remove or replace any rule already covered earlier in this course, such as escaping output, checking for an empty value after trimming, or using require_once correctly.

A single file can also handle both showing a form and processing its submission, by checking $_SERVER["REQUEST_METHOD"], instead of being split into two separate files at all. Both designs are valid, and the choice mainly affects how many files and requests are involved.

A working small app, built only on this course's earlier tools, is a complete program in its own right, even before anything more advanced, such as a database or a framework, ever gets introduced.

<?php
session_start();

if ( ! isset( $_SESSION[ "items" ] ) )
{
    $_SESSION[ "items" ] = [];
}

if ( $_SERVER[ "REQUEST_METHOD" ] === "POST" )
{
    $new_item = trim( $_POST[ "item" ] ?? "" );

    if ( $new_item !== "" )
    {
        $_SESSION[ "items" ][] = $new_item;
    }

    header( "Location: index.php" );
    exit;
}
?>
<!DOCTYPE html>
<html>
<body>

<form method="post" action="save.php">
    <input type="text" name="item">
    <button type="submit">Add</button>
</form>

<ul>
<?php foreach ( $_SESSION[ "items" ] as $item ) { ?>
    <li><?php echo htmlspecialchars( $item ); ?></li>
<?php } ?>
</ul>

</body>
</html>

Everything from session_start() through exit; represents what a file such as save.php would do on its own. Everything from <!DOCTYPE html> onward represents what index.php would show. In a real, split version of this app, each one is its own separate file.

header( "Location: index.php" ) followed immediately by exit; sends the visitor's browser a brand-new request to index.php and stops the current script from producing any output of its own. Without exit; directly after it, PHP keeps running the rest of the file even though the browser has already been told to leave.

$_SESSION["items"][] = $new_item; only runs when $new_item is not an empty string, after trim(). A visitor submitting the form with nothing typed in it does not add a blank entry onto the list, the same not-empty check from the forms lecture doing exactly the same job here.

The foreach loop building the <ul> reads $_SESSION["items"], the same array the save logic added the new item onto. This works across two genuinely separate requests only because $_SESSION persists between them for the same browser, not because any PHP variable is shared directly between the two scripts.

htmlspecialchars( $item ) appears here for exactly the same reason it appeared in the very first lecture of this course. An item typed by a visitor is still visitor-supplied text the moment it is printed back out in a list, regardless of how many files or steps it passed through to get there.

$new_item, $_POST, and every other ordinary variable inside the saving script's own run are gone completely the instant that script finishes. Only the one line that wrote into $_SESSION carries the new item forward at all into the later request that loads the list.

Removing exit; right after header( "Location: index.php" ) does not stop the redirect from working, but it does let every line below it in the same file keep running anyway, including further session writes, which can cause confusing duplicate effects on a script the visitor's browser has technically already left.

The exact same escaping habit, the exact same trim()-before-empty-check pattern, and the exact same require_once duplicate-protection from earlier lectures all still apply individually inside each file. Combining files into a small app changes how many files exist, not which already-covered rules still matter.

Storing items only in $_SESSION, the way this example does, means clearing browser cookies, switching browsers, or the session simply expiring removes every item ever added, with nothing left over anywhere. A version of this same app meant to keep items permanently would need to write them to a file or a database instead, using the techniques from the saving-information lecture.

A developer testing locally, with no slow code after the redirect line, may never actually notice a missing exit;, because the browser typically moves to the next page before any visible difference shows up. The leftover code after the redirect can still run in full on the server, regardless of how quickly the browser leaves.

When an AI tool writes a small multi-file app, three things are worth checking. First, does every header( "Location: ..." ) redirect get paired with an exit; immediately afterward. Second, does code split across multiple files re-apply this course's established habits, such as escaping and validating, in each file individually, rather than assuming they only need to exist once somewhere in the project. Third, does the app's only storage mechanism, such as a session alone, actually match what the app is supposed to do if data needs to survive longer than one browser's session.

Remove the exit; line after the header() call, add a second line right after it that also appends to $_SESSION["items"], and confirm a single form submission now adds the new item twice.

Submit the add form with the text field left empty, and confirm, by checking $_SESSION["items"] directly, that no blank entry was added.

Replace $_SESSION["items"] with a JSON file read and written using the pattern from the saving-information lecture, so the list survives even after the session itself expires.

Forgetting exit; immediately after a header() redirect, allowing the rest of a script to keep running on the server even after the visitor's browser has already been told to leave for another page.

Building two separate files for showing a form and handling its submission, when the exact same single file, branching on $_SERVER["REQUEST_METHOD"], could do both, adding an unnecessary extra file and an unnecessary extra request for no real benefit.

Re-checking $new_item !== "" only on the page that displays the list, and skipping that exact same check on the page that actually saves it, so a direct, hand-crafted submission straight to the saving script can still add a blank item that the form itself would have blocked.

Assuming a small multi-file app shares one set of session data, or one set of saved items, across every visitor, instead of correctly understanding that each browser gets its own separate, private session and its own separate list.

Treating this lecture's session-only storage as a finished, permanent solution, rather than as a working first version that the saving-information lecture's file-based pattern, or a real database, is meant to eventually replace.

You can now build a small program split across more than one file, where one file handles a submission and another displays a result, and you can correctly identify exactly what does, and does not, survive between those two separate requests. You also have a complete, working example that combines every habit from this course, escaping output, validating before saving, redirecting safely with exit, and choosing the right place to store information, into one functioning small application.