- How do I install wp-laracode and create a new WordPress plugin?
- Installation is Composer-first: run composer global require andexer/wp-laracode to get the CLI, then scaffold a plugin with composer create-project andexer/wp-laracode my-plugin. Each generated plugin ships with its own CLI, dependency container, Blade-style views and Livewire, so the plugin stays self-contained rather than relying on a shared framework install. This assumes a Composer-capable developer workstation and, for deployment, a Composer-capable build pipeline such as Bedrock, WP Engine, Kinsta or a CI-built release zip.
- What PHP version does wp-laracode require, and does it support Livewire 3?
- Yes, wp-laracode embeds Livewire 3, which requires PHP 8.1 or newer. WordPress core still supports PHP 7.2.24+, and a meaningful part of the WordPress hosting long tail runs 7.4 or 8.0, so if your target hosting estate is not at 8.1+ this framework is off the table. Verify the PHP version of every environment, including staging and any legacy client sites, before committing.
- Will wp-laracode conflict with other WordPress plugins or themes?
- The package claims dependency isolation with zero conflicts, achieved through prefixed namespaces and an isolated autoloader. That is plausible, but 'zero conflicts' is an absolute claim you should validate yourself rather than accept from release notes. The usual failure surfaces are class-name collisions, multiple Composer ClassLoader instances and global hook or filter namespace collisions, so build a co-residency test with your real plugin stack before rollout.
- Can I use wp-laracode in a plugin installed through the normal wp-content/plugins upload workflow?
- Not comfortably. The architecture assumes a Composer step for scaffolding and dependency resolution, which fits standalone first-party plugins where your team owns the full stack and ships a built artifact. It is a poor fit for plugins that must live inside the standard upload workflow with no build step, or that must interoperate deeply with third-party plugin data and conventions.
- Why is the composer global require step a deployment concern?
- A global Composer install pins a third-party CLI into every developer machine, which creates a silent version-skew vector across the team and across CI runners. The CLI does print a framework banner, so drift is at least visible, but it is not enforced. Pin the version explicitly in onboarding docs and CI images, or wrap the generator in a project-local setup to avoid surprises.
- Is wp-laracode v1.0.50 stable enough for production WordPress sites?
- Treat it as a conditional pilot, not an approved production dependency. v1.0.50 is the first stable release after roughly 49 pre-1.0 iterations, and it shipped with a fix for early-boot fatal errors, which is the worst failure class in this architecture because it happens before WordPress error handling and can white-screen a site. That suggests the boot bridge only recently settled, so run it through realistic staging traffic, cache-cold and cache-warm, plus an error-path test before trusting it in front of users.
- Which Laravel and WordPress versions does wp-laracode support?
- No supported Laravel range, WordPress range, PHP min or max, or tested compatibility matrix is stated in the release notes. The package does follow Laravel 10+ conventions, such as moving translations to a root /lang directory, and the Livewire 3 dependency implies PHP 8.1+. Ask the maintainer for an explicit matrix or derive one from your own CI matrix before scheduling adoption.
- Can two wp-laracode plugins run on the same WordPress site at once?
- That is the exact scenario the isolation design is meant to survive, but it is not proven by the release notes. Two plugins each booting an Illuminate container in the same PHP process is where class, autoloader and global-state collisions surface. Write a two-plugin co-residency test early, since the result determines whether this scales beyond a single-plugin deployment.
- What performance overhead does the Laravel container and Blade add per request?
- Container boot, Blade compilation and the Livewire asset payload are strictly additive compared with a conventional hook-driven plugin. The release notes do not quantify the cost. Benchmark against the incumbent plugin on realistic pages in both cache-cold and cache-warm conditions, and check the front-end impact of Livewire assets before adopting on high-traffic sites.
- Who maintains wp-laracode, and is there a security or LTS policy?
- The andexer namespace suggests an individual or small-team vendor rather than an established organisation, and no security policy, CVE process, LTS commitment or funding model is published. For anything touching a production WordPress site, single-maintainer and supply-chain risk is the dominant concern. Mitigate by pinning versions, vendoring dependencies in your build artifact, and having a documented fallback if the package stops receiving updates.