../courses.php

Procedural PHP

PHP

90

Saving Information With PHP

Why writing a file can erase everything that was in it a moment ago.

A page saves a visitor's note to a file using file_put_contents( "notes.txt", $note );, and it works perfectly the first time. The second time a different visitor submits a note, the entire file only contains the second note. The first visitor's note is gone completely, even though nothing deleted it directly. Why would saving a second piece of information erase the first?

file_put_contents(), called with no extra flag, replaces the entire file's previous contents every single time it runs, by default, rather than adding new content onto what is already there. The second call does not delete the file as a separate step. It simply replaces everything the file held, because that is this function's default behavior, unless the FILE_APPEND flag is passed as a third argument, or the existing contents are read and combined first.

file_get_contents() reads an entire file's contents into a single string in one call. file_put_contents() writes a string out to a file in one call, creating the file if it does not already exist.

Most information saved this way needs structure beyond a single block of text, such as a growing list. json_encode() turns a PHP array into one text string that can be saved, and json_decode() turns that same string back into a PHP array later.

Saving new information safely, when something should be added rather than replaced, normally means three steps in order: read whatever already exists, change that in memory, then write the whole, updated result back out.

Both file_get_contents() and file_put_contents() can fail, returning false instead of stopping the script outright, most often because the file or folder does not have the right permissions for the server to read or write.

Information saved to a file this way survives after the request that wrote it finishes, which is different from an ordinary variable, gone the moment its own request ends, and different from a session value, tied to one visitor's browser alone.

Adding one note onto a growing list saved as a JSON file

file_get_contents( $file ) reads the entire current contents of notes.json into one string. If the file does not exist yet at all, this specific call produces a warning and returns false instead of stopping the program outright.

json_decode( $existing_data, true ) turns that one long string back into a real PHP array. The second argument, true, is what makes the result an array instead of an object, which matters for whether $notes[] = ... works at all on the next line.

The ?? [] right after json_decode(...) supplies an empty array specifically for the very first save, when the file does not exist yet and $existing_data came back false, which json_decode() would otherwise turn into null rather than a usable array.

$notes[] = $_POST["note"] ?? ""; adds exactly one new note onto the array already read from the file, in memory, before anything is written back out. Nothing is saved to disk yet at this exact point.

json_encode( $notes ) converts the entire, now-updated array back into one single string, and file_put_contents() writes that whole string out, replacing the file's previous contents entirely with a new, complete version that already includes every old note plus the new one.

file_put_contents replaces the whole file by default

Calling file_put_contents( $file, $new_text ) with no third argument removes everything the file held before and replaces it entirely with $new_text. Saving a second, unrelated note this way, without reading the file first, would leave exactly one note in the file, the most recent one, with the first one gone.

Two visitors saving at almost the same moment can overwrite each other

If two notes are submitted within a fraction of a second of each other, both requests can read the same starting file contents before either one writes anything back, and the second write to finish still simply replaces the file. Whichever request's write call finishes last wins, and the other visitor's note is lost with no error reported to either of them.

A file that does not exist yet is not automatically an error

file_get_contents() on a file that has never been created returns false, with a warning, rather than stopping the script. The ?? [] in this code specifically exists to turn that false, by way of json_decode() producing null, into a normal, empty array, so the very first save still works correctly.

json_encode and json_decode must agree on whether something is an array or an object

json_decode( $string, true ) produces an array, but json_decode( $string ) with no second argument produces an object instead, where $notes[] = ... would fail outright. Mixing these two forms across different parts of the same program is a common, easy-to-miss source of a fatal error.

Writing to a file requires the server to actually have permission to write there

file_put_contents() returns false, and produces a warning, rather than stopping the program outright, when the server process does not have permission to write to the given folder. A save that silently does nothing, with the page still loading normally, is a common sign of exactly this kind of permissions problem rather than a mistake in the PHP code itself.

Overwriting the file with each new note

Reading, updating, then writing the whole file back

When an AI tool writes file-saving code, three things are worth checking. First, does it read the file's existing contents before writing, whenever the goal is to add to what is already there rather than replace it. Second, does it check what file_get_contents() or file_put_contents() actually returns, since both can fail and return false instead of stopping the script. Third, does json_decode() get called with the right second argument to match how the rest of the code expects to use the result, as an array or an object.

Remove the ?? [] from this lecture's code, delete notes.json if it exists, and submit a note to see exactly what error appears on the very first save.

Submit three notes in a row and open notes.json directly afterward to confirm all three are present together, not just the most recent one.

Change file_put_contents( $file, json_encode( $notes ) ); to file_put_contents( $file, $_POST["note"] ?? "" ); instead, to recreate the overwrite problem from the why cards on purpose, then undo the change.

Call json_decode() without its second argument anywhere in this code, and read the resulting error when $notes[] = ... runs immediately afterward.

Predict what count( $notes ) will print the very first time the page is ever submitted, before notes.json exists at all, then run it to check.

Calling file_put_contents() without first reading the file's existing contents, whenever the goal was actually to add new information rather than replace everything.

Assuming file_get_contents() on a missing file behaves the same as reading an existing but empty file. One produces false with a warning. The other produces a real, empty string with no warning at all.

Storing structured information, such as a list of notes, as plain comma-separated text instead of a format such as JSON, then writing custom code to split it back apart later, which breaks the moment any single note happens to contain a comma itself.

Trusting that a save always succeeds just because the page finished loading without any visible error. file_put_contents() returning false on a permissions problem does not stop the rest of the page from running normally afterward.

Forgetting that two requests arriving close together can each read the file before either has written anything back, so both saves still go through individually, but the second one's write fully replaces the first one's, even though both believed they were only adding one new note.

You can now explain why file_put_contents() must be paired with reading the file first whenever new information should be added rather than replace what is already saved. You can also describe the specific situation where two visitors saving information close together can cause one of them to be silently lost.