Download the PHP package preflow/notify without Composer

On this page you can find all versions of the php package preflow/notify. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

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 PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • 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.
Please rate this library. Is it a good library?

Informations about the package notify

preflow/notify

Send email, SMS and other messages through pluggable transports. Application code depends on one class, Notifier, and on small message value objects. Which provider delivers a channel is configuration.

Notifier is injected by constructor like any other service. Sending is synchronous. This is not a message bus or queue (unlike Symfony Messenger): it only delivers outbound messages.

Configuration

Core boots the package when config/notify.php exists:

Drivers

Driver Needs Purpose
log nothing Appends a summary and the body to storage/logs/messages.log (or path).
null nothing Drops messages.
memory nothing Keeps messages in memory (sent(), reset()) for tests.
failover nothing Tries transports in order. Skips any that can't send the message type.
symfony-mailer composer require symfony/mailer dsn: smtp://user:pass@host:587 or any Symfony mailer bridge DSN.
symfony-notifier-sms composer require symfony/notifier plus a bridge (e.g. symfony/twilio-notifier) dsn: e.g. twilio://SID:TOKEN@default?from=+41….

Messages

A provider with its own SDK

Implement Preflow\Notify\Transport and register it as a driver from a service provider:

Then set 'texts' => ['driver' => 'acme-sms', 'key' => getenv('ACME_KEY') ?: ''] in transports.

Sending after the response

Sending takes an SMTP round trip. On account flows (forgot password, registration, resend confirmation) that makes "an account exists" answer measurably slower than "no account", which leaks which addresses are registered. Queue those mails instead:

sendLater() only queues. Core sends the queue once the response has gone out: Application::run() emits the response, releases the client the way Symfony's Response::send() does (fastcgi_finish_request() on PHP-FPM, else litespeed_finish_request() on LiteSpeed LSAPI, else outside the CLI it flushes all output buffers), then calls flushDeferred(). The flush sits in a finally, so mail queued before an exception or an error page still goes out.

The "after the response" guarantee holds on PHP-FPM and LSAPI. Elsewhere (mod_php, plain CGI) it is best effort: the connection stays open until the script ends. Some timing differences remain regardless of the transport: building the message and any database writes happen before the response. Keep those equally cheap on both branches of an account flow. register_shutdown_function was not used: it runs outside the application's control and cannot be flushed deterministically in the CLI and in tests.

Errors

Every failure is a Preflow\Notify\TransportException. Provider errors are wrapped, and their message is masked: URL user-info (smtp://***@host) and secret-looking query parameters (api_key=***, password=***, token=***). The original exception is chained unmasked as getPrevious(), so don't log the whole chain verbatim.

When a failover delivers through a fallback, SentMessage::$failures lists each transport it fell back from (name → masked reason). Log these. Otherwise a broken SMTP setup goes unnoticed while mail quietly lands in the log transport.

The caller decides what a failure means; for a contact form, store the submission first, then send.

CLI

This sends a fixed test message through the configured transport and prints the result or the error. It exits non-zero when a failover had to fall back, and prints why the preferred transport failed. Use it to check credentials on a live server.


All versions of notify with dependencies

PHP Build Version
Package Version
Requires php Version >=8.4
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package preflow/notify contains the following files

Loading the files please wait ...