PHP
How does a browser request become a page or a JSON response? Begin with one PHP file, one exact command, and one visible result. Then learn values, decisions, functions, arrays, form input, HTTP messages, sessions, files, objects, and errors in the order a small server-side program needs them. Database access, authentication, packages, tests, application structure, caching, background work, and deployment come later. Each chapter states what its local example proves and what still needs a real Web server, database, credential store, workload, and production environment.
Runtime, web server, and Composer setup
Objective Run PHP from CLI and a Web server with reproducible dependencies.
Core explanation
PHP executes scripts per CLI command or Web request. php.ini controls runtime behavior, extensions, limits, and error reporting. Composer manages package versions and autoloading. Development should display errors locally but log safe diagnostics in production. CLI, the built-in development server, Apache modules, CGI, and PHP-FPM have different process, configuration, and concurrency behavior. Inspect the loaded php.ini and extensions for the actual SAPI instead of assuming CLI matches production. Pin the supported PHP and Composer platform, commit composer.lock for applications, install from it without development packages in production, and verify extension requirements. Keep one public front controller under the document root while source, configuration, vendor metadata, uploads, and secrets remain inaccessible. Treat OPcache, memory, execution time, upload, session, and error-display settings as versioned deployment configuration.
Understand the PHP request and CLI execution models
PHP executes an entry script inside a configured runtime. A CLI process usually serves one command, while a traditional Web deployment routes each HTTP request through a Web server and PHP-FPM worker. Source is compiled to opcodes and may be cached, but application globals, loaded extensions, ini settings, environment, working directory, and process permissions still shape behavior. Treat the runtime configuration as part of the program.
Map browser, reverse proxy, Web server, FPM pool, application entry point, dependencies, database, cache, and response. Distinguish a PHP syntax or type error, Web-server routing failure, proxy timeout, FPM exhaustion, unavailable extension, dependency autoload error, application exception, and invalid HTTP response. Preserve request identity and the earliest safe diagnostic instead of reporting every failure as a generic page.
Create a deterministic Composer project and autoloader
Composer resolves declared packages and writes an exact lock file plus generated autoload metadata. Commit composer.json and composer.lock for an application, validate platform PHP and extension requirements, and install with the lock rather than updating during deployment. PSR-4 maps namespace prefixes to directories; class names and paths must match case on case-sensitive production filesystems even if a development machine is forgiving.
The public document root should contain a narrow front controller and static assets, not secrets, source control, configuration backups, or vendor metadata intended to remain private. Require vendor/autoload.php once at the composition boundary. Application classes should not perform ad hoc relative includes. A clean-copy command must install declared production dependencies, run verification, and build the same immutable artifact later deployed.
Separate development diagnostics from production responses
Development can display detailed errors to an authorized developer, while production must return a stable safe response and send structured diagnostics to controlled logs. display_errors, error_reporting, logging destination, timezone, memory limit, upload limits, execution timeout, OPcache, and extension versions need explicit per-environment configuration. Never let a production user see stack traces, SQL, paths, secrets, or source excerpts.
A top-level error boundary attaches request or job identity, records exception type and safe context, selects an HTTP status or CLI exit code, and preserves observability failure as secondary. Deprecations and warnings should fail CI under an owned policy before a runtime upgrade. Health checks must reveal service readiness without leaking configuration. Verify the effective php.ini and loaded extensions from the deployed process, not only from a developer shell.
Laboratory: trace one application across local and FPM execution
Build a Composer application with PSR-4 source, a CLI command, front controller, health endpoint, typed configuration, and one service. Run it with the PHP development server for learning and with a local FPM or equivalent packaged setup for deployment evidence. Record PHP, Composer, extensions, ini sources, lock hash, source revision, entry route, process user, and artifact hash.
Seed missing autoload file, wrong namespace case, unavailable extension, syntax error, invalid environment, unwritable log, exhausted FPM pool, proxy timeout, and uncaught exception. Acceptance classifies each layer, returns safe HTTP or CLI outcomes, logs one correlated cause, exposes no secret, passes a clean install, and proves the tested artifact is byte-identical to the promoted artifact.