Wp Password Bcrypt Laravel Package

Product Decisions This Supports

• Vendor-risk / end-of-life planning. Release 1.3.0 is an explicit sunset release ("Sunset package," #52). The primary PM decision it supports is no longer "should we adopt?" but "how and when do we exit?" — i.e., an EOL workstream with an owner, a migration ticket, and a removal date.
• Build vs. buy (buy vs. use core). The plugin's remaining value was always "bcrypt hashing that WordPress core didn't ship." With the project sunsetting and core-side hashing maturing (the 1.3.0 work explicitly tracks WordPress 6.7 action signatures), the buy-vs-core decision tips decisively toward core + a maintained fallback rather than a third-party shim.
• Roadmap sequencing for security hardening. Bcrypt (vs. legacy phpass/MD5) is a security posture item that shows up on compliance questionnaires. This release supports closing that line item without a deprecation surprise in the middle of an audit cycle — provided we schedule the migration now.
• Platform/runtime roadmap input. The PHP >= 8.0 floor (#46) is a hard gate. If any property still runs PHP 7.4, this release cannot ship there — that constraint should feed the PHP upgrade roadmap, not be discovered at deploy time.
• Dependency policy and version pinning. Sunset + a PHP floor bump is the textbook case for pinning to 1.2.x on legacy hosts and freezing the dependency in the lockfile with a documented exception.
• Low-cost quality wins worth logging, not celebrating. SensitiveParameter on $password/$hash (#45) keeps secrets out of stack traces, and the $old_user_data parameter (#43) restores parity with the WordPress 6.7 wp_set_password action. Both reduce incidental risk; neither changes the strategic picture.

When to Consider This Package

Consider it only in these narrow cases:

• An existing WordPress site already running it on PHP 8.0+, where ripping it out mid-cycle is riskier than leaving it pinned for one more release window.
• You need bcrypt hashes verified on a stack pinned below the WordPress version that ships modern hashing natively, and you accept the maintenance burden yourself (the code is small and forkable).
• You are doing a migration, not an adoption: this release is the reference implementation for how existing bcrypt hashes must keep validating after you remove the plugin.

Look elsewhere — or plan removal — when:

• Starting anything new. A sunset package is not a foundation. Use core WordPress hashing.
• Any host is on PHP 7.x. 1.3.0 requires PHP >= 8.0; upgrading is a breaking change for those environments. Stay on 1.2.x or upgrade PHP first.
• You require a supported dependency with a security-response commitment. A sunset project has no such commitment; a CVE would land on your team.
• Your platform is Laravel or another non-WordPress PHP framework. This is a WordPress plugin hooked into wp_hash_password/wp_check_password; it delivers no value outside WordPress, despite being Composer-installable.

Adoption gate: do not greenlight unless there is a named owner, a dated removal milestone, and a test proving existing user credentials still authenticate after removal.

How to Pitch It (Stakeholders)

To executives (one paragraph): The bcrypt password plugin we depend on has been formally sunset in its 1.3.0 release. Nothing is broken today — 1.3.0 is small and low-risk: it raises the PHP floor to 8.0, keeps secrets out of error logs, and aligns with WordPress 6.7's password API. But there will be no future fixes, so the security value it once provided now has to come from WordPress core. The ask is modest: approve a planned migration this quarter and a short freeze on the dependency in the meantime, so we retire it deliberately instead of reactively.

To engineering:

• Do not auto-upgrade to 1.3.0 on any host below PHP 8.0 — that is the breaking change. Pin 1.2.x there and open a PHP upgrade ticket.
• Where PHP 8.0+ is available, 1.3.0 is safe to take: bug-fix-level changes only, plus a stricter action signature matching WP 6.7.
• Treat the repo as read-only. No upstream fixes are coming; if we need a patch, we own it — so fork deliberately or remove, don't drift.
• Build one regression test now: user with a bcrypt hash logs in after plugin removal. That test is the exit criterion.
• Track removal as a real backlog item with a date, not a "someday" note.

Bottom line: this release is a stop sign, not a feature drop. The PM action is to convert an unmaintained dependency into a scheduled, tested decommission — and to make sure no new work is built on top of it.