Du bist nicht angemeldet. Der Zugriff auf einige Boards wurde daher deaktiviert.

#1 14. Januar 2022 16:05

Andynium
Moderator
Ort: Dohna / SN / Deutschland
Registriert: 13. September 2010
Beiträge: 7.014
Webseite

[CMS V1] AdvancedContent und Lokalisierung benutzerdefinierter Blocktypen

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

Offline

#2 14. Januar 2022 17:55

NaN
Moderator
Ort: Halle (Saale)
Registriert: 09. November 2010
Beiträge: 4.409

Re: [CMS V1] AdvancedContent und Lokalisierung benutzerdefinierter Blocktypen

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.

	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.


Module: GBFilePicker, AdvancedContent
Sicherheit: Beispiel .htaccess-Datei
CMSms 1.12.2 unter PHP 7:
cmsms-1.12.2-php7.2-diff.tar.gz (nur die geänderten Dateien)
cmsms-1.12.3.zip (inoffiziell - komplett inkl. Installer)

Offline

#3 18. Januar 2022 16:29

Andynium
Moderator
Ort: Dohna / SN / Deutschland
Registriert: 13. September 2010
Beiträge: 7.014
Webseite

Re: [CMS V1] AdvancedContent und Lokalisierung benutzerdefinierter Blocktypen

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

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)

Offline

#4 19. Januar 2022 17:40

Andynium
Moderator
Ort: Dohna / SN / Deutschland
Registriert: 13. September 2010
Beiträge: 7.014
Webseite

Re: [CMS V1] AdvancedContent und Lokalisierung benutzerdefinierter Blocktypen

Andynium schrieb:

Ich hatte zum Ausprobieren im Seiten-Template

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 ...

Offline

#5 19. Januar 2022 21:22

NaN
Moderator
Ort: Halle (Saale)
Registriert: 09. November 2010
Beiträge: 4.409

Re: [CMS V1] AdvancedContent und Lokalisierung benutzerdefinierter Blocktypen

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.


Module: GBFilePicker, AdvancedContent
Sicherheit: Beispiel .htaccess-Datei
CMSms 1.12.2 unter PHP 7:
cmsms-1.12.2-php7.2-diff.tar.gz (nur die geänderten Dateien)
cmsms-1.12.3.zip (inoffiziell - komplett inkl. Installer)

Offline