Tharow Manuals

# Event listener (backend)

[[toc]]

# Event System

Laravel itself has an event system, so we can easily implement event listening to perform certain operations.

In the function returned in the plugin's bootstrap.php, if you want to listen to events, you can write like this:

use Illuminate\Contracts\Events\Dispatcher;

return function (Dispatcher $events) {
   //...
};

# Listen to events

Taking the above as an example, the listen method in $events allows you to listen to events. The listen method receives two parameters: the first is the class of the event you want to listen to, and the second parameter is the callback function to be executed when the event is triggered.

Suppose we now want to listen to the RenderingFooter event so we can add some content to the page. The process is as follows:

First of all, you need to know where the class of the event you want to listen to is located. All events of Blessing Skin itself are located under App\Events, so the first parameter of listen method is App\Events\RenderingFooter::class. If you want to listen to events from Laravel, please consult the Laravel documentation.

The second parameter is the callback function. For the callback function used to listen to the event, it has a parameter, which is the instance of the event. In our case, an instance of App\Events\RenderingFooter::class.

The complete example is as follows:

$events->listen(App\Events\RenderingFooter::class, function ($event) {
   // $event-> ...
});

# Write event subscribers

Instead of listening to events in bootstrap.php as described above, you can also write event subscribers. An event subscriber is a class that can subscribe to multiple events within itself, that is, multiple event handlers can be defined in a single class.

A subscribe method must exist on the class of an event subscriber, which is used to associate the event with the listener.

For example, we want to listen to the RenderingHeader event and the RenderingFooter event in an event subscriber, and the two use different listeners (that is, the code executed after the event is triggered is different). Then we can add a class like this in the src directory:

class RenderSubscriber
{
   public function onRenderingHeader($event)
   {
     //
   }

   public function onRenderingFooter($event)
   {
     //
   }

   public function subscribe($events)
   {
     // Assume our plugin's namespace is `Example`

     $events->listen(
       'App\Events\RenderingHeader',
       'Example\RenderSubscriber@onRenderingHeader'
     );

     $events->listen(
       'App\Events\RenderingFooter',
       'Example\RenderSubscriber@onRenderingFooter'
     );
   }
}

Next, to register this event subscriber, add the following code in bootstrap.php:

$events->subscribe(Example\RenderSubscriber::class);

# All available events

Here is a list of all defined events in Blessing Skin. Usually the instance of the event will have one or more attributes, which represent the data involved when the event is triggered. Therefore, we agree that we use the third-level title to indicate the name of the event, and use the fourth-level title to list the attributes on the event instance.

# ConfigureAdminMenu

trigger timing

Before generating the sidebar menu in the admin panel.

Type: array

Meaning: the entire menu list

# ConfigureRoutes

trigger timing

Before generating Laravel routes.

# Router

Type: Illuminate\Routing\Router

Meaning: Laravel's routing object, which contains a series of available methods.

# ConfigureUserMenu

trigger timing

Before generating the sidebar menu in the normal UI.

Type: array

Meaning: the entire menu list

# PlayerProfileUpdated

trigger timing

After the role information is updated.

# player

Type: App\Models\Player

Meaning: role instance

# PlayerRetrieved

trigger timing

Read role information from the database.

# player

Type: App\Models\Player

Meaning: role instance

# PlayerWasAdded

trigger timing

After the role is added. At this point the role has been created and you can get an instance of the role.

# player

Type: App\Models\Player

Meaning: an instance of the newly created role

# PlayerWasDeleted

trigger timing

After the character is deleted. At this point the role has been deleted and you cannot get an instance of the role.

# playerName

type: string

Meaning: the name of the role being deleted

# PlayerWillBeAdded

trigger timing

Just before the character is added. At this point the role has not been created and you cannot get an instance of the role.

# playerName

type: string

Meaning: The name of the character to be added

# PlayerWillBeDeleted

trigger timing

before the character is deleted. At this point, the role has not been deleted, and you can still get the instance of the role.

# player

Type: App\Models\Player

Meaning: an instance of this role

# PluginWasDeleted

trigger timing

The plugin was removed before. Note from the author: The naming of this event is misleading. Although the name is PluginWasDeleted, the plugin has not been deleted at this time (you can read the source code of Blessing Skin for details), otherwise this event will lose its meaning. 😅

# plugin

Type: App\Services\Plugin

Meaning: an instance of a plugin that is about to be removed

# PluginWasDisabled

trigger timing

After the plugin is disabled.

# plugin

Type: App\Services\Plugin

Meaning: an instance of a disabled plugin

# PluginWasEnabled

trigger timing

After the plugin is enabled.

# plugin

Type: App\Services\Plugin

Meaning: an instance of the enabled plugin

trigger timing

The page is after rendering the HTML at the bottom. At this point, Blessing Skin's own JavaScript files have been loaded, and you can safely use the front-end interface from Blessing Skin.

# contents

Type: array with elements of type string

Meaning: All elements in this array will be added one by one to the HTML at the bottom of the page.

# addContent

Type: function

Meaning: This is actually a method on the RenderingFooter event instance, not a property. This method receives a string as a parameter, which is used to add content to the page.

example:

$event->addContent('<script></script>');

# RenderingHeader

trigger timing

The page is after rendering the top HTML. Note that the main content of the page has not been rendered yet.

# contents

Type: array with elements of type string

Meaning: All elements in this array will be added one by one to the HTML at the top of the page.

# addContent

Type: function

Meaning: This is actually a method on the RenderingHeader event instance, not a property. This method receives a string as a parameter, which is used to add content to the page.

example:

$event->addContent('<style></style>');

# TextureDeleting

trigger timing

The material will be deleted.

# contents

Type: App\Models\Texture

Meaning: The material being deleted.

# UserAuthenticated

trigger timing

After user authentication. Note that this does not equate to a user login. The specific performance is that, regardless of whether the user has logged in or not, Blessing Skin will check the user's login status. If the user is logged in at this time (not necessarily just logged in, it may be that he has logged in before and then visited other pages, or the user has opened the "Remember me" option), then this event will be triggered.

# user

Type: App\Models\User

Meaning: an instance of this user

# UserLoggedIn

trigger timing

After the user logs in.

# user

Type: App\Models\User

Meaning: an instance of this user

# UserProfileUpdated

trigger timing

After the user's profile is updated.

# type

type: string

Meaning: Indicates which data item is updated. Currently the following values are available:

  • nickname - Indicates that the user has updated their nickname

  • password - Indicates that the user updated the password

  • email - Indicates that the user has updated their email address

# user

Type: App\Models\User

Meaning: an instance of this user

# UserRegistered

trigger timing

After user registration. At this point the user has been created.

# user

Type: App\Models\User

Meaning: an instance of the newly created user

# UserTryToLogin

trigger timing

When the user tries to log in, no operations such as password verification are performed at this time.

# identification

type: string

Meaning: The user's identity, which may be the user's mailbox, or the name of the role held by the user. See the authType property for details.

# authType

type: string

Meaning: Indicates the type of the identification attribute. If the user logs in as an email address, then this value is email; if the user logs in as his/her role name, then this value is username (you read that right, it is username not playerName).

← Event monitoring (front end) →