- How do I install j7mbo/twitter-api-php in a Laravel application?
- Install it with composer require j7mbo/twitter-api-php. There is no Laravel service provider, facade, or PSR-4 autoloading, so you instantiate the global TwitterAPIExchange class directly with four credential strings. In a Laravel app, avoid referencing the class throughout your code and wrap it behind an interface adapter instead.
- Does j7mbo/twitter-api-php work with Laravel 9, 10, and 11?
- It is not Laravel-aware and has no declared compatibility with modern Laravel versions. The package is a single global-namespace class built on hand-rolled cURL and OAuth 1.0a, archived and unmaintained since around 2017/2018. It can technically be called from Laravel 9–11, but only as vendored code behind an adapter you own and test.
- How do I make GET and POST requests to Twitter API v1.1 with this package?
- You instantiate TwitterAPIExchange with a config array containing oauth_access_token, oauth_access_token_secret, consumer_key, and consumer_secret. Then call setGetfield() or setPostfields(), set the endpoint URL, and call performRequest(). The package handles OAuth signing and cURL transport, but returns raw JSON strings or null rather than structured responses.
- Is j7mbo/twitter-api-php still maintained or safe for production?
- No, it is archived and unmaintained, with no security patching, PHP compatibility guarantees, or maintainer escalation path. It also has no retry, backoff, timeout configuration, or rate-limit awareness, so 429 and Retry-After handling are your responsibility. Treat it as archived code with a stated exit date, not a long-term dependency.
- Can I use Laravel's Http::fake() or mock this package in tests?
- No, the package does not use Laravel's HTTP client, so Http::fake() cannot intercept its cURL calls. It has no tests and no HTTP abstraction, so mocking requires stubbing the TwitterAPIExchange class itself. The safer approach is to define your own TwitterClient interface, bind an adapter in the container, and write contract tests against the interface.
- How should I store Twitter API credentials when using this package in Laravel?
- Keep credentials in config/services.php fed by environment variables, never in request input or hard-coded arrays. The adapter should be the only place that reads those config values and passes them to TwitterAPIExchange. This keeps token rotation and environment separation out of application logic.
- What are the security risks of j7mbo/twitter-api-php, such as SSRF or TLS issues?
- setUrl() accepts an arbitrary URL, so any user-influenced input reaching it could cause credentials to be POSTed to an attacker-chosen host. The class also exposes cURL options that let careless callers disable peer verification. Restrict URLs to hard-coded Twitter endpoints, enforce TLS verification, and never let request data flow into setUrl().
- Does j7mbo/twitter-api-php support media uploads or chunked upload?
- No, chunked media upload with INIT, APPEND, FINALIZE, and STATUS is not implemented. Anything beyond a simple text tweet requires custom work. If media posting is a requirement, plan for a different client or a dedicated upload implementation.
- Which endpoints can I actually use with Twitter API v1.1 today?
- Most v1.1 read endpoints are unavailable to apps created after the 2023 platform changes, so endpoint access is the real gating item, not integration effort. Before writing application code, prove endpoint availability and your app's access tier with a throwaway script. Also decide whether you need user-context OAuth 1.0a or app-only authentication.
- What alternatives to j7mbo/twitter-api-php should I consider for Laravel?
- If you still have v1.1 access, abraham/twitteroauth is a more actively used OAuth library option. If you are moving to Twitter API v2, build a client on Laravel's Http client so you can use fakes, timeouts, retries, and centralized error handling. Either way, keep the package behind an adapter interface so replacement is a one-file change.