- Is ollieltd/instagram-bundle a Laravel package?
- No. It is a Symfony2 bundle that wraps the Instaphp v2 library in a Symfony dependency injection service. It ships no Laravel service provider, facade, publishable config, or Laravel-native HTTP and token abstractions. For a Laravel application it is at best a reference implementation rather than a dependency.
- Will this package install in Laravel 10 or Laravel 11?
- Almost certainly not without significant adaptation. The bundle carries legacy Symfony2 and PHP version constraints, while modern Laravel releases depend on current Symfony components and newer PHP versions, so Composer conflicts are likely. A short timeboxed install spike in your actual target version is the only reliable way to confirm.
- How do you install ollieltd/instagram-bundle?
- In a Symfony2 project you would require it via Composer and register the bundle in AppKernel, then configure your Instagram API credentials through the bundle configuration. There is no Laravel installation path, so Laravel users would need to bridge the services manually. Check the repository's composer.json for exact PHP, Symfony, and Instaphp version constraints before attempting anything.
- Does the underlying Instagram API integration still work today?
- This is the most likely hard blocker. Instaphp v2 targets older Instagram API behavior, and Instagram's API surface has changed substantially since then, with the current Graph and Basic Display APIs requiring different authentication and endpoints. Unless the bundle has been updated, the calls it makes may no longer exist or may no longer be authorized the same way.
- What PHP and Symfony versions does this bundle support?
- The package is a Symfony2-era bundle, so expect old PHP and Symfony 2.x constraints along with a dependency on Instaphp v2. Those constraints are what typically collide with modern Laravel and Symfony dependency trees. Verify the declared versions in composer.json rather than assuming compatibility.
- Can I use it to show an Instagram feed in a Laravel Blade view?
- Not directly, because the bundle exposes Symfony services and templates rather than Laravel views. The reusable idea is the boundary: isolate Instagram access behind an internal gateway interface and inject that into your controller or view composer. Then implement the gateway with Laravel's HTTP client, config, caching, and logging.
- What are the alternatives for Instagram integration in Laravel?
- The lowest-risk option is usually direct HTTP calls to the official Instagram Graph or Basic Display API behind your own small gateway class. You get full control over token storage, caching, rate limiting, and testing, and you avoid a legacy dependency chain. A maintained third-party SDK is a reasonable alternative if it supports the current API and modern Laravel versions.
- Is ollieltd/instagram-bundle maintained and safe for production?
- The signals are weak: about 10 stars, zero dependents, and no evidence of active maintenance. Combined with the legacy Symfony2 and Instaphp v2 dependencies, that creates real security and maintenance exposure for production use. If you adopt it at all, vendor a fork with explicit ownership and a documented exit plan.
- How would I migrate an existing Symfony2 integration off this bundle?
- Do not migrate onto the bundle; migrate away from it incrementally. First wrap the existing integration behind an internal InstagramGateway interface so callers are decoupled from Instaphp, then replace the implementation with calls to the current Instagram API one use case at a time. Validate each replacement against real endpoints before removing the old path.
- What should I check before adopting this bundle?
- Confirm your target use case is actually supported by Instagram's current Graph or Basic Display APIs, and verify the target stack is Symfony rather than Laravel. Then run a dependency, license, and security audit of both the bundle and Instaphp v2, and perform a throwaway install spike under your real Composer constraints. Finally, decide who owns maintenance and whether direct API calls would meet the requirement more cheaply.