Liebes Forum 
ich grübele über diesen Ausdruck:
{include file=„string:{config name=mainfeatures}“}
in checkout/confirm_item.tpl.
Was passiert da ? Was macht das config ? Was macht das string ???
Könnte mir bitte jemand erklären, was da passiert? Ich habe da gar keinen Ansatz…
Liebe Grüße
Kerstin
config holt daten aus einer „Liste“ wo die key/name „mainfeatures“ ist. config name=„shopName“ ist zum Beispiel der Name des Shops in der Grundeinstellung.
ok, danke, und wo finde ich diese Liste ? Oder ist das irgendwo dokumentiert ?
Das ist das “Template für die wesentliche Merkmale” aus den Grundeinstellungen. Du kannst nach dem Namen “mainFeatures” einfach in der s_core_config_elements suchen, dann siehst du wie die Einstellung im Backend heißt.
Ich kline mich mal ein, weil es in etwa die gleiche Frage ist 
[@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski „Moritz Naczenski“)
Kannst Du mir evtl. auch den Fall vom E-Mail Header und Footer erklären?
Die Header und Footer werden zwar in der E-Mail-Config eingetragen, dann in den E-Mails aber auch per include eingebunden.
{include file="string:{config name=emailheaderplain}"}
{include file="string:{config name=emailfooterplain}"}
{include file="string:{config name=emailheaderhtml}"}
{include file="string:{config name=emailfooterhtml}"}
Also werden scheinbar Werte aus der Config als (temporäre) Dateien eingebunden?!?
Ich suche nämlich nach einer Lösung für mein Problem Shopware Issuetracker
@sonic
Habe dir im eigentlichen Thread geantwortet 
Danke Moritz einen Schritt weiter…
Ich würde den Ausdruck gerne verstehen. Ich finde so etwas bei smarty nicht. - Ist das etwas shopwarespeziefisches?
Und ist das irgendwo dokumentiert ?
Woher „weiß“ das Programm z.B., dass es in der Tabelle s_core_config_elements nachschlagen soll? (Und nicht in einer anderen?
Was ist das für ein geheimnisvoller Ausdruck „file“ ? Als ich das zuerst gelesen habe, dachte ich, dieser Ausdruck: „string:{config name=mainfeatures}“
würde den Namen eines files liefern, das dann includiert wird. So scheint es aber nicht zu sein. Aber wie ist es ?
Liebe rüße
Kerstin
Schau mal hier: http://www.smarty.net/docs/en/resources.string.tpl
Ich bin jetzt kein Entwickler. Soweit ich es verstehe führt das {include file=„string:$template_string“} dazu, dass es nur einmal kompiliert wird und ich es an verschiedenen Stellen nutzen kann. Das hat also nichts mit dem Einbinden eines Files zu tun (im Beispiel wird ja auch eine Variable genutzt). Die {config name =…} wird dann eine zusätzliche Funktion sein die den passenden Code aus der config ausließt. Wo genau das gemacht wird, müsste ich auch erst erfragen.
Der “string:” Befehl kannst du die wie “eval” in PHP oder Javascript vorstellen. Der wertet einfach nur den dahinter stehenden Code aus. (Vielleicht etwas verwirrend, weil sie den Befehl wie den Datentyp “String” genannt haben. Bedeutet aber nur, dass Smarty hier den nachfolgenden String als SmartyCode interpretieren soll.)
Warum wurde das so gelöst? {include file="…"} fügt den Inhalt einer bestimmten Datei in das Template ein. Das Problem: Im Parameter file kann ich zwar Variablen* einsetzen allerdings keinen SmartyCode. {config name=""} ist ein Smarty Plugin von Shopware selbst. Es lässt dich - wie oben schon gesagt - die Grundeinstellungen auslesen. Nun funktioniert folgendes jedoch nicht: {include file="{config name=‘xxx’"}, da - wie bereits gesagt - der file-Parameter eine Variable* benötigt. Daher wird jetzt “string:” eingesetzt um den Code auszuwerten.
=> “string:{config name=mainfeatures}” wird ausgewertet zum “/frontend/…” und dann durch {include file="…"} eingebunden.
* ( “Mein Test” wäre auch eine Variable nur in der Kurzschreibweise für Strings)
@simkli
Das kann aber nur die halbe Wahrheit sein. Nehmen wir denn Fall mit den E-Mail Header und Footer.
Ich habe das gerade gegengetestet: Das {config name=emailfooterplain} gibt mir den Inhalt der Config aus, und trägt dieses dann auch so in den E-Mails als Text ein.
Dann müsste SW ja zumindest in den E-Mails das Verhalten von „include“ als Funktion überschreiben.
string:{config name=emailfooterplain} selber kann ich nicht aufrufen, also muss ich den Umweg über eine andere Funktion gehen, also include. Aber warum wird dann der Inhalt ausgegeben und der geparste Wert nicht als Dateiname betrachtet?!?!?!?
Aber das müsste ich dann ja im anderen von Moritz erwähnten Thread diskutieren, obwohl es das gleiche Thema ist
Danke euch beiden !!
In dem Link von Moritz
Schau mal hier: http://www.smarty.net/docs/en/resources.string.tpl
wird beschrieben, dass das „string“ für den „later use“ da ist.
Wie kann man das „later usen“ ? Es gibt doch gar keine Variable oder so.
Liebe Grüße
Kerstin
Aha: “With a string: resource type, each unique string generates a compiled file. Smarty cannot detect a string that has changed, and therefore will generate a new compiled file for each unique string. It is important to choose the correct resource so that you do not fill your disk space with wasted compiled strings.”
Also: string compiliert den übergebenen Wert als Smarty-Template und legt dieses als Cache-Datei ab. Der Dateinamen ist gleich dem Inhalt. Nun guckt Include, ob es schon eine compilierte Version der Datei im Cache gibt, und nimt diese. Das ist der Later-Use, wenn ich also den “Dateinamen” kenne, kann ich die compilierte Datei mehrmals per include einbinden - so verstehe ich das zumindest im Moment
@sonic hat Recht. Dass die „string“-Funktion eine Datei generiert war mir so auch nicht bewusst. Dann kann es sogar sein, dass es möglich ist Smartycode in die Funktionsparamter zu übergeben. Ich kann mich jedoch mal daran erinnern, dass das bei mir nicht geklappt hat.
Die mit der „string“-Funktion generierten Dateien enden dann sogar auf „.string.php“ und haben einen Hash-Wert als Ursprungsdatei angegeben (normalerweise ist das ja immer die entsprechenede .tpl Datei). Falls das jemanden interessiert 
@Kerstin83 genannten string Funktion im ersten Post)
Ist gut und übel zugleich.
[OT]
Wenn Shopware diesen Umweg zum Parsen von Textbausteinen etc. verwenden sollte, und z.B.sich ändernde Werte wie „Namen“, „Adressen“ etc. damit in Textbausteine compiliert werden, muss man sich nicht wundern, dass in manchen Shops der Template-Cache förmlich explodiert. So generierte Werte müssten eigentlich nach dem Seitenaufbau wieder gelöscht werden.
Und das Later-Use geschieht dann so, dass man in dem Beispiel {include file=“string:{config name=mainfeatures}”} einfach nochmals einfügt. Und das wird dann nicht erneut compiliert, weil es ja schon im cache steht ?
Ist das so?
Man muss doch keine Nachforschungen über md5-php-Dateien machen. Soll ja eine Hochsprache sein.
Das cache-Beispiel von sonic war trotzdem interessant…
Liebe Grüße
Kerstin
*Fluch* - jetzt hatte ich gerade so eine schöne Erklärung geschrieben, und die „Vorschau“ hat es gelöscht
Kurzfassung - wenn ich 100% richtig liege - aber Experimente zu meinem E-Mail Problen legen es nahe:
Das „later Use“ bringt Dir nichts, da Du dazu ja den passenden Dateinamen zum Hash benötigen würdest. Hier hast Du dann aber ein Henne-Ei-Problem, da der Dateiname genau der Inhalt wäre. „string“ rendert und liefert das Ergebnis zurück, was include wieder einbindet. Wenn Du später string wieder aufrufst, wird auch wieder gerendert.
Willst Du den gleichen Inhalt in einem Renderdurchgang verwendet, musst Du den Rückgabewert in eine Variable ablegen und die der Include übergeben. Was aber sinnfrei ist, da Include dann die Cache-Datei ausgibt - was aber gleich dem Namen ist.
„Later Use:“
{assign name="meinvar" value=string:{config name="namederconfig"}}
{include file=$meinvar}
irgendwas
{include file=$meinvar}
oder so
{$meinvar}
irgendwas
{$meinvar}
Nach dem finalen Rendern der Seite war es das mit dem „Later Use“ und Du hast Datenmüll im Template-Cache 
Also deine Konstruktion geht bei mir überhaupt nicht (…leider ist ein Fehler aufgetreten).
Weder das:
{assign name="meinvar" value=string:{config name="mainfeatures"}}
{include file=$meinvar}
noch das:
{assign name="meinvar" value=string:{config name="mainfeatures"}}
{$meinvar}
Was aber funktioniert ist einfach wie ich das schon erwähnt hatte:
{include file="string:{config name=mainfeatures}"}
irgendetwas
{include file="string:{config name=mainfeatures}"}
Dann wird es zwei Mal ausgegeben aber nur ein Mal compiliert (im Cache wird es nur 1 Mal angelegt). Ob man allerdings oft exakt den selben code mehrfach braucht ist allerdings fraglich.
Wenn man es mit dem erwähnten “eval” macht, dann wird im Cache entsprechend keine php-Datei angelegt.
Es wird dennoch 2x gerendert. Da das Ergebnis bei gleichem Input aber das gleiche bleibt, wird auch der gleiche “hash” erzeugt und damit die vorhandene Datei überschrieben. “string” weiss vor dem Rendern ja nicht, dass es das schonmal gerendert hat, weil ja ggf. Variablen drin sind. 
Wenn es nicht funktioniert, hab ich wohl einen kleinen Fehler eingebaut Der Wert für “Name” ohne " ggf. dafür aber ggf den ganzen Ausdruck mit " kapseln.
{assign name="meinvar" value=string:{config name=mainfeatures}}
oder
{assign name="meinvar" value="string:{config name=mainfeatures}"}
Edit: Oben ist falsch - evtl. so:
{assign var="meinvar" value=string:{config name=mainfeatures}}
oder
{assign var="meinvar" value="string:{config name=mainfeatures}"}
oder
{assign "meinvar" "string:{config name=mainfeatures}"}
Also bei mir geht das alles nicht. 
Hast du es mal getestet?
Ob es ein zweites Mal gerendert wird ? - Man weiß es nicht. Vielleicht gibt es ja eine Abfrage, ob die Datei schon existiert o. ä. Ist ja auch nicht entscheidend. Was in der Beschreibung steht ist, dass der Cache-Platz dadurch gespart wird. Und so ist es ja auch.
Es steht doch in der Anleitung zu Smarty - oben zitiert
Smarty cannot detect a string that has changed, and therefore will generate a new compiled file for each unique string.
Keine Ahnung, warum es bei Dir nicht funktioniert. Ich habe es in der Form mit meiner E-Mail vorlage gemacht, und da hat es funktioniert - mir aber beim Problem nicht geholfen. bin es halt 2x ein - ich guck mir das am WE nochmal an - wo der Fehler ist
Edit: Mein Fehler: Im assign wird der Variablenname nicht per „name“ sondern per „var“ festgelegt *verschämt gucken tu*