Guard fopen() results with a false-check before fwrite/fprintf/fclose

On PHP 7.4, calling fwrite()/fprintf()/fclose() with a false handle
(a failed fopen(), e.g. from a bad path, missing directory, or
permissions issue) just emits a warning and no-ops. On PHP 8.0+, these
functions require a resource argument and throw an uncaught TypeError
instead, turning what used to be a silent degradation into a fatal
crash of the whole request.

This patch wraps every fopen()-then-write call site in the codebase
(18 files) with an `if ($handle !== false) { ... }` check, matching
the existing pattern used elsewhere in the codebase. Where the same
$fpvar handle is threaded through shared helper functions
(enter_ban_list/banlist/whitelist, duplicated across
remove_variables_processing.php, remove_variables_processing_default.php,
modify_structure_learning.php and tier_description_processing_gom.php),
the guard was added inside those functions too for consistency, even
though the call sites are currently dead/commented-out in three of the
four files — so the same landmine doesn't reappear if that code is
ever re-enabled.

Verified empirically against PHP 8.3.28: fopen() on an unwritable path
followed by fwrite() on the resulting `false` throws
  TypeError: fwrite(): Argument #1 ($stream) must be of type resource, false given
without the guard; with the guard, the call is skipped instead of
crashing. The normal (successful fopen) path was also re-run through
mat_structure.php's structure_change() and still produces identical
output to before the change.

Reviewed by: Frederick M Muriithi <fredmanglis@gmail.com>

0 files changed, 0 insertions, 0 deletions