Here are a few lines of TypoScript code that really took me a long time to get to.
In TYPO3 4.x, I would fetch an image which is inserted on a certain page as a normal content element (CE) and use it for example as an site wide header image.
In this example, the image in question is located in the backend column 'left' (id 1) on the root page of the site, the PID of that page is stored in a TS-variable {$home_dir}, since I change it further down the page tree via TS-constants.
TYPO3 4.x
temp.headerimg < styles.content.getLeft temp.headerimg { select { pidInList = {$home_dir} max = 1 } renderObj = IMAGE renderObj { file.import.field = image file.import = uploads/pics/ stdWrap.typolink.parameter = {$home_dir} } } |
With TYPO3 6.2, this won't work, since the image/file handling has fundamentally changed with the introduction of the FAL (file abstraction layer). I had lots of funny effects before I arrived at this working solution:
TYPO3 6.2
temp.headerimg < styles.content.getLeft temp.headerimg { select { pidInList = {$home_dir} max = 1 } renderObj = FILES renderObj { references { table = tt_content fieldName = image uid.data = uid } renderObj = IMAGE renderObj { file.import.data = file:current:originalUid // file:current:uid stdWrap.typolink.parameter = {$home_dir} } } } |
The above works and enables you to turn off the fallback "contentAdapter" in the Install Tool, which, if enabled, makes sure that your legacy 4.x TypoScript will work, but slows down the FE rendering quite a bit, and TYPO3 will make sure to remind you of this fact if you have a look at the "reports" tool in the back end.
Since I didn't find this use case (content image, not page:media image) and the according TypoScript anywhere, maybe this is of some help to others.
Eine Reaktion zu “TYPO3 6.2 content image in Typoscript”
(Mittlerweile ist es gelöst, siehe Update(s) weiter unten)
Ok, ich geb’s auf.
Ich probiere nun seit Tagen, auf einer aus 4.7 aktualisierten TYPO3 6.2 Version von dem
contentAdapter=1
weg zu kommen, um in den vollen Genuss der TYPO3 Frontend-Performance zu kommen und die Seite, bzw meine alten TypoScripte, zukunftssicher zu bekommen.Wieder einmal stehe ich vor einem (TYPO3)rätsel, in dem eine auf den ersten Blick total simple Anforderung auch im x-ten Anlauf nicht funktionieren will.
Die Ausgangslage
Ich habe auf der der Root-Seite der Webseite einen normalen, vom Redakteur pflegbaren Content-Record vom Typ Image, in der Backend-Spalte mit der
ID=1
.Ich möchte dieses Bild auch auf den Unterseiten verwenden und nutze es dazu, ein Header-Motiv auf der Seite darzustellen.
Mein bislang funktionierender TS-Code ist dieser:
temp.headerimg = COA
temp.headerimg {
10 < styles.content.get
10.select {
where = colPos=1
pidInList = {$home_dir}
max = 1
}
10.renderObj = COA
10.renderObj {
5 = IMAGE
5 {
file.import.field = image
file.import = uploads/pics/
stdWrap.typolink.parameter = {$home_dir}
}
}
}
}
wobei
{$home_dir}
eine per TS-Konstante gefüllte Variable mit der PID der “Home”-Seite der jeweiligen Webseite ist.Das funktionierte in TYPO3 4.7 und funktioniert auch in TYPO3 6.2, solange der contentAdapter gesetzt ist.
Sobald ich den contentAdapter ausschalte, das IMAGE renderObj um
file.treatIdAsReference=1
erweitere und dasfile.import=uploads/pics/
rausnehme, wird statt des erwarteten Header-Motivs ein Bild ausfileadmin/_migrated_
genommen, dessen ID in der sys_file_records-Tabelle die ID 1 hat. Äh, ja.Ich habe mittlerweile so ziemlich alles an Tutorials und Manuals zu TYPO3 und FILES und References und so gelesen, aber ich habe keine funktionierende TypoScript-Anweisung zusammengebastelt bekommen, die dieses SUPEREINFACHE Usecase hinbekommt.
Ich glaube, ich bin einfach zu blöd für TYPO3 6.2 — oder es hat irgendwas bei dem Update ausgerechnet dieser Seite zerhauen, und die File-Reference ist kaputt.
Glaube ich allerdings nicht, denn auch mit abgeschaltetem contentAdapter sind alle “normalen” Content-Records, die per styles.content.get “geholt” werden, richtig.
Es liegt also wohl doch an meiner Unfähigkeit, hier ein passendes TypoScript zu finden.
Nachdem der vermeindlich einfache Ansatz, nur dem IMAGE mitzuteilen, dass es doch bitte eine Referenz benutzt, nicht geklappt hat, war mein vorerst letzter Ansatz, das komplette renderObj statt IMAGE zu FILES zu machen — aber auch das funktioniert nicht, obwohl nach meinen Debug-Ausgaben die UID für das Reference-Ding korrekt ankommt.
...
10.renderObj = FILES
10.renderObj {
references {
table = tt_content
fieldName = image
uid = uid
}
renderObj = IMAGE
renderObj {
file.import.data = file:current:uid
file.treatIdAsReference=1
stdWrap.typolink.parameter = {$home_dir}
}
}
...
Es wäre ausserordentlich großartig, wenn da vielleicht jemand mit mehr Durchblick mir mal einen Tip oder zwei geben könnte, danke. Wahrscheinlich ist es ein saudummer offensichtlicher Fehler, der mir da unterläuft, aber ich finde es einfach nicht. :-/
Update 7.4.15, 18:50h:
Gerade eben nach dem Runtertippen der Codes hatte ich die Eingebung, dass das mit dem renderObj im renderObj vielleicht keine so gute Idee ist und habe es auf ein cObject abgeändert:
...
10.cObject = FILES
10.cObject {
references {
table = tt_content
fieldName = image
uid = uid
}
renderObj = IMAGE
renderObj {
file.import.data = file:current:uid
file.treatIdAsReference=1
stdWrap.typolink.parameter = {$home_dir}
}
}
...
Nach der ersten Freude, dass das Headerbild weiterhin erscheint (mit der dopplelten renderObj Variante war gar kein Bild sichtbar), kam jedoch schnell die Ernüchterung nach Ausschalten des contentAdapters: Jetzt ist wieder das falsche Bild, wie oben beschrieben, zu sehen. :-(
Update – 7.4.15 22:30h
Ha. Ha!! Haaaa!!! Isch werd’ verüggd, nu geehds!!!
temp.headerimg = COA
temp.headerimg {
10 < styles.content.get
10.select {
where = colPos=1
pidInList = {$home_dir}
max = 1
}
10.renderObj = FILES
10.renderObj {
references {
table = tt_content
fieldName = image
uid.data = uid
}
renderObj = IMAGE
renderObj {
file.import.data = file:current:publicUrl
stdWrap.typolink.parameter = {$home_dir}
}
}
}
Das geht bestimmt noch etwas eleganter, aber zumindestens kommt jetzt endlich das richtige Bild im Frontend an – auch mit ausgeschaltetem contentAdapter. Danke an @benjaminkott, der mit seinem gist einige Lämpchen in meinem Oberstübchen angeknipst hat, sowie @faulancr, der beiläufig in einer dm erwähnte, dass das
treadIdAsReference
bei einem Content-Element doch gar kein Sinn machen würde. Danke!So, und hier noch eine etwas verschlanktere Version des TypoScript-Codes:
temp.headerimg < styles.content.getLeft
temp.headerimg {
select {
pidInList = {$home_dir}
max = 1
}
renderObj = FILES
renderObj {
references {
table = tt_content
fieldName = image
uid.data = uid
}
renderObj = IMAGE
renderObj {
file.import.data = file:current:publicUrl
stdWrap.typolink.parameter = {$home_dir}
}
}
}
Update 8.4.15, 10:10h:
Eben bekam ich noch einen Tip aus dem TYPO3 slack channel:
Ich habe das TS entsprechend abgeändert und tatsächlich funktioniert das. Also:
temp.headerimg < styles.content.getLeft
temp.headerimg {
select {
pidInList = {$home_dir}
max = 1
}
renderObj = FILES
renderObj {
references {
table = tt_content
fieldName = image
uid.data = uid
}
renderObj = IMAGE
renderObj {
file:current:originalUid // file:current:uid
stdWrap.typolink.parameter = {$home_dir}
}
}
}
Ich schreibe den Start- und End-Typoscript-Code gleich nochmal in einem englischen Artikel zusammen, ohne die Prosa dazwischen. Und ja, oben genannten Use-Case könnte man auch und vielliecht sogar besser mit einem Bild im Page Media Feld abhandeln; allerdings ist ein Bild, was sich per “normalem” Content-Element vom Redaktuer pflegen lässt, für diesen erstmal einfacher, als über die Seiteneigenschaften -> Medien zum Bild zu gelangen.
Kommentare sind geschlossen.