Wpsp Core Laravel Package

Getting Started

• composer require oceancodex/wpsp-core — then read the require block in vendor/oceancodex/wpsp-core/composer.json before assuming Laravel/PHP compatibility. On the 13.x line the constraint is what tells you whether your host app is supported; the patch number itself (13.1.71) never is.
• Service provider registration is normally handled by package discovery. If you've disabled discovery, add it to bootstrap/providers.php (Laravel 11+) or config/app.php.
• Look here first, in this order: vendor/oceancodex/wpsp-core/config/ (the published config file is your real API contract — every toggle, driver and default lives there), then the service provider's register()/boot() to see what gets bound into the container and which vendor:publish tags exist, then src/Contracts/ for the interfaces you're meant to type-hint.
• First use case: install, publish config (php artisan vendor:publish --provider="OceanCodex\WpspCore\...ServiceProvider" --tag=wpsp-config), publish and run migrations, then resolve the package's main manager/contract in php artisan tinker and call one method on it. That single round trip proves discovery, config loading, container bindings and DB wiring all at once — do it before you write any application code against the package.

Implementation Patterns

• Config over subclassing. Behaviour in a -core package is overwhelmingly driven from the published config file. Change the driver/toggle there and commit it; you get upgrade-safe customisation and the package's own tests keep covering your path.
• Resolve from the container, never new. Type-hint the package's contract in your own services and commands. The facade is fine for one-liners in controllers and Artisan commands, but constructor injection is what makes the thing swappable in tests.
• Write a thin adapter around it. One small class in your app that wraps the package's entry points. When a future major version renames something, you edit one file instead of grepping your codebase.
• Publish by tag, never blanket. --tag=wpsp-config and --tag=wpsp-migrations separately, so you can upgrade the package's migrations without clobbering your config.
• Testing: bind a fake or MockInterface of the contract into the container in your TestCase::setUp() rather than hitting the real implementation — core packages usually reach for HTTP, filesystem or DB, and you don't want that in unit tests.
• Integration point: if the package emits events or exposes hooks, prefer subscribing to those over wrapping its public methods; subscriptions survive internal refactors.

Gotchas and Tips

• The release notes are not the changelog. v13.1.71 shipped with nothing but a compare link, and it's the 71st patch on the 13.1 line — that cadence means patch releases are frequently untitled fixes. Treat github.com/oceancodex/wpsp-core/compare/v13.1.70...v13.1.71 as the only real source of truth and skim the diff before bumping in a production app.
• Nothing in this release warrants changing your integration. A notes-less patch bump at this position in the series is a maintenance release; there is no signal of a breaking change, deprecation or new feature. Do not restructure code around it.
• Constraint strategy vs. cadence. ^13.1 or ~13.1.0 gives you automatic patch uptake, which is usually what you want for bugfixes — but if you need byte-identical deploys, pin the exact version (13.1.71) and bump deliberately. Whichever you choose, commit the lock file.
• config:cache freezes the published config. After editing it locally, re-run php artisan config:cache or you'll debug a phantom for twenty minutes.
• Never patch vendor/. Extension points are container bindings (rebind the contract in your own provider after the package's), the config file, and published migrations. If you find yourself needing more than that, open an issue upstream instead.
• Debugging checklist: php artisan about for provider discovery, php artisan tinker → app()->make(YourContract::class) to confirm the binding resolves, and config('wpsp') (or whatever the published filename is) to confirm config actually loaded from your app rather than the package default.