Undefined array key "SERVER_ADDR" / "SERVER_NAME"
in Bizuno Accounting

The log line

[28-May-2026 21:50:13 UTC] PHP Warning:  Undefined array key "SERVER_ADDR" in
  /wp-content/plugins/bizuno-accounting/src/model/msg.php on line 46
[28-May-2026 21:50:13 UTC] PHP Warning:  Undefined array key "SERVER_NAME" in
  /wp-content/plugins/bizuno-accounting/src/model/msg.php on line 46

The two lines are the same problem with two different keys. This was observed in our compatibility lab on PHP 8.3 with current WordPress and the Bizuno Accounting plugin active. The line number can differ between plugin versions, but the file (src/model/msg.php) and the cause are the same.

What the error means

PHP exposes details about the current request through the $_SERVER superglobal, an associative array. $_SERVER['SERVER_ADDR'] is meant to hold the IP address of the server handling the request, and $_SERVER['SERVER_NAME'] the host name from the server configuration.

Bizuno Accounting reads those two keys directly in src/model/msg.php to build context for its messaging and logging. When PHP runs the code in a context where those keys were never set, the read lands on a key that does not exist. On PHP 8.0 and later, accessing a missing array key raises an E_WARNING with the text Undefined array key. On PHP 7.x the exact same access only produced a quieter E_NOTICE (Undefined index), which is why the same plugin code looks fine on older PHP and noisy on PHP 8.

It is a warning, not a fatal. The request or task keeps running, and whatever value the code expected from those keys is simply empty. The practical cost is the log noise: with WordPress debug logging on, the line is written every time the affected code path runs.

Why it happens

The keys are not guaranteed. PHP only fills SERVER_ADDR and SERVER_NAME when a web server passes a real HTTP request to PHP, and even then only when the server is configured to provide them. The usual triggers are:

• WP-CLI and command-line runs. The CLI SAPI has no HTTP request behind it, so neither key exists. Any wp command that boots WordPress with Bizuno active hits the warning.
• System cron jobs. A scheduled task that loads WordPress outside a web request is the same story as WP-CLI. This is the most common way the line ends up repeating in a debug log.
• Some FastCGI / proxy setups. SERVER_ADDR in particular is not always forwarded to PHP-FPM. nginx, and some Caddy and reverse-proxy configurations, omit it unless you pass it explicitly, so even normal web requests can raise the SERVER_ADDR half.

So this is a PHP 8 compatibility gap in older plugin code: code that reads $_SERVER keys without checking they are present first, combined with PHP 8 raising the visibility of that access.

The fix

Pick the option that matches who controls the code and the server. They are listed from most durable to most situational.

Option 1: Update the plugin (preferred)

1. In WP Admin, Plugins, check whether an update is available for Bizuno Accounting, and apply it.
2. If you already run the latest version and the warning persists, report it to the plugin author with the exact log line and your PHP version. The correct upstream fix is to read the keys defensively, for example $_SERVER['SERVER_ADDR'] ?? '' instead of $_SERVER['SERVER_ADDR'].

This is the durable path because the change lives in the plugin and survives the next update.

Option 2: Guard the access in code

If you maintain a fork or need an immediate fix, change the bare key reads in src/model/msg.php to use the null coalescing operator, which returns a fallback when the key is missing and raises no warning:

// Before (raises the warning on PHP 8 when the key is absent)
$addr = $_SERVER['SERVER_ADDR'];
$name = $_SERVER['SERVER_NAME'];

// After (no warning; empty string when the key is not set)
$addr = $_SERVER['SERVER_ADDR'] ?? '';
$name = $_SERVER['SERVER_NAME'] ?? '';

Note that editing a plugin file directly is overwritten the next time the plugin updates. Treat this as a stopgap until Option 1 ships, and keep a record of the change.

Option 3: Provide the values to PHP (server level)

If the warning appears on normal web requests because your stack does not forward SERVER_ADDR, supply it at the web-server layer. On nginx with PHP-FPM, add the parameter to the location block that runs PHP:

fastcgi_param  SERVER_ADDR  $server_addr;
# SERVER_NAME is usually present already; if not:
fastcgi_param  SERVER_NAME  $host;

Reload nginx after the change. This populates the keys for web requests so the read succeeds. It does not affect WP-CLI or cron runs, which have no web server in front of them, so combine it with Option 1 or 2 if your noise comes from scheduled tasks.

What not to do

Downgrading PHP to 7.x would silence the line, because the same access was only a notice there, but trading a modern PHP for one warning is the wrong direction. Likewise, switching off WP_DEBUG or suppressing E_WARNING globally only hides the message and would mask other genuine warnings at the same time.

How to verify it is resolved

1. Make sure debug logging is on so you can watch the file: in wp-config.php, WP_DEBUG and WP_DEBUG_LOG set to true.
2. Note the current end of the log, then reproduce the trigger. For the cron and CLI case, run a command that boots WordPress, for example wp eval 'echo "ok";'. For the web case, load a Bizuno admin page.
3. Inspect the new lines in wp-content/debug.log and confirm no fresh Undefined array key "SERVER_ADDR" or "SERVER_NAME" entries pointing at bizuno-accounting/src/model/msg.php appear after your fix.
4. Leave it through at least one real cron cycle, since cron-driven runs are the usual source. A clean log across a full day of scheduled tasks confirms the fix held.

If the line still appears only under cron or WP-CLI after a server-level change, that is expected: Option 3 fixes web requests only. Apply Option 1 or 2 to cover the command-line paths.