Wp Concurrent Remote Requests Laravel Package

Getting Started

What this package does (v1.1.1): It bridges Laravel-style exception handling into WordPress by converting thrown exceptions into WP_Error objects, so failures surface as structured, is_wp_error()-checkable values instead of fatals or raw stack traces.

Minimal steps

1. Install and register the service provider the same way you would any Laravel package inside your WordPress plugin/bootstrap:

   composer require <vendor>/<package>
   

2. Look first at the exception handler / converter class — this is the single most important file in the package. Everything you do day-to-day routes through it.
3. Confirm you're on ^1.1.1. If you're on 1.1.0 or earlier, the conversion path was broken, so any assessment you made of the package's error behaviour before this release is invalid.
4. First use case: wrap a controller/callback that can throw and assert the result is a WP_Error rather than an exception bubbling to the surface.

   $result = $this->someRiskyOperation();
   
   if ( is_wp_error( $result ) ) {
       return new WP_REST_Response( $result->get_error_data(), 500 );
   }
   

Where to look next: the config file (error codes/messages mapping, debug flag), then the REST/controller integration points, since that's where WP_Error is most useful.

Implementation Patterns

Treat the converter as a boundary, not a blanket. The healthiest pattern is to let exceptions fly inside your domain/service layer and only convert at the edges — REST controllers, AJAX handlers, admin-post callbacks, CLI commands. Wrapping every internal call in try/catch defeats the purpose and produces nested WP_Error handling.

Consistent controller shape:

public function handle( WP_REST_Request $request ) {
    try {
        return new WP_REST_Response( $this->service->run( $request ), 200 );
    } catch ( Throwable $e ) {
        return $this->errorConverter->toWpError( $e ); // returns WP_Error / WP_REST_Response
    }
}

Catch Throwable, not Exception — see gotchas.

Map exception types to error codes deliberately. Don't let every failure collapse into a generic 'error' code. Consumers (JS in the block editor, other plugins) will branch on $error->get_error_code(). A small mapping table — validation → invalid_param + 400, not-found → not_found + 404, everything else → internal_error + 500 — pays for itself immediately and keeps your front-end handling stable.

Keep WP_Error data payloads dumb. Put machine-readable context in get_error_data() (field name, ID, status) and human-readable text in the message. Don't put stack traces in the data array on production — gate that behind WP_DEBUG.

Log on conversion, not on throw. Because the converter is the chokepoint, it's the natural place to emit error_log() / a logger call. One log line per converted exception gives you observability without scattering Log::error() across the codebase.

Test the conversion explicitly. A unit test asserting is_wp_error( $converter->convert( new RuntimeException( 'x' ) ) ) is the regression test that would have caught the bug fixed in 1.1.1. Add it if the package doesn't ship one.

Gotchas and Tips

Error is not Exception. PHP's TypeError, ArgumentCountError, and most engine-level failures implement Throwable but do not extend Exception. If your try/catch (or the package's) catches Exception, those still blow through and produce a fatal. Verify the converter accepts Throwable. This is the single most likely source of the class of bug fixed in 1.1.1.

Upgrade and re-verify. If you previously worked around the broken conversion with your own try/catch shim, upgrade to 1.1.1 and remove the shim — otherwise you'll get double-converted errors or a WP_Error wrapped inside another WP_Error's data.

WP_Error is a return value, not an exception. Anywhere you throw a WP_Error or return one into code that expects a value, you silently get an object where a string/array was expected. Sanitise at the boundary and check is_wp_error() before using results. In WP_REST_Response, pass the error's data, not the WP_Error object itself, unless your route's permission_callback/schema expects it.

Don't rely on it converting in every context. Conversion is only meaningful where something consumes the WP_Error. In a WP-CLI command or a cron job, a converted WP_Error that nobody checks is a silently swallowed failure — explicitly check and WP_CLI::error() or log it there.

Status codes are yours to set. A WP_Error carries no HTTP status on its own. If you rely on the package to infer 4xx/5xx, verify it actually does; otherwise set the status in your response wrapper and keep the mapping in one place.

Extension point: the converter is usually the intended subclass/swap point — if you need custom codes or a different log target, extend it and rebind in the container rather than editing vendor code.

Debugging tip: when an exception appears to vanish, check the order of registration. A handler registered before the package's provider (or a set_exception_handler call elsewhere in the plugin) will win and bypass conversion entirely.