Counter Management Bundle Laravel Package

Getting Started

Start with the package README, composer.json, service provider, facade, and published config. Confirm the supported Laravel/PHP versions and whether config/service provider auto-discovery is enabled. The 0.1.1 release note is only a Yandex Metrika documentation link for objects/enableall.xml, so treat this as an additive/pre-1.0 release and inspect the actual enableAll method signature before relying on it.

Publish any package config and set the Yandex Metrika OAuth token and counter ID via environment/config. Do not call env() directly outside config. For the first smoke test, resolve the client from the container, perform a read-only call for a known counter, then run enableAll against a non-production counter and inspect the raw response.

First day-to-day use case: after provisioning a tenant/site or importing Metrika objects, bulk-enable all relevant objects for that counter from an artisan command or queued job rather than from a controller.

Implementation Patterns

• Keep Metrika credentials and counter IDs in config, with per-environment and per-tenant overrides. Avoid a single hard-coded counter ID if the app is multi-tenant.
• Wrap package calls in an application service such as MetrikaService::enableAllObjects(int $counterId). This keeps controllers thin and gives you one place to map exceptions, log requests, and adapt to future package API changes.
• Run bulk enableAll operations through queued jobs or artisan commands. Use ShouldQueue, sensible retries/backoff, and log the counter ID and response status for each attempt.
• Provide a command like metrika:enable-all {counter} {--dry-run} {--force} so operators can preview impact and avoid accidental production-wide changes.
• Test with Laravel’s HTTP fake or the package’s fake/test hooks if available. Assert the endpoint, payload, headers, and response handling; do not hit the live Yandex API in the test suite.
• Integrate with tenant provisioning: dispatch an enable-all job after counters/objects are created, then store a sync status or emit an event on success/failure.
• For scheduled syncs, make the operation idempotent and record last-run state. Do not blindly re-run destructive or broad operations without checking current state.

Gotchas and Tips

• 0.1.1 is early-stage and the release note contains no migration or breaking-change details. Pin the version and review the changelog before upgrading.
• enableAll is likely broad and permission-sensitive. Verify the token has the required Yandex Metrika scopes, the user can manage the counter, and you understand whether it enables all objects or only a subset.
• The linked Yandex documentation uses an .xml path. Confirm the response format your package returns and parse/handle XML or JSON accordingly; do not assume JSON.
• Handle rate limits and partial failures. Retry transient errors with backoff, but avoid blind retries for operations that may not be safely repeatable.
• After changing token/counter config, run php artisan config:clear; cached config is a common cause of “it works locally but not in production.”
• In multi-tenant apps, never fall back silently to a default counter. Resolve the counter from the tenant context and log which counter an operation targeted.
• For debugging, temporarily enable HTTP client logging, inspect status codes and response bodies, and check Yandex API permissions. Keep detailed logs for queued jobs where stack traces are less visible.
• Keep the package behind your own service/interface. That gives you extension points for custom HTTP timeouts, exception mapping, and future pre-1.0 API changes.