Reicht es aus, nur ein untergeordnetes Thema zu erstellen - sagen wir technisch, ohne etwas anderes als das absolute Minimum an style.css hinzuzufügen -, damit die Übersetzung des übergeordneten Themas auch automatisch für das untergeordnete Thema verwendet wird?
Grundsätzlich lautet die Antwort NEIN , ... aber ... es gibt eine Option:
Fügen Sie ein Mu-Plugin hinzu.
Dieses (MU-) Plugin macht verschiedene Dinge:
- Es wird
after_setup_themeeine Priorität von 20 festgelegt - vorausgesetzt, die übergeordnete Textdomain / i18n .mo-Datei wird korrekt mit der Standardpriorität für den richtigen Hook geladen .
- Dann ruft es
instanceofdas WP_Theme- in diesem Fall das untergeordnete Thema - ab.
- Dann überprüft er , ob es tatsächlich ist ein Kind Thema in Gebrauch.
- Wenn dies zutrifft, wird nur die Textdomäne aus der übergeordneten Datei geladen.
Es ist eigentlich ganz einfach, da die Kernklasse viele Überprüfungen für uns durchführt: Sie ruft eine weitere Instanz WP_Themefür das übergeordnete Thema ab. Anschließend wird überprüft, ob der TextDomainHeader gesetzt ist, indem : $current_theme->get( 'TextDomain' );. Der Punkt ist also, dass es eine Konvention im Spiel gibt: Dieses Plugin funktioniert nur , wenn das übergeordnete Thema einen Text Domainund (!) Einen Domain PathHeader-Satz hat.
<?php
/**
* Plugin Name: (#113391) Parent Theme i18n Autoloader
* Description: Load Twenty12 Child theme translation files automagically from Parent
*/
add_action( 'after_setup_theme', 'wpse113391_parent_theme_i18n_autoloader', 20 );
function wpse113391_parent_theme_i18n_autoloader()
{
$current_theme = wp_get_theme();
if ( is_child_theme() )
$current_theme->parent()->load_textdomain();
}
Hier kommt nun das Problem: Die von Core gelieferten Standard- / Standard-Twenty * -Themen haben (()) keinen Domain PathHeader-Eintrag. Und das müssen wir sofort beheben , da load_theme_textdomain()sonst die Übersetzungsdatei nicht im übergeordneten Themenordner, sondern gesucht wird
- zuerst im untergeordneten Themenordner :
get_stylesheet_directory().WP_Theme::get( 'DomainPath' ), was bedeutet, dass (A) das Domain Pathgesetzt werden muss und ein Schrägstrich vorangestellt werden muss : /.
- dann im untergeordneten Themenordner: `get_stylesheet_directory (). '/ Languages'.
- und zuletzt im
WP_LANGUAGE_DIR.'/themes'Verzeichnis in.
Hinweis: Ich denke, das ist nur ein Fehler, der aus Gründen der "Abwärtskompatibilität" niemals behoben wird. Mit anderen Worten, es liegt ein Fehler vor, aber möglicherweise arbeiten bereits Entwickler daran. : P.
Dann gibt es noch ein anderes Problem. Die WP_ThemeKlassenmethode load_textdomain()übergibt intern ein $pathan load_theme_textdomain(). Und dieser Parameter ist $this->get_stylesheet_directory(). Und diese Methode kehrt zurück $this->theme_root . '/' . $this->stylesheet. Die Funktion würde also eigentlich ganz gut funktionieren , aber sie bringt es durcheinander, einfach einen internen Ersatz für aufzurufen get_stylesheet_directory()(was filterbar gewesen wäre). Man könnte jetzt denken
"Hey! Die Klasse implements ArrayAccess! Also setze einfach den fehlenden Array-Schlüssel von Domain Path!"
Falsch. Alle Klasseneigenschaften sind markiert privateund nicht zugänglich.
Dann könnten Sie denken
"Warum nicht einfach extenddie WP_ThemeKlasse und eine set()Methode definieren, damit wir die fehlenden Header-Einträge manuell festlegen können?"
Falsch. Die Klasse selbst ist finalund nicht erweiterbar.
Ergebnis: Wir bleiben mit dem, was load_theme_textdomain()uns - die letzte Funktion in der Anrufkette - bietet. Jetzt haben wir ein größeres Plugin, das den load_theme_textdomain()Aufruf abfängt , um die richtige Datei zu laden . Um das Laden anderer i18n-Dateien nicht zu stören, wird der Rückruf sofort aus dem Filter entfernt, um die Umgebung sauber zu halten.
<?php
/**
* Plugin Name: (#113391) Parent Theme i18n Autoloader
* Description: Load Twenty12 Child theme translation files automagically from Parent
*/
add_action( 'muplugins_loaded', array( 'WPSE113391Parenti18nLoader', 'getInstance' ) );
class WPSE113391Parenti18nLoader
{
public static $instance = null;
private $theme = null;
public static function getInstance()
{
null === self::$instance AND self::$instance = new self;
return self::$instance;
}
public function __construct()
{
add_action( 'after_setup_theme', array( $this, 'i18nAutoloader' ), 20 );
}
public function setTheme( $theme )
{
return $this->theme = $theme;
}
public function getTheme()
{
return $this->theme;
}
public function i18nAutoloader()
{
if ( ! is_child_theme() )
return;
$current_theme = wp_get_theme();
if ( '' === $current_theme->parent()->get( 'DomainPath' ) )
{
$this->setTheme( $current_theme->parent() );
add_filter( 'override_load_textdomain', array( $this, 'overrideI18nLoader' ), 10, 3 );
}
$current_theme->parent()->load_textdomain();
}
public function overrideI18nLoader( $activate, $domain, $mofile )
{
// Don't intercept anything else: Self removing
remove_filter( current_filter(), __FUNCTION__ );
// Rebuild the internals of WP_Theme::get_stylesheet_directory() and load_theme_textdomain()
$theme = $this->getTheme();
$path = trailingslashit( $theme->get_theme_root() ).$theme->get_template();
$locale = apply_filters( 'theme_locale', get_locale(), $domain );
load_textdomain( $domain, "{$path}/{$locale}.mo" );
// Return true to abort further attempts
return true;
}
}
functions.php. Ihre Antwort ist großartig, steht aber nicht in Konflikt mit einem untergeordneten Thema, über das die eigene untergeordnete Textdomäne definiert wirdload_child_theme_textdomain? Allerdings +1 sicher.