agentleFS
AnyOrgNameAnyOrgName/php-skills/skills/cakephp/controllers/SKILL.md

controllers

Skill4 starsChanged 4 months agoMITView on GitHub

Handle requests with CakePHP controllers — actions, the request and response objects, components, and thin actions that delegate to the ORM and services. Use when the user is adding or editing a CakePHP controller action that responds to a routed request; the user wants to share request-handling logic (auth, flash, pagination) across controllers via a component; the user needs to read request data (query, post, params) or build a response (redirect, JSON, status) in a CakePHP controller. Keywords: cakephp, controllers, actions, request, response, components, input.

The file

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Do not put app-wide request concerns (CORS, HTTPS enforcement, body parsing) in a controller.

    line 65
  2. Distinctive:

    Do not use this skill for Symfony, Laravel, or Laminas controllers.

    line 66

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md
<!-- generated: do not edit — source: knowledge/atoms/cakephp/controllers/ --><!-- schema: atomVersion=3 skillVersion=2 graphVersion=1 --><!-- compile: @php-skills/compiler v1.0.0 (deterministic build) -->

CakePHP Controllers

When to use

  • The user is adding or editing a CakePHP controller action that responds to a routed request.
  • The user wants to share request-handling logic (auth, flash, pagination) across controllers via a component.
  • The user needs to read request data (query, post, params) or build a response (redirect, JSON, status) in a CakePHP controller.

When NOT to use

  • Do not put app-wide request concerns (CORS, HTTPS enforcement, body parsing) in a controller; handle them in PSR-15 middleware in the application stack.
  • Do not use this skill for Symfony, Laravel, or Laminas controllers; the action, component, and ServerRequest API is CakePHP specific.

Core guidance

  • Read request data through the ServerRequest accessors — Read input with $this->request->getData('field'), getQuery('key'), and getParam('id') rather than touching superglobals, and provide a default for optional values.
  • Keep actions thin and delegate to Tables and services — Limit an action to reading input, calling a Table finder or service, setting view variables, and returning a response; push domain logic into the model layer.

Quick recipe

  1. In the action, guard the method with $this->request->is('post'), then build an entity with patchEntity($entity, $this->request->getData()). (verify: The entity carries the submitted fields subject to accessibility rules)
  2. Persist with $table->save($entity) and branch on the boolean result, reading $entity->getErrors() when it fails to surface validation messages. (verify: A valid entity saves; an invalid one exposes per-field errors)
  3. On success, set a flash message and return $this->redirect(['action' => 'index']); on failure, set the entity as a view variable and let the action render the form. (verify: Success redirects with a flash; failure re-renders the form with errors)

Best practices

  • Reach for a component when logic needs the request, response, or controller lifecycle (flash, auth, pagination); for pure domain logic, use a plain service class instead
  • Turn request data into entities with newEntity()/patchEntity() and persist with save(), checking the entity's errors, rather than assigning request fields onto entities by hand
  • Return the result of $this->redirect(...), $this->response->withType(...), or a rendered view from the action; never call exit/die or echo output directly

Anti-patterns

Anti-patternWhy it failsDo instead
Echoing output and calling exit from an actionBypassing the response pipeline skips middleware, view rendering, and error handling, and makes the action untestable.Build and return a Response object (JSON, redirect, or rendered view) instead.
Business and query logic packed into the actionA fat action cannot be reused or unit-tested apart from the HTTP cycle and duplicates logic across actions.Move query logic to Table finders and business rules to services, leaving the action to orchestrate.
Reading input from PHP superglobalsSuperglobals bypass the request object's normalization and make the action impossible to test with a mocked request.Use $this->request->getData(), getQuery(), and getParam() instead.

See references/anti-patterns.md.

Common mistakes

  1. getData returns null for absent keys — $this->request->getData('missing') returns null when the key is absent, so passing it straight into strict logic causes type errors. Fix: Provide a default (getData('field', '')) or validate presence via marshalling before use.
  2. Forgetting to return the redirect response — Calling $this->redirect(...) without returning it lets execution continue and the action still tries to render a view. Fix: Always return $this->redirect(...) (and return early) so no further action code runs.
  3. Public helper methods become routable actions — Any public method on a controller is dispatchable as an action, so a public helper can be reached via a crafted URL. Fix: Make non-action helpers protected/private, or restrict routing so only intended actions are reachable.

Version notes

  • CakePHP 5 requires PHP 8.1 and typed controller signatures — CakePHP 5 requires PHP 8.1+ and ships stricter types on the request/response objects and component APIs, so actions and component hooks should use the typed signatures rather than the looser CakePHP 4 forms.

Security

  • Validate input and authorize the action at the boundary — In every action, read input through the request accessors, marshal it through the Table so validation and field accessibility apply, and confirm the current user is authorized before mutating or exposing data.

Testing

  • Activation and decision behavior are verified in eval/scenarios/cakephp/controllers.yaml.

Additional resources

  • references/anti-patterns.md
  • references/core.md
  • references/examples.md
  • references/pitfalls.md
  • references/recipes.md
  • references/version-differences.md

Knowledge graph

Prerequisites: cakephp/orm
Related: cakephp/validation

<!-- graph-fragment: graph/fragments/cakephp/controllers.yaml -->

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.