Download the PHP package winter/wn-notify-plugin without Composer
On this page you can find all versions of the php package winter/wn-notify-plugin. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download winter/wn-notify-plugin
More information about winter/wn-notify-plugin
Files in winter/wn-notify-plugin
Package wn-notify-plugin
Short Description Notify plugin for Winter CMS
License MIT
Homepage https://github.com/wintercms/wn-pages-plugin
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package wn-notify-plugin
Notification Engine Plugin
NOTE: Plugin is currently in Beta status. Proceed with caution.
Adds support for sending notifications across a variety of different channels, including mail, SMS and Slack.
Notifications are managed in the backend area by navigating to Settings > Notification rules.
Installation
This plugin is available for installation via Composer.
After installing the plugin you will need to run the migrations and (if you are using a public folder) republish your public directory.
Notification workflow
When a notification fires, it uses the following workflow:
- Plugin registers associated actions, conditions and events using
registerNotificationRules - A notification class is bound to a system event using
Notifier::bindEvent - A system event is fired
Event::fire - The parameters of the event are captured, along with any global context parameters
- A command is pushed on the queue to process the notification
Queue::push - The command finds all notification rules using the notification class and triggers them
- The notification conditions are checked and only proceed if met
- The notification actions are triggered
Here is an example of a plugin registering notification rules. The groups definition will create containers that are used to better organise events. The presets definition specifies notification rules defined by the system.
Here is an example of triggering a notification. The system event winter.user.activate is bound to the UserActivatedEvent class.
Here is an example of registering context parameters, which are available globally to all notifications.
Here is an example of an event preset:
Creating Event classes
An event class is responsible for preparing the parameters passed to the conditions and actions. The static method makeParamsFromEvent will take the arguments provided by the system event and convert them in to parameters.
Creating Action classes
Action classes define the final step in a notification and subsequently perform the notification itself. Some examples might be sending and email or writing to the database.
A form fields definition file is used to provide form fields when the action is established. These values are accessed from condition using the host model via the $this->host property.
An action may choose to provide no form fields by simply returning false from the defineFormFields method.
Creating Condition classes
A condition class should specify how it should appear in the user interface, providing a name, title and summary text. It also must declare an isTrue method for evaluating whether the condition is true or not.
A form fields definition file is used to provide form fields when the condition is established. These values are accessed from condition using the host model via the $this->host property.
Model attribute condition classes
Model attribute conditions are designed specially for applying conditions to sets of model attributes.
An attributes definition file is used to specify which attributes should be included in the condition.
Save to database action
There is a dedicated table in the database for storing events and their parameters. This table is accessed using the Winter\Notify\Models\Notification model and can be referenced as a relation from your own models. In this example the MyProject model contains its own notification channel called notifications.
This channel should be registered with the Winter\Notify\NotifyRules\SaveDatabaseAction so it appears as a related object when selecting the action.
The label is shown as the related object, the class references the model class, the relation refers to the relation name. The param defines the parameter name, passed to the triggering event.
So essentially if you pass a project to the event parameters, or if project is a global parameter, a notification model is created with the parameters stored in the data attribute. Equivalent to the following code:
Dynamically adding conditions to events
Events can be extended to include new local conditions. Simply add the condition class to the event $conditions array property.
