Social Post Bundle Laravel Package

Getting Started

Don’t install the Symfony bundle into a Laravel app and expect it to work. martin-georgiev/social-post-bundle is a Symfony bundle (symfony-bundle type), archived since 2020, and Laravel’s package discovery will not register it. The usable part is the underlying posting library it wraps; the bundle is mainly a Symfony DI/config layer.

Minimal path for a Laravel developer:

1. Inspect the repository before installing:
   • README.md for the supported providers and config shape.
   • DependencyInjection/Configuration.php for the exact config keys.
   • Resources/config/services.* for the service ID/class to bind.
   • The underlying martin-georgiev/social-post library’s builder and provider classes, because that is what actually calls Facebook/LinkedIn/Twitter.
2. If you control a Symfony app, register MartinGeorgiev\SocialPostBundle\SocialPostBundle in config/bundles.php, add config/packages/social_post.yaml, and inject the SocialPost service into a command or controller.
3. In Laravel, install the underlying library and write a small service provider that binds a singleton around its builder. Keep credentials in config/social_post.php and .env.

First use case: a queued Laravel job that publishes the same announcement to Facebook, LinkedIn, and Twitter, then logs per-network success/failure. Start with a console command or php artisan tinker against sandbox accounts before putting it behind a queue.

// App\Jobs\PublishAnnouncement
class PublishAnnouncement implements ShouldQueue
{
    use InteractsWithQueue, Queueable;

    public function __construct(public string $message) {}

    public function handle(SocialPost $socialPost): void
    {
        // The exact method names come from the underlying library.
        $socialPost->post($this->message);
    }
}

Implementation Patterns

Wrap, don’t couple. Treat the bundle as a reference implementation. In Laravel, create App\Services\SocialPoster or bind the underlying library’s SocialPost/builder in a service provider. Your application code should depend on your wrapper, not on Symfony service IDs or the bundle namespace.

Use one job per network when reliability matters. The package’s default model is “post the same message everywhere.” That is convenient for a demo and fragile in production: one expired token can fail the whole fan-out. Prefer dispatching separate jobs per provider, or catch and record per-provider failures so a LinkedIn outage does not block Twitter.

Keep credentials per environment. Use sandbox/test accounts locally and separate app credentials per environment. Never commit tokens. In Laravel, put the config in config/social_post.php and read from .env; run php artisan config:clear after changes.

Queue with backoff and idempotency. Social APIs return rate limits and transient 5xx errors. Use ShouldQueue, tries, backoff(), and a failed() handler. Store a local record of what was posted where, because blind retries can duplicate posts. If the provider response includes a post ID, persist it.

Log the provider context. Log network name, HTTP status, and a redacted request/response summary. If the library uses Guzzle, add a Guzzle middleware/history handler in development to see the actual request. Do not log access tokens or consumer secrets.

Test with fakes, not live APIs. Bind a fake implementation of the provider interface in tests, or use Guzzle’s mock handler. Keep a tiny manual smoke test against sandbox accounts because these APIs change frequently.

Extension point: custom providers. If you need a network the package does not support, implement the underlying library’s provider contract and register it in your own builder/binding. In Symfony you can override the bundle service; in Laravel you own the binding entirely.

Gotchas and Tips

• Archived and stale. Last release was 2020-05-31. Facebook Graph, LinkedIn, and Twitter APIs have all changed since then. Expect deprecated endpoints, OAuth 1.0a/Twitter v1.1 issues, and 401/403/410 responses. Check the provider classes for hard-coded API versions before promising anything.
• Not a Laravel package. No Laravel service provider, no facade, no package discovery. The Symfony bundle config, cache warmup, and DI conventions do not apply. A Laravel adapter is custom code you must maintain.
• Likely text-only. Do not assume media upload, threading, or rich previews are supported. Verify each provider’s capabilities in source. Message limits differ: truncate or validate per network rather than relying on one shared message length.
• Single credentials per provider. The bundle-style config typically assumes one Facebook app/page, one LinkedIn account, and one Twitter account. Multi-tenant or multi-brand posting requires multiple builder instances or custom provider configuration.
• No token refresh strategy. Short-lived tokens expire. Build refresh/reconnect flows and alert on auth failures; do not wait for the first failed campaign.
• Config cache quirks. In Symfony, run cache:clear after config changes. In Laravel, run config:clear/config:cache. Mismatched env names are a common cause of “it works in tinker but not in the queue worker.”
• Error messages may be generic. Inspect the underlying exception and HTTP response. If debugging is hard, wrap the client with logging middleware or temporarily dump the response body in a local command.
• Avoid retrying non-idempotent posts blindly. Rate-limit retries are fine; retrying after a timeout can double-post. Use a local “already published” marker per network and message hash.
• Verdict for day-to-day Laravel work: do not adopt this for new production code. Use it only as a reference for the underlying library, or as a short-lived legacy bridge. For new work, prefer maintained provider SDKs or a cross-posting service, and use Laravel Socialite only for OAuth, not for publishing.