Start Here

Start Here

This course teaches PHP by asking you to read a small idea, run an example, change it, and solve a related task. The first goal is therefore not to understand the entire language or build a web application. It is to establish a dependable feedback loop between your editor, the PHP runtime, and the terminal.

By the end of this lesson, you should be able to create a PHP file, run it deliberately, recognise whether the expected file ran, and use an error message as evidence rather than as a reason to guess.

Who This Is For

This lesson is for learners who may be completely new to PHP. You are not expected to know Composer, Laravel, databases, object-oriented programming, frameworks, or web servers yet.

You will use a terminal, but only for a few small commands. Basic terminal use is introduced gently as you need it.

Expected time: 20-40 minutes. It may take longer if PHP is not installed yet.

What You Need

You need three things for the early lessons:

  • a PHP command-line runtime;
  • a plain-text code editor;
  • a terminal in which you can run commands.

Check whether PHP is available:

php -v

A working installation prints version and build information. The first line normally begins with PHP followed by a version number. This course uses PHP 8.5.6 as its default language baseline, although later tracks explain older versions and compatibility decisions.

Stop here if php -v fails. Do not continue by copying example output. Use the setup lesson for your operating system first:

Then return to this lesson and run php -v again. The official PHP installation documentation remains the primary reference when you need more detail.

Your editor must save plain text. Visual Studio Code, PhpStorm, Zed, Sublime Text, and other programming editors are suitable. A word processor is not: it can insert formatting or typographic quotation marks that are not PHP source code.

Create A Course Workspace

Keep course work in a dedicated directory. A predictable workspace makes it easier to know which file a command is running and prevents examples from being scattered across downloads and temporary folders.

A possible structure is:

php-from-zero/
  00-start-here/
  01-language-basics/
  experiments/

The exact names do not matter. What matters is that you can find the directory again, open it in your editor, and open a terminal in the same location.

Before running a file, ask two questions:

  1. Which directory is this terminal currently using?
  2. Which exact file will the command execute?

On macOS and Linux, pwd prints the current directory. In PowerShell, Get-Location does the same. Most terminals also show part of the current path in their prompt.

List the files when you are uncertain:

ls

In PowerShell, Get-ChildItem or its ls alias lists the directory. Shell commands are covered more carefully later; for now, use the listing only to confirm that the PHP file exists where you think it does.

Write Your First PHP File

Create first.php in the workspace:

PHP example
<?php

declare(strict_types=1);

echo "My first PHP script", PHP_EOL;

// Prints:
// My first PHP script

The opening <?php tells the interpreter that PHP code follows. This course normally includes declare(strict_types=1); in complete files. You are not expected to fully understand that line yet. It is included now so every PHP file follows the same safe shape from the beginning.

echo sends text to standard output. PHP_EOL adds the normal line ending for the current platform so the terminal prompt begins on the next line.

The final two lines are comments. PHP ignores text after // on those lines. The comments document the expected output; they are not produced automatically.

Save the file, then run it from the directory containing it:

php first.php

The terminal should display:

$ php first.php
My first PHP script

The output itself is:

My first PHP script

This proves several separate things:

  • the php command resolves to an executable;
  • the runtime can read the selected file;
  • the file contains valid syntax;
  • the instruction reached the output stream.

A copied screenshot or expected-output comment proves none of those things. Run the code yourself.

Build The Edit-Run-Observe Loop

Change the message to something unmistakably different:

PHP example
<?php

declare(strict_types=1);

echo "I changed and reran this file", PHP_EOL;

// Prints:
// I changed and reran this file

Save it and run the same command again:

php first.php

The output should change. This short cycle is the central working habit for the beginning of the course:

  1. Read the current code.
  2. Predict what it will do.
  3. Run it.
  4. Compare actual output with the prediction.
  5. Change one relevant detail.
  6. Save and rerun.
  7. Explain why the result changed.

Prediction matters. If you only run code and accept whatever appears, you are observing without testing your understanding. A wrong prediction is useful because it identifies a specific idea to revisit.

