Sprachabhängiges "serendipity_fetchPrintEntries"

[unlock]

Hallo

Als erstes mal *big thumbs up* für die tolle Blog-Software. Ich setzte sie zur Zeit bei neuen Projekten als einzige ein.

Bei einer zweisprachigen Seite bin ich nun über ein kleines Problem gestolpert. Ich benutze das Multilingual-Plugin mit Sidebar-Dropdown und das funktioniert alles eigentlich wunderbar. Für die Frontpage benötige ich aber die Funktion "serendipity_fetchPrintEntries". Diese liefert mir aber, egal welche Sprache ich im Dropdown ausgewählt habe, nur Deutsche (Deutsch = Default-Sprache) Entries zurück. Was für Properties bzw. Trigger/Hooks muss ich hier angeben, definieren, was auch immer, damit da die Entries sprachabhängig daherkommen?

Vielen Dank & Gruss,
Andry

[garvinhicking]

Hi!

Puh. Das is glaub ich nicht so trivial.

Theoretisch müsste es eigentlich die aktuell gewählte Sprache bereits ausführen. Wie genau sieht dein fetchPrintEntries-Aufruf aus?

Da das multilingual-Plugin im 'entry_display' die Sprache des Eintrages "switcht" ist es wichtig, dass dieser Hook ausgeführt wird. Der Hook wird durch include/functions_entries.inc.php, funktion serendipity_printEntries() ausgelöst, aber nur wenn $use_hooks gesetzt ist:

Code: Select all

    if ($use_hooks) {
        $addData = array('extended' => $extended, 'preview' => $preview);
        serendipity_plugin_api::hook_event('entry_display', $entries, $addData);

        if (isset($entries['clean_page']) && $entries['clean_page'] === true) {
            if ($serendipity['view'] == '404') {
                $serendipity['view'] = 'plugin';
            }

            $serendipity['smarty']->assign(array(
                'plugin_clean_page' => true,
                'view'              => $serendipity['view'])
            );
            serendipity_smarty_fetch($smarty_block, 'entries.tpl', true);
            return; // no display of this item
        }
    }

Du könntest mal versuchen an der stelle in der IF-Abfrage was auszuführen um zu gucken ob es angezeigt wird. DAs knifflige daran ist, dass diese Funktion vermutlich bei dir zweimal aufgerufen wird, einmal durch den Smarty-Aufruf und einmal ganz normal. Sprich wenn Du ein die("Huhu, ich bins") da einfügst, dann wird er auch bei dem normalen smarty-aufruf dort was ausgeben.

Toller wäre daher sowas wie

Code: Select all

print_r($entries);

auszugeben und später in der HTML-Ausgabe zu prüfen ob das 1. zweimal auftaucht und 2. mit den korrekten Eingangsdaten für die Einträge die man anzeigen will.

Ob $use_hooks gesetzt wird, wird entschieden durch include/functions_smarty.inc.php, funktion serendipity_smarty_fetchPrintEntries(). Standardmäßig steht das glaub ich auf false:

Code: Select all

    if (empty($params['use_hooks'])) {
        $params['use_hooks'] = false;
    }

Evtl. hilft es daher wenn du deiner {smarty_fetchPrintEntries} Aufruf eine "use_hooks=true" mit auf den Weg gibst?

Grüße,
Garvin

[unlock]

Hey! Vielen Dank für die schnelle Antwort - das ist ja echt Service!

Mein Aufruf sieht so aus:
{serendipity_fetchPrintEntries limit="3" use_hooks=false template=frontpage_entries.tpl}

Wenn ich nun use_hooks=true verwende, werden gar keine Entries mehr angezeigt.

Ich werde später noch Deine andere Test-Vorschläge anschauen & austesten.

Danke erstmal!

[unlock]

Ich habe Deinen Tip mit print_r($entries); gleich mal versucht. Die Funkton wird tatsächlich 2 Mal ausgeführt. Dabei werden auch die verschiedenen Sprach-Versionen ausgegeben:

