Processone Bundle Laravel Package

Getting Started

Before writing any code, open the repository and read three things in this order: the README.md, composer.json, and the bundle's service definition file (Resources/config/services.xml or services.yml). With 3 stars and a final release in December 2015, that trio is the only real documentation you will get — there is no maintained docs site, no changelog worth trusting, and no ecosystem of blog posts. The service definition is the source of truth for what service IDs exist, what they are aliased to, and which constructor arguments/configuration keys they expect.

Understand what you are actually installing. This is a Symfony bundle, not a Laravel package. It wraps ProcessOne's HTTP API (the company behind ejabberd; the bundle targets their push/messaging service) in Symfony DI services. In a Laravel context you have two realistic paths:

1. Use it inside a legacy Symfony app — the intended use case. Register new Rezzza\ProcessOneBundle\RezzzaProcessOneBundle() in AppKernel.php (Symfony 2/3 era), import the bundle config, set credentials, done.
2. Borrow the client, skip the bundle — for a Laravel app this is almost always the right call. Install into a scratch directory, inspect the client class the bundle registers, and either use that class directly via new or wrap it in your own thin client. You avoid the Symfony kernel and DI baggage entirely.

Installing it at all is the first hurdle. The dependency tree was resolved against PHP 5.x/early-7.x and a mid-2010s Guzzle. On a modern PHP 8 runtime composer require rezzza/processone-bundle will likely fail on platform constraints. Try it in a throwaway project with --ignore-platform-reqs just to inspect the code, then decide whether to vendor the one or two classes you actually need into your own namespace.

First use case: send a single push notification (or XMPP message, depending on which ProcessOne endpoint this bundle targets) through the client service, log the raw response, and confirm it lands. Do that once in a tinker-style script — not through your app's abstraction — so you learn the actual request/response shape before designing around it.

Implementation Patterns

Inject, don't instantiate, inside Symfony. The whole point of the bundle is that the client is a DI service with credentials wired from config. Fetch it from the container (or inject it into your service) rather than constructing it, so the bundle's HTTP client, base URL, and auth headers are configured in one place.

Always send from a queued job. Push/messaging APIs are network calls owned by a third party. Wrap the client call in a queued job so a slow or failing ProcessOne endpoint doesn't block a request cycle, and so you get retries and backoff for free.

// Laravel-land: adapter around the bundle's client class
final class ProcessOneNotifier
{
    public function __construct(private \Rezzza\ProcessOne\Client $client) {}

    public function push(string $deviceToken, string $message): bool
    {
        try {
            $response = $this->client->push($deviceToken, $message);
            return $response->isSuccessful();
        } catch (\Exception $e) {
            report($e); // log and let the job retry
            throw $e;
        }
    }
}

Config per environment. The bundle expects credentials through its config tree (the Configuration.php class documents the exact keys). Mirror those into env() calls in your app's config so sandbox/production tokens never leak between environments, and so rotating a token doesn't require a code change.

Introduce your own interface early. Define an application-level Notifier interface (or a small value object for a notification) and implement it with the ProcessOne client. That way the bundle's likely-abandoned API surface is contained in one adapter class you can rewrite when you eventually migrate, rather than smeared across your codebase.

Test with the transport mocked, not the client. Because this is an HTTP wrapper, mock at the Guzzle/handler layer or stub your adapter interface. Do not hit ProcessOne in tests. If you kept the bundle installed, note that it may have its own test helpers — but don't rely on them; they're a decade old.

Gotchas and Tips

• This package is effectively abandoned. Last release 2015, 3 stars, 0 dependents. Treat it as a code sample, not a supported dependency. Budget for vendoring the client class into your own codebase rather than carrying the composer dependency forever.
• PHP and Guzzle version mismatch is the most likely first failure. Expect platform-requirement conflicts and a pinned old Guzzle. If you must install, isolate the dependency; if you don't, copy the classes out.
• No Laravel service provider exists. You will write your own binding in a ServiceProvider (or plain new) if you want container-managed access.
• Symfony DI conventions will confuse you coming from Laravel. Services are defined in XML/YAML with constructor arguments and tagged services — there is no auto-discovery, no facades, no config/packages/*.yaml modern style. Read the bundle's service definition file carefully before wiring anything.
• Configuration keys are undocumented outside Configuration.php. Read that class to learn required vs optional keys and defaults; it is the contract.
• Credential handling is your responsibility. Don't hardcode tokens in the bundle config; pull them from environment and keep them out of version control.
• Error handling in the old client is probably coarse — likely throwing generic exceptions or returning a response object with a status. Log the raw response body on failure; ProcessOne's error messages will be the fastest way to debug 401s (bad token) vs 4xx (bad payload).
• Extension points are minimal. If the bundle lacks a method you need, don't fork it — extend or decorate the client in your own class. That keeps you off the abandoned upstream.
• Before adopting, sanity-check the endpoint and API version. A 2015 client may target an older API path or payload shape. Confirm against current ProcessOne documentation, because a silently changed API is exactly the kind of failure an unmaintained bundle cannot warn you about.