Feature #19693

Integrate possibility to define additional header data via TypoScript

Added by Oliver Hader almost 11 years ago. Updated about 1 year ago.

Status:
Closed
Priority:
Should have
Assignee:
Category:
Communication
Target version:
-
Start date:
2008-12-11
Due date:
% Done:

0%

PHP Version:
5.2
Tags:
Complexity:
Sprint Focus:

Description

Imagine you've got an extension that shall add a JavaScript and a CSS file to the HEAD part of the HTML document of the current page. This is possible in modifying $TSFE->additionalHeaderData. However, when your extension does not come with a PHP part and consists only of TypoScript, it's not possible.

Thus, this feature request is about to integrate an accordant possibility.

Example:
10 = HEADERDATA
10 {
data = path:EXT:myextension/res/stylesheet.css
wrap = <link rel="stylesheet" type="text/css" href="|" />
prepend = TEXT
prepend.char = 9
}

This would do the following:
  • add the CSS file "stylesheet.css" to the HEAD part of the current document

(issue imported from #M9923)

0009923.patch View (1.02 KB) Administrator Admin, 2008-12-11 20:55

0009923_v2.patch View (1.4 KB) Administrator Admin, 2009-06-25 19:42


Related issues

Related to TYPO3 Core - Bug #20661: [Feature] Add class for render HTML header/footer for BE and FE Closed 2009-06-24

History

#1 Updated by Oliver Hader almost 11 years ago

Documentation changes:

doc_core_tsref, functions, stdWrap:
Property: additionalHeaderData
Data Type: cObject
Description: Adds the cObject to the <HEAD> part of the current document

#2 Updated by Steffen Kamper almost 11 years ago

Hi olly,

This is a nice idea, it allows adding header data depending on defined objects.
+1!

#3 Updated by Johannes von Bargen over 10 years ago

Yeah! That would be cool! I just had a discussion with several people at typo3camp Hamburg about such a possibility.
+1!!!
I am currently working on a extension which integrates jQuery Galleriffic and Galleria into cType Image. That brought the ugly headerData array back to my mind... Additionally it would be cool if headerData was associative and extensions wouldautomatically have a private namespace in the array to add their stuff (the extension key). This way the case where one ext overwrites js /css/meta stuff added by another one would never happen again by accident but otherwise fields of the array could be addressed explicitly if ext B absolutely wants to change something ext A has added.

I think I will open up an own bug for that...

#4 Updated by Vladimir Podkovanov over 10 years ago

+1 for stdWrap.additionalHeaderData

to Johannes von Bargen,
+ 1 for converting page.headerData to assoc array so extension does not bother which numeric keys are used yet. I was running into it too.

#5 Updated by Oliver Hader over 10 years ago

Documentation changes:
add a new entry to "Content Objects (cObject)" (tsref.cObject):

HEADERDATA

HEADER is very similar to the cObject "TEXT". However the result will not be added to the content but to the HTML HEAD section of the page. This can be used to define JavaScript or Stylesheets on an extension level for example.

Property              Data type    Description
value                 string       text, wrap with stdWrap properties
(stdWrap properties)

Example:
10 = HEADERDATA
10 {
  value = script.js
  wrap = <script src="|" type="text/javascript"></script>
}

#6 Updated by Oliver Hader almost 10 years ago

This is solved with the PageRenderer in issue #20661

#7 Updated by Benni Mack about 1 year ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF