class Analyzer::Php::Phalcon

• Analyzer::Php::Phalcon
• Analyzer::Php::PhpEngine
• FileScanEngine
• Analyzer
• Reference
• Object

Overview

Phalcon (https://phalcon.io/) is a PHP framework implemented as a C extension. It exposes two independent routing styles that real apps mix freely in the same codebase:

• Micro — a Slim-style DSL: $app->get('/path', function () {...});, optionally grouped with Phalcon\Mvc\Micro\Collection.
• MVC — Phalcon\Mvc\Router::add() (+ addGet/addPost/…, optionally grouped with Phalcon\Mvc\Router\Group), PHPDoc annotation routing (@RoutePrefix/@Get/@Route) and convention-based controller/action dispatch (ProductsController::showAction -> /products/show).

Defined in:

Constant Summary

ACTION_METHOD_RE = /public\s+function\s+(\w+)Action\s*\(([^)]*)\)/

ADD_REGEX = /\$(\w+)->add(?!Get|Post|Put|Patch|Delete|Options|Head|Purge)\s*\(/i

4. MVC Router / Group generic add(), optionally chained with via(): $router->add('/products/update', 'Products::update')->via(['POST', 'PUT']); $blog->add('/save', ['action' => 'save']); Negative lookahead excludes addGet/addPost/... (case 3 above) and addPurge (a real Phalcon Router method for the non-standard PURGE verb, which this analyzer doesn't otherwise model — better to emit nothing for it than to mis-report it as an unrestricted GET route).

ADD_VERB_REGEX = /\$(\w+)->add(Get|Post|Put|Patch|Delete|Options|Head)\s*\(\s*['"]([^'"\r\n]+)['"]/i

3. MVC Router explicit-verb helpers: $router->addGet('/path', 'Products::edit');

ANNOTATION_ROUTE_RE = /@Route\s*\(\s*['"]([^'"]+)['"]([^)]*)\)/m

ANNOTATION_VERB_RE = /@(Get|Post|Put|Patch|Delete|Options|Head)\s*\(\s*['"]([^'"]+)['"]/

5. PHPDoc annotation routing: /**
   • @RoutePrefix('/api/products') / class ProductsController extends Controller { /* @Get('/search') / public function searchAction() {} /* @Route('/save', methods={'POST', 'PUT'}) */ public function saveAction() {} }

CONTROLLER_CLASS_RE = /class\s+(\w+)Controller\s+extends\s+\\?([\w\\]+)\b[^{]*\{/

6. Convention-based controller/action dispatch: a public fooAction method on a controller extending Phalcon\Mvc\Controller maps to /{controller}/{action} (default action index is omitted), with any action parameters appended as positional path segments — showAction($id) on ProductsController -> /products/show/{id}.

   Skipped entirely for controllers that already use PHPDoc annotation routing (case 5): an app wired with RouterAnnotations typically replaces the default convention router outright, so guessing convention routes alongside real annotation routes would invent endpoints that are never actually reachable.

HTTP_METHODS = ["GET", "POST", "PUT", "PATCH", "DELETE", "OPTIONS", "HEAD"]

MAP_CALL_RE = /\$(\w+)->map\s*\(/i

2. map()/via(): $app->map('/repos/store/refs', 'actionProduct')->via(['GET', 'POST']); Matched by call boundary (not a single-line path+comma regex) because the trailing ->via(...) lookup needs the position right after the map() call's own closing paren — which a non-closure handler (a bare string/callable-array, with no body to bound) doesn't otherwise give us.

NON_ROUTE_RECEIVERS = Set {"config", "di", "container", "session", "cookies", "request", "response", "validator", "validation", "flash", "filter", "tag", "assets", "view", "dispatcher", "acl", "security", "crypt", "cache", "eventsmanager", "logger", "translate", "url", "escaper", "modelsmanager", "transactionmanager", "annotations"}

->get(...)/->add(...) are not unique to routing in a Phalcon app: Phalcon\Config/Phalcon\Di objects answer to ->get($key, $default) (a 2-arg call shape identical to a route registration) and Phalcon\Validation answers to ->add($field, $validator). Both are extremely common in real Phalcon code — a config->get('adapter', 'Unknown') or validator->add('email', new Uniqueness(...)) call in a model or service provider would otherwise read as a phantom route. These are the receiver names real Phalcon apps conventionally use for those non-routing services; a variable holding an actual Micro app, Router or route Collection/Group is never named one of these.

PARAM_PATTERNS = [{/->request->getQuery\s*\(\s*['"]([^'"]+)['"]/, "query"}, {/->request->getPost\s*\(\s*['"]([^'"]+)['"]/, "form"}, {/->request->getPut\s*\(\s*['"]([^'"]+)['"]/, "form"}, {/->request->getPatch\s*\(\s*['"]([^'"]+)['"]/, "form"}, {/->request->get\s*\(\s*['"]([^'"]+)['"]/, "query"}, {/->request->getHeader\s*\(\s*['"]([^'"]+)['"]/, "header"}, {/->cookies->get\s*\(\s*['"]([^'"]+)['"]/, "cookie"}, {/->dispatcher->getParam\s*\(\s*['"]([^'"]+)['"]/, "path"}]

Request/response accessors a Phalcon handler (Micro closure, MVC controller action, or annotation-routed action) reads incoming data through. $this->request/$this->cookies are available in every one of those contexts — Phalcon binds Micro closures to the application instance, so $this resolves the same way it does inside a controller action.

PHALCON_MARKER_RE = /Phalcon\\/

Every PHP analyzer is fed every .php file in a project-wide scan, so this gate is the only thing keeping Phalcon off other frameworks' route/controller files. "Phalcon" itself is unambiguous — no other ecosystem framework spells this namespace — so a plain substring match is safe without the narrower use X\Y;-only matching Laminas needs against the generic word "Zend".

VERB_REGEX = /\$(\w+)->(get|post|put|patch|delete|options|head)\s*\(\s*['"]([^'"\r\n]+)['"]\s*,/i

1. Micro app / Collection direct verb calls: $app->get('/path', function () {...}); $invoices->post('/add', 'add');

Class Method Summary

• .tech_name : String

Instance Method Summary

• #analyze_file(path : String) : Array(Endpoint)
• #tech : String

  Instance-side view of the same declaration.

Class Method Detail

Instance Method Detail