Php4Mailer Bundle Laravel Package

Getting Started

This is a Symfony bundle wrapping PHPMailer, not a Laravel package — there is no service provider, no config/php4mailer.php, and no facade. Before reaching for it, confirm you actually need it: Laravel's Mail facade (Symfony Mailer under the hood since Laravel 9) covers virtually every case this bundle handles.

If you still want to proceed:

1. composer require uga/php4mailer-bundle — expect dependency friction; it was last released in Feb 2017 and targets PHP 5.6/7.0-era Symfony.
2. Inspect the repo's Resources/config/ and any *Extension.php — that is where the service definitions and default config live. That config shape is what you'd translate into a Laravel config file if you decide to wrap it.
3. First use case in a Laravel app: a small PhpMailerServiceProvider that binds an instance of the bundle's mailer class into the container, OR (simpler) just use phpmailer/phpmailer directly and skip the bundle entirely.

For a Laravel project, the pragmatic first step is usually the last one — install PHPMailer, wire your own small service, and treat this bundle only as reference code.

Implementation Patterns

Because the bundle targets Symfony's DI container, you'll be re-hosting its core (usually a thin wrapper around PHPMailer) yourself:

• Service provider binding. Register the bundle's mailer class as a singleton in AppServiceProvider, injecting SMTP credentials from config/mail.php or a dedicated config/php4mailer.php you create.
• Facade (optional). Wrap the singleton in a PhpMailer facade for ergonomic calls: PhpMailer::to(...)->subject(...)->send().
• Job-based sending. Never call SMTP synchronously in a request. Dispatch a SendPhpMailerJob so retries and timeouts are handled by the queue, not the user's request.
• Mailable-like DTO. Create a small class (PhpMailer message) holding recipients, subject, HTML/plain bodies; have the job translate that into the PHPMailer instance. This keeps templates testable.
• Config translation. Map any Symfony bundle parameters (mailer.host, mailer.port, mailer.username, mailer.encryption) 1:1 into your Laravel config keys so migration between the two is mechanical.
• Testing. Bind a fake mailer into the container in tests rather than hitting SMTP — since the bundle has no Laravel-aware fakes, you're responsible for the seam.

Gotchas and Tips

• It's not a Laravel package. No auto-discovery. Composer will install it, but nothing is wired up. If you're expecting php artisan vendor:publish, you'll find nothing.
• Age and compatibility risk. Last release 2017, zero stars, no dependents in the ecosystem. It almost certainly predates PHP 8 types and may fail strict-null checks, or pull in old Symfony components that clash with Laravel 9+'s shipped Symfony pieces. Test on a throwaway branch first.
• Symfony component conflicts. The bundle will pull in symfony/dependency-injection and friends. If version-constrained, Composer may downgrade framework packages — inspect composer why before merging.
• Debugging PHPMailer. Set SMTPDebug = 2 (or 3) and pipe to a logger; PHPMailer's raw output is noisy but the only way to diagnose SSL/auth failures. SMTPAuth = true plus SMTPSecure = 'tls' on port 587 is the modern baseline.
• Extension points are thin. The bundle's "extension" is really just its DI config. If you need retries, logging, or templating, you're building it yourself — which is the same work as using phpmailer/phpmailer directly.
• Verdict for a Laravel dev. Treat this repo as documentation, not a dependency. Reuse its PHPMailer wiring ideas; depend on phpmailer/phpmailer (actively maintained) or, better, stay on Laravel's built-in mailer unless you specifically need PHPMailer features (raw SMTP control, legacy attachment quirks, Microsoft Exchange behaviors).