[CMS V1] AdvancedContent und Lokalisierung benutzerdefinierter Blocktypen

Andynium · 14. Januar 2022 16:05

Moin,

Hat AC eine Schnittstelle für die Lokalisierung von benutzerdefinierten Blocktypen hinterlegt?

Hab in der API dazu nix gefunden... und noch nicht die Zeit gehabt, den kompletten Code zu checken ops

NaN · 14. Januar 2022 17:55

Nö hat es noch nicht.
Du könntest aber, wenn Du schon benutzerdefinierte Blocktypen hast, im Constructor eine Eigenschaft namens "localize_label" (bool) hinzufügen.
Wenn true, dann in der Methode GetProperty() den Rückgabewert vorher mit der Lang() Funktion übersetzen.

Hier klicken, um den Code zum Kopieren zu markieren

	function __construct(&$content_obj, $params = array())
	{
		parent::__construct($content_obj, $params);
		...
		$this->params['localize_label'] = isset($params['localize_label']) && Utils::get_instance()->IsTrue($params['localize_label']);
	}
	
	public function GetProperty($name, $default = '')
	{
		$prop = parent::GetProperty($name, $default);
		if($name == 'label' && $this->params['localize_label'])
		{
			$AC   = &\cms_utils::get_module('AdvancedContent');
			$prop = $AC->Lang($prop);
		}
		return $prop;
	}

Code ist für die AC Version aus dem SVN branch für die 2.0.
Wenn Du eine andere Version nutzt, dann statt der Utils Klasse die Klasse ac_utils verwenden.

Dann kannst Du via module_custom eine eigene Sprachdatei für AC anlegen und jedes Label übersetzen.
Habs noch nicht getestet, aber das ginge vielleicht sogar ohne PHP nur übers Template.
Weiß aber gerade nicht, ob die Backend-Templates nicht doch irgendwie gecached werden.

Andynium · 18. Januar 2022 16:29

Danke für die Anregung.

Ich bin mit meinen Überlegungen gerade an der Stelle, mein Ziel ohne eigenen Blocktypen zu erreichen.

Das Ziel soll sein, mittels AC sowie den Parametern smarty="true" und default=":::test:::" die Felder im Backend vorzubelegen, konkret mit den Metadaten einer Abfrage der YouTube API (Titel, Release-Datum, Beschreibung, Laufzeit, Thumbnail).

Gibt es eine Möglichkeit, die einmal durch die API-Abfrage ermittelten Werte an andere Inhaltsblöcke weiterzureichen?

Ich hatte zum Ausprobieren im Seiten-Template

Hier klicken, um den Code zum Kopieren zu markieren

{$test = 'Testtext'}

eingetragen und dann default=":::$test:::" ausprobiert. Output war (leider nur)

.((string)->tpl_vars['test']->value).

Als UDT mit default=":::test:::" und als GCB mit default=":::global_content name='test':::" hingegen funktioniert es.

Würde aber im Ergebnis 5 API-Abfragen pro Seite bedeuten, was ich gern vermeiden möchte...

Beitrag geändert von Andynium (18. Januar 2022 17:01)

Andynium · 19. Januar 2022 17:40

Andynium schrieb:

Ich hatte zum Ausprobieren im Seiten-Template
Hier klicken, um den Code zum Kopieren zu markieren
{$test = 'Testtext'}
eingetragen und dann default=":::$test:::" ausprobiert. Output war (leider nur)
.((string)->tpl_vars['test']->value).

Ein default=":::eval var=$test:::" hat wie vermutet das gleiche Ergebnis gebracht monkey ...

NaN · 19. Januar 2022 21:22

Warst lange nicht mehr damit beschäftigt, hm? tongue

Hat mit AC nichts zu tun.
Liegt an Smarty und wie es in CMSms eingebunden wird.

Smarty wird doch in mehreren Stufen ausgeführt.

Stufe eins: Parsen.
Lies das Template, suche nach Smarty Tags und mach PHP-Code draus.

Stufe zwei: Rendern.
Führe den PHP-Code aus.

Logischerweise brauchen wir im Backend Stufe zwei überhaupt nicht. Wir wollen nichts rendern. Deshalb wird Smarty im Backend auch anders eingebunden als im Frontend. Da wird das Seitentemplate nur geparst, aber nicht gerendert.

