Table of Contents
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:
$this->getPluginPath();
// DONT!
Utility::resolvePath();
Access Global Configuration
// access in in config_loaded event:
$config = $eventData['config'];
…
// DONT!
Registry::get('Phile_Settings')
Access Template Variables
// access in template_engine_registered event:
$templateVars = $eventData['data'];
…
$eventData['data'] = $myTemplateVars;
// DONT!
Registry::get('templateVars')
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)
->createHtmlResponse($html)
->withHeader(<header>);
$eventData['response'] = $response;
}
}
The core is going to stops further request-processing and sends the response early.