Why does the WP Human Resource Management plugin break on PHP 8?

The original plugin was written for PHP 5.6 and last shipped around 2019. PHP 7 and 8 turned a number of previously-silent warnings into fatal errors (for example, passing an array where a string is expected, arithmetic on non-numeric strings, or date functions on the wrong type). The plugin's code is full of those older patterns, so on PHP 8 they fire as TypeError fatals that stop the page mid-request. That produces the white screen, the add-employee save hang, and the broken punch-out.

Can I just fix the PHP 8 errors in the plugin myself?

You can patch individual errors, but it isn't durable. There's no single line to fix — the type errors are spread across the codebase, and the plugin ships on data-layer libraries that themselves don't run on PHP 8. Any hand-edit is also wiped on reinstall, with no upstream to merge from. The original plugin was additionally removed from WordPress.org in 2025 over a security issue with publicly catalogued vulnerabilities, so a stable-but-abandoned copy still carries risk. Moving to a maintained fork fixes the fatals at the source and addresses the known security holes.

Will I lose my data if I migrate to a maintained fork?

No. The maintained fork uses the same data model — employees are WordPress users plus the same wp_hrm_ tables — so your employees, attendance, and leave records carry over. It's a migration, not a rebuild. The fork runs an idempotent schema reconcile on first load that only adds tables and columns and never deletes data, and a documented one-time SQL script plus a verification pack handle the few renamed legacy columns. It's reversible if you back up first, and best done on a staging copy before production.

WP Human Resource Management PHP 8 Fix (Real Solution)

If you updated your server to PHP 8 and your “WP Human Resource Management” plugin suddenly started white-screening, hanging on save, or refusing to record clock-outs, you’re in the right place. The short version: the original plugin was written for PHP 5.6, last shipped around 2019, and was removed from the WordPress.org plugin directory on July 1, 2025. There is no patch coming from the original author. This post explains exactly what’s failing, why a “quick fix” usually isn’t durable, and what the real fix looks like.

We’ll be honest up front: we maintain a hardened, security-fixed fork of this plugin called Punchwell. We’re an independent third-party maintainer of the GPL code — not the original author, and not affiliated with wpspear or weDevs. We mention the original plugin by name only so people stuck on it can find a working path forward. With that on the table, let’s diagnose your problem.

The symptoms (and why they all trace back to PHP 8)

The original plugin’s code predates a number of changes PHP made in versions 7 and 8 — things that used to be silent warnings became fatal errors. When a fatal error hits during a request, PHP stops mid-page, and WordPress can’t finish rendering. That’s why the failures look scattered but share one root cause. The usual reports:

White screen of death. You open the HR admin screen (or sometimes the whole wp-admin) and get a blank page or a “critical error” notice. This happens when a fatal fires while WordPress is building the page.
“Add employee” hangs on the spinner. The form posts, the saving spinner spins forever, and nothing is created. Behind the scenes the AJAX request hit a type error and returned an unusable response, so the JavaScript front-end never gets the “done” signal.
Punch-out stops working. Staff can sometimes clock in, but the clock-out silently fails, leaving open shifts. Date and duration math written for the old PHP throws on PHP 8.
Profile and department saves hang or error. Same pattern as adding an employee — a save that used to limp through now hits a hard stop.

The common thread is PHP’s stricter type and date handling. Code that passed an array where a string was expected, did arithmetic on a non-numeric string, or called date functions on the wrong type used to produce a warning and keep going. On PHP 8 those are TypeError fatals. The original plugin is full of these patterns because it was written for an era when they were tolerated.

Why the obvious “fixes” don’t hold up

When a site breaks after a PHP upgrade, the first instinct is to make the error go away. A few common attempts, and why they tend to disappoint:

Rolling PHP back to 7.x. This can get you running again today, but it’s a dead end. PHP 7.4 reached end of life at the end of 2022 — it no longer gets security patches, and your host is steering you toward PHP 8 (and WordPress 7 expects a modern PHP) for good reason. You’d be freezing your whole server on an unsupported runtime to keep one abandoned plugin alive.

Hiding errors with WP_DEBUG off or display suppression. Turning off error display stops you from seeing the white-screen text, but the fatal still fires — the page still doesn’t finish, the save still fails. You’ve hidden the symptom, not fixed it.

Patching the plugin’s PHP by hand. A skilled developer can chase down the type errors one at a time. The trouble is there’s no single line to fix — it’s a pattern spread across the codebase, plus an old data layer (the plugin shipped on libraries that themselves don’t run on PHP 8). And every edit you make is wiped the moment anyone reinstalls or “updates” the plugin. You’d be maintaining an abandoned codebase indefinitely, by yourself, with no upstream to merge from.

