Download the PHP package railroad/mailora without Composer

Mailora

Wrapper for Laravel's email functionality that adds HTTP API and front-end-dev-friendly view-creation and use.

Table of Contents:

• Mailora
  • 1 - Installation and Configuration
  • 1.1 - Installation
  • 1.2 - Configuration
    • 1.2.1 - Laravel-native 'config/mail.php'
    • 1.2.2 - Package provided 'config/mailora.php'
    • 1.2.2.1 - TL;DR
    • 1.2.2.2 - Details
      • 1.2.2.2.1 - Top-level values
      • 1.2.2.2.2 - values nested under "defaults"
    • 1.2.3 - authentication middleware
  • 1.3 - Config for local-development
  • 2 - Features
  • 2.1 - send email with POST requests to endpoint
  • 2.2 - configure default values for common operations
  • 2.3 - "all-you-can-eat view variables"
    • 2.3.1 - Accessing Values Passed to View
  • 2.2 - Easy Custom Views
    • 2.2.1 - Flowchart for class and view to use
    • 2.2.2 - View files nested in email-directory sub-directories
  • 3 - API Reference
  • 3.1 - Send email from anywhere
    • 3.1.1 - Request Example
    • 3.1.2 - Request Parameters
    • 3.1.3 - Response Example
    • 3.1.3.1 - {200 OK}
    • 3.1.3.2 - {500 Internal Server Error}

1 - Installation and Configuration

1.1 - Installation

Install using Composer by running

or add to composer.json

and then run composer update railroad/mailora.

(I'm not sure what to do regarding specifying which version to use. Maybe just use "dev-master"?)

Add \Railroad\Mailora\Providers\MailoraServiceProvider::class, to the providers array in your application's config/app.php.*

run php artisan vendor:publish, selecting this package from the resultant list of options.

This will register views and routes, and will copy the configuration file into your application. Commit the config file to you application. Detailes on configuration are below.

* (minor note RE future dev of this project) We shouldn't need to do this, but it seems feature of Laravel where the Service provider can just be registered in a package's own composer.json file... is not working, and so therefore you must add this to the application.

1.2 - Configuration

There are two files to configure. They are both in you application's "config" directory:

1. 'mail.php'
2. 'mailora.php'

See more details about each in the two sections below.

Note that both config files can use Laravel's "env()" helper function. Thus, you can override a value hardcoded in a config file at any time by supplying an environment variable. This can be useful for alternate configurations for local or staging environments.

You can then call these configuration values using Laravel's config helper

Example:

1.2.1 - Laravel-native 'config/mail.php'

This is a Laravel-native file to provide email-sending-service details. This file configures standard Laravel functionality and you can refer to their documentation for details.

Supply the secret for your chosen email service as an environment variable, do not commit the actual value to a config file.

You can hard-code other non-sensitive values in the config file.

1.2.2 - Package provided 'config/mailora.php'

1.2.2.1 - TL;DR

The bare minimum to provide to config/mailora.php is the following:

• 'safety-recipient'
• 'defaults'
  • 'sender-address'
  • 'recipient-address'
• one or both of the following
  • 'auth_middleware'
  • one or both of the following
    • 'approved-recipients'
    • 'approved-recipient-domains'

1.2.2.2 - Details

This file is copied from this package to your application's "config" directory by running artisan vendor:publish.

There are two basic functions. One is sending by calling an unprotected route. This is available to the whole world, and so will only send to email addresses (or domains) explicitly allowed by configuration. The other ("secure") is only accessible to authenicated users. For the former you must supply 'approved-recipients' or 'approved-recipient-domains' values and use the public route. For the latter you must supply a authentication middleware to use the "secure" route.

1.2.2.2.1 - Top-level values

1.2.2.2.2 - values nested under "defaults"

* with caveat—see note

Link to config file template.

1.2.3 - authentication middleware

Supply one value in a string as "auth_middleware". Use the key from the "$routeMiddleware" property of your application's App\Http\Kernel class (configured as per Laravel functionality).

For example, if your app/Http/Kernel.php has:

...then in config/mailora.php you can have something like this:

1.3 - Config for local-development

Rather than mess around with changes to the config file, because Laravel's env() function is used, you can just provide environment variable to override anything hard-coded in the config files. Define values in a ".env" file in your application root.

At a bare minimum, you provide "MAILORA_SAFETY_RECIPIENT" so that you're sure of where emails are being sent. Emails will only be sent to that address when the enviroment is is anything other than "production" (or the value returned by config('mailora.name-of-production-env') if it's different than "production");

example:

Or supply many values:

2 - Features

2.1 - send email with POST requests to endpoint

To send an email, simply send a POST request as described in these docs. You'll receive a simple "sent" boolean value in response.