D.h. ((string)->tpl_vars['test']->value) ist exakt das, was nach Stufe eins an AC als Parameter übergeben wird. Damit kann aber zu diesem Zeitpunkt weder AC noch Smarty etwas anfangen. Auch nicht mit Eval. Weil das ein Stück Code ist, das völlig aus dem Kontext gerissen ist. Das macht nur im Zusammenhang mit dem kompletten Seitentemplate Sinn.

Noch dazu kommt, dass das zwei verschiedene Templates sind, die nichts voneinander wissen.
Das eine ist das Seitentemplate.
Dort wird die Variable $test definiert.
Die im Smarty Cache kompilierte in PHP-Code übersetzte Notation von {$test} ist ((string)->tpl_vars['test']->value) . Ausgeführt und mit entsprechendem Rückgabewert ausgegeben wird das aber erst dann, wenn das Template gerendert wird. Das passiert aber erst im Frontend.

:::$test::: ist ein völlig eigenständiges Template, das nichts mit dem Seitentemplate zu tun hat und demnach auch nicht auf dessen Variablen zugreifen kann. Smarty weiß bis zu diesem Zeitpunkt noch nichtmal dass :::$test::: überhaupt ein Template ist. Das weiß es erst nach Auslesen der Parameter und Ändern von ::: in geschweifte Klammern. Bis dahin ist das für Smarty einfach nur Text. Das sind schlicht verschiedene "Prozesse".

Verschachtelte Smarty-Tags sind meines Wissens erst ab einer neueren Smarty Version in CMSms 2.0 möglich.

Du kannst an dieser Stelle also nur den Rückgabewert eines Plugins oder UDts verwenden, aber keine Templatevariable.

EDIT:

Ich überlege gerade, ob das nicht endlich mal ein prima Szenario für cms_utils::set_app_data() / cms_utils::get_app_data() wäre. Dort soll man ja irgendwie systemweit Daten teilen können. (wie eine globale Variable)

D.h. Du prüfst in Deinem Plugin zuerst mit cms_utils::get_app_data('my_api_call'), ob das Resultat dieser API-Abfrage schon vorhanden ist. Wenn nicht -> API Abfrage durchführen und Resultat mit cms_utils::set_app_data('my_api_call', $result) für weitere Verwendungen speichern.

Was Du auch noch machen könntest, wäre das Resultat des API-Calls in einer Session-Variable zu speichern. Hätte den Vorteil, dass es nicht bei jedem Seitenaufruf erneut abgefragt wird.

Andynium · 22. Januar 2022 11:29

NaN schrieb:

Warst lange nicht mehr damit beschäftigt, hm?

Sehr sehr lange hmm

NaN schrieb:

Logischerweise brauchen wir im Backend Stufe zwei überhaupt nicht. Wir wollen nichts rendern. Deshalb wird Smarty im Backend auch anders eingebunden als im Frontend. Da wird das Seiten-Template nur geparst, aber nicht gerendert.

Vermutlich liegt dort mein Denkfehler.

Ich bin davon ausgegangen, dass dadurch, dass die Modul-Backends via Smarty generiert werden, $test auch im AC Backend verfügbar ist, da ja das Seiten-Template dafür eingelesen werden muss. Mir war nicht bewusst, dass es sich sozusagen um zwei verschiedene Smarty Sitzungen handelt.

NaN schrieb:

Verschachtelte Smarty-Tags sind meines Wissens erst ab einer neueren Smarty Version in CMSms 2.0 möglich.

Funktioniert in der 1.12.3 auch - verwende in meinem aktuellen Projekt dies

Hier klicken, um den Code zum Kopieren zu markieren

{DownCnt sid={$mpkg}}

Ohne Probleme. Oder meintest du etwas anderes?

NaN schrieb:

Was Du auch noch machen könntest, wäre das Resultat des API-Calls in einer Session-Variable zu speichern. Hätte den Vorteil, dass es nicht bei jedem Seitenaufruf erneut abgefragt wird.

Diese Variante ist mir die sympathischste - mit der CMS/ms API steh ich momentan etwas auf Kriegsfuß, wie du bereits erkannt hast tongue .

Kann ich dafür die CMS/ms Backend Session nutzen? Oder sollte ich lieber eine eigene Session-Variable erstellen?

Beitrag geändert von Andynium (22. Januar 2022 11:32)

NaN · 22. Januar 2022 14:04

