TYPO3 Core

This is a duplicate of #0012424. But #0012424 does not have a patch.

The example shown above should not work even with stdWrap added to additionalHeaders, because the syntax would be wrong due to stdWrap not being a fully fledged $this->cObj->cObjGetSingle:

This should be enough to just get a typolink (without any linked text)

config.additionalHeaders {
typolink.parameter = YY
typolink.returnLast = url
wrap = Location: {$config.baseURL}|
}

and if you wanted the parameter to behave as a TEXT object, you should do it like that:

config.additionalHeaders.cObject = TEXT
config.additionalHeaders.cObject {
value = Something
typolink.parameter = YY
typolink.returnLast = url
wrap = Location: {$config.baseURL}|
}

no need to put any stdWrap in between (like additionalHeaders.stdWrap.blah), because it would be enough to just make the parameter stdWrap-aware itself.

same for page.config.additionalHeaders and of course same for any other parameter that will gain stdWrap functionality in 4.5

But this hasn't happened unfortunately, sorry Rik. Postponing it to 4.6 then.

As far as I remember we decided not to touch the config parameters with stdWrap, since they are top level objects that don't belong to tslib_content directly.

Another reason was, that config parameters like baseURL are used by extensions that would not be able to handle stdWrap this way (i.e. realURL)

If I remember correctly it was undecided. Some people said not to use stdWrap in config others pointed out that it could be valuable.

Adding additionalHeaders as a property of the PAGE object. Would that be an idea?

Yes, I think that wouldn't touch the "holy .config" and have an implementation in a place where you can be sure that a valid cObject is available (also loaded with the current's page $row in ->data).

Thanks Rik!

Ok cool. I'll look into this.

Ok, I dove into this a little. But, this deep I've never been. I noticed that the page is generated first, after which processOutput() in tslib_fe outputs header info.
Can you give a hint on where to implement this feature if I do it trough the PAGE object.

Is there any new information on this?
I would really like to see this feature implemented, regardless wether in the CONFIG or PAGE object.

I can hardly bear that the only way to redirect a visitor dynamically with the allmighty TypoScript is by using meta.refresh ... :-(

I assume there is no news on this issue - i'm stuck with the same Problem, i want to redirect - but meta refresh is a litte clumsy solution

In case there is no other option that is being overlooked here, I'd also strongly vote for stdWrap option here.

I vote for this feature too because it would be very useful to redirect to a login page with adding the referrer when an user visits restricted pages without being logged in.

[PIDinRootline = 123,321] && [loginUser = ]
    page.config >
    page.config.additionalHeaders = TEXT
    page.config.additionalHeaders {
        data = getIndpEnv:TYPO3_REQUEST_URL
        wrap = {$config.baseURL}/login/?referer= |
    }
[end]

May I vote for this feature, too? :o) +1

It's very senseful for dynamic shortcuts - in my case for QR-Codes on real-world products.

I would like to have something like this (not working, of course...):
page.config.additionalHeaders.dataWrap = Location: http://www.asdfghj.de/index.php?id={field:shortcut}&utm_source=Verpackungen&utm_medium=Mobile&utm_term=abc&utm_campaign=QR-Code |

-> for Google Analytics

Vote for this too.

Struggling with a basic login/redirect scheme and this would solve it.

Voting for this too

Feature was merged. Now let's add stdWrap! :)

+1 for stdWrap!

On the way ...

config.additionalHeaders {
  10.header = foo:
  10.header.dataWrap = |{page:uid}
}

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/50142

Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/50142

Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/50142

Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/50142

Patch set 6 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/50142

Hi,

Sorry, I'm not hugely familiar with this process.. if implemented, in which versions will it be? Only in 8.x or by any chance in 7.6?

Hello Thomas,

It will not be in any of these versions, because it is not merged yet. Because it is a new feature, it can only be merge to master (see Releases line). That means, it will appear in a version of TYPO3 9.x (if merged at all).

If you want this feature to appear in future TYPO3 version, then please test the change and leave a review note on the review server.
https://docs.typo3.org/typo3cms/ContributionWorkflowGuide/

Patch set 7 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/50142

Patch set 8 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/50142

Patch set 9 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/50142

If it is rejected it is not reverted, it just never will be done. So why closing it?

Reverted with #86492 (https://review.typo3.org/58517) I guess. Am I wrong?