- Is rilwis/meta-box a Laravel package?
- No. rilwis/meta-box is a WordPress plugin for registering custom fields, meta boxes, and settings pages. It ships no service provider, facade, or Laravel-facing config contract, and it depends on WordPress primitives such as add_meta_box, wp_nonce_field, current_user_can, get_post_meta, and the $wpdb global. In a Laravel-only codebase this is a category mismatch rather than an integration problem.
- Can I install rilwis/meta-box with Composer inside a Laravel application?
- Composer can fetch it, typically via wpackagist or a private VCS path repository, but installing it into a Laravel vendor tree does not make it work. The plugin must run inside a WordPress runtime, so the sane approach is to vendor it into a WP plugin or mu-plugin directory, pin the version, and exclude it from automatic updates. It should never be bootstrapped from a Laravel service provider.
- How do I integrate Meta Box custom fields with a Laravel app?
- Only side-by-side. Either the Laravel application embeds or hosts a WordPress instance where Meta Box configures the editorial experience, or the app is headless and Laravel consumes WP-managed content through REST, WPGraphQL, or a library such as Corcel. In both cases Laravel reads wp_postmeta across an explicit read boundary, typically a repository or read-model class that maps rows, including serialized values, into domain objects.
- Does rilwis/meta-box support Laravel 10 or Laravel 11?
- There is no Laravel version support at all, because the package is not built for Laravel. The relevant compatibility question is which PHP and WordPress versions it runs under, and the last tagged release is from January 2018, which predates the current PHP 8.2 and 8.3 baselines that modern Laravel requires. Verify against the exact PHP and WP versions in your target environment before committing to it.
- Is the rilwis/meta-box GitHub repository still maintained?
- The last tagged release is 2018-01-08, roughly seven years old, and the public repository appears to be a mirror. The vendor's commercial product and the wordpress.org distribution have likely moved on, so GitHub is probably not the canonical source of truth. Pin to a specific version from wordpress.org via wpackagist and confirm who owns patch responsibility if the upstream tag goes cold.
- Which Meta Box features require a Pro license?
- Repeater, Settings Pages, Custom Tables, Meta Box Builder, and Views are Pro features. The free plugin is deliberately limited, so any roadmap built on the free tier will hit a paid upgrade. Check whether a GPL plugin plus a commercial add-on fits your license and distribution model before designing around those features.
- What are Laravel-native alternatives to Meta Box?
- For Laravel applications the native options are Eloquent JSON casts, JSON columns, and admin builders such as Filament or Nova. Moving from Eloquent and JSON columns to wp_postmeta is a regression in ergonomics and query capability, not an upgrade. The realistic direction is the reverse: if WordPress is already present, Meta Box replaces hand-rolled add_meta_box calls and standardizes field definitions.
- How do I read Meta Box field data from a Laravel model?
- Treat WP meta keys as an external contract rather than a typed interface, because Meta Box field definitions are PHP arrays registered at runtime and are not portable schema. Wrap access in a repository or read-model class that maps wp_postmeta rows, including serialized values, into your domain objects. Keep that contract stable so the WordPress dependency can be swapped later without touching application code.
- Is Meta Box compatible with the block editor and PHP 8.2?
- Untested territory. A 2018 release predates the block editor's maturity and the PHP 8.2+ baseline, so expect deprecation noise and unverified behavior. Security posture is the usual WordPress admin-side surface: nonce and capability checks are present, but the code is old enough that unpatched CVEs in adjacent dependencies are a real consideration.
- How should I test and pin rilwis/meta-box for production?
- Pin an exact version, vendor it into the WP plugin directory, and disable automatic updates so deployments are reproducible. Run a spike against your real WordPress and PHP versions first, exercising field registration, save flows, capability checks, and serialized meta reads from the Laravel side. Decide up front who patches the plugin if upstream stalls, and keep the Laravel read boundary covered by tests so a future swap is a contained change.