Wp Laracode Laravel Package

Getting Started

andexer/wp-laracode is a Laravel-style framework for building isolated WordPress plugins. With v1.0.50 marked as the first stable release, this is a reasonable baseline for new plugin work.

Minimal setup:

composer global require andexer/wp-laracode

or scaffold a plugin directly:

composer create-project andexer/wp-laracode my-plugin

First steps:

1. Confirm the global CLI is available and check the branded output:

   wp-laracode --version
   

   The CLI should display Laravel Framework {plugin_name}/{version}.
2. Review the generated plugin structure, especially the bootstrap/bridge file, service providers, routes/views, and root /lang directory.
3. Run the available generator commands to confirm the suite is wired correctly:

   wp-laracode make:controller ExampleController
   wp-laracode make:model Example
   wp-laracode make:livewire ExamplePanel
   

4. Start with a small admin-facing use case: a Blade-rendered settings page or a Livewire 3 component for a reactive WordPress admin screen.

Look first at how the package boots Laravel inside WordPress, how service providers are registered, and where WordPress hooks are connected to Laravel controllers/components. That bridge is the key integration point for day-to-day development.

Implementation Patterns

Treat the plugin as a small Laravel application embedded inside WordPress:

• Scaffold with the CLI, then customize: use make:controller, make:model, make:livewire, and related generators for boilerplate, then keep business logic in application classes rather than in WordPress hook callbacks.
• Keep WordPress hooks thin: register hooks in a dedicated bootstrap/provider layer, and delegate to Laravel services, controllers, or Livewire components.
• Use Blade for server-rendered admin UI: render settings pages, meta boxes, and plugin screens through Blade views while keeping WordPress enqueue/register logic in the integration layer.
• Use Livewire 3 for reactive admin workflows: good candidates are settings forms, list tables with filters, import/export panels, and multi-step admin tools. Keep Livewire components namespaced to the plugin to preserve isolation.
• Separate domain code from WordPress APIs: wrap get_option, update_option, custom post types, shortcodes, and REST endpoints behind plugin services so the Laravel side remains testable.
• Generate consistently: use the command suite for controllers, models, and components so namespaces, paths, and registration follow the package’s expected structure.
• Use create-project for new plugins and global CLI for existing plugins: composer create-project is best for a clean plugin baseline; the global binary is useful for adding classes/components inside an existing plugin.
• Keep translations in the root /lang directory: v1.0.50 standardizes this to Laravel 10+ conventions. Update any custom loading paths or tooling that assumed an older location.
• Use the CLI branding for diagnostics: when reporting issues or checking versions, the Laravel Framework {plugin_name}/{version} output helps confirm which plugin and framework version is active.

A practical first workflow is: scaffold a plugin, create a Livewire component for an admin settings screen, bind it to a WordPress admin menu page, and keep option persistence in a service class resolved through the Laravel container.

Gotchas and Tips

• Bootstrap order matters in WordPress: v1.0.50 fixes early-boot fatal bridge errors, but plugin initialization still runs during WordPress’s early load path. Keep the bridge defensive: verify autoloading, avoid assuming WordPress admin APIs are available too early, and defer admin-only integrations until the appropriate hook.
• Global Composer binaries need to be on PATH: if wp-laracode is not found, check Composer’s global bin directory and shell path configuration before debugging the package itself.
• Translations moved to /lang: if upgrading an existing plugin or custom template, check translation loading, .pot generation, and deployment scripts. A missing translation file is often a path issue rather than a package failure.
• Template consolidation may affect older custom scaffolds: v1.0.50 simplifies the base template. Compare generated structure against any local stubs or overrides before assuming parity with previous output.
• Do not parse CLI branding casually: the new branded output is helpful interactively but may affect scripts that expected older, plain command output. For automation, rely on exit codes and generated files rather than exact stdout.
• Livewire 3 inside WordPress admin needs asset awareness: confirm scripts/styles are enqueued only on the plugin’s admin screens, and avoid loading Livewire globally unless required.
• Isolation does not remove naming responsibilities: still namespace PHP classes, view names, Livewire components, option keys, hooks, and asset handles to avoid collisions with other plugins/themes.
• Debug with WordPress and Laravel signals together: enable WP_DEBUG, inspect PHP fatal logs for bridge/autoload failures, and verify the Laravel container/provider boot path. Early-boot failures often present as blank admin pages or plugin activation errors.
• Use the complete command suite as an extension point: custom generators and local stubs are the natural place to standardize your team’s controllers, services, and Livewire components once the built-in commands are confirmed working.
• Start small after the stable release: because this is the first stable version, validate the bridge, command suite, Blade rendering, and Livewire asset loading in a staging WordPress install before relying on it for complex production plugins.