Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Page_Header_MetaViewHelper should override existing meta tags #319

Closed
leonderijke opened this issue Sep 12, 2013 · 5 comments
Closed

Page_Header_MetaViewHelper should override existing meta tags #319

leonderijke opened this issue Sep 12, 2013 · 5 comments

Comments

@leonderijke
Copy link

I'm not sure if this could be fixed in this project or it should be fixed in the TYPO3 Core, but here are two very similar problems:

Problem 1

Added meta tags are not overridden but instead added to the page.

Fluid template:

<v:page.header.meta name="test" content="Test 02"></v:page.header.meta>
<v:page.header.meta name="test" content="Test 03"></v:page.header.meta>

Output:

<meta name="test" content="Test 02" />
<meta name="test" content="Test 03" />

Problem 2

Furthermore, if a meta tag is already set by TypoScript, both are added to the page.

TypoScript:

page.meta.test = Test 01

Fluid template:

<v:page.header.meta name="test" content="Test 02"></v:page.header.meta>
<v:page.header.meta name="test" content="Test 03"></v:page.header.meta>

Output:

<meta name="test" content="Test 02" />
<meta name="test" content="Test 03" />
<meta name="test" content="Test 01" />
@bjo3rnf
Copy link
Contributor

bjo3rnf commented Sep 21, 2013

Hi @leonderijke,

the thing is that the viewhelper calls $GLOBALS['TSFE']->getPageRenderer()->addMetaTag(); to add a full blown tag and thus doesn't only take the name argument into account to determine if it has already been added. This is also why tags added via TS would get overwritten only if they are identical re. name and content. Maybe there's another way to add meta tags to have them processed by TYPO3 at an earlier stage.

Cheers
Björn

@cedricziel
Copy link
Member

There is no other way. The only exit-lane is to add Raw-Header-Data. But I would also discourage this.

This is a candidate for a Core Bug, as the PageRenderer only checks for exact clones (Ref: http://typo3.org/api/typo3cms/class_t_y_p_o3_1_1_c_m_s_1_1_core_1_1_page_1_1_page_renderer.html#a2adb3104adcf5892b61f8cd8bc200fc7 ) This could have been fixed by now in current master.

Anyways-this is not our part to fix the core behaviour here ;)

Thank you for reporting it. I take the liberty to close it-but we can of course further discuss it, if you're not convinced., or need to. :-)

@leonderijke
Copy link
Author

Thanks, I understand why this can't be fixed in VHS.

This is a candidate for a Core Bug (...) This could have been fixed by now in current master.

What do you mean? There isn't a Core Bug for this in Forge currently, is there? Maybe we should add it then.

@cedricziel
Copy link
Member

Hi @leonderijke ,

Sorry for being unclear: If that one is not fixed in current HEADs of 4.7 6.0, 6.1 or in master (6.2)-would you please file a bug on forge? (Maybe post the link here afterwards, so we can follow)

Thank You,
Cedric

@leonderijke
Copy link
Author

I filed a bug on Forge: http://forge.typo3.org/issues/52471

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants