Extending plugins

Extending with events

The Event service is the primary way to inject or modify the functionality of core classes or other plugins. This service can be imported for use in any class by adding use Event; to the top of your PHP file (after the namespace statement) to import the Event facade.

Subscribing to events

The most common place to subscribe to an event is the boot method of a Plugin registration file. For example, when a user is first registered you might want to add them to a third party mailing list, this could be achieved by subscribing to a winter.user.register global event.

public function boot()
{
    Event::listen('winter.user.register', function ($user) {
        // Code to register $user->email to mailing list
    });
}

The same can be achieved by extending the model's constructor and using a local event.

User::extend(function ($model) {
    $model->bindEvent('user.register', function () use ($model) {
        // Code to register $model->email to mailing list
    });
});

Declaring / Firing events

You can fire events globally (through the Event service) or locally.

Local events are fired by calling fireEvent() on an instance of an object that implements Winter\Storm\Support\Traits\Emitter. Since local events are only fired on a specific object instance, it is not required to namespace them as it is less likely that a given project would have multiple events with the same name being fired on the same objects within a local context.

$this->fireEvent('post.beforePost', [$firstParam, $secondParam]);

Global events are fired by calling Event::fire(). As these events are global across the entire application, it is best practice to namespace them by including the vendor information in the name of the event. If your plugin Author is ACME and the plugin name is Blog, then any global events provided by the ACME.Blog plugin should be prefixed with acme.blog.

Event::fire('acme.blog.post.beforePost', [$firstParam, $secondParam]);

If both global & local events are provided at the same place it's best practice to fire the local event before the global event so that the local event takes priority. Additionally, the global event should provide the object instance that the local event was fired on as the first parameter.

$this->fireEvent('post.beforePost', [$firstParam, $secondParam]);
Event::fire('winter.blog.beforePost', [$this, $firstParam, $secondParam]);

Once this event has been subscribed to, the parameters are available in the handler method. For example:

// Global
Event::listen('acme.blog.post.beforePost', function ($post, $param1, $param2) {
    Log::info($post->name . 'posted. Parameters: ' . $param1 . ' ' . $param2);
});

// Local
$post->bindEvent('post.beforePost', function ($param1, $param2) use ($post) {
    Log::info($post->name . 'posted. Parameters: ' . $param1 . ' ' . $param2);
});

Extending backend views

Sometimes you may wish to allow a backend view file or partial to be extended, such as a toolbar. This is possible using the fireViewEvent method found in all backend controllers.

Place this code in your view file:

<div class="footer-area-extension">
    <?= $this->fireViewEvent('backend.auth.extendSigninView', [$firstParam]) ?>
</div>

This will allow other plugins to inject HTML to this area by hooking the event and returning the desired markup.

Event::listen('backend.auth.extendSigninView', function ($controller, $firstParam) {
    return '<a href="#">Sign in with Google!</a>';
});

Note: The first parameter in the event handler will always be the calling object (the controller).

The above example would output the following markup:

<div class="footer-area-extension">
    <a href="#">Sign in with Google!</a>
</div>

Usage examples

These are some practical examples of how events can be used.

Extending a User model

This example will modify the model.getAttribute event of the User model by binding to its local event. This is carried out inside the boot method of the Plugin registration file. In both cases, when the $model->foo attribute is accessed it will return the value bar.

class Plugin extends PluginBase
{
    [...]

    public function boot()
    {
        // Local event hook that affects all users
        User::extend(function ($model) {
            $model->bindEvent('model.getAttribute', function ($attribute, $value) {
                if ($attribute === 'foo') {
                    return 'bar';
                }
            });
        });

        // Double event hook that affects user #2 only
        User::extend(function ($model) {
            $model->bindEvent('model.afterFetch', function () use ($model) {
                if ($model->id !== 2) {
                    return;
                }

                $model->bindEvent('model.getAttribute', function ($attribute, $value) {
                    if ($attribute === 'foo') {
                        return 'bar';
                    }
                });
            });
        });
    }
}

Extending backend forms

There are a number of ways to extend backend forms, see Backend Forms.

This example will listen to the backend.form.extendFields global event of the Backend\Widget\Form widget and inject some extra fields when the Form widget is being used to modify a user. This event is also subscribed inside the boot method of the Plugin registration file.

class Plugin extends PluginBase
{
    [...]

    public function boot()
    {
        // Extend all backend form usage
        Event::listen('backend.form.extendFields', function($widget) {
            // Only apply this listener when the Users controller is being used
            if (!$widget->getController() instanceof \Winter\User\Controllers\Users) {
                return;
            }

            // Only apply this listener when the User model is being modified
            if (!$widget->model instanceof \Winter\User\Models\User) {
                return;
            }

            // Only apply this listener when the Form widget in question is a root-level
            // Form widget (not a repeater, nestedform, etc)
            if ($widget->isNested) {
                return;
            }

            // Add an extra birthday field
            $widget->addFields([
                'birthday' => [
                    'label'   => 'Birthday',
                    'comment' => 'Select the users birthday',
                    'type'    => 'datepicker'
                ]
            ]);

            // Remove a Surname field
            $widget->removeField('surname');
        });
    }
}

Note: In some cases (adding fields that should be made translatable by Winter.Translate for example), you may want to extend the backend.form.extendFieldsBefore event instead.

Extending a backend list

This example will modify the backend.list.extendColumns global event of the Backend\Widget\Lists class and inject some extra columns values under the conditions that the list is being used to modify a user. This event is also subscribed inside the boot method of the Plugin registration file.

class Plugin extends PluginBase
{
    [...]

    public function boot()
    {
        // Extend all backend list usage
        Event::listen('backend.list.extendColumns', function ($widget) {
            // Only for the User controller
            if (!$widget->getController() instanceof \Winter\User\Controllers\Users) {
                return;
            }

            // Only for the User model
            if (!$widget->model instanceof \Winter\User\Models\User) {
                return;
            }

            // Add an extra birthday column
            $widget->addColumns([
                'birthday' => [
                    'label' => 'Birthday'
                ],
            ]);

            // Remove a Surname column
            $widget->removeColumn('surname');
        });
    }
}

Extending a component

This example will declare a new global event winter.forum.topic.post and local event called topic.post inside a Topic component. This is carried out in the Component class definition.

class Topic extends ComponentBase
{
    public function onPost()
    {
        [...]

        /*
         * Extensibility
         */
        $this->fireEvent('topic.post', [$post, $postUrl]);
        Event::fire('winter.forum.topic.post', [$this, $post, $postUrl]);
    }
}

Next this will demonstrate how to hook to this new event from inside the page execution life cycle. This will write to the trace log when the onPost event handler is called inside the Topic component (above).

[topic]
slug = "{{ :slug }}"
==
function onInit()
{
    $this['topic']->bindEvent('topic.post', function($post, $postUrl) {
        trace_log('A post has been submitted at '.$postUrl);
    });
}

Extending the backend menu

This example will replace the label for CMS and Pages in the backend with ....

class Plugin extends PluginBase
{
    [...]

    public function boot()
    {
        Event::listen('backend.menu.extendItems', function($manager) {

            $manager->addMainMenuItems('Winter.Cms', [
                'cms' => [
                    'label' => '...'
                ]
            ]);

            $manager->addSideMenuItems('Winter.Cms', 'cms', [
                'pages' => [
                    'label' => '...'
                ]
            ]);

        });
    }
}

Similarly we can remove the menu items with the same event:

Event::listen('backend.menu.extendItems', function($manager) {

    $manager->removeMainMenuItem('Winter.Cms', 'cms');
    $manager->removeSideMenuItem('Winter.Cms', 'cms', 'pages');

    $manager->removeSideMenuItems('Winter.Cms', 'cms', [
        'pages',
        'partials'
    ]);
});

Keep informed

Sign up to our newsletter to receive updates on Winter CMS releases, new features in the works, and much more.
We'll never spam or give this address away.

Latest blog post

October CMS as you know it is Dead

Published April 12, 2021
We regret to inform you that October CMS as you have known it for the past 7 years is no more. The founders have decided to make it a paid proprietary product; unfortunately abandoning the open source community in the process as "source partially available" is not open source. The core maintainers of the project have forked, and will continue development as Winter CMS....

View this post Read all posts

Latest Winter CMS release

v1.1.3

Released April 26, 2021
3 UX/UI Improvements, 19 API Changes, 23 Bug Fixes, 3 Security Improvements, 4 Translation Improvements, 1 Community Improvement, 2 Dependencies

View details View all releases