Change one thing at a time while learning. If you rename the file, rewrite the code, move directories, and change the command together, a failure leaves four possible causes. A small change produces clearer evidence.

Know Which File You Ran

The terminal executes the path supplied to php; it does not know which editor tab you intended.

Suppose first.php contains a new message, but you run:

php test.php

PHP executes test.php. If that file contains an older message, the old output is correct for the command even though it is not what you wanted.

When output appears stale, check in this order:

  1. Save the editor buffer.
  2. Read the filename in the terminal command.
  3. Confirm the terminal directory.
  4. List the directory and verify the file exists.
  5. Add a temporary distinctive message if two files look similar.
  6. Run the exact file again.

Do not respond by reinstalling PHP or changing unrelated code. First establish which bytes the runtime actually read.

File extensions can also be misleading on systems that hide known extensions. A file displayed as first.php might actually be named first.php.txt. Configure the file browser to show extensions or confirm the name from the terminal.

Read Errors From The Beginning

Errors are part of the feedback loop. Deliberately remove the closing quote from the message:

<?php

declare(strict_types=1);

echo "This string does not end, PHP_EOL;

Running the file produces a parse error. The exact wording can vary by PHP version, but it identifies a syntax problem and gives a file and line number.

Read the message from its beginning. Useful questions are:

  • Is this a parse error, warning, or uncaught exception?
  • Which file is named?
  • Which line is named?
  • Did the mistake begin on an earlier line?
  • What token was PHP expecting or surprised to find?

A parser often reports where it became impossible to continue, not necessarily where the mistake began. An unclosed quote or bracket can make the next line look faulty. Inspect the named line and the lines immediately above it.

Restore the quote and rerun the file. Fixing a controlled mistake teaches more than treating every red message as an emergency.

Use Course Examples Actively

Each lesson article explains a focused subject. Many PHP blocks include expected output and a Run / edit action that opens the example on 3v4l.org. That external runner is useful for comparing PHP versions or trying a snippet quickly, but it does not replace a local environment. File paths, databases, web requests, extensions, and project dependencies often require local tools.

When studying an example:

  1. Read it before running it.
  2. Identify unfamiliar syntax.
  3. Predict the output or failure.
  4. Run the exact example.
  5. Make one small change.
  6. Restore it or keep the experiment in a separate file.

Do not paste large examples into one permanent scratch file. Old variables, functions, and output can affect later experiments. Use one file per example or clear the file deliberately.

The practice cards appear after the lesson. Attempt the task before opening its solution. A solution is one clear implementation, not text to memorise. Compare it with your work by asking:

  • Does my result satisfy every requirement?
  • Did I handle the named edge case?
  • Is my output visible and correct?
  • Can I explain each line I wrote?
  • Did the solution reveal a language rule I missed?

If you copied the solution, change its input or wording and rerun it until you can predict the new result.

Keep Experiments Separate From Answers

It is useful to break code intentionally, print intermediate values, and try alternatives. Keep those experiments distinct from the final exercise answer.

For example:

00-start-here/
  first.php
  first-broken-quote.php
  exercise-01.php

Clear names preserve the evidence of what each file is for. Names such as new.php, test2.php, and final-final.php become difficult to distinguish.

Do not store passwords, API keys, production data, or private customer information in course files. Later lessons cover environment variables and secret handling, but the safe habit begins now.

Common First Mistakes

  • The file was changed in the editor but not saved.
  • The terminal is open in a different directory.
  • The command runs the wrong file.
  • The file is accidentally named first.php.txt instead of first.php.
  • Expected-output comments such as // Prints: describe output; they are not output themselves.
  • PHP errors often point near the problem, but not always exactly at the original cause.

When You Are Ready To Continue

Before moving to the introduction, confirm that you can:

  • run php -v and identify the version line;
  • create and save a .php file as plain text;
  • open a terminal in the correct directory;
  • run a named file with php filename.php;
  • change the file and observe changed output;
  • distinguish expected-output comments from actual output;
  • diagnose a wrong filename or unsaved file;
  • read the file and line named by a parse error;
  • attempt a practice task before reading its solution.

