Ozon Support Laravel Package

Getting Started

This is a Symfony-style bundle (bin/console), not a Laravel package despite the "Laravel/Symfony" description — plan accordingly before you commit to it.

1. Require the package

composer require baks-dev/ozon-support

Check what it pulled in — the module almost certainly depends on baks-dev/users (it registers a profile type) and a core baks-dev/core-style package. Run composer show baks-dev/ozon-support and inspect require before anything else:

composer show baks-dev/ozon-support

2. Register the profile type

php bin/console baks:users-profile-type:ozon-support

This is the single mandatory post-install step. It persists an Ozon Support user profile type into the database so that Ozon-side identities can be attached to your users. It is idempotent by design, but run it once per environment (dev, staging, prod) as part of your deploy script.

3. Clear caches and check schema

php bin/console cache:clear
php bin/console doctrine:migrations:status   # see whether the bundle shipped migrations

If migrations exist, run them. If the profile-type command writes rows, confirm it did:

php bin/console doctrine:query:sql "SELECT * FROM users_profile_type"  # adjust table name to the real one

4. Verify the install with the package's own tests

php bin/phpunit --group=ozon-support

This is your fastest smoke test — it exercises the bundle's own fixtures rather than your app.

Where to look first, in order:

First use case: attach an Ozon Support profile to an existing user so their Ozon identity is resolvable in the app's user context — then query that profile back to prove the wiring works end-to-end.

// After the console command has registered the type
$profileType = $profileTypeRepository->findByIdentifier('ozon-support');
$user->addProfile($profileType, $ozonAccountData);
$em->flush();

Confirm the exact repository/identifier API from src/ — the identifier string is not documented anywhere but the command class.

Implementation Patterns

Register the profile type declaratively in deploys. Don't ask humans to run one-off commands. Wire it into your release pipeline so it's always present:

php bin/console baks:users-profile-type:ozon-support --no-interaction
php bin/console cache:clear

Run it after migrations, before workers restart.

Resolve the profile type by identifier, never by hardcoded ID. Auto-increment IDs differ across environments; the identifier string is the stable handle.

Encapsulate behind your own service. With zero docs and zero stars, treat the bundle as a third-party integration boundary. Wrap every call into a thin adapter of your own:

final class OzonSupportGateway
{
    public function __construct(private readonly ProfileRepository $profiles) {}

    public function forUser(User $user): ?OzonSupportProfile
    {
        return $this->profiles->findOneByUserAndType($user, 'ozon-support');
    }
}

If the bundle is abandoned or breaks on a PHP bump, you rewrite one class instead of grepping your codebase.

Test with the shipped group, and mirror it. Run --group=ozon-support in CI alongside your own suite. When you write your own tests, copy the bundle's fixture setup — it already solved the "how do I bootstrap a profile type in tests" problem that isn't documented.

<!-- phpunit.xml.dist -->
<testsuite name="ozon-support">
    <directory>vendor/baks-dev/ozon-support/tests</directory>
</testsuite>

Pin the version in composer.json. Given the release cadence (v7.4.13 → v7.4.16 with empty release notes), use an exact or tilde constraint rather than ^:

"baks-dev/ozon-support": "7.4.16"

Upgrade deliberately, one version at a time, and diff vendor/baks-dev/ozon-support/src between tags before bumping — the changelogs tell you nothing.

Multi-environment config. If the bundle reads connection credentials (Ozon client ID/secret), put them in .env and reference from the bundle's config file rather than editing vendor code. Locate the config key name in src/Resources/config/.

Gotchas and Tips

The README is the entire documentation. Three commands and a license. Budget real time for source reading before estimating. The assessment-tpm.md list of "key questions" is effectively your discovery checklist — most of it is unanswered by the package itself.

PHP 8.4+ is a hard floor. ![php 8.4+] in the badge is not aspirational; the codebase uses modern syntax. Verify your runtime, CI matrix, and your Docker base image. Don't attempt this on 8.3.

No Laravel support despite the marketing. bin/console and baks: command prefixes are Symfony Console. If you're on Laravel you'll need the Symfony console bridge or to invoke the underlying service directly — and the users-profile-type command will not be registered with Artisan out of the box.

Empty release notes across four consecutive versions. v7.4.13, .14, .15, .16 each say only v7.4.16. You cannot assess upgrade risk from changelogs. Mitigation: pin, vendor-diff before bumping, and keep the --group=ozon-support test run as your gate.

Zero stars, zero dependents, zero community. This is a single-maintainer ecosystem package. Assume no upstream support. Two concrete hedges:

• Fork to a private VCS repo ("repositories": [{"type": "vcs", ...}]) so a deletion or force-push on GitHub can't break your builds.
• Commit composer.lock and use composer install --no-dev in production — never update on deploy.

The profile-type command is environment state, not code state. If you restore a database dump from before the command ran, the profile type vanishes and profile attachment silently fails. Make the command part of your restore/seed runbook.

Debugging a failed attachment: check in this order — (1) did the profile-type command actually run on this database, (2) is the identifier string spelled exactly as the command class defines it, (3) did you cache:clear after registration (Symfony caches the service/type registry), (4) does the bundle need a DB migration you haven't run? Symptom of a missing type is typically a null profile rather than an exception, so add an explicit null-check assertion at your integration boundary.

Russian-language domain assumptions are baked in. Expect hardcoded Russian strings and Ozon-specific fields (tax IDs, warehouse locations, Ozon Pay/Delivery references). If you need other locales, do it at your presentation layer — don't patch vendor translations you'll lose on the next bump.

Extension points to prefer, in order: (1) Symfony service decoration / a wrapper service of your own; (2) event subscribers on whatever events the bundle dispatches — find them in src/Resources/config; (3) configuration overrides; (4) vendor patches as an absolute last resort, tracked in a fork.

Run the group tests before you write integration code, not after. They're the only executable specification you have, and a failing --group=ozon-support run on a clean install is a red flag worth discovering on day one rather than week three.