Salesforce Bundle Laravel Package

Getting Started

Reality check before you composer require anything: this is a Symfony 2 bundle, not a Laravel package. There is no service provider, no config publish tag, and no php artisan integration. It was last released in May 2015, has zero stars, zero dependents, and no signs of maintenance. Treat it as reference material for how someone once wired Salesforce into a legacy Symfony app, not as something you'll actually drop into a modern Laravel project.

If you genuinely need to evaluate it (e.g. you inherited a Symfony 2 app that already uses it):

1. composer require xrow/salesforce-bundle — expect version conflicts against anything modern (PHP 8, Symfony 5+, Laravel 9+). You'll likely need an isolated Symfony 2 app or Docker image to even install it.
2. Register the bundle in app/AppKernel.php (the old registerBundles() array, not config/bundles.php).
3. Put credentials under a namespaced key in app/config/config.yml — open the bundle's DependencyInjection/Configuration.php first to see exactly which keys it expects (endpoint, username, password, security token, and probably a WSDL path).
4. Find the main client service — likely Resources/config/services.yml will name it. That's your single entry point for all API calls.
5. First useful thing to try: query a Salesforce object by ID through the client and dump the response in a controller. That confirms auth, WSDL, and network egress in one shot.

For a Laravel project, the pragmatic move is to skip this entirely. The bundle is thin — the real work is in whatever SOAP client it wraps (likely phpforce/soap-client). You will save time by installing that client directly, or better, using omniphx/forrest (REST, Laravel-native, actively maintained) or the official Salesforce REST client.

Implementation Patterns

Assuming you're on a Symfony 2.x codebase that can actually run this:

• Inject the client service, don't instantiate it manually. The bundle's whole value is wiring the SOAP client singleton with credentials from config; bypassing it means redoing auth everywhere.
• Wrap it. Controller → your own SalesforceService/repository → bundle client → SFDC. Never call the bundle client straight from a controller; you want one seam you can swap when (not if) you migrate off the bundle.
• Typical operations are SOAP-shaped: query() with SOQL, create(), update(), upsert() (external-ID based, ideal for idempotent syncs from your Laravel app), describeSObject() for field metadata.
• Batch your writes. SOAP round-trips are expensive per record. For bulk loads, either loop with a small BatchSize or push to the Salesforce Bulk API separately (this bundle almost certainly doesn't wrap it).
• Cache describe results aggressively. Schema calls are slow and rarely change; cache them in your app's cache layer (Redis, filesystem) with a long TTL and a manual flush hook.
• Credential handling: keep secrets in env vars, not config.yml. Even in a Symfony 2 app, use %env(...)% or a parameters file that isn't committed.

For a Laravel app that wants the same capability:

• Bind a SalesforceClient interface in a SalesforceServiceProvider.
• Use omniphx/forrest for REST/SOQL, or phpforce/soap-client directly if you specifically need SOAP (legacy Enterprise/Unlimited orgs sometimes force it).
• Keep SOQL and payload logging on by default in non-prod.

Gotchas and Tips

• Dead package. 2015 vintage, no security updates, essentially no chance of clean installation on PHP 8+. Assume every modern framework version conflict is real until proven otherwise. Do not put this on a production path you can't isolate.
• Symfony-only integration. There is no Laravel equivalent; you cannot composer require and use it. Your realistic options are (a) a Symfony 2 sidecar/service, (b) extract the client logic by reading the bundle and porting it, or (c) use a maintained alternative.
• WSDL stubs. SOAP Salesforce clients typically regenerate PHP stubs from a WSDL. First call is slow; if the bundle generates stubs on the fly, cache them on the filesystem or the app will feel broken on cold starts.
• Session reuse matters. Salesforce sessions expire, and repeated logins burn through API request limits fast. Check whether the bundle caches the session ID — if it doesn't, add your own cache around the login step.
• Opaque errors. Salesforce SOAP faults often come back as generic INVALID_FIELD, UNKNOWN_EXCEPTION, or cryptic MALFORMED_QUERY. Enable __getLastRequest() / __getLastResponse() dumps on the underlying SOAP client (guard behind a dev flag) — without the full envelope you will guess for hours.
• Auth token confusion. Salesforce credentials need username + password + security token concatenated (or a trusted-IP exemption). This is a very common first-run failure and the bundle won't tell you which piece is wrong.
• Extension points are shallow. The bundle mostly wires config into a client. If you need custom behavior, fork and replace the client service class rather than trying to extend the bundle — it's not designed for it.
• Migration recommendation: if you're choosing today, don't choose this. omniphx/forrest for Laravel REST, the official salesforce/rest-api client for a vendor-neutral option, and reserve SOAP clients for orgs that genuinely require them. Keep this bundle only if you're maintaining an existing Symfony 2 install and have no upgrade path.