phpwcms Support Forum

Moin Leute,

ich benutze in einer Seite den Language-Switch basierend auf den Sprachplatzhaltern [DE] [EN] usw.

Im Prinziop habe ich soweit alles in den Griff bekommen inkl. richtige Darstellung der Navi.

(btw. hier ein Tip: Die Datei "lang_replace.php" umbenennen zu z.B. "z_lang_replace.php". Die Frontend scripts werden
scheinbar alphabetisch abgearbeitet. In dem Fall kommt das script zum ersetzen der Sprache auch wirklich zum Schluss -> z.B. NACHDEM die NAvi gerendert wird, dann klappen auch in einer Nav_Horiz... die Sprachschalter.)

Mein Problem:

In einem Teaser werden 20 Schlagwörter gerendert. Der Teaser schneidet dann das schließende [/DE] oder [/EN] ab, und die gesamte Seitendarstellung kommt ins schleudern.

Hat sich da schon mal jemand mit beschäftigt? Ich bin leider eher der PHP-Handwerker, also von allem ein bischen aber eigentlich keine Ahnung.

Mein Ansatz wäre in der lang_replace.php zu prüfen, ob nach dem öffnenden [SPRACHE] eine Zeichenkombination auftaucht, die das Ende eines Teasers anzeigt, also z.B. {TEASER_END} oder so.

Dies müsste das Script dann wie das schließende Sprachtag behandeln und das Problem wäre gelöst.
Ich denke ich würde das mit meinen eher handwerklichen PHP-Fertigkeiten irgendwie hinbekommen, aber evtl. hat ja schon jemand sowas gebastelt?

Beim Teaser selbst gibt es ja das Feld "Erlaubte Tags", da habe ich einfach mal [DE] und [EN] reingeschrieben in der Hoffnung da würde auf den schließenden Tag geprüft, aber da war wohl eher der Wunsch der Vater des Gedankens

Hi,

ich würde das separat in eine CP-Trigger prüfen um nicht immer die ganze Seite damit zu belasten.
Beim einfachen Kürzen von Text, sei es mit der Anzahl Worten- oder Zeichen, ist eine Prüfung auf TAGpaarungen nicht so ganz einfach.

Das Gleiche passiert auch in der Artikellistenansicht wenn eine max. Wortanzahl vorgegeben wird und beschränkt sich nicht nur auf diese erfundenen TAGs sondern auch auf alle HTML TAGs die geschlossen werden möchten. (Jetzt gerade selbst erlebt in einem anderen Zusammenhang, ich habe dazu das System gepatcht und ein zweites einfaches Eingabefeld neben den Summary eingebaut das in den Templates separat ausgegeben werden kann).

Ich würde das im Fall des Teaser-CPs so machen:
In eine Trigger-CP diesen CP auslesen und speziell auf [XX]...[/XX] Paare untersuchen. Vielleicht mit preg_match.
Nun in jeder Paarung nachsehen, ob es dort irgendwo ein öffnenden [XX] TAG gibt, denn dann ist dort etwas falsch gelaufen.

Das geht natürlich nur wenn es überhaupt eine [/XX] TAG gibt und nicht alle abgeschnitten worden sind.
Sonst muss man halt nach anderen Abgrenzungskriterien suchen und dann nach [XX] TAGS untersuchen.
Diese Kriterien könnten die jeweils einleitende Klasse zu jedem Artikeltext sein mit dem entsprechenden Ende.

Ist nur ein Denkanstoß, mehr nicht.

Um die Reihenfolge bei den Scripten exakt festzulegen kannst du in frontend_render alle Scripte die in einem anderen Ordner liegen müssen in ein einziges Script includieren.

Knut

Danke Knut,

Trigger-CP ist ein guter Tip. Hab mich damit mal beschäftigt und funktioniert ja ohne Probleme. Mehr Probleme bereitet mir eher dieser Mist mit den regulären Ausdrücken. Da brauch man ja ein Studium um das abschließend zu verstehen