2.2 - configure default values for common operations

Always send to the same email address. Set that as the default in the configuration, and then on requests to send to that address, don't pass a "recipient-address" value. The default will be used.

In fact, the endpoint has no required parameters—you can place all required information in the configuration and only provide unique info when required.

2.3 - "all-you-can-eat view variables"

You can easily pass values you need and have them available in your custom view. No PHP needed.

2.3.1 - Accessing Values Passed to View

Values passed to view in request are nested in $input variable.

Thus, if you pass:

You can access the custom values you're passing via the $input variable in the view. For example:

Note the $line variable. This is defined in the foreach-loop, and thus is not $input[line].

2.2 - Easy Custom Views

If no 'type' value is provided in a request, the Mailora's General class and general.blade.php view will be used. If a type value is passed, Mailora will look for a class matching the CapitalizedCamelCase version of that value*. Mailora will look for this class in the namespace returned by config('mailora.mailables-namespace)**. If a class exists there, it will be used. If no class is used, Mailora's General class will be used. This class is simply uses whatever view supplied, and passes a $input parameter along to the view so that all values are retrieved from that.

This enables the following.

Regardless of what class is used—that is to say even if no Mailable class was found matching the ConvertedCapitalizedCamelCase 'type' value passed, Mailora will then look for a view file matching that type value. It looks for files in the directory described by the string returned by config('mailora.views-directory')**. If one if found, that is used. If not, mailora's general.php is used***.

The upshot of all this is that new email-templates can be created with no back-end modifications required. Simply create a view file, and supply and retrieve values from the $input parameter.

TL;DR Regarding the value 'type' specified in request data. It will resolve to class if possible. Else, the default General PHP Mailable class will be used, and 'type' will resolve to a view, if possible. Else, the default 'general.blade.php' will be used.

* the value foo-bar-baz would use the class FooBarBaz and the view file "foo-bar-baz.blade.php".

** this is set—and can therefore be changed—in the mailora.php config file

*** Note that this file exists in "/your-application/vendor/railroad/mailora/resources/views/"

2.2.1 - Flowchart for class and view to use

2.2.2 - View files nested in email-directory sub-directories

To specify a view in a subdirectory (of your emails directory), simply type that relative path of the view file.

For Example, let's say your views dir is: /appFoo/resources/views/emails. You can use the view file /appFoo/resources/views/emails/fooView.blade.php by specifying the "type" value for your email request as "fooView". But what if you have a view file in the emails/barDir directory? Say maybe something like /appFoo/resources/views/emails/barDir/quxView.blade? Well, you would just specify the type as barDir/quxView.

This is all of course assuming you don't need any getting or special transformations possible with a custom laravel Mailable PHP class and are okay with the default Mailora General PHP class being used.

3 - API Reference

There are two endpoints:

1. POST /mailora/public/send (Publicly accessible)
2. POST /mailora/secure/send (User must be authenticated to access this endpoint)

See details below.

In addition to the parameters listed below, any other parameter can be passed, and it will be available in the view!

For example, if you have a 'foo' : 'bar' item in data for a request, in the view, {{ $input['foo'] }} will print "bar".

Another example: 'foo' : 1 in the request will allow {{ $input['foo'] ? 'true' : 'false' }} in the view.

3.1 - Send email from anywhere

POST /mailora/public/send/

Can be called from anywhere. Handy for sending emails from publicly-accessible support and sales pages.

Recipient cannot be specified. Will be sent to MAIL_FROM_ADDRESS unless MAIL_FROM_ADDRESS_PUBLIC provided. Though, you can set the "Sender name"

User must be defined in config file "config/mailora.php". If user is not present there, email will not be send to intended recipient.

3.1.1 - Request Example

Alternatively, set "recipient-address" (and optionally "recipient-name") rather than "recipient" if you just have one to specify.

3.1.2 - Request Parameters

Provide all parameters in the request body.

Note that no fields are required!!

Note 1: A provided name is not used unless address also provided from same source. For example: Say sender-address and sender-name are both set in the configuration file. If a request doesn't not specify request-address, then the addresss and name from the config will be used. However, if the request supplies an address but no name, then that address (from the request) will be used, but not the name from config. The only time the name in the config is used, is when the address in the config is used. When an address is provided in the request, only a name similarily provided in the request will be used. A name provided from config will not be used if an email address is provided in a request.

Note 2: Pass any number of recipients as items in array formatted as JSON-string. Each recipient is an item in the array. There are two options to specify each recipient in the array:

1. as just a string of the address.
2. as an object-literal with the "address" defined, and optionally the "name"

Example:

Also, this will be renamed to "recipients" one day.

3.1.3 - Response Example

3.1.3.1 - {200 OK}

3.1.3.2 - {500 Internal Server Error}

or