Introduction To PHP

PHP is a general-purpose programming language with a strong history in server-side web development. It can generate HTML, expose JSON APIs, process forms, communicate with databases, run scheduled jobs, consume queues, build command-line tools, and automate maintenance work.

A PHP program can be one short file or part of an application containing thousands of classes and dependencies. The language used in both cases is the same. What changes is the execution environment, the inputs available to the program, and where its output goes.

This lesson establishes that mental model before the course introduces PHP syntax in depth.

Source Code Needs A Runtime

A .php file is plain text containing PHP source code. The file does not execute itself. A PHP runtime must read, parse, and execute it.

When you run:

php first.php

three relevant pieces are involved:

php selects the command-line PHP executable;
first.php selects the source file passed to that process;
the terminal receives the process's standard output and errors.

The source remains in the file. Output is produced by one execution of that source. Changing terminal output does not edit the file, and editing the file does not affect a process that has not been run again.

A simple script makes the relationship visible:

PHP example

<?php

declare(strict_types=1);

echo "Source file: ", __FILE__, PHP_EOL;
echo "Runtime: ", PHP_VERSION, PHP_EOL;

__FILE__ is a magic constant containing the full path of the current source file. PHP_VERSION identifies the runtime executing it. Your path and version will differ from somebody else's, even when both people use identical source code.

PHP Can Run In Different Contexts

The first course examples use PHP CLI, the command-line interface. It gives a short feedback loop and makes output easy to inspect.

PHP also commonly runs behind a web server. In a web request, a server selects a PHP entry point, provides request information, and sends the program's response back to a browser or API client. Output that appeared in a terminal during CLI execution may become part of an HTTP response in web execution.

PHP can also run as:

a long-lived queue worker;
a scheduled command;
a one-off deployment or migration task;
an application server worker;
an interactive shell session;
code embedded in a larger tool.

The execution context affects available inputs, configuration, process lifetime, permissions, current directory, environment variables, and output destination. It does not create a separate PHP language.

For example, this code is valid in both CLI and web execution:

PHP example

<?php

declare(strict_types=1);

echo "Hello from PHP", PHP_EOL;

In a terminal, the text appears in standard output. In a web request, the text can become response content. Later lessons explain why production web applications should construct deliberate responses rather than freely echoing diagnostic text.

Server-Side Does Not Mean Browser-Side

In a conventional PHP web application, the browser does not receive PHP source code. The server executes PHP and sends the resulting response, such as HTML or JSON.

Consider a PHP file that produces HTML:

PHP example

<?php

declare(strict_types=1);

$pageTitle = "PHP From Zero";
?>
<!doctype html>
<html lang="en">
<head>
    <meta charset="utf-8">
    <title><?= htmlspecialchars($pageTitle, ENT_QUOTES, 'UTF-8') ?></title>
</head>
<body>
    <h1><?= htmlspecialchars($pageTitle, ENT_QUOTES, 'UTF-8') ?></h1>
</body>
</html>

The client receives the generated HTML. Variables, function calls, and other PHP instructions are executed on the server. This distinction matters for security: secrets must not be printed into the response, and client-side behaviour cannot directly call an arbitrary PHP function without making a request to a server endpoint.

JavaScript commonly runs in the browser, although it can also run on servers. PHP commonly runs on servers, although it can also run entirely from a terminal. The runtime location, not the file extension alone, determines what resources and responsibilities the program has.

PHP Is More Than Page Templates

PHP began as tooling for dynamic web pages, but modern PHP applications often separate concerns into routes, controllers, services, domain objects, database layers, message handlers, and tests. Frameworks such as Laravel and Symfony provide conventions and components for those applications. Composer installs reusable packages and records dependency constraints.

The language itself remains important beneath every framework. A developer still needs to understand:

values and types;
operators and control flow;
functions and error handling;
arrays, strings, dates, and standard-library APIs;
objects, interfaces, namespaces, and exceptions;
files, requests, databases, and external services;
testing, static analysis, security, and runtime behaviour.

