Instagram Bundle Laravel Package

Getting Started

This is a Symfony2-era bundle that exposes the sesser/instaphp Instagram client as a container service. Expect to spend more time making it install than using it.

1. Install the dependency. Add it to composer.json (usually "oh/instagram-bundle": "~1.0" or dev-master). The bundle's own constraints almost certainly pin Symfony 2.x and PHP 5.x, so composer why-not oh/instagram-bundle symfony/framework-bundle is your first diagnostic step before you hit a wall on modern projects.
2. Register the bundle in app/AppKernel.php:

   new Oh\InstagramBundle\OhInstagramBundle(),
   

3. Configure credentials in app/config/config.yml. You will need client_id, client_secret, and (for read operations) an access_token. Verify the exact key names in DependencyInjection/Configuration.php — they vary across old bundles.
4. Find the service ID. Open Resources/config/services.yml (or .xml) and DependencyInjection/OhInstagramExtension.php. The client is typically aliased to something like oh_instagram.client; confirm before wiring it anywhere.
5. First use case: fetch a user's recent media from a controller:

   $api = $this->get('oh_instagram.client');
   $result = $api->Users->Recent($userId);
   

   The exact call shape depends on the Instaphp version vendored in; inspect the Instaphp namespace in vendor/sesser/instaphp for the available endpoints.

If step 1 fails on Composer conflicts, stop and evaluate whether a maintained Graph API client is a better fit — it almost always is.

Implementation Patterns

• Wrap, don't call directly. Create your own InstagramFeedProvider service that takes the bundle's client as a constructor argument. This isolates your application from the vendor library's quirks and lets you swap implementations later without touching controllers.
• Normalize responses. Instaphp returns its own response objects/arrays with inconsistent shapes per endpoint. Map them to small DTOs or plain arrays in your wrapper so templates and commands don't branch on library internals.
• Cache aggressively. Wrap calls in a Symfony cache (Doctrine cache provider in Symfony2) keyed by user/endpoint/params. Instagram's old rate limits are unforgiving, and a cached feed also hides the library's latency.
• Handle OAuth in one place. If you need per-user tokens, build a dedicated controller/route for the redirect back from Instagram and persist the token via a small TokenStore service. Do not scatter token exchange logic across controllers.
• Use a console command for sync. A app/console instagram:sync command that iterates tracked accounts and writes to your database keeps API traffic out of the request cycle and gives you a retry point.
• Inject via constructor everywhere. Skip $this->get() in new code where possible; define services in your bundle's services.yml and let autowiring/arguments do the work. This also makes unit testing feasible.
• Compose into a Twig extension if the feed is rendered directly — a {{ instagram_feed('account') }} function backed by your cached provider is cleaner than doing API calls in templates.
• Log every outbound call (endpoint, params minus secrets, status). This is the only sane way to debug rate-limit and auth failures later.

Gotchas and Tips

• The underlying API is retired. Instaphp targets Instagram's pre-Graph public API, which was shut down in 2020. Treat this bundle as a legacy artefact; plan a migration to the Facebook Graph API for any new functionality.
• Symfony 2 is EOL. You will not install this alongside Symfony 4/5/6 without forking and rewriting the service definitions. Check composer.json constraints first; if they conflict, don't waste time on --ignore-platform-reqs in production.
• No maintenance signal. Two stars, zero dependents, no CI or tests. Fork it into your own namespace the moment you rely on it — upstream fixes will not arrive.
• Config quirks. Old bundles frequently use %parameters% for credentials rather than proper config nodes, meaning env-specific overrides behave unexpectedly. Keep secrets in parameters.yml/parameters.yml.dist and never commit tokens.
• Rate-limit errors surface as exceptions, not status codes. Wrap all client calls in try/catch around the Instaphp exception classes and treat rate-limit responses as retryable with backoff; treat 400/401 as fatal so you don't hammer the API.
• Token expiry is silent until a call fails. Store expires_at alongside the token and refresh proactively; there's usually no helper in the bundle for this.
• Debugging: enable the Symfony profiler, tail app/logs/dev.log, and temporarily set the client to log raw HTTP bodies. The bundle rarely logs anything itself.
• Extension point for swaps. You can override the bundle's service definition by declaring the same service ID in your app's services.yml (loaded after the bundle). This is the cleanest way to substitute a fake client in tests without editing vendor code.
• Don't composer update blindly. Because dependencies are so old, a lock-file bump is likely to pull a version that breaks the bundle's assumptions; pin major versions and commit the lock file.