Unknown Named Parameter Error in wp-cron.php: The 2 Minute Fix
in /wp-content/…/wp-cron.php …
If that is the line staring back at you from your error log, you are in the right place. The unknown named parameter error is not a new bug in your site. It is an old, harmless habit that PHP 8 turned into a fatal one, and it usually traces back to a cron event scheduled years ago by a plugin or theme you have since removed.
A scheduled cron event was created with a string-keyed arguments array, something like ['interval' => 3600]. On PHP 7 that key was quietly ignored. On PHP 8, WordPress passes those arguments to the event’s handler, and the string key becomes a named parameter. If nothing is listening for a parameter with that name, PHP throws a fatal error, and because the event reschedules itself, the crash repeats on schedule, often at the same time every day.
The fix is deleting the leftover cron event. No code changes, no downgrade. See “How Do You Fix It?” below for the two commands.
Quick answer: An “unknown named parameter” fatal in wp-cron.php means an old cron event is passing arguments in a format PHP 8 reads differently than PHP 7 did. Delete the orphaned event with WP Crontrol or wp cron event delete, and the fatal stops for good. No plugin reinstall or code fix required.
What Does “Unknown Named Parameter” Mean in wp-cron.php?
Your error log is telling you that WordPress tried to call a function using a named argument (something like $interval) that the function does not accept. In plain terms: a scheduled task on your site was set up with extra, labeled data attached to it, and the code that runs when the task fires does not know what to do with that label. Instead of quietly ignoring it, as PHP 7 did, PHP 8 throws a fatal error and stops the request.
The parameter name in your own error will vary. We have seen $interval most often, but the underlying cause is always the same: a cron event stored years ago with a string-keyed arguments array that PHP 8 now reads differently.
Why Did This Start When You Moved to PHP 8?
PHP 8.0 introduced named arguments as a language feature. That changed what a single line deep in WordPress core effectively does every time a cron event fires:
call_user_func_array( $callback, $args );On PHP 7, the keys in $args were ignored. Values were passed positionally, string keys and all, and nothing complained. On PHP 8, string keys in that array are treated as named parameters. So a cron event scheduled like this:
wp_schedule_event( time(), 'daily', 'some_hook', [ 'interval' => 43200 ] );now calls every handler attached to some_hook with a named parameter $interval. If a handler’s function signature does not declare $interval, that is a fatal error, every time the event runs.
Here is the part that catches people off guard: the plugin that scheduled the event this way may have fixed the underlying pattern in a later update, or it may not even be installed on your site anymore. Cron events do not get cleaned up when a plugin is deleted. The schedule outlives whatever created it, sitting quietly in your options table until PHP 8 arrives and gives it a reason to detonate.
| What Happens | PHP 7 | PHP 8 |
|---|---|---|
| Cron event args stored with string keys | Passed positionally, keys ignored | Read as named parameters |
| Handler has no matching parameter name | No error, silently fine | Fatal error thrown |
| Owning plugin removed years ago | Orphaned event, harmless dead weight | Orphaned event, fatal on every run |
The Orphaned Event We Kept Finding on Our Fleet
On our own client sites, the exact event was et_builder_fonts_cron with an interval argument, a font-cache job scheduled by the Divi page builder. The sites throwing this fatal were not running Divi. It had been removed long before, replaced with a different theme entirely. The event survived the removal and detonated on schedule, one site logging the identical fatal at 15:05 UTC every day, regular enough to set a watch by.
Once we knew what to look for, we swept every site we manage and found the same shape of problem in bulk: orphaned cron events left behind by removed SEO plugins, link plugins, and builders, one abandoned event family alone turning up on more than 60 sites. Most orphans are just dead weight. The ones with string-keyed arguments are small time bombs waiting for a PHP 8 upgrade to arm them.
How Do You Find the Orphaned Cron Event?
With WP Crontrol (Easiest)
Install WP Crontrol, then go to Tools, then Cron Events, and look for two signs:
- Events whose Action column shows “None.” No code is listening for that hook, which means the plugin or theme that owned it is gone.
- Events whose arguments display string keys, for example
{"interval":43200}, rather than a plain array like[43200].
The event matching your fatal is usually the one whose hook name appears near the error in your log, or, failing that, the one scheduled to run at the time of day your error keeps recurring.
From the Command Line
wp cron event list --format=tableSpot the suspicious hook, then inspect the raw arguments:
wp option get cron --format=json | python3 -m json.tool | lessSearch that output for “args” entries that are objects, like {"interval": 43200}, instead of plain arrays. An object means string keys, and string keys are your prime suspect.
How Do You Fix It?
Delete the event. In WP Crontrol, open the event’s row and choose Delete, or run it from the command line:
wp cron event delete et_builder_fonts_cronThat is genuinely the whole fix. If the owning plugin is gone, there is nothing left to reconfigure. You are deleting a schedule for code that no longer exists on your server.
- Verify before deleting. “No callback registered” usually means the event is orphaned, but some handlers only register in specific contexts, and a hook’s owner is not always obvious from its name. We have seen an active plugin’s events look orphaned simply because its folder name shares nothing with its hook prefix. If the hook’s prefix matches a plugin you still run, leave it and update that plugin instead.
- Delete the whole family. A removed plugin rarely leaves behind just one event. While you are in there, clear its siblings too, and if the fatal arrived with company (out-of-memory errors, a bloated options table), the same removed plugin may be behind those as well.
The Bigger Pattern: What Deleted Plugins Leave Behind
This error is one symptom of a general truth: removing a plugin removes its code, not its footprint. Scheduled events, database options (sometimes megabytes of them, autoloaded on every single page view), and background job queues all tend to stay behind. We audit for all three across our 105+ active client sites, and the results still surprise us.
If your error log shows this fatal on a repeating schedule, budget about ten minutes: fix this event, then take a look at what else might be sitting in your cron table. The site that led us to this pattern had been crashing on schedule, every single day, for longer than anyone on the team could say. The fix was one deleted row.
Not sure what else is quietly sitting in your cron table?
A fatal error on a schedule is easy to miss until it starts costing you traffic or transactions. Every hour your site spends throwing silent errors is an hour it is not doing its job for your business. We will check your site’s cron table, options table, and leftover plugin footprint as part of getting to know it.
FAQ
What does “unknown named parameter” mean in a WordPress fatal error?
It means a piece of code, usually a scheduled cron event, is calling a function with a labeled argument that the function’s signature does not declare. WordPress passes cron event arguments straight through to whatever function is listening, and on PHP 8, string-keyed array items become named arguments. If the function does not expect that name, PHP stops with a fatal error.
Why did this only start happening after I moved to PHP 8?
Named arguments are a PHP 8 language feature. On PHP 7, the same stored cron event caused no problem at all, because string keys in an arguments array were simply ignored. The event had likely been sitting on your site for years without incident.
Is it safe to delete the cron event?
In most cases, yes, especially if WP Crontrol shows “None” in the Action column, meaning no code is currently listening for that hook. Confirm the hook name does not match a plugin you still actively use before deleting, since a small number of plugins only register their handlers in specific contexts.
What if I cannot tell which plugin created the orphaned event?
Search your error log and your active plugin list for the hook prefix first. If it still shows no callback registered anywhere in your active code, it is very likely an orphan from something removed long ago.
Will a new fatal like this happen again after I delete this one?
It can, if your site has more than one orphaned event with the same string-keyed pattern. That is why it is worth checking the whole cron table in one pass rather than deleting a single event and moving on. Removed plugins rarely leave behind just one leftover event.
How do I check my whole site for cron events like this, not just the one in my error log?
Run wp option get cron --format=json | python3 -m json.tool | less and scan the output for any “args” entry that is an object with named keys rather than a plain numbered array. Every object-style entry is worth a closer look, whether or not it has thrown an error yet.
Jonathan Wofford is the founder of Your WP Guy (yourwpguy.com), a WordPress care and maintenance service supporting 105+ active client sites. He and his team specialize in keeping WordPress sites fast, secure, and running, so business owners can stay focused on their business instead of their website.
Talk to a WordPress Expert