Hi @sesame307,
The blank red box is actually a useful clue, so you’re further along than it feels.
That notice renders whatever message came back from the REST API request behind the button. When it shows up empty, it usually means the response wasn’t valid JSON at all, so the JavaScript had nothing to display. The interesting question stops being “what is the error” and becomes “what did the server actually send back.”
Quick correction on the debug side first, because it’s a common one. The file you’re looking for is wp-content/debug.log, not debug.php, and WP_DEBUG alone won’t create it. You need all three lines in wp-config.php, above the “stop editing” comment:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
That last one matters more than usual here. If PHP notices are printing to the screen, they’re also printing into the REST response, which would break the JSON and produce exactly the empty box you’re seeing.
Now the test that will most likely find it. Open your browser’s developer tools and go to the Network tab rather than the Console. Click Add New Application Password, then find the POST request ending in application-passwords and open its Response tab.
What’s in there tells you which problem you have:
- Valid JSON with a message in it means the error is real and readable, and the UI just failed to surface it.
- HTML, or a blank line or stray characters before the opening
{ means something is printing output before WordPress sends the response. Usually a stray blank line after a closing ?> in wp-config.php or a theme file.
- A 403, or a page from your host or security software means the request is being blocked before WordPress ever sees it.
On that last one, it’s worth saying that deactivating all plugins doesn’t switch off all the code. Must-use plugins in wp-content/mu-plugins/ keep running, your active theme keeps running, and anything at the server level keeps running regardless. A web application firewall at the host, or a ModSecurity rule, will happily block REST API writes without leaving a trace in WordPress. If you can, try switching to Twenty Twenty-Five briefly as well, since the theme is the piece that plugin deactivation doesn’t cover.
One more thing worth ruling out early. Application Passwords are only offered over HTTPS. If your site sits behind a load balancer or a proxy that terminates the certificate, WordPress can think the connection is insecure even though your browser shows the padlock. Check what is_ssl() actually returns on your setup.
Post what the Response tab shows and it should be fairly quick from there.