These are small operational skills, but every later PHP topic depends on them. A reliable edit-run-observe loop lets you investigate language behaviour directly instead of depending on memory or guesswork.

Practice

Run And Verify Your First Script

Create a new directory for this exercise and add first.php containing a complete PHP script.

Requirements

  • Include the PHP opening tag and declare(strict_types=1);.
  • Print PHP is ready followed by a platform-appropriate line ending.
  • Add expected-output comments in the same PHP block.
  • Save the file and run it from its containing directory with php first.php.
  • Change the message to PHP is ready for changes, save, and run it again.
  • Record both terminal outputs and explain what the changed output proves.

Do not use a browser or an online runner for this task. The purpose is to verify your local editor-terminal-runtime loop.

Show solution
PHP example
<?php

declare(strict_types=1);

echo "PHP is ready", PHP_EOL;

// Prints:
// PHP is ready

Run it from the directory containing first.php:

php first.php

The first terminal output is:

PHP is ready

After changing and saving the source, the file becomes:

PHP example
<?php

declare(strict_types=1);

echo "PHP is ready for changes", PHP_EOL;

// Prints:
// PHP is ready for changes

Run the same command again. The second output is:

PHP is ready for changes

The changed output proves that the editor saved the new source and that the terminal command executed that same file. It does not prove only that PHP is installed; php -v already checks the runtime. This exercise verifies the complete edit-save-run-observe loop.

Diagnose The Wrong File
first.php
status.php

You changed first.php so it should print new first message, but this command still prints old status message:

php status.php

Write a short diagnosis and verification procedure.

Requirements

  • Identify why the output is correct for the command but wrong for the developer's intention.
  • State how to confirm the terminal's current directory and list its files on your operating system.
  • Give the corrected command.
  • Include one way to prove the intended file was saved and executed.
  • Explain why reinstalling PHP or changing both files would be a poor first response.
Show solution

The command explicitly asks PHP to execute status.php, so old status message is valid output for that command. Editing first.php does not change what status.php prints.

First confirm the terminal location. On macOS or Linux:

pwd
ls

In PowerShell:

Get-Location
Get-ChildItem

Verify that first.php appears in the listing, save it in the editor, and run:

php first.php

A distinctive message such as new first message proves that the intended file ran. If uncertainty remains, temporarily add the filename to its output, rerun it, and remove the diagnostic text afterward.

Reinstalling PHP is not justified because the runtime successfully executed status.php. Changing both files would remove the useful distinction between them and make it harder to identify which command caused the observed output. The smallest supported diagnosis is a filename mismatch.

Introduce And Repair A Parse Error

Start from a working first.php, then remove the closing quote from its output string and run the file.

Requirements

  • Preserve the failing command output long enough to identify the error category, filename, and reported line.
  • Inspect the reported line and the line immediately above it.
  • Restore the missing quote without changing unrelated code.
  • Run the repaired script and show the expected output The syntax is fixed.
  • Explain why PHP can report a line after the place where a quote or bracket was originally left open.

Use a disposable copy if you want to keep the original first script unchanged.

Show solution
<?php

declare(strict_types=1);

echo "The syntax is broken, PHP_EOL;

Running php first.php produces a parse error. Exact wording and the reported line can vary by PHP release, so the useful evidence is the error category, named file, and nearby source rather than memorising one message.

The repaired file is:

PHP example
<?php

declare(strict_types=1);

echo "The syntax is fixed", PHP_EOL;

// Prints:
// The syntax is fixed

Run:

php first.php

PHP now prints:

The syntax is fixed

A parser reports the point where the source can no longer be interpreted consistently. An opening quote or bracket changes how subsequent characters are read, so PHP may only become certain that the source is invalid on a later line. Inspecting the reported line plus the lines immediately above it is therefore more reliable than editing only the final token named in the error.