Swiftmailerdbbundle Laravel Package

Getting Started

This is not a Laravel package. zrgisa/swiftmailerdbbundle is a Symfony bundle (a fork of WhiteOctober's SwiftMailer DB spool). There is no service provider, no facade, no config publish tag. If you composer require it into a Laravel app, nothing will auto-wire.

What to actually do first:

1. Skim the source, don't install it. Look at Entity/ (the spooled-message schema) and Spool/ (the queue/flush logic). That schema is the only part worth borrowing.
2. Decide what you're solving. The bundle's job is "persist mail before sending so a crash doesn't lose it." Laravel already solves that with the queue: Mail::to($user)->queue(new WelcomeMail) on a database queue driver. Use that first.
3. First real use case for a port: durable spooling where you want to audit every outbound message or replay failed ones. In that case copy the schema (id, message body, status, attempts, timestamps) into a migration and wrap it in an Eloquent model + queued job.

Implementation Patterns

The bundle's Symfony pattern is:

• Config selects a DB spool service in the mailer config.
• A service implements Swift_Spool with queueMessage() / flushQueue(), persisting rows via Doctrine.
• A cron job runs swiftmailer:spool:send to drain the table.

The Laravel equivalent, in decreasing order of "you should do this":

Pattern 1 – Native queue (recommended).

Mail::to($user)->queue(new WelcomeMail($user));

Configure QUEUE_CONNECTION=database, run php artisan queue:work. You get retries, failed_jobs, and Horizon for free—the bundle offers none of that.

Pattern 2 – Transport decorator. Wrap Laravel's mailer transport so send() writes an RFC822 blob to a table, and a scheduled command re-sends and marks sent. Register by extending Illuminate\Mail\MailManager and adding a custom driver.

Pattern 3 – Full port of the bundle. If you insist: create a mail_spool migration (message LONGTEXT, status, attempts, next_attempt_at), an Eloquent model, a SpoolMail job, and a php artisan mail:flush command on the scheduler. Do not pull in doctrine/orm just to reuse the bundle's entities—Laravel devs should stay in Eloquent.

Integration tips for Pattern 2/3:

• Store the mailable class + serialized constructor args, not just the rendered body, so you can re-render after template fixes.
• Add a unique message_id column for idempotent re-sends.
• Use schedule->command('mail:flush')->everyMinute()->withoutOverlapping().

Gotchas and Tips

• SwiftMailer is EOL (Nov 2021). Laravel 9+ ships Symfony Mailer, so the bundle targets a transport Laravel no longer uses. Do not build on it.
• No service provider = no auto-discovery. Its config tree (white_october_swift_mailer_db or similar) is entirely ignored by Laravel's config system.
• Doctrine vs Eloquent. The bundle's entities expect doctrine/orm. Wiring that into Laravel means a second ORM and a second connection stack—almost never worth it.
• Zero stars, zero dependents. Treat this as reference code, not a dependency. There's no security or bugfix support channel.
• Large payloads. RFC822 message bodies blow past TEXT limits; use LONGTEXT/MEDIUMBLOB and guard against MySQL max_allowed_packet errors on the flush insert.
• Table bloat. Every mail is a row. Schedule a prune (->dailyAt('03:00')) that deletes sent rows older than N days, and index (status, next_attempt_at).
• Double-send on concurrency. The original cron model just reads-and-sends. Multiple workers will double-send unless you claim rows atomically—e.g. UPDATE ... SET status='sending' WHERE id=? AND status='queued' and check affected rows. This is the main bug you need to fix if porting.
• Extension seam. In the Symfony world you'd override the spool service. In Laravel, the equivalent hooks are MailManager::extend() (custom driver) or a queued job's middleware()/failed() callbacks—use those rather than editing vendor code.
• Debugging tip. If mail "vanishes", check whether the spool row is queued but no worker/scheduler is running—the bundle's design assumes an external cron (swiftmailer:spool:send) that has no Laravel analogue by default.