This course teaches those foundations before relying heavily on a framework. Framework knowledge is easier to transfer when you can distinguish a PHP rule from a framework convention.

Identify The Runtime You Are Actually Using

Check the CLI runtime with:

php --version

The first line identifies the PHP version. Additional lines can identify the build type, thread-safety mode, Zend Engine, and enabled Zend extensions such as OPcache or Xdebug.

For machine-readable output, PHP exposes constants:

php -r 'echo PHP_VERSION, PHP_EOL;'

The -r option executes the supplied PHP code without requiring a <?php opening tag. It is convenient for a short inspection command. It becomes awkward for multi-line programs, quoting, reusable work, and code review; use files for course exercises and application code.

A more structured version check is:

PHP example

<?php

declare(strict_types=1);

printf(
    "PHP %s (%d)%s",
    PHP_VERSION,
    PHP_VERSION_ID,
    PHP_EOL,
);

// Example shape:
// PHP 8.5.6 (80506)

PHP_VERSION_ID encodes major, minor, and patch numbers as an integer. The exact value depends on the runtime. Do not hard-code the example output as evidence that your machine uses that release; run the script.

The CLI runtime is not guaranteed to match the runtime serving a website. A machine can have several PHP installations, containers, PHP-FPM pools, or hosting configurations. The runtime and server tracks later show how to inspect each context.

Understand The Course Baseline

The curriculum uses PHP 8.5.6 as its default baseline. Examples may use modern syntax available in that release. The dedicated version guide explains features, deprecations, removals, and migration concerns from PHP 7.0 onward.

A course baseline means:

examples are designed for that language level unless stated otherwise;
expected behaviour is checked against that runtime family;
older environments may reject newer syntax before execution begins;
professional projects can choose a different minimum version.

It does not mean every production application already runs PHP 8.5.6. Real repositories declare and verify their own compatibility constraints. When reading an existing project, check its Composer requirement, CI matrix, deployment runtime, and dependency support before using a newer feature.

Programs Receive Input And Produce Effects

A useful way to reason about any PHP program is to identify:

its entry point;
its inputs;
the transformations it performs;
its outputs and side effects;
its failure path.

For the first CLI script:

entry point: first.php;
input: the source file and process environment;
transformation: execute the echo instruction;
output: terminal text;
failure path: syntax or runtime errors sent to the error stream.

A web application adds request methods, URLs, headers, cookies, and bodies as inputs. A database migration changes persistent schema. A queue worker receives messages and may send email. This entry-input-effect model scales from a five-line script to a production service.

Errors Are Runtime Evidence

PHP can fail at different stages. A syntax error means the parser could not build a valid program. A type error means an executed operation received an incompatible value. An uncaught exception means code reported a failure that nothing handled. A warning can report a problem while execution continues.

Do not reduce all of these to "PHP is broken." Record:

the command or request that reproduced the issue;
the PHP version and execution context;
the complete first error;
the named file and line;
the smallest input that still fails.

That evidence lets you distinguish a language problem, configuration problem, missing extension, application defect, or wrong command.

What This Course Will Ask You To Do

You will write scripts, web endpoints, object-oriented code, database operations, tests, and deployment-oriented configuration. Examples are intentionally small when a language rule is new and become more integrated as the course progresses.

For each topic, aim to do more than recognise syntax. You should be able to:

predict behaviour;
run and inspect it;
explain the rule in your own words;
apply it to a slightly different input;
identify an important failure case;
choose when the feature is appropriate.

PHP proficiency is not memorising every built-in function. It is being able to form a model, consult accurate documentation, test assumptions, and maintain the result in a real execution environment.

Before Moving On

You are ready for the runtime-path lesson when you can explain:

the difference between a PHP source file and one execution of it;
why PHP needs a runtime;
where CLI output goes;
why a browser normally receives generated output rather than PHP source;
why CLI and web PHP can report different versions or configuration;
what the course's PHP 8.5.6 baseline does and does not promise;
how an entry point, inputs, effects, and failures describe a program.

