Prestashop Webservice Bundle Laravel Package

Getting Started

This package is a Symfony bundle for the PrestaShop Web Service, not a Laravel package. A Laravel developer should start by treating it as a reference implementation and consuming the underlying libraries directly:

• prestashop/webservice-lib — the core API client.
• webservice-lib-extra — now bumped to v1.3 in this release; this is the most likely source of behavioural changes.

Minimal steps:

1. Add the underlying libraries to your Laravel app:

   composer require prestashop/webservice-lib
   composer require jupi007/webservice-lib-extra
   

2. Add credentials to config/services.php and .env:

   'prestashop' => [
       'url' => env('PRESTASHOP_URL'),
       'key' => env('PRESTASHOP_WS_KEY'),
   ],
   

3. Bind a configured client in a service provider:

   $this->app->singleton(PrestaShopWebservice::class, fn () => new PrestaShopWebservice(
       config('services.prestashop.url'),
       config('services.prestashop.key')
   ));
   

Where to look first:

• The package README.md (updated in v1.2.0) for bundle configuration keys and example calls.
• The bundle’s DependencyInjection/Configuration.php to see which options are expected.
• The webservice-lib-extra v1.3 changelog before upgrading — the bundle release only bumps that dependency.

First use case: Fetch a paginated product list and inspect the XML response:

$client->get([
    'resource' => 'products',
    'options'  => ['limit' => 10, 'display' => '[id,name,price]'],
]);

Implementation Patterns

Because the Symfony bundle’s DI wiring is not reusable in Laravel, wrap the client in a small Laravel service and build repositories around it.

Recommended layering:

• PrestaShopClient singleton in a service provider.
• One repository per resource (Products, Orders, Customers, StockAvailables).
• DTOs or arrays mapped from the XML responses via simplexml_load_string.

Common workflows:

• CRUD: use get, add, edit, delete, and head on the client. Send XML bodies built with SimpleXMLElement.
• Filtering/pagination: pass limit, filter, sort, and display through the options array; centralise this in a query builder to avoid repeated boilerplate.
• Sync jobs: wrap each resource sync in a queued job. Keep a cursor or last-sync timestamp so failed jobs resume rather than re-fetching everything.
• Caching: cache read-only lookups (taxes, carriers, categories) with Cache::remember; avoid caching stock or order data without a short TTL.
• Testing: mock the HTTP layer or inject fixtures of real XML responses. PrestaShop’s XML schema is strict; fixture-based tests catch payload errors before they reach the API.

Integration tips:

• Keep the PrestaShop client out of controllers; inject repositories instead.
• Normalise PrestaShop’s language and shop-ID fields (id_lang, id_shop) in one place.
• Log raw request/response pairs at debug level, but redact the API key.

Gotchas and Tips

• This is not a Laravel bundle. Do not try to register the Symfony bundle in Laravel. Use the underlying libraries or run a Symfony sidecar service if you need the bundle’s exact behaviour.
• webservice-lib-extra v1.3 is the real change here. Review its changelog and pin the version in composer.json before upgrading production.
• API key permissions are configured in the PrestaShop back office. A key with read-only access will fail silently on add/edit unless you check the response.
• XML, not JSON. Expect SimpleXMLElement, CDATA handling, and required fields that the PrestaShop schema does not validate client-side. Missing fields often fail only at the API.
• null vs empty string matters in PrestaShop payloads, especially for associations and optional fields.
• Error handling: catch PrestaShopWebserviceException and inspect the HTTP status and response body. PrestaShop returns useful error XML that is easy to discard.
• Debugging: use Guzzle’s debug option or Laravel’s HTTP client when building a replacement transport. Log the exact URL and XML body.
• Extension points: the underlying client usually exposes the HTTP transport; swap it for Laravel’s Http facade or a mocked client in tests. The bundle’s configuration shows the expected shape of connection settings.
• Version compatibility: check PHP version constraints of webservice-lib-extra v1.3 against your Laravel runtime before upgrading.
• Release scope: v1.2.0 is a README update plus a dependency bump. There are no new features described, so evaluate the webservice-lib-extra v1.3 changes rather than the bundle itself.