Eval Command Laravel Package

Product Decisions This Supports

• Build vs. buy (and the third option: already have it). This isn't a library you evaluate and adopt — it ships inside WP-CLI itself. The decision is really "do we standardize on WP-CLI for WordPress-adjacent operational work, or do we build an internal admin panel / throwaway plugin to do the same jobs?" Given MIT licensing, zero install, and a maintained release line (v3.0.1 as of late 2026), the default answer should favor the CLI unless there's a strong reason otherwise.
• Roadmap scoping for internal tooling. wp eval / wp eval-file let you ship operational capability (data backfills, content migrations, one-off reporting, smoke checks) without allocating engineering time to a UI or a bespoke plugin. That frees roadmap capacity for customer-facing work.
• "Do we need to build this?" triage for common requests. Recurring asks like "can someone check what's in this option / transient / user meta on staging?", "can we regenerate these slugs?", "can we fire this after init to reproduce the bug?" are all one-liners here. Each one you don't turn into a ticket is a measurable roadmap saving.
• Incident response and support engineering. wp eval gives support and on-call engineers read/write access to a bootstrapped WordPress runtime — WP_CONTENT_DIR, wp_get_current_user(), options, hooks — without deploying code. This shortens time-to-diagnosis and reduces "we need a hotfix release to print a variable" cycles.
• Hook-aware debugging as a first-class capability. --hook=<hook> defers execution until a specific WordPress lifecycle event fires. That's the difference between "we can't reproduce it" and "we reproduced it deterministically," and it should inform how you staff and tool WordPress plugin/theme debugging.
• Scripted, version-controlled operations. wp eval-file <file> [<arg>...] with $args, plus - for STDIN, turns ad-hoc ops into parameterized scripts you can commit, review, and run in CI. This supports a decision to treat ops runbooks as code rather than wiki pages.
• CI and environment validation. --skip-wordpress gives you a plain PHP execution context on the same binary, useful for quick environment assertions and pipeline glue without booting a full stack.
• Explicit non-goal: do not confuse this with Laravel tooling. For a Laravel codebase, artisan tinker / PsySH / custom Artisan commands remain the right answer. This package is for the WordPress half of a hybrid stack. Making that boundary explicit in your architecture docs prevents teams from reaching for wp eval to poke at Laravel services (and vice versa).
• Product risk decision: keep it internal. Because it executes arbitrary PHP, any temptation to expose eval-like functionality to customers or non-engineers should be killed at the roadmap stage. Its value is to your team.

When to Consider This Package

Adopt / standardize on it when:

• Your product or platform includes WordPress — headless WordPress behind a Laravel front end, a maintained plugin or theme, WooCommerce, a content-marketing property, or a client site portfolio.
• Your engineers already have shell access to environments and WP-CLI is part of the deploy/ops workflow.
• You need repeatable, reviewable ops scripts rather than one-off copy-paste — i.e., eval-file with positional args committed to the repo.
• You're debugging behavior tied to WordPress lifecycle events and --hook would give you deterministic reproduction.
• You want a zero-cost escape hatch for the long tail of "just run this PHP against WordPress once" requests.
• You need to run PHP in a WordPress-capable environment without loading WordPress (--skip-wordpress).

Look elsewhere when:

• There is no WordPress in the stack. Pure Laravel → artisan tinker, PsySH, custom Artisan commands. This package adds nothing.
• You have no shell access. Managed WordPress hosts that disable WP-CLI, or teams without SSH, get zero value here.
• The operations must be performed by non-engineers or need audit trails, approvals, and granular permissions. That's a product surface, not a CLI command — build an admin tool with RBAC and logging.
• You need sandboxing, multi-tenancy, or execution of untrusted code. There is none. Arbitrary PHP runs with the privileges of the WordPress process.
• The logic is long-lived and business-critical. If a snippet keeps getting re-run, promote it to a proper WP-CLI command package or plugin with tests — eval'd code has no test harness, no autoloading guarantees, and global-variable gotchas (code runs inside a method, so globals must be explicitly global'd).
• You need cross-framework hook integration. The --hook mechanism is WordPress-specific; synchronizing with Laravel's event system requires custom adapters you'd own.
• You're on legacy PHP. The package requires PHP 7.2.24+ and recent releases track WP-CLI v2.12/v2.13 — fine for modern stacks, a blocker for genuinely old ones.

Signal caveat worth noting: 10 GitHub stars and 0 listed dependents look weak, but that's a distribution artifact — the package is bundled with WP-CLI, so usage doesn't register as a Composer dependency. Don't let the vanity metric drive the decision; the relevant question is "do we run WP-CLI?"

How to Pitch It (Stakeholders)

To executives (30 seconds): This is a free, MIT-licensed command that's already included in WP-CLI — the standard command-line tool for WordPress. It lets our engineers run PHP against a live WordPress environment in one line, which means faster incident diagnosis, ops scripts we can commit and review instead of run by hand, and fewer throwaway plugins built just to flip a flag or fix some data. There's no license cost, no integration project, and no new vendor — the only decision is whether we standardize our WordPress ops on it and set guardrails.

To engineering: It's essentially artisan tinker for WordPress. wp eval '<code>' runs inline PHP; wp eval-file <file> [<arg>...] runs a file with arguments exposed as $args, and - reads from STDIN. --skip-wordpress executes without bootstrapping WordPress; --hook=<hook> defers execution to a WordPress lifecycle event, which is how we get deterministic repro for lifecycle bugs. Two things to internalize: executed code runs inside a method, so globals must be explicitly globalized, and this is arbitrary code execution with no sandbox — treat it with the same care as php -r on a production box.

The ask, concretely: (1) Adopt it as the default for WordPress-adjacent ops rather than approving new one-off plugins. (2) Write the guardrails down — staging first, production requires approval and a logged command, recurring scripts live in the repo as eval-file targets, not in a wiki. (3) Keep the boundary explicit in our docs: wp eval for the WordPress side of the stack, Artisan/tinker for the Laravel side. (4) Track success with three numbers: mean time to diagnose WordPress incidents, count of one-off plugins avoided, and count of ops procedures under version control instead of documentation.