Unterstützung von User Admin Language in WordPress 4.7

[glueckpress]

Bisher (Version 0.2.0) arbeitet Stringintelligenz mit der Site Locale de_DE. Wenn diese nicht gesetzt ist, reagiert das Plugin mit einer Warnung im UI und stoppt die weitere Ausführung:

if ( 'de_DE' !== get_locale() ) {
    add_action( 'admin_notices', array( new StringintelligenzAdminNotice(
        $this->templates_folder . '/admin-notice-locale-not-supported.php'
    ), 'render' ) );

    return;
}

In WordPress 4.7 gibt es das neue Feature der User Admin Language. Da es sich bei Stringintelligenz um die Sprache im UI dreht, scheint die Erwartung legitim, dass die User Locale unterstützt werden sollte und das Plugin auch dann einwandfrei funktioniert, wenn de_DE als User Locale gesetzt ist, die Site Locale aber ggf. eine andere ist.

Die Bedingung für das Anzeigen einer „Nicht-unterstützt“-Nachricht und für den Stopp der weiteren Ausführung sollte also die neue User Locale mit einbeziehen:

$user_id = get_current_user_id();
if ( 'de_DE' !== get_locale() || 'de_DE' !== get_user_locale( $user_id )  ) {
    // s.o.
}

⚠️ Leider stehen WP_User bzw. Funktionen wie get_user_locale() während der gegenwärtigen Abfrage noch nicht zur Verfügung; bei einem Dump werden Fallback-Werte geliefert:

Current user ID: 0
Current user locale: en_US

Die Ergänzung der if-Abfrage um get_user_locale() scheint also an ihrer momentanen Position in Stringintelligenz::initialize() nicht möglich.

@tfrommen, wie würdest du das architektonisch lösen?

[2ndkauboy]

Vermutlich würde es funktionieren, wenn man die admin_notice erst einmal immer hinzufügt und dann innerhalb davon, vor der Ausgabe der notice, die Überprüfung auf den Nutzer durchführt. Das müsste klappen.

[tfrommen]

Hey @glueckpress,

schau doch mal in den neuen Issue-Branch rein. Ich würde das so lösen - weiß aber nicht, ob ich dich richtig verstanden habe.

Viele Grüße, Thorsten

[glueckpress]

@tfrommen Fantastisch, vielen Dank! Merge in master und release auf w.org folgt.