- What is oceancodex/wpsp-core used for?
- It is the shared foundation layer for WPSP-based WordPress plugins, bundling common bootstrapping, service registration, container helpers, and configuration or option management. Rather than duplicating that setup in every plugin, feature packages depend on wpsp-core and stay lightweight. It is distributed as a Composer-installable PHP package. Confirm the exact API surface against the source before committing, because the published description is currently the main contract documentation available.
- How do I install oceancodex/wpsp-core with Composer?
- Install it with composer require oceancodex/wpsp-core, ideally pinned to an exact version such as 13.1.76 rather than a floating ^13.1 constraint. If it follows standard Laravel package conventions, auto-discovery registers its service provider and you can publish config with vendor:publish. Neither the composer.json constraints nor the provider list are documented in the release artifacts reviewed, so verify discovery behavior in a scratch project first. Plan a short integration spike instead of assuming a plug-and-play install.
- Which Laravel and PHP versions does oceancodex/wpsp-core support?
- The supported PHP and Laravel version ranges are not stated in the package description or release artifacts reviewed, so treat compatibility as unverified. The package targets modern Composer-based applications with auto-discovery, and the 13.x major line implies a long prior breaking-change history. Check the composer.json require and require-dev blocks plus the CI matrix before you adopt it. Pin explicitly and test against your exact Laravel major.
- Is wpsp-core a WordPress plugin or a Laravel package?
- It is a Composer-installable PHP package that provides the core runtime for WPSP-based WordPress plugins, using Laravel-style conventions such as service registration and container helpers. It is not a standalone WordPress plugin you activate in wp-admin; it is a dependency your plugins or feature packages build on. That dual framing is why the name is ambiguous and why domain fit should be validated separately from framework fit. Confirm whether it expects a full Laravel container or a lightweight WordPress-bridged container.
- What does the wpsp-core service container register globally?
- The package advertises service registration and container helpers, but the specific global registrations such as middleware, migrations, scheduled tasks, or hooks are not documented in the available artifacts. Anything registered globally is inherited implicitly by every plugin that depends on the core, which directly affects upgrade risk. Inspect the service provider register and boot methods in the source and list every hook it attaches. Wrap the package behind your own adapter so its facades do not leak into domain code.
- How do I publish the configuration files for wpsp-core?
- If the package follows standard Laravel conventions, configuration publishing uses php artisan vendor:publish with the package provider tag. That workflow is not confirmed for wpsp-core in the published documentation, so verify the provider tag and config path in the source first. Option and configuration management utilities are listed features, so determine whether settings live in config files, WordPress options, or both. Document the precedence rules before shipping, since option handling is a common source of environment drift.
- Is oceancodex/wpsp-core safe for production use?
- Recent releases are patch bumps published with only a compare link, and several intervening patches carried no changelog, migration note, or CVE reference, so you cannot easily triage a security fix from a cosmetic change. That release opacity is an observed pattern rather than a one-off. The code may well be fine, but the release process gives you little to audit against. Pin an exact version, review diffs yourself before upgrading, and keep the abstraction boundary in your own code.
- How do I test a plugin built on oceancodex/wpsp-core?
- Test your services and configuration logic in isolation by injecting the container rather than reaching for facades, so unit tests do not need a WordPress bootstrap. For integration coverage, run the plugin inside the WordPress test suite or a WP-CLI driven environment and assert the hooks and options wpsp-core registers. No test suite or CI signal from the package itself was visible in the reviewed artifacts, so do not rely on its tests as a safety net. Add contract tests around the adapter you place in front of it.
- What changed in version 13.1.76 of wpsp-core?
- The release is a patch bump published with only a compare link, and at least five intervening patches between 13.1.71 and this version were also undocumented. Whether those changes were behavioral or cosmetic cannot be determined from the release notes alone. Read the commit diff and grep for changes to hooks, container bindings, and option keys before upgrading. Update deliberately on your own schedule instead of floating the constraint.
- What are the alternatives to oceancodex/wpsp-core for WordPress plugin structure?
- Alternatives include writing a small in-house bootstrap and container layer, or adopting a more widely documented package that provides service providers and config publishing for WordPress. The right comparison depends on what wpsp-core actually abstracts, which the public description leaves ambiguous. If you already have an internal foundation layer, run the package in parallel behind a feature flag and compare maintenance cost. The key decision is keeping your own adapter interface so switching later stays cheap.