Beautymail Laravel Package

Getting Started

1. Install: composer require snowfire/beautymail.
2. Publish config and theme views so you can see/edit them:

   php artisan vendor:publish --provider="Snowfire\Beautymail\BeautymailServiceProvider"
   

   This drops config/beautymail.php and theme views under resources/views/vendor/beautymail/.
3. First use case — replace a plain Mail::send() with a themed send:

   use Snowfire\Beautymail\Beautymail;
   use Illuminate\Support\Facades\Mail;
   
   Beautymail::send('emails.welcome', ['name' => $user->name], function ($message) use ($user) {
       $message->to($user->email)->subject('Welcome!');
   });
   

4. Your Blade view extends the package layout and fills the content section:

   @extends('beautymail::layout')
   @section('content')
     <h1>Welcome, {{ $name }}</h1>
   @stop
   

   The shipped themes (default, muse, malihu) ship responsive, inline-styled tables around that content — that's the primary value. Look at config/beautymail.php first; it's where theme and branding live.

Implementation Patterns

• Standard send vs. queue: Beautymail::send(...) for synchronous, Beautymail::queue(...); for background. Signatures mirror Mail::send/Mail::queue, so porting existing calls is mostly a find-and-replace.
• Mailable wrapper: since the package predates Mailable, wrap calls in a small helper or your own Mailable subclass that delegates to Beautymail::send() inside build(). Keeps the rest of your app on Laravel-native APIs.
• Custom theme: publish views, copy resources/views/vendor/beautymail/theme/default to a new folder, edit the Blade/CSS, then set 'theme' => 'mytheme' in config/beautymail.php. Avoid editing vendor views.
• Shared layout across emails: create resources/views/emails/base.blade.php extending beautymail::layout, define reusable @section('header')/@section('intro') bits, then have each email extend that instead of the package layout directly.
• Logo/asset delivery: keep logos as absolute URLs under a public CDN; the theme templates use asset(), so set APP_URL correctly per environment.
• Testing: because it delegates to Laravel's Mail/queue infrastructure, Mail::fake() / Queue::fake() assertions usually still apply — but verify against your version.

Gotchas and Tips

• APP_URL is load-bearing. If APP_URL is http://localhost, every email logo/image will be broken in real clients. Set it per environment.
• Base64 and local paths get stripped. Gmail and Outlook block inline base64/logos and any file:// or localhost references. Always host assets publicly.
• Theme name must match the folder under resources/views/vendor/beautymail/theme/. A typo in config('beautymail.theme') produces cryptic Blade "view not found" errors, not a theme error.
• You're maintaining CSS now. The bundled themes are a starting point; responsive email quirks (Outlook fixed width, Outlook.com clipping, dark mode overrides) still require manual work in the published views. Inline-styles-first is the norm.
• Don't confuse Beautymail::send with Mail::send. They share a facade-ish feel, but only Beautymail applies the layout — if you accidentally leave a Mail::send() in a notification path you'll get unstyled mail.
• Extension point is the view, not the driver. Want new sections or a different wrapper? Override the layout view (beautymail::layout) in your published views or extend it — don't try to subclass the mailer.
• Upgrade caution: the package sits on top of Laravel's mailer internals; bumping Laravel major versions can silently break theme rendering before you notice. Add a render-to-string test that snapshots one template.