Download the PHP package elcreator/aphalcon without Composer

aPhalcon

Phalcon inside Evolution CMS.

One Phalcon DI for the site, opened on the CMS's own database credentials, with the site's Phalcon models and services in it. Those services are one call away from any Latte template aLatteX renders — a CMS page can list rows from a Phalcon\Mvc\Model — and Phalcon routes mounted under a CMS path can render the CMS's own views/<alias>.latte files. Two frameworks, one container, one database, one set of templates.

Configurable for a plugin developer: which container to start from, which connection to expose, which Phalcon\Di\ServiceProviderInterface classes register the site's services, and whether the mount runs a Phalcon\Mvc\Micro built from route handlers or a full Phalcon\Mvc\Application of your own.

Requirements

• PHP 8.3+ with the Phalcon 5 extension loaded
• Evolution CMS 3.5.9+
• aLatteX 0.5+ (pulled in via Composer)

Installation

The publish step copies config/aphalcon.php to core/custom/config/aphalcon.php. That file is where a site says what it has; every key left out keeps the default.

Configuration

What is in the DI before your providers run

Everything FactoryDefault provides (modelsManager, modelsMetadata, request, response, router, …) is there as usual, so a Phalcon\Mvc\Model works with nothing more than a source name:

Phalcon binds a closure definition to the container before calling it, and a route handler to the app. A static closure cannot be bound and resolves to null with a warning — use function () use (...), not static fn.

Phalcon services on a CMS page

Every Latte template aLatteX renders — a template held in the database, or a file the manager's Template code → In a file → Latte switch made — gets the {phalcon()} function:

To keep the CMS's parser off a file template entirely, so {{chunk}} and [*field*] are just text, set aLatteX's switch:

Document fields are still there as plain variables — that is aLatteX's own renderView(), not the parser.

CMS views from Phalcon routes

Route handlers get the DI, so $app->cms (Micro) or $this->cms (a controller) reaches the site:

Cms::view($alias, $data) renders any view the CMS's view factory knows — views/<alias>.latte first, .blade.php as well — to a string; Cms::respond() wraps it in a Phalcon\Http\Response. The view sees $data, $evo, and {phalcon()}.

The mount is a Laravel route registered ahead of the CMS's parser fallback: /app/... never reaches the document tree, and the request the handler sees is the real one ($app->request reads the same superglobals). Whatever the handler produces — a Phalcon Response, a string, an array, printed output — becomes the Laravel response the CMS sends.

Replacing the CMS front end

With this on, Phalcon answers every front-end request and the CMS renders only the manager (its own entry point, manager/index.php, never touched). A request path is resolved to a document the way the CMS would resolve it — site_start for /, ?id=N, or the alias path with friendly_url_prefix / friendly_url_suffix stripped and use_alias_path honoured — and the document is rendered from its template's views/<templatealias>.latte, with the content table's columns and the document's TVs as plain variables:

No parser pass: {{chunk}}, [[snippet]] and [*tv*] are text. What a page needs beyond its own row it asks Phalcon for through {phalcon()}. Weblinks redirect, unpublished and deleted documents are misses, and a miss renders the error_page document with a 404.

The reads go through the DI's db — Frontend\Documents is a small repository over site_content, site_templates and the TV tables — so the front end runs on Phalcon's connection with the CMS's credentials, and the same object is the DI's site service, for a route that wants a page:

fallback (default true) is the escape hatch: a document whose template has no view file — one still held in the database — and a miss whose error_page cannot be rendered are handed back to the CMS parser, by the NotFoundHttpException that Core::processRoutes() answers with executeParser(). A site can move templates to Latte one at a time. With fallback => false those are a plain 500 / 404 from Phalcon and the parser never runs. Every response the front controller produces carries X-Rendered-By: aPhalcon.

What the parser did that this does not: web-user access (privateweb, unauthorized_page), the page cache, and the document-level plugin events (OnLoadWebDocument, OnWebPagePrerender, …). A site that needs them for some documents keeps fallback on and their templates in the database.

Demo

Installs one template kept in views/aphalcon-demo-page.latte, one document at /demo (alias demo) using it, a Phalcon route set at /app/ rendering views/aphalcon-demo.latte, the two parents both of those extend — aphalcon-section.latte → aphalcon-base.latte, a three-level {extends} chain the way the aLatteX demo lays pages out, with the CMS document and the Phalcon route as two roots of the same chain — and, only if the site has none of its own, core/custom/config/aphalcon.php naming the demo's provider and routes and core/custom/config/alattex.php switching the parser off for file templates. Removal deletes only files still identical to what was installed.

The demo config turns frontend.takeover on, so the demo page is served by the front controller (X-Rendered-By: aPhalcon), /app/page/{id} renders any document from a route through the site service, and the stock start page — its template in the database — is handed back to the CMS by fallback.

The same classes are the test fixtures: tests/Integration/DemoTest.php runs the demo's provider, model and routes over an in-memory sqlite and renders the shipped views through the real aLatteX engine; FrontendTest.php resolves and renders a small document tree the way the front controller does.

Development

See AGENTS.md for the layout.

License

GPL-3.0-or-later