When a user requests a page, Typemill initiates the application, loads plugins, merges settings, starts the template engine, scans the content folder, collects content, and finally renders the page. These steps collectively form the life cycle of Typemill.

Throughout this life cycle, Typemill consistently fires events and often sends data with these events. Developers can listen to these events, hook into the system, and add their own functionality.

Event Overview

Here is a list of events that Typemill fires during its life cycle, ordered accordingly. The last column specifies the data passed to your subscriber method.

Life Cycle Variations

Note that the life cycle of Typemill can vary based on specific contexts. For example: The admin area does not fire events for content rendering since the content is not rendered at all in this context.

These events are fired in all cases:

• onSettingsLoaded
• onPluginsLoaded
• onSessionSegmentsLoaded
• onRolesPermissionsLoaded
• onResourcesLoaded
• onTwigLoaded

These events are only fired for system area:

• onSystemnaviLoaded

These events are only fired for content pages:

• onShortcodeFound
• onPagetreeLoaded
• onBreadcrumbLoaded
• onItemLoaded
• onMarkdownLoaded
• onMetaLoaded
• onRestrictionsLoaded
• onContentArrayLoaded
• onHtmlLoaded
• onPageReady

Get and Return Event-Data

If Typemill passes data to your subscriber method, then you can get the data, use the data, manipulate the data, and return the data to the app. You can do this with two simple methods: getData() and setData().

Let's take the HTML event as an example:

use Typemill\Plugin;

class MyPlugin extends Plugin
{
    public static function getSubscribedEvents()
    {
        return array(
            'onHtmlLoaded'      => 'onHtmlLoaded'
        );
    }

    public function onHtmlLoaded($html)
    {
        $data = $html->getData();
        $data .= '<p>This is a paragraph that I added at the end of the page content</p>';      
        $html->setData($data);
    }
}

Other Event-Parameters

TYPEMILL uses the Symfony event dispatcher for the event system. The event dispatcher adds two other variables to each event by default:

• The second parameter is the name of the event.
• The third parameter is the event dispatcher itself.

So in each of your event methods in your plugin, you can also read the event name, and you have access to the dispatcher object itself:

public function onHtmlParsed($html, $eventName, $dispatcher)
{
    // read the $eventName
    // use the $dispatcher
}

There are not many use cases for accessing the event name or the dispatcher in this way. Theoretically, you could fire your own events with the dispatcher object, but it's much better to access the dispatcher object within Slim's dependency container.

The dependency container is one of the properties and methods provided by TYPEMILL's basic plugin class. Because all plugins extend this basic plugin class, all plugins have access to these useful properties and methods.