[multilingual_body] enthält den Englischen Text.
[body] enhält die Deutsche Version.

Dazu hin gibt's im [properties]-Array noch folgendes:
[multilingual_body_en], und das enthält nochmal die Englische Version.

Das alles, wenn ich Englisch auswähle als Sprache.

Sobald ich Deutsch auswähle (Default-Blog-Sprache) fehlt [multilingual_body] und sonst ist es das selbe.

Hilft und das jetzt weiter?

[garvinhicking]

Hi!

Das Problem ist, dass use_hooks beim kombinierten Aufruf von fetchPrintEntries INNERHALB einer s9y Seite wo die Methode bereits vom Kern aufgerufen ist, so nicht wirklich Sinn macht und Schwierigkeiten hervorruft, da beide Aufrufe einen gemeinsamen Datenpool haben. In Deinem Fall führt das dann zu der "leeren" Ausgabe, weil dort der Pool "verunreinigt" wird.

Was Du machen könntest ist für die Ausgabe deiner eigenen Einträge eine eigene smarty templatedate zu erstellen. Sprich, deine frontpage_entries.tpl editieren. Dort benutzt Du dann anstellen von {$entry.body} direkt die Zielsprache {$entry.properties.multilingual_body_en}. Um dynamisch die Sprache des Benutzer auszusuchen müsste man noch etwas Smarty/PHP-Code vorausschicken, das ist nicht so trivial. Evtl. müsste man das multilingual-plugin patchen damit es eine globale variable mit der sprache füllt und man dann dynamisch das korrekte properties-Feld anspricht.

Viele Grüße,
Garvin

[unlock]

Alles klar! Das kriege ich hin - jetzt hab ich nämlich mal ein wenig die Struktur und den Ablauf geschnallt. Sobald ich eine Lösung habe, werde ich das hier noch hinposten. Danke für diesen Realtime-Support!

[garvinhicking]

Hi!

Kein Problem, viel Erfolg. Je nachdem wie deine PHP-Skills sind kann man natürlich auch einen anderen Weg gehen und ein s9y Plugin erstellen, dass die API-Methoden ausserhalb von Smarty aufruft. Da ist man dann nämlich flexibler im Aufruf der Event-Hooks.

Grüße,
Garvin

[unlock]

Hi

Ich habe, um das ganze möglichst einfach zu halten, noch ein wenig mit Smarty rumgespielt. Dabei habe ich die Variable $lang gefunden. Entsprechend kann ich nun bei meiner Ausgabe mit dieser Variable entscheiden, welche Sprachversion ich ausgeben will:

Code: Select all

{if $lang=="de" }
  {$entry.body}
{else}
  {$entry.multilingual_body}
{/if}

Vielleicht ist das jetzt komplett doof? Wofür ist multilingual_body im normalen S9y-Ablauf gedacht?

Ein weiteres (nicht so schlimmes) Problem ist jetzt, dass $entry.body korrekt daher kommt, auf $entry.multilingual_body aber keine Formatierungen vorgenommen wurden. Hook-Problem?

Danke & Grüsse aus der Schweiz,
Andry

[garvinhicking]

Hi!

Woher multilingual_body kommt kann ich so garnicht sagen, das kommt auf jeden Fall vom Plugin. Ich selber werte bevorzugt lieber das properties-array aus, wo der sprachsuffix jeweils drin ist.

Ein weiteres (nicht so schlimmes) Problem ist jetzt, dass $entry.body korrekt daher kommt, auf $entry.multilingual_body aber keine Formatierungen vorgenommen wurden. Hook-Problem?

Jupp, denn nur auf die Felder 'body' und 'extended' werden Markup-Transformationen vorgenommen, also Hooks ausgeführt. Daher kriegst Du das nur mit einem eigenen s9y plugin behoben wo du dann die multilingual-felder auch durch "frontend_display" schleifst. Eventuell kannst du den frontend_display hook aber durch umbenennung etc. auch selber innerhalb der smarty ausführen (also "{hook_event}" oder so aufrufen). Ich schreib aber hier aufs blaue, ob das funktioniert kann ich leider nicht so sagen. Das geht dann schon in tiefere Bereiche des ganzen Systems ein.

