Wp Type Extensions Laravel Package

Getting Started

The v5.0.0 release notes only point at the changelog. Treat that link as required reading before doing anything else: a major version bump on a package that sits close to WordPress registration APIs almost always means renamed/removed methods, changed constructor signatures, or bumped PHP/WordPress minimums. Do not upgrade blindly on a Friday.

Minimal path:

1. Read CHANGELOG.md#500 and the diff for composer.json (PHP constraint, WordPress minimum, dependency bumps).
2. composer require alleyinteractive/wp-type-extensions:^5.0 in the WordPress-facing codebase — typically the mu-plugin/plugin layer, or a Laravel service provider that only boots when WordPress is loaded.
3. Confirm where the package is autoloaded. In Bedrock/Roots this is usually automatic; in a classic WP install make sure the mu-plugin requires vendor/autoload.php.
4. Pick one small existing custom post type or taxonomy and migrate it first. Register it through the package on init, load the admin, and hit the REST endpoint to confirm nothing regressed.

Where to look first in the source:

• The type/registration classes under src/ — these are the day-to-day API surface.
• The README examples for the current major version; old blog posts and Stack Overflow answers will be for v2/v3/v4 and may not compile.
• The package's own tests for expected hook timing and argument shapes.

First use case: replace a hand-rolled register_post_type() call in an mu-plugin with the package's typed registration class, keep the same slug and capabilities, and verify the editor and REST responses are unchanged. That gives you a safe, reversible migration unit before touching taxonomies, meta, or blocks.

Implementation Patterns

Boot from a service provider, register on init. In a Laravel app that also ships WordPress, keep the package out of the default Laravel boot path. Bind configuration in register(), but defer WordPress-facing work to a dedicated mu-plugin or a provider that checks function_exists( 'register_post_type' ). Register types on init (priority 10 is fine unless you are coordinating with other plugins).

Centralize type definitions. The main value of the package is that post types, taxonomies, meta, and fields are declared as PHP objects instead of scattered arrays. Put those declarations in one place — a WordPress/Types directory or a config array mapped into constructors — so a new post type is one class plus one registration call, not five files.

Keep Laravel config and WP registration separate. Laravel's config/ is great for slugs, labels, and feature flags; WordPress registration is not a Laravel concern. Map config into the type objects at boot, but don't let config:cache become a hidden dependency of init.

Headless pattern. If Laravel is the front end and WordPress is the content back end, register types and meta with show_in_rest => true and explicit auth_callbacks, then consume them in Laravel through HTTP/DTOs. Do not reach into the WP database from Laravel; that coupling is what the typed registration layer is supposed to prevent.

Compose, don't inherit deeply. Use the package's extension points (subclassing a type class, filters on arguments) rather than editing vendor files. If you need a custom field type, wrap it and keep the package class as the inner implementation.

Testing. Unit-test the argument arrays your classes produce without bootstrapping WordPress where possible. For integration, use the WordPress test suite and assert both get_post_type_object() and the REST schema. Add a smoke test that the type appears in show_in_rest — it catches the most common editor breakage.

CI matrix. Run at least the oldest and newest supported PHP and WordPress versions from the v5 changelog. Major releases often drop older PHP; your CI should fail loudly rather than your production site.

Gotchas and Tips

• v5.0.0 is a breaking release by definition. Pin ^5.0 only after reading the changelog; grep the codebase for any methods/classes listed as removed or renamed. Run static analysis (PHPStan/Psalm) and your test suite before merging.
• Hook timing is the classic failure. Calling registration code on plugins_loaded or at file load produces _doing_it_wrong notices and types that don't appear in the admin. Register on init; if you need to modify another plugin's type, use a later priority.
• Autoload order in WordPress. A package that works in Laravel tests can still fatal in WP if vendor/autoload.php isn't loaded by the mu-plugin. Verify with composer dump-autoload -o and a fresh WP bootstrap.
• Don't share Laravel and WordPress containers casually. Resolving package classes through Laravel's container inside a WP hook can work, but only if the container is booted. Prefer explicit instantiation in the WP layer for registration objects.
• REST and meta registration. show_in_rest on the post type is not enough for meta; each meta key needs its own registration with a schema and auth callback or the block editor silently drops it.
• Translation loading. WordPress 6.7 changed load_plugin_textdomain timing; if labels come through empty or untranslated after the upgrade, check when text domains are loaded relative to init.
• Debugging. Turn on WP_DEBUG and WP_DEBUG_LOG, and watch for _doing_it_wrong and doing_it_wrong notices. For registration issues, wp post-type list and wp taxonomy list via WP-CLI are faster than clicking around the admin.
• Extension points. Check whether v5 changed filter names or constructor visibility before subclassing. If the changelog is thin, diff the src/ directory between v4 and v5 — that is usually more accurate than release prose.
• Rollback plan. Because this is a major bump, keep the previous version constraint in a branch and verify a downgrade path. If v5 changes stored meta keys or registration args, rolling back may require data cleanup; test on a staging copy first.