CakePHP: a convention-based MVC framework

Sources and evidence limits

The only evidence is the official CakePHP introduction page, so anything it does not state is marked unknown.

What CakePHP is

CakePHP is a web application framework. It is not a PHP runtime or interpreter, and it is not a CMS product. PHP itself, the language and its engine, is a separate thing that CakePHP runs on. A CMS such as Drupal is a finished content product built on PHP. CakePHP is a toolbox you build your own application with. The source describes it as an all-in-one toolbox whose parts work well together or separately.

The source's central idea is conventions over configuration. CakePHP defines conventions for class names, filenames, database table names and more. Following them avoids needless configuration and gives projects a uniform structure. The source admits the conventions take time to learn and points to a separate conventions chapter.

Architecture: model, view, controller

The introduction organizes the framework into three layers.

• Model layer: business logic. It retrieves data and turns it into meaningful application concepts, including processing, validating and associating data. The source loads a table with fetchTable('Users'), calls find()->all(), and creates entities with newEntity() and save(). When you have not defined table or entity classes, CakePHP uses standard classes by convention.
• View layer: presentation of modeled data. It can render HTML templates, and it can also deliver JSON, XML or other formats such as CSV through a pluggable architecture. Reuse points are view templates, elements and cells.
• Controller layer: handles user requests. It checks validity against authentication or authorization rules, delegates data work to the model, picks the response format, and delegates rendering to the view. In the source's registration example, no view is explicitly rendered. Conventions select the view, and data is passed with set().

Execution model: the classic request cycle

The source describes a typical request cycle:

1. Webserver rewrite rules direct the request to webroot/index.php.
2. Your application is loaded and bound to an HttpServer.
3. Application middleware is initialized.
4. The request and response pass through PSR-7 middleware, typically including error trapping and routing.
5. If middleware returns no response and routing information exists, a controller and action are selected.
6. The action interacts with models and components.
7. The controller delegates response creation to the view.
8. The view uses helpers and cells to build the body and headers.
9. The response goes back out through the middleware.
10. The HttpServer emits the response to the webserver.

This is a classic request lifetime: the application is loaded and a response is produced for each request. The source does not say that CakePHP supports persistent workers, so that support is unknown here. The source does mention a locking API for coordinating critical sections across concurrent requests, workers and commands. That shows concurrency is considered, but it is not evidence of a long-running server mode.

Persistent workers: state leakage and cleanup

In a persistent worker, such as a Swoole or Open Swoole style server, a process handles many requests. Swoole and Open Swoole are separate projects and must not be conflated. Persistent workers are an execution style, not a CakePHP feature described in the source. If you ever run any framework that way, state can leak between requests. Static properties, singletons, cached entities, open connections, authenticated user data and request-scoped services may all survive into the next request. The usual defence is to reset or rebuild request-scoped state after every request, and to keep per-user data out of shared objects. Whether CakePHP offers such cleanup hooks is unknown from the supplied source. Under the classic cycle above, the process normally starts fresh for each request, which hides these problems.

Practical use cases

The source supports these uses:

• Database-backed applications with validation and associations, using the ORM-style model layer.
• HTML pages through templates and elements.
• JSON, XML or CSV output from the same data through the view layer.
• Applications that benefit from a uniform structure across projects.

The source also lists a caching framework integrating with Memcached, Redis and other backends, code generation tools, and an integrated testing framework. It gives no details of how to use them.

Installation approach

The source says only to download CakePHP, read the tutorial, and build something. It gives no installation commands, system requirements, PHP version support or package names. Those are unknown here. Follow the official installation and tutorial pages to create an application skeleton, and verify the supported PHP version against official documentation before choosing it. The learning track uses PHP 8.4, with PHP 8.5 planned. CakePHP's compatibility with either is not established by the source. The example below therefore avoids PHP 8.4-specific features.

The example

The example adds a Users listing to an existing CakePHP application. It uses conventions from the source: a controller, a table found by name, a template chosen by convention, and an element rendered per user. The example assumes the application skeleton supplies the base controller and default routing. It also assumes a configured database with a users table that has a username column. The source does not confirm any of these assumptions. This is not a browser exercise. It needs a PHP environment, Composer and a database service.

Strengths

• Clear MVC separation with documented responsibilities.
• Conventions reduce configuration and make projects look alike.
• The same model and controller can serve HTML or data formats.
• PSR-7 middleware sits in the request pipeline.
• Caching, locking, code generation and testing are part of the framework's feature set.

Limitations

• The source is a short overview, so version, support status, licence, performance and deployment details are unknown. The lifecycle is recorded as unknown.
• Conventions must be learned, and deviating from them means extra configuration.
• Persistent-worker support is not described.
• It is a framework, not a CMS, so you build content-management features yourself or add them separately.

Deployment

From the source, the deployment-relevant facts are that webserver rewrite rules must send requests to webroot/index.php, and that the webserver receives the response from the application's HttpServer. Specific server configuration, hosting needs and production hardening are not in the source. Use the official documentation for them. For local development, bind any exposed port to 127.0.0.1. Never expose a FastCGI endpoint publicly.

Next steps

Read the official introduction, then the tutorial and the conventions chapter. Have a human check the example against a fresh application skeleton on the PHP version you target.

<?php
declare(strict_types=1);

namespace App\Controller;

class UsersController extends AppController
{
    public function index()
    {
        $users = $this->fetchTable('Users')->find()->all();
        $this->set('users', $users);
    }
}

<h1>Users</h1>
<ul>
<?php foreach ($users as $user): ?>
    <li class="user">
        <?= $this->element('user_info', ['user' => $user]) ?>
    </li>
<?php endforeach; ?>
</ul>

<span><?= htmlspecialchars((string)$user->username, ENT_QUOTES, 'UTF-8') ?></span>

php -v
composer --version
php -l src/Controller/UsersController.php