Grüße,
Garvin

[unlock]

Das Problem mit der Anzeige der Texte habe ich mittlerweile gelöst (ohne allerdings es geschafft zu haben, die Sache durch die Formatierungsplugins zu schleifen -> ist aber nicht so schlimm).

In diesem Zusammenhang aber noch eine Frage: Gibt es irgend eine eingebaute Möglichkeit, dass ich die RSS/ATOM-Feeds auch sprachabhängig rausbekommen, oder müsste dafür Code angepasst werden (was nach einem ersten Blick nicht so eine Sache sein dürfte)? Wenn's aber schon irgendwas schlaues gibt, müsste ich nichts programmieren

Danke & Gruss

[garvinhicking]

Hi!

Die rss.php-Feeds müsstest Du eigentlich auch via rss.php?lang=XX oder rss.php?serendipity[lang]=XX sprachabhängig aufrufen können.

Viele Grüße,
Garvin

[unlock]

Das funktioniert leider scheinbar nicht. Evtl. ist das ein neues Feature? Meine S9y-Version ist schon ca. 3 - 4 Monate alt.

[garvinhicking]

Hi!

Eigentlich müsste das schon seit langem gehen, denn die GET-Variable wird ja ins zentrale s9y framework "geschleudert".

Aber es kann sein dass das das selbe Problem ist wie mit deiner Smarty-Aufruf.

Check mal die *.tpl Dateien und guck mal ob Du da nicht evtl. auf {$entry.properties} zugreifen kannst. Dann könntest du einfach unterschiedliche "versionen" erzeugen:

rss.php?version=2.0de
rss.php?version=2.0en

etc., mit jeweiligem .tpl dass die korrekte property anspricht. Ist irgendwie was hacky, aber kann sein dass im rss-feed die 'entry_display' hook methode (auch) noch nicht genutzt wird.

Das mit den RSS-Feed Templates klappt aber erst am s9y 1.0.

Grüße,
Garvin

[unlock]

Hallo Garvin

Nun, irgendwie hab ich letzte Woche wohl den Wald vor lauter Bäumen nicht mehr gesehen. Die RSS/ATOM-Feeds sind natürlich bereits sprachabhängig und brauchen auch keinen speziellen Aufruf oder Anpassungen an Source oder Templates.

Scheinbar gerät s9y aber durcheinander, wenn man eingeloggt ist. In diesem Fall wird nämlich der persönlichen Spracheinstellung ein höheres Gewicht gegeben als wenn man nicht eingeloggt ist. Die Auswahl durch das Multilingual-Sidebar-Plugin ist, wenn man eingeloggt ist, nur bis zum nächsten Seitenaufbau ausschlaggeben. Danach "resetted" sich s9y wieder auf die eingestellte Sprache.

Wenn man nicht eingeloggt ist, funktionieren sowohl die Staticpages, wie auch Einträge und auch die RSS-Feeds so wie man es von ihnen erwartet

Vielen Dank trotzdem, für die Hilfe!

Gruss,
Andry

[garvinhicking]

Hi!

Scheinbar gerät s9y aber durcheinander, wenn man eingeloggt ist. In diesem Fall wird nämlich der persönlichen Spracheinstellung ein höheres Gewicht gegeben als wenn man nicht eingeloggt ist. Die Auswahl durch das Multilingual-Sidebar-Plugin ist, wenn man eingeloggt ist, nur bis zum nächsten Seitenaufbau ausschlaggeben. Danach "resetted" sich s9y wieder auf die eingestellte Sprache.

Ja, das ist richtig. Die voreingestellte Sprache hat immer höchste Priorität. Für Serendipity 1.2-snapshots hat sich da jedoch etwas geändert, evtl. für deine zwecke zum besseren...schonmal probiert ob sich da was tut?

Viele Grüße,
Garvin