Funktioniert in der 1.12.3 auch - verwende in meinem aktuellen Projekt dies
Hier klicken, um den Code zum Kopieren zu markieren
{DownCnt sid={$mpkg}}
Ohne Probleme. Oder meintest du etwas anderes?

Nö, genau das meinte ich.
Dachte, das kam erst später.
Bringt aber in Deinem Fall auch kein Ergebnis.
Da steht bei mir dann nur "$_tmp1"

Kann ich dafür die CMS/ms Backend Session nutzen? Oder sollte ich lieber eine eigene Session-Variable erstellen?

Ich würd die Backend-Session nutzen.
Aber Du brauchst da keine API für.
Du kannst einfach auf die Superglobale Session-Variable $_SESSION zugreifen.
Denn eine Session wird im Backend ja so oder so gestartet.
Bsp UDT:

Hier klicken, um den Code zum Kopieren zu markieren

if(!isset($_SESSION['my_var'])) 
    $_SESSION['my_var'] = 'FOO!';
return $_SESSION['my_var'];

Ich stelle aber gerade wieder ein altes Problem fest.
Beim Wechsel zwischen den Inhaltstypen kommt es unter PHP 7.4 zu Fehlermeldungen.
Außerdem kommt es auf die Reihenfolge an, in der man zum Inhaltstypen wechselt.
Wechselt man von Content auf AdvancedContent, werden die Inhaltsblöcke nicht erneut aus dem Template ausgelesen und somit auch das Smarty-Zeugs nicht ausgeführt. Der nimmt stattdessen alles aus dem Serialisierten Objekt was da via Post mitgeschleift wird. (Nope: der nimmt die Werte wie sie in den Inputfeldern stehen, muss also beim Befüllen der Inputfelder nochmal prüfen, ob die verarbeitet werden müssen) Man muss also anschließend nochmal kurz das Template wechseln.

Hatte das zwar alles schonmal behoben, aber leider kurz vor Weihnachten massiven Datenverlust erlitten. Im SVN ist alles was ich dazu als "backup" habe. Und das ist leider nicht die aktuellste Version.

NaN · 22. Januar 2022 17:02

Nachtrag: Hab gerade gesehen, dass ich den Parameter "translate_labels" und "translate_values" bereits eingebaut hatte. D.h. Alles was man zum Übersetzen der Labels braucht ist eine Custom Lang Datei.
Das Label ist dann einfach der Index des Lang-Arrays.

Hier klicken, um den Code zum Kopieren zu markieren

[== smarty template ==]
{content label="halligalli" translate_labels="true"}

Hier klicken, um den Code zum Kopieren zu markieren

[== lang datei ==]
<?php
$lang['halligalli'] = "Inhalt";

NaN · 24. Januar 2022 17:19

Die benannten Fehler sollten im SVN behoben sein.
Hab auch gleichzeitig versucht, Kompatibilität für PHP 8.1 herzustellen.
Bringt aber erstmal nicht viel, weil CMSms 1.12.3 noch nicht unter PHP 8.1 läuft ...

Forum für CMS/made simple

#1 14. Januar 2022 16:05

[CMS V1] AdvancedContent und Lokalisierung benutzerdefinierter Blocktypen

#2 14. Januar 2022 17:55

Re: [CMS V1] AdvancedContent und Lokalisierung benutzerdefinierter Blocktypen

#3 18. Januar 2022 16:29

Re: [CMS V1] AdvancedContent und Lokalisierung benutzerdefinierter Blocktypen

#4 19. Januar 2022 17:40

Re: [CMS V1] AdvancedContent und Lokalisierung benutzerdefinierter Blocktypen

#5 19. Januar 2022 21:22

Re: [CMS V1] AdvancedContent und Lokalisierung benutzerdefinierter Blocktypen

#6 22. Januar 2022 11:29

Re: [CMS V1] AdvancedContent und Lokalisierung benutzerdefinierter Blocktypen

#7 22. Januar 2022 14:04

Re: [CMS V1] AdvancedContent und Lokalisierung benutzerdefinierter Blocktypen

#8 22. Januar 2022 17:02

Re: [CMS V1] AdvancedContent und Lokalisierung benutzerdefinierter Blocktypen

#9 24. Januar 2022 17:19

Re: [CMS V1] AdvancedContent und Lokalisierung benutzerdefinierter Blocktypen

Fußzeile des Forums