Na ja, ich beiß mich mal da durch. Beim CP Suche taucht ja das gleiche Problem auf. In den aktuellen Versionen kann man zwar den Schlagtext ausschalten, aber das ist so nicht gewollt, und finde ich auch eher unschön. Ein Textanreißer sollte bei den Ergebnissen schon dabei sein.

Wenn ich ein brauchbares Ergebnis habe poste, werde ich es posten.

Ok, das ist dann doch etwas komplizierter. Bevor lang_replace greift (greifen kann) hat der CP Teaser ja bereits sein Werk erledigt, und das Ergebnis (nämlich den bereits geschnittenen Schlagtext) in der $content['all'] bzw. im CP-HTML generiert. D.h. in der Regel liegt in $content['all'] nur noch der erste Sprachtag vor, da der zweite bereits abgeschnitten wurde.

Beispiel:

Artikeltext:

[DE]Ich bin der Artikeltext[/DE][EN]I am the article text[/EN]

Einstellung Teaser: Schlagtext 3 max. Anzahl Worte (Ob der Sprachtag als Wort gezählt wird ist unwichtig)
Ergibt in der $content['all']

[DE]Ich bin der...

[...] = aus Template bzw. config

Soweit so gut.

Damit die Prüfung per preg_match bzw. preg_replace einfacher wird (zumindest für mich , baue ich im Teaser Template folgendes ein ->
Gerendert wird also:

##SUMMARY_START##[DE]Ich bin der...##SUMMARY_END##

Jetzt prüfe ich per Trigger-CP den Bereich zwischen Start/End ob jeweils ein öffnendes und schließendes Sprachtag vorhanden ist, und ergänze falls nötig. Abschließend noch meine Hilfsmarkierungen raus-preg-matchen und ich erhalte:

[DE]Ich bin der...[/DE]

Toll nicht wahr? Jetzt kann lang_replace seine Arbeit aufnehmen. Der geneigte Leser wird sich jetzt aber zu recht fragen: Prima, bei [lang=DE], aber was ist wenn [lang=EN] gesetzt ist??? Rüchtüüüüch! Der englische Text ist ja bereits am Anfang meiner Ausführungen raus-ge-teasert worden

Dann steht in der generierten Seite:

Da lang_replace bei [lang=EN] alles mit [DE][/DE] raus-ge-preg-replaced hat

Soviel zum Teaser. (Vom CP-Suche sprech ich mal erst gar nicht...)

Hilfe?

Kleiner Nachtrag: Bei der Suche gibt es ein feld "Sprache". Da habe ich mal mit den Tags de, en usw. rumgespielt. Das hat aber auf den ersten Blick iwi keine Auswirkungen, oder aber ich benutze das falsch.

So, ich habe das jetzt für mich in meiner handwerklichen Art und Weise erledigt und die Sprachersetzung einfach in den Core gehauen Hier erfolgt jetzt die Prüfung & Ersetzung der Sprach-Tags immer bevor ein Text vom System gekürzt wird. Die Sprachersetzung der restlichen Seite erfolgt dann weiterhin über die lang_replace.php im frontend_render.

Funktioniert für mich jetzt einwandfrei, auch bei der Suche

Ich bin zwar auch kein Freund davon Core-Files zu hacken, von wegen Update & Pflege, aber eine andere Möglichkeit gibt es wohl derzeit nicht. (Zumindest nicht mit meinen bescheidenden Fähigkeiten)

Ein Frontend-Render Script scheidet grundsätzlich aus, da zum Zeitpunkt wo das greift, die Seite ja schon generiert ist, und nur auf Auslieferung wartet.

Trigger-CP sah vielversprechend aus, aber auch der greift erst, nachdem zumindest der HTML des entsprechenden ContentPart (in diesem Fall Teaser bzw. Suche) ebenfalls bereits fertig zusammengebaut ist.