Jan (interiete.net)

Wie von Heiko bereits erwähnt, lädt WordPress zuerst das functions.php des Child- und anschliessend das des Parent-Themes (Sofern eine solche Datei existiert).

Ich habe mich nun mittels dem Action-Hook “after_setup_theme” zuhelfen versucht. Die Ladereihenfolge der functions.php habe ich so zwar nicht umdrehen können, doch innerhalb der functions.php lade ich nun die jeweilige PHP-Klasse mit unterschiedlicher Prioität. So erreiche ich, dass zuerst der Code fürs Parent-Theme und erst anschliessend das Child-Theme abgearbeitet wird.

Im Action-Hook erstelle ich hierbei eine anaonyme Funktion, in welcher ich die init-Methode meiner Klasse aufrufe. Entscheidend hier ist die Prioritätsangabe als letzten Parameter. Diese muss höher sein, als der Standardwert von WordPress (10).

In der Init-Methode der Parent-Klasse, lade ich nun via der Funktion “load_theme_textdomain” die Sprachfiles.

Im Child-Theme mache ich prinzipiell das selbe, ausser das ich hier dem Action-Hook “after_theme_setup” nun eine niedrigere Priorität (10 statt 9) zuweise. Somit stelle ich sicher, dass die Init-Methode des Child-Themes erst nach der des Parent-Themes abgearbeitet wird.

In der Init-Methode des Child-Themes kommt dann die Funktion “load_child_theme_textdomain” zum Zug. Als Paremeter diesmal nicht TEMPLATEPATH sondern STYLESHEETPATH, da wir uns ja nun im Child befinden.

Das Schöne dabei, ich kann nun im Child auf Klassen im Parent-Theme zugreifen, von diesen erben und eigene Implementierungen schreiben. Änderungen am Parent haben somit ebenfalls Einfluss aufs Child, da ich hierbei nicht auf Action-Hooks sondern auf die OO-Technik von PHP5 setze.

Korrigiert mich wenn ich irgendwo einen Fehler drin habe resp. dieses Vorgehen in Zukunft zu grösseren Problemen führen könnte. Meine bisherigen Seiten laufen nun jedoch bereits einige Zeit mit zahlreichen 3th-Party Plugins ohne Probleme. Was ich selbst noch nicht testen konnte, war die Implementation in eienr WPMU Umgebung.

Gruss
Roman

Zum Huhn und Ei Problem: Seh ich genau so wie du. Der Entscheid vom WP Dev Team, zuerst das Child anstelle des Parent zu laden, ist aus OO sicht völliger quatsch. Verstehe nicht, weshalb dies so entschieden wurde. Auch wenn WordPress für PHP4 geschrieben wurde, sollte man von dem Ansatz wegkommen und etwas objektorientierter denken.

Mein eigenes Framework setzt auf PHP5 auf. Da ich jedoch keine Hooks im Child-Theme benutzen wollte, sondern das Child-Theme anschliessend gewisse Basis-Klassen überladen sollte (sofern erlaubt natürlich), laufe ich dank der “falschen” Ladereihenfolge nun in ein Problem. Dem Child sind alle Klassen des Basis Themes nicht bekannt. Ein nachträgliches includen hilft auch nicht, da dies erst zu einem späteren zeitpunkt durchgeführt wird. Ich suche und hoffe immer noch nach einem übersehen action hook, doch bisher leider Fehlanzeige.

Gruss
Roman

Ich hab in letzter Zeit mehrfach Premium Themes (primär bei Themeforest) gesehen die einfach nur auf englisch waren und keinerlei Gebrauch von den WP-Funktionen zur Mehrsprachigkeit gemacht haben. Genauso “toll”: ich bastel momentan an “The Morning After” rum das ja seit einiger Zeit von WooThemes betreut wird. Nicht nur, dass deren Framework zum Teil nicht übersetzbar ist… nein… zumindest bei TMA gibt es einen wilden Mix von übersetzbaren und nicht übersetzbaren Strings, fehlender Nutzung von _n() wo es angebracht wäre und totaler Ignoranz gegenüber Argumenten und Argument Swapping was dann zu so Konstrukten führt wo erst ein Teil eines Satzes ausgegeben wird, dann eine Zahl und dann der Rest des Satzes. Schön aufgeteilt in seperate Aufrufe von _e() und echo.

Und bei PlugIns sieht die Sache nicht besser aus. Sie wird höchstens noch durch sinnfreies laden von CSS und JS-Dateien verschärft (mein Favorit im Moment: ein Syntax-Highlighter PlugIn welches ca. 20 JS-Dateien in die Seite klatscht - egal ob das PlugIn überhaupt auf der jeweiligen Seite etwas zu tun hat oder ob nicht).

I definitely understand your frustration. I have the same frustrations with WordPress. My theme users want to keep their parent theme translations in their child theme. Otherwise, their translation is lost when the parent theme is updated. Because so many of them asked about this, I created a solution that would fix this problem for them.

If I had $5 for every time I was asked for this solution, I’d be a wealthy man. I’ve only been asked about integration with your plugin one time. So, I have to look at which solution is currently the best for the majority of my users, even if that means not working with some plugin.

Admittedly, I should’ve used a filter in version 0.8, but as you’ve seen, I’ve added this to the next update. Obviously, this doesn’t fix the problem with your plugin. Continuing to call the theme code non-standard and incorrect does nothing to help solve the issue. Using a filter hook available in WordPress is “standard” practice. If the plugin doesn’t recognize this, then there’s an obvious problem there.

The default in WordPress should be $textdomain-de_DE.mo for themes. This would help solve the issues with child themes and parent themes by allowing users to have multiple theme translations inside of the child theme. It should also satisfy your plugin’s need to scan for files that aren’t loaded. I will support any ticket you bring up on Trac with a good patch/solution.

1
2
3
4

<?php
require('my_theme_core.php');
$my_theme = new my_theme_class();
?>

Wie überschreibst du jetzt gefahrlos die Klassenmethode, die die Sprachdatei lädt in der functions.php deines Child-Themes?
Warum sollte ich 2 mal ein *.mo File laden müssen (aus Speicher- und Performancegründen nicht akzeptabel), wenn es mit einmal laden auch getan wäre ?
Wie du siehst, sind die Probleme nicht kleiner sondern sehr viel komplexer. Viele Theme-Frameworks lassen sich schlicht nicht aushebeln und geben dir als Child-Theme Writer auch keine Möglichkeiten, das zu beeinflussen. Deshalb tüftel ich an einer Lösung, die sich einfach in den WP Core als Patch beantragen lassen sollte und mit Bestandssoftware korrekt weiterarbeitet.

Das ist jetzt nur so ein kleiner Denkansatz

Als allgemeine Lösung wäre ein zusätzlicher Header in der style.css vielleicht hilfreich, der das regelt. Etwa so:

Load Parent Language: first|second|never

Willst du das mal im Trac oder auf wp-hackers diskutieren?