Genesis PHP Errors: When an Old Child Theme Meets a New PHP Version

Fatal, warning or notice: how a Genesis site complains

PHP reports trouble at three volumes. A fatal error stops the page: visitors get a critical error message or a white screen, and the admin email gets a recovery link. A warning lets the page finish but can print text into it if error display is on, which is how a header ends up shoved down by a line of file paths. A notice or deprecation message stays in the log and bothers nobody until the log is so full that a real fault hides inside it.

The general mechanics, including recovery mode and how to log errors without showing them to visitors, are in WordPress theme PHP errors. This page is about the messages that are specific to Genesis sites, and they tend to be these:

• Call to undefined function create_function(). Fatal on PHP 8.0 and later. Old code, usually in the child theme or a pasted snippet.
• Call to undefined function followed by a genesis_ name. Fatal. The child theme calls something the framework no longer has.
• Translation loading for the ... domain was triggered too early. A notice WordPress 6.7 introduced. The domain it names tells you which theme or plugin to look at.
• A deprecation message naming a Genesis hook. Harmless today, a to-do list for tomorrow.
• Undefined array key or undefined variable. PHP 8 promoted these from notices to warnings, so code that was quiet for years starts talking.

Read the path before you read the message

Every PHP error names a file. On a Genesis site, the folder in that path sorts the problem into one of three piles. wp-content/themes/genesis means the framework. wp-content/themes/ followed by your child theme's folder name means the design layer, which is your code even if you bought it. wp-content/plugins means a plugin, often one written specifically for Genesis years ago. Sort the log by those three before fixing anything, because the fix for each pile is different.

Framework errors almost always have the same cure: update Genesis. The changelog shows a steady run of PHP repairs in the patch releases, and a site still on an early 3.x version is carrying warnings that were fixed long ago.

Four sources of Genesis errors, most common first

1. Child theme code PHP 8 no longer accepts

PHP 8.0 removed create_function() and each() outright; the PHP manual suggests anonymous functions and foreach instead. Child themes and snippets from the early 2010s used both. A typical case is a one-line widget registration hooked to widgets_init and written with create_function. It worked for a decade, then the host upgraded PHP and the whole site went down at once. Check: search the child theme folder and any site-specific plugin for create_function( and each(.

2. Genesis functions that version 3.0 deleted

Genesis 3.0.0, released in June 2019, removed every function deprecated before Genesis 2.0.0, along with all non-HTML5 output and templates such as page_blog.php. A child theme written in the Genesis 1.x era can still call one of those functions from functions.php or a custom template. StudioPress's own developer docs advise testing with function_exists() rather than comparing version numbers, precisely so code survives removals. Check: if the fatal error names a genesis_ function, search the Genesis changelog for it.

3. Translation notices from layouts.php and early menu setup

WordPress 6.7 began flagging translations loaded too early. Genesis 3.6.0 deferred its own menu, layout and admin notice logic to cure the framework's share. The changelog then hands child theme developers a task: if the theme ships config/layouts.php, strip translation functions such as __() out of it and put the translated labels in config/layouts-labels.php. Genesis Sample 3.4.3, released in March 2025, also moved its responsive menu registration into a function hooked to after_setup_theme for the same reason. Check: the notice names a text domain; if it is your child theme's, these two files are the first places to look.

4. Genesis filters that were retired

Genesis 3.1.0 deprecated the genesis_footer_creds_text filter that countless child themes used to set footer text, and added a footer text field under Theme Settings, then Footer, in the Customizer. Old filters keep working until they do not, and in the meantime they add deprecation lines to the log. Check: search functions.php for any hook the deprecation message names.

Clearing a Genesis error log without a second outage

1. 1

   Copy the site to staging on the target PHP

   Never trial a PHP jump on the live site. If production is already down, our guide to a site that broke after a PHP update covers the rollback and the order of updates.

2. 2

   Update Genesis first

   Install 3.6.2, and update Genesis Blocks and any other Genesis plugins. That removes the framework pile from the log in one move.

3. 3

   Sort what remains by path

   Group the remaining entries into child theme and plugin files, and count how many distinct lines each file produces.

4. 4

   Rewrite removed PHP functions

   Replace create_function() with an anonymous function and each() with foreach. These are mechanical edits, but test each one, because the surrounding code was written for an older PHP too.

5. 5

   Replace or guard old Genesis calls

   Swap removed functions for their current equivalents and wrap optional ones in function_exists() checks, as the Genesis docs recommend.

6. 6

   Split layout labels and move footer text

   Move translated layout labels into config/layouts-labels.php, and move footer credits from the old filter into Customize, Theme Settings, Footer.

7. 7

   Run clean for a week, then switch

   Browse every template with logging on. When the log stays quiet, change PHP on production and keep watching the log for a few days.

Why the Requires PHP line will not warn you

The last Genesis changelog entry to state requirements is 3.1.0, from August 2019: PHP 5.6 or later and WordPress 5.0 or later. Genesis Sample's stylesheet header still says Requires PHP: 5.6. Those lines are floors, not promises about the ceiling. Nothing in the dashboard tells you that a child theme bought in 2016 contains a function PHP 8.0 deleted. You find out when the host upgrades, which hosts do on their own schedule when old versions stop receiving security fixes.

The habit that prevents the outage is boring. Once a year, or whenever your host announces a PHP change, copy the site to staging on the next PHP version and read the log before anyone forces you to. Keep a list of every custom snippet in the child theme, with what it does, so the person reading the log knows what is safe to rewrite. Watch the Genesis review for changes to the framework's status, and remember that a stale log also hides speed problems covered in the Genesis speed guide.

When the child theme is older than the PHP underneath it

Each fix above is small. The pattern is not. A Genesis child theme written years ago runs on a server whose PHP changes underneath it, beside plugins written by other people for other PHP versions, and the only test is the live site the morning after the host upgrades. Patching keeps it alive. It does not change the arrangement.

A Next.js site has dependencies too, but they are pinned, reviewed and tested in a build before deploy, and prerendered pages do not run PHP at all. It costs more to build and needs a developer for structural changes. Weigh it in Genesis vs Next.js, read how moving from Genesis to Next.js works, and see how owners edit afterward in Athena CMS. If a broken layout appeared alongside the errors, see Genesis layout broken; for menus, Genesis mobile menu not working. Other problems live in the troubleshooting section, and our theme troubleshooting service takes the ones you would rather hand off.