Magewire Laravel Package

Getting Started

Treat 3.7.2 as an urgent security upgrade. Confirm the installed version first:

composer show magewirephp/magewire

Affected versions are 3.0.0–3.7.1; the fix is 3.7.2. If the project’s root constraint allows it, upgrade with:

composer update magewirephp/magewire:3.7.2 --with-all-dependencies
composer show magewirephp/magewire

Then review the lockfile, run the application test suite, and deploy through the project’s normal Magento process.

Where to look first:

• The security advisory: GHSA-64j9-rg74-hqc7
• UPGRADING.md, especially the browser-callable component methods section
• The changelog diff from 3.7.1 to 3.7.2

The first practical use case is an audit of custom Magewire components. Look for browser-callable methods, event listeners, inherited helper calls, and lifecycle hooks that may now be restricted.

Implementation Patterns

Use a repeatable upgrade workflow across projects:

1. Check composer.lock and deployed images for magewirephp/magewire versions in the affected range.
2. Update to 3.7.2 with --with-all-dependencies.
3. Commit the updated lockfile.
4. Rebuild deployment artifacts and container images.
5. Verify composer show magewirephp/magewire in each target environment.
6. Test component interactions before promoting.

For agencies and teams maintaining multiple client projects, inventory all lockfiles, build images, staging environments, demos, and local setups. The advisory explicitly requires upgrading every environment, not only production.

When custom components call inherited Magewire helpers or lifecycle hooks directly from the browser or from event listeners, refactor them into a deliberate public application action. That action should authorize the operation and then call the helper internally. This keeps the browser-facing surface narrow and aligns with the new restrictions.

For event-driven components, verify listener targets against the new validation rules. For lazy-loaded components, ensure lazy loading is used only with a genuine placeholder.

Hyvä Checkout 1.4.0 beta users need coordinated handling: a 1.4.0-beta6 release is expected to follow. Do not assume a Magewire-only update will work if the Checkout beta pins an affected Magewire version. Follow the Checkout release owner’s supported upgrade instructions and verify the installed Magewire dependency contains the fix.

Gotchas and Tips

• Do not defer this to production only. The release requires upgrading production, staging, development, local, demo, and test installations.
• Root-level pins can block the fix. If composer update cannot reach 3.7.2, update the root constraint as part of the security upgrade.
• Use --with-all-dependencies. Transitive constraints may otherwise keep an affected Magewire version in place.
• Check the lockfile and the deployed image. A local composer show is not enough; verify the version actually shipped to each environment.
• Hyvä Checkout beta pins may block a Magewire-only update. Coordinate with the Checkout release owner and upgrade to beta6 when available.
• Browser-callable method restrictions can break custom UI. If a component action stops working, check whether it calls inherited helpers or lifecycle hooks directly from the browser or an event listener. Move that logic behind an authorized public application action.
• Lifecycle hooks are reserved. Avoid exposing or relying on them as browser-callable extension points.
• Test event listeners and lazy loading explicitly. These are called out in the release and are common places for regressions after a security hardening update.
• Follow the normal Magento deployment process. This is a security release, but it still needs the project’s standard build, cache, and deployment steps.