Project

General

Profile

Actions

Feature #20619

closed

extension key namespaces in headerData

Added by Johannes von Bargen over 15 years ago. Updated about 11 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2009-06-15
Due date:
% Done:

0%

Estimated time:
PHP Version:
4.3
Tags:
Complexity:
Sprint Focus:

Description

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... It would be cool if headerData was associative and extensions would automatically 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. For example tt_news could add its own meta-description, meta-author and overwrite the things brought by tt_content. Stuff added to the head should be put out sorted by tag-type simply for clean nice-looking HTML code.

Let me point this out in with some pseudo HTML code

head

meta blabla /
meta lululu /
meta brrrr /

link type="text/css" href="path/to/file/one" /
link type="text/css" href="path/to/file/two" /
link type="text/css" href="path/to/file/three" /

script type="javascript" src="path/to/file/one" ... /script
script type="javascript" src="path/to/file/two" ... /script
script type="javascript" src="path/to/file/three" ... /script

// space for stuff included the old way (old extensions)
// here the usual wild-west-code would show up

/head

Greetings to all Typo3Camp Hamburg people!

There already is an issue plus patch which adds a function to simply add something to headerData without having to specify a field number which prevents the overwriting issue. This leaves open the changeability after something has been added since you don't know the "address".

Issue #0009923
(issue imported from #M11333)

Actions #1

Updated by Alexander Opitz over 11 years ago

  • Status changed from New to Needs Feedback
  • Target version deleted (0)

The issue is very old, does this issue exists in newer versions of TYPO3 CMS (4.5 or 6.1)?

Actions #2

Updated by Alexander Opitz about 11 years ago

  • Status changed from Needs Feedback to Closed

No feedback for over 90 days.

Actions

Also available in: Atom PDF