Log-Eintrag bei jedem Seitenaufruf durch multilingualpress

Das Plugin MultilingualPress nutzt intern die AWS PHP SDK, die standardmäßig versucht, Konfigurationsdateien im Home-Verzeichnis des Users zu lesen (z. B. ~/.aws/config).

Auf dem Server ist open_basedir so konfiguriert, dass PHP nur auf bestimmte Verzeichnisse zugreifen darf. Das führte in sekündlichen Abständen zu einer Fehlermeldung wie dieser:

[error] 90674#90674: *905155 FastCGI sent in stderr: "PHP message: PHP Warning: is_readable(): open_basedir restriction in effect. File(/www/projectidspace/.aws/config) is not within the allowed path(s): (/www/projectidspace/public:/www/projectidspace/mysqleditor:/www/projectidspace/web:/www/projectidspace/deploy:/www/projectidspace/deployment:/www/projectidspace/deployments:/usr/share:/tmp:/dev/urandom) in /www/projectidspace/public/wp-content/plugins/multilingualpress/vendor/aws/aws-sdk-php/src/DefaultsMode/ConfigurationProvider.php on line 126" while reading response header from upstream, client: {IP-Adresse}, server: project.com, request: "POST /wp-admin/admin-ajax.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php8.3-fpm-projectid.sock:", host: "project.com:35480", referrer: "https://project.com/wp-admin/post.php?post={postID}&action=edit"

In der wp-config.php kann das Verhalten abgefangen werden.

Snippet 1

/**
 * Disable AWS SDK non-default config loading and EC2 metadata,
 * to avoid open_basedir warnings from MultilingualPress' AWS SDK.
 */
if (!defined('AWS_SDK_LOAD_NONDEFAULT_CONFIG')) {
    // Verhindert, dass ~/.aws/config & Co. gelesen werden
    putenv('AWS_SDK_LOAD_NONDEFAULT_CONFIG=false');
}

if (!defined('AWS_EC2_METADATA_DISABLED')) {
    // Verhindert Zugriffe auf EC2-Metadaten (die auf Shared Hosting ohnehin nicht funktionieren)
    putenv('AWS_EC2_METADATA_DISABLED=true');
}

• Sagt der AWS SDK: „Lade keine zusätzlichen/benutzerdefinierten Konfigurationen (z. B. aus ~/.aws/config).“
• Ergebnis: Die Bibliothek verlässt sich eher auf explizite Konfiguration (Code/Env), statt heimlich Dateien zu durchsuchen, die auf Shared Hosting ohnehin meist nicht existieren oder verboten sind.

Snippet 2, der eigentliche Problemlöser

/**
 * Workaround for MultilingualPress / AWS SDK open_basedir warnings.
 *
 * The AWS SDK tries to read ~/.aws/config based on the HOME env var.
 * We point HOME to ABSPATH (WordPress root), which is inside open_basedir,
 * so is_readable() will quietly return false instead of triggering a warning.
 */
if (defined('ABSPATH')) {
    $wp_home = rtrim(ABSPATH, '/\\');

    // Set HOME for CLI / PHP environment
    putenv('HOME=' . $wp_home);

    // And for web server vars, just in case the SDK looks there
    $_SERVER['HOME'] = $wp_home;
}

Da dieses Verzeichnis außerhalb der in open_basedir erlaubten Pfade liegt, führte jeder Zugriffsversuch von is_readable() auf diese Datei zu wiederkehrenden PHP-Warnings im Error-Log, obwohl die eigentliche Funktionalität der Website nicht beeinträchtigt war. Durch das Umleiten von HOME auf das WordPress-Verzeichnis (innerhalb von open_basedir) wurde dieses Problem behoben, da die AWS-SDK-Aufrufe nun auf einen zulässigen Pfad zeigen und in aller Stille fehlschlagen, ohne Warnings zu erzeugen.

Das Server-Fehlerlog bleibt damit sauber.