Plugin Best Practices

Phile's code-base is compact. You're free to use it as you see fit. That's one of the great aspects of Phile.

Nevertheless you're strongly encouraged to take advantage of events and data passed by events. You should also always prefer methods and attributes provided by the Phile\Plugin\AbstractPlugin class. There's a special effort that those facilities stay as stable as possible when developing the Phile core.

Resolve Plugin Path

// do:

// DONT!

Access Global Configuration

// access in in config_loaded event:
$config = $eventData['config'];

// DONT!

Access Template Variables

// access in template_engine_registered event:
$templateVars = $eventData['data'];
$eventData['data'] = $myTemplateVars;

// DONT!

Send a Response

The core uses PSR-7 Request and Response objects and allows the usage of PSR-15 compatible middleware.

In the past sending output early and exiting at any moment wasn't a problem. Using Phile standalone and without additional middleware that's still the case. But with additional middleware the system breaks because it depends on request and response "bubbling" through the middleware.

To send output early in a middleware-conform way the following events:

  • after_init_core
  • request_uri
  • after_resolve_page
  • before_render_template

allow to set a 'response' parameter in the event-data now. A PSR-7 response must be used, which can be created by calling one of the new factory methods of the Response class. Long story short:

class Plugin extends AbstractPlugin
    protected $events = ['before_render_template' => 'doMyThing'];

    protected function doMyThing($eventData)
        $html = '…';

        // new (PSR-7):
        $response = (new \Phile\Core\Response)
        $eventData['response'] = $response;

The core is going to stops further request-processing and sends the response early.

Edit the source page on github…