There’s also a bigger reason not to keep the original running, even if you got it stable: it was pulled from WordPress.org because of a security issue. Several vulnerabilities are publicly catalogued against it, including a privilege-escalation flaw (CVE-2025-5953, rated 8.8) in which a logged-in employee could be elevated to a WordPress administrator, and an arbitrary user-deletion flaw (CVE-2025-5956, rated 8.1) in which any logged-in user could delete any account. Those affect the original, unmaintained plugin and are not getting patched there. A site running the abandoned version on a live host is carrying real risk. (We cite already-public advisory information only — see our security page for the details.)

The real fix: move to a maintained fork

The durable answer isn’t to patch dead code or freeze your PHP — it’s to move to a maintained continuation of the same plugin. Because the data model is identical (employees are WordPress users, plus the same wp_hrm_* database tables), this is a migration, not a rebuild. Your existing employees, attendance records, and leave history carry over.

Here’s what “maintained” actually buys you, concretely:

It runs on PHP 8. The fork is PHP 8 / WordPress 7 / MySQL 8 clean. The type and date fatals that white-screen your admin and hang your saves are fixed at the source, and the old data layer was modernized off the end-of-life libraries the original depended on. The white screen, the add-employee hang, and the broken punch-out go away because the underlying cause is gone.
The known security holes are addressed. The fork capability-gates the AJAX endpoints behind the public disclosures — for example, the employee-delete handler now requires the proper delete_users capability before it will touch an account, and the role and leave handlers are gated too. We describe this as addressing the class of flaw and gating the endpoints, not as a blanket “unhackable” guarantee — that wouldn’t be honest.
No data call-home. The original carried an update-checker that phoned a vendor host (now defunct). All of that outbound network code was removed and verified, so the plugin isn’t reaching out to a server that no longer exists — and your data never reaches anyone at all. (Pro’s only outbound call is license validation to our own billing server.)

How the migration works

You don’t have to wing it. The data lives in the same place it always did, and the fork reconciles the schema for you on first load — it runs an idempotent dbDelta step the first time you open wp-admin (or deactivate and reactivate the base plugin) that adds any new tables and columns and never deletes your data. For the handful of legacy columns that were renamed over the years, there’s a documented one-time SQL script plus a read-only verification pack so you can confirm every row copied before you trust it.

The whole thing is reversible if you back up first, and it’s sensible to do it on a staging copy before touching production. We’ve written the full step-by-step — order of operations matters (let the schema reconcile run before the data SQL, or Leave and Work-Experience records will look blank) — in the migration guide. Plan on roughly 30 to 60 minutes.

A quick way to check where you stand

If your site is currently broken, the PHP 8 fatals are the loud, obvious problem. But even if you rolled PHP back and things look fine, the security exposure is the quiet one. A reasonable order of operations:

Take a full backup (files and database) before you change anything.
Spin up a staging copy so you can test the migration without risking the live site.
Read the security page to understand what you’re exposed to on the abandoned version.
Follow the migration guide to move to the maintained fork on staging, verify your data with the included check pack, then promote to production.

That’s the calm version. There’s no need to panic-buy anything — the maintained fork has a free community tier on WordPress.org that covers core HR, leave, basic attendance, and a basic single-office IP clock-in lock, which is enough to get a broken site running on PHP 8 again. If you later want the deeper attendance-integrity controls — per-employee and per-office IP locking, GPS geofence, kiosk and mobile punch — those live in Pro, which is a flat $99/year per site, never per seat, with unlimited employees. But that’s a decision for after you’re un-broken.

Bottom line

The “WP Human Resource Management PHP 8 fix” you’re looking for isn’t a code snippet you paste into a dead plugin — it’s moving to a version of that plugin someone is actually keeping alive. The original was written for PHP 5.6, last shipped around 2019, and was removed from WordPress.org in 2025 over a security issue; patching it by hand or freezing your PHP just defers the problem. Migrating to a maintained fork fixes the PHP 8 fatals at the source, addresses the publicly disclosed vulnerabilities, and keeps your existing employee, attendance, and leave data exactly where it is.

When you’re ready, start with the migration guide — your data carries over, and you can test the whole thing on staging first.

Punchwell is an independent, third-party maintained fork of the GPL-licensed “WP Human Resource Management” plugin. Sturdyhaus is not affiliated with, endorsed by, or sponsored by wpspear, weDevs, or the original author. “WP Human Resource Management” is referenced descriptively (nominative fair use) solely to identify the software lineage and help affected users find a maintained alternative. Security details cite already-public advisory information; pricing is current as of June 2026 — confirm current rates. All third-party names belong to their respective owners.

Punchwell is an independently maintained GPL fork. Not affiliated with the original “WP Human Resource Management” plugin or its authors. Competitor names and figures are nominative and approximate (as of the date noted) — confirm current rates.