Explore creating scalable PHP web applications, structuring code efficiently, managing data storage, and implementing automated testing to ensure robustness and maintainability in real-world projects.

docker.tar.gz

Serve /usercode

Run index.php (quiet composer install)

Serve /usercode (quiet composer install)

execute_apcu

This course is for people who have already learned the basics of PHP (or just finished the "Learn PHP from Scratch" course) and want the bigger picture of making big web applications with this language.

First, you'll learn how all PHP web applications communicate with the world and how to turn multiple source code files into one application. Then you'll learn multiple approaches to structuring the whole application. It will help you write code that's easy to maintain. Also, this is a common topic for job interview questions.

Next, you'll learn different data storage methods, from user sessions to databases. This course doesn't duplicate the official documentation but instead provides an overview of the various tools you can use. You'll learn how to use them in PHP, their tradeoffs, and how to pick what's best for your project.

Finally, you'll learn how to make automated tests for your project to ensure that it works as expected.

Developing Web Applications with PHP

In this lesson, we’ll learn the directory structure of a typical web application in PHP. Our project will probably look slightly different because frameworks often enforce directory structure conventions. Still, we’ll have something similar to this because although different frameworks assume different directory structures, they have a lot in common. Often the only difference is in the directory names.

Here are the directories we can usually find in the project root:

bin/
config/
migrations/
public/
└index.php
resources/
src/
test/
var/
vendor/

Let's see what each of them means.

# The `src` directory

This is a directory for the source code files. Usually, we don’t place source code files in the root directory because it’s already cluttered with tool configs like `composer.json` and `.gitignore`. Also, having all the source code files in a single directory makes it easy to configure PSR-4 autoloading.

# The `test` directory

This is the directory with the source code for tests. Having them gathered in a single directory is convenient because it’s easy to filter them out when we don’t need them. For example, we can skip tests when deploying to production. Another example is ignoring tests while searching for class usage in code.

When we split the source code into multiple modules, it’s common to have  separate test directories in each module. Also, it makes it much harder to filter out tests. That’s why, even with multiple modules, some prefer to duplicate the module structure within a shared `test` directory.

# The `resources` directory

This is a directory for the non-source code files used by the application. It could be YAML/XML configuration files, template files, CSS, or JS files to be copied to the public directory. In the applications formed from multiple modules, there’s usually a separate `resources` directory within each module.

# The `config` directory

This is a directory with the global application configuration files. Sometimes it’s pushed into the `resources` directory.

# The `bin` directory

This is a directory with files that we can run in the terminal. Initially, that’s just the entry-point script for the application’s console commands, but it gradually gets filled with the different tools we use for application development. For example, the easiest way to install PHPStan is to drop its phar file in the `bin` directory.

# The `migrations` directory

When we use relational databases, we want to be able to evolve a database schema without dropping all the existing data. We can achieve this with **database migrations**, which are scripts that make reversible changes to the database schema. They should be version tracked in the same repository as the source code to make sure the database schema version matches the application version. At the same time, migrations aren’t part of the application’s logic, so we store them outside the `src` directory.

Sometimes the database migrations are grouped into the `database` directory with other database-related logic.

# The `vendor` directory

We'll always find this one because it's a directory managed by Composer. Usually, there's no need to look inside.

# The `var` directory

Also known as `runtime` or `storage, this is` the directory for the files our application might create. These could be logs, caches, or compiled template files.

It’s a good habit to enforce security on a file system level. Usually, file permissions are configured in a way that restricts applications from writing into their own source code files. The same goes for files in which write permission isn’t required.

The `var` directory is unique—it’s the only directory where the application has write permission.

# The `public` directory

Also known as `www,` this is a root directory of the HTTP server. Here, we can find the front controller (usually as `index.php`). Also, it might contain static files such as CSS files, .js files, and images if the same HTTP server serves them.

## What’s the front controller

Front controller is a single PHP script that receives all the HTTP requests and forwards them to the correct handler. In practice, it's a small script that loads the Composer autoloader and then runs our framework.

## Why it matters

If we don’t stick to the front controller pattern, we might let our HTTP server pick the script to run based on the request URL. That’s how we end up with URLs like `https://app.test/order.php?…`. Each file will contain the same application bootstrap logic. Also, it will be hard to keep the application structure consistent when it has multiple entry points. We can configure the clean URLs in the HTTP server configuration, but in addition to previous problems, it would couple our HTTP server configuration to the business logic.

It’s much better to configure the HTTP server to process all the requests with a single PHP script and do the routing inside the application.


## Why should we have a separate `public` directory

We should create a separate directory to serve as an HTTP root. But, it looks like pointing the HTTP server to the project’s root directory is easier. So, why bother? Again, the answer is security.

If our HTTP server root directory is the project root, the client may request any file, and the HTTP server will run or return it. In even the best case, that’s useless. Usually, it’s harmful because any client could be a potential a hacker.

Imagine the client requests our configuration files, and the HTTP server returns them. That’s not good, especially if our database access configuration is there. The same goes for the application logs. The client might also request our internal PHP file, and the HTTP server will run it. If the server can serve our `.git` directory, hackers might get our application’s source code and its version history. And, it doesn’t end up with our code. 

Remember all those nice dependencies in the `vendor` directory? Now imagine one of these libraries depends on another library that has a small backdoor in it. It may be made up of some tiny script we’ll never notice, but it can give full server access to someone who requests a particular URL like `/vendor/nice-maintainer/nice-library/bad-script.php`.
 
Even if there’s no malice, our dependencies might be vulnerable enough to admit the hacker. When it’s impossible to call our internal scripts from outside, it’s much harder to exploit possible vulnerabilities. So, we should limit the HTTP server’s access to the single internal directory. Otherwise, we leave a vast, uncontrolled attack surface for hackers.


# Conclusion

We have learned about the most common directories in PHP applications. In general, we should follow the conventions of the framework we picked. Just make sure to limit the scope of potentially dangerous things like write access or HTTP access.

Now we know how to structure the application files. In the next chapter, we'll move to another abstraction level and learn how to structure the business logic.

Learn the meaning behind the common directories in most PHP projects.

Introduction

Communicating with the Client

Static Web Application

Structuring Code Files

Application Architecture Basics

PHP-Based Web Application

Storing State

Databases

Using a Database in the PHP Application

Testing

Testing the PHP Application

Advanced Architecture Patterns

Final Assessment

Conclusion

Directory Structure Of A Web Application