Fix 'Fatal error: Maximum function nesting level of 100 reached' in WordPress

TL;DR

Nine times out of ten, this error comes from Xdebug — not your code. It enforces a default nesting cap of 100 to catch runaway recursion. Raise it in php.ini:

; Add or update in php.ini
xdebug.max_nesting_level = 512

Restart PHP-FPM or Apache, then reload the page. Not using Xdebug? You have a real recursion bug — skip to Fix 4.

What's actually happening

PHP has no built-in nesting limit. That specific error message — Fatal error: Maximum function nesting level of '100' reached, aborting! — is injected entirely by the Xdebug extension. Xdebug hard-caps call depth at 100 to stop infinite recursion before it stack-overflows the PHP process.

WordPress burns through 50–80 nested calls just loading a single page. Hooks, filters, template includes — they stack up fast. One plugin that adds a handful of extra call layers, and on a dev machine with Xdebug active, you're over the limit before the page finishes rendering.

Production servers almost never run Xdebug. If this error appears in production, it's a genuine recursion bug — not a config issue.

Fix 1: Raise the Xdebug nesting limit (most common)

First, find which php.ini is actually being loaded:

php --ini
# or:
php -r "echo php_ini_loaded_file();"

Open that file and add or update this line:

xdebug.max_nesting_level = 512

Then restart your web server:

# Apache
sudo systemctl restart apache2

# Nginx + PHP-FPM
sudo systemctl restart php8.1-fpm

# MAMP / WAMP / Laragon: use the GUI restart button

512 is a safe value for WordPress. Still hitting the error at 512? You almost certainly have a real recursion loop — no config change will fix that.

Fix 2: Disable Xdebug entirely (if you don't need it right now)

Xdebug installed just for occasional step-debugging? Turn it off when you're not actively using it:

# On Ubuntu/Debian
sudo phpdismod xdebug
sudo systemctl restart apache2   # or php-fpm

# Or comment out the extension line in php.ini:
; zend_extension=xdebug.so

Without Xdebug loaded, the nesting check disappears entirely. WordPress loads as normal.

Fix 3: Override via .htaccess (shared hosting fallback)

Can't edit php.ini directly? Some shared hosts allow overriding PHP settings through .htaccess:

# .htaccess (Apache only)
php_value xdebug.max_nesting_level 512

One caveat: Xdebug reads its nesting limit at extension load time, before any PHP code runs. That means ini_set() in wp-config.php won't work — the limit is already locked in by then. The .htaccess approach works on some hosts, not all. If it fails, contact your host and ask them to raise the limit or disable Xdebug.

Fix 4: Track down actual infinite recursion

Running on production without Xdebug and still seeing this? Something is genuinely recursing out of control. The usual suspects:

• A plugin hooks into a filter and calls the function that triggers that same filter
• A shortcode that renders another shortcode, which calls the first one back
• A custom Walker class calling wp_nav_menu() inside itself
• A recursive function with a missing or unreachable base case

Disable all plugins at once to confirm the source:

# Via SSH — rename the plugins folder temporarily
mv wp-content/plugins wp-content/plugins_backup
mkdir wp-content/plugins

Error gone? Re-enable plugins one by one until it comes back. That's your culprit.

To pinpoint where the loop starts, drop a backtrace into the suspected hook:

add_filter('the_content', function($content) {
    debug_print_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS);
    return $content;
}, 5);

Look at the stack trace output. The repeated function names near the bottom of the call stack are where the recursion is cycling.

Verifying the fix

Reload the page — it should come up clean. Then confirm Xdebug picked up the new value from the command line:

php -r "echo ini_get('xdebug.max_nesting_level');"
# Should print 512 (or whatever you set)

Prefer checking from inside WordPress? Drop this into a temporary theme file:

<?php
echo ini_get('xdebug.max_nesting_level');

Still showing 100? Your web server isn't reading the php.ini you edited. CLI, PHP-FPM, and the Apache module can each load a different ini file. Run php --ini in your web server's context (or check phpinfo()) to find which file it's actually using.

Local dev environment cheat sheet

• Lando: add xdebug.max_nesting_level: 512 under config: php: in .lando.yml, then run lando rebuild
• Valet: edit /usr/local/etc/php/8.x/conf.d/ext-xdebug.ini
• Docker: set the environment variable XDEBUG_CONFIG=max_nesting_level=512, or mount a custom ini file into the container
• MAMP: edit /Applications/MAMP/bin/php/phpX.X/conf/php.ini directly, then restart MAMP from the GUI