Alright, let's get your machine ready for PHP. I remember when I first started with server-side languages; I spent an hour wondering why my browser was just printing my code instead of executing it. I'm going to walk you through how I usually set things up, and more importantly, why we do it this way.

Wait, why is my code just text?

Let's start by doing exactly what I did years ago. I'll create a file called server_check.php. I'm not going to do a generic "Hello World"—instead, I want to see if the server can tell me the current time, which proves the code is actually executing on a backend.

<?php
  echo "The server thinks the current time is: " . date('Y-m-d H:i:s');
?>

Now, if I just double-click this file in my folder, my browser opens it. But look at the screen: it literally just shows <?php echo... or it tries to download the file. It's a disaster. Why? Because your browser (Chrome, Firefox, Safari) is a client. It understands HTML, CSS, and JavaScript, but it has absolutely no idea what a <?php tag is. It sees a tag it doesn't recognize, so it just ignores it or treats it as plain text.

The missing piece: The Engine

To fix this, we need a PHP interpreter. This is the "engine" that reads that file, executes the logic, and turns it into plain HTML that the browser can actually understand. You have a few choices here. You could install a massive bundle like XAMPP or MAMP, but honestly? For learning, I prefer the leaner approach. I'm just going to install PHP directly.

If you're on macOS, you might use Homebrew (brew install php). On Windows, you'll grab the binaries from php.net. Once I've got it installed, I check if it's working by hitting my terminal:

php -v

If I see "PHP 8.x.x", I'm in business. But we still have the same problem: the browser can't "talk" to this engine just by opening a file. We need a bridge. That bridge is a web server.

Talking to the server

Now, I could spend twenty minutes configuring Apache or Nginx, but that's overkill for this lesson. PHP actually comes with a built-in development server for exactly this scenario. I'll navigate to the folder where my server_check.php is and run this:

php -S localhost:8000

The terminal tells me "Development Server started." Now, instead of double-clicking the file, I'll go to my browser and type http://localhost:8000/server_check.php. Suddenly, it works. I see "The server thinks the current time is: 2023-10-27 14:30:05".

What happened here? By using localhost:8000, I told the browser to send a request to the PHP server running on my own machine. The server saw the .php extension, handed the file to the PHP engine, the engine processed the date() function, and sent back pure HTML. The browser is happy, and I have a working environment.

Smoothing out the workflow

The only annoying part is that I have to keep this terminal window open. If I close it, my site dies. In a professional production environment, a server like Nginx runs as a background service (a "daemon") so it's always on. For us, though, this manual start is actually better because it reminds you exactly where your "backend" is living. Just remember: if you get a "404 Not Found" or "Connection Refused" error, the first thing you should check is whether you actually started that php -S command.

📋 Practical Task

Build a Dynamic System Status Page

Now that your environment is running, let's verify it's handling logic correctly. Create a file named status.php in your local server directory. Instead of a static message, write a script that uses the phpinfo() function and a custom echo statement that displays your current operating system using the PHP_OS constant.

• Start your local PHP server via the terminal.
• Navigate to http://localhost:8000/status.php.
• Ensure the page displays both your specific OS and the full PHP configuration table.