The following lessons turn this model into a working local environment and show how PHP configuration, extensions, and execution modes fit together.

Practice

Record The Runtime Identity

Run the CLI version command and create a short PHP script that reports the runtime executing it.

Requirements

Run php --version and record the complete first line.
Create runtime.php that prints PHP_VERSION, PHP_VERSION_ID, and PHP_SAPI with labels.
Include expected-output comments that describe the output shape without claiming a version you did not observe.
Run the file with php runtime.php.
Explain which values identify the release and which value identifies the execution interface.
State whether this result alone proves that a separately configured website uses the same PHP runtime.

Show solution

php --version

Your first line depends on the installed build. Record it rather than copying somebody else's version.

A suitable runtime.php is:

PHP example

<?php

declare(strict_types=1);

echo "Version: ", PHP_VERSION, PHP_EOL;
echo "Version ID: ", PHP_VERSION_ID, PHP_EOL;
echo "SAPI: ", PHP_SAPI, PHP_EOL;

// Output shape:
// Version: <major.minor.patch>
// Version ID: <integer version identifier>
// SAPI: cli

Run it with:

php runtime.php

PHP_VERSION is the readable release string. PHP_VERSION_ID is its numeric form. PHP_SAPI identifies the Server API used for this process; running the file through the php command should report cli.

This result identifies only the CLI process you launched. A website may be served by PHP-FPM, Apache integration, a container, or another installed PHP binary with a different version and configuration. Inspect that execution context separately.

Compare Inline Code With A Source File

php -r 'echo PHP_VERSION, PHP_EOL;'

Then create a source file that prints the same value.

Requirements

Predict the inline command's output before running it.
Explain why code passed to -r does not include the <?php opening tag.
Create a complete file with an opening tag and declare(strict_types=1);.
Run the file and compare its output with the inline command.
Name two reasons a file is preferable for a multi-line course exercise.
Explain why the expected-output comments inside a source file are not themselves terminal output.

Show solution

php -r 'echo PHP_VERSION, PHP_EOL;'

The -r option receives code directly, so an opening <?php tag would be treated as invalid input. A source file does need the opening tag:

PHP example

<?php

declare(strict_types=1);

echo PHP_VERSION, PHP_EOL;

// Prints the installed PHP version followed by a line ending.

If the file is named version.php, run:

php version.php

Both executions use the same CLI command and should report the same runtime version. A file is preferable for multi-line work because it avoids complicated shell quoting, remains available for reruns and review, and can be formatted or analysed by editor tooling.

The expected-output line begins with //, so it is a PHP comment. PHP ignores it. Only the echo instruction produces terminal output.

Diagnose An Unavailable PHP Command

A learner runs php --version and receives a shell message saying that php cannot be found or is not recognised.

Write a diagnosis plan that separates installation from command resolution.

Requirements

Explain what the shell error proves and what it does not prove.
Check whether PHP CLI is installed for the operating system.
Check whether the executable is available on PATH.
Account for a machine with multiple PHP versions or a container-only project runtime.
Give a final verification command and describe the evidence required before continuing.
Do not recommend editing PHP source code, enabling random extensions, or reinstalling unrelated web-server software.

Show solution

The shell message proves that it could not resolve a command named php in the current environment. It does not prove that no PHP executable exists anywhere on the machine, nor does it identify a PHP syntax problem.

Use this sequence:

Confirm that a PHP CLI package or executable is installed using the operating-system-specific setup instructions.
Locate the executable through the package manager, installation directory, command -v php on a POSIX shell, or Get-Command php in PowerShell.
If PHP exists but is not found by name, correct the shell's PATH or use the documented version-manager command.
If several versions exist, identify which executable should own the php command and avoid changing links blindly.
If the project intentionally runs only in a container, use its documented container command rather than assuming a host installation.

Verify the result with:

php --version

Continue only when the command exits successfully and its first line identifies the intended PHP release. Extensions and web-server configuration are separate concerns; changing them does not repair a shell that cannot locate the CLI executable.