With fillin enabled, accentuated chars inside meta tags values are printed before the tag itself

[validate/index.yml]
fillin:
	enabled: true
	param:
		name: form01
		content_type: xml

I can confirm, I have the same problem.

As the change history shows, it is also needed to specify a content_type: xml in order to have valid xhtml tags...

Moreover w3c says name attribute is deprecated in xhtml, I saw that using id works fine too, but no doc is available for this

seems to occur only with content_type: xml. the accented char is pulled out of the attribute. in html it also seems as the output escaping is not applied to the head section

reason is that é is a unknown entity for the parser. perhaps this is more a output escaping issue. But http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_Latin-1_characters actually lists it...

got it. this entity is only available externally, your php doesnt know about it. we could "$dom->resolveExternals" but that would result in a hhtp request everytime.

@fabien Fabien, I guess this issue is only resolvable when you can prevent your utf-8 chars in view.yml for the metas to be replaced by htmlentites. HTML entites are externally defined and would require a request every parsing, or ideally people would copy the dtd to a local catalog file. Both solutions are beyond the scope of a simple fix. It would be much simpler to say: only escape special chars in metas, leave entities intact. I can recall seeing a changeset on this, but I dont know if its in sf 1.0

I thought this through again and I see no real backwards compatibility issue. As we encourage to use utf-8 the utf-8 but named entities currently get converted, actually making the html LESS utf-8 as before. This might be tolerated but is not nice. If somebody does not use utf-8 but some standard charset which also has known entities its the same: the result is no longer close to the intended charset. The only "issue" we could have is with people that use utf-8 in their view.yml but want to have the entites encoded. This is not very likely as there are not for every utf-8 char entities that will htmlentities resolve. Those people perhaps already used the entities in their view.yml (which in both cases would result in an ä being converted to ä. Another BC issue might arise from the fact that somebody parses the resulting html in an filter to either correct exactly this error or do something else. Error correction would be fine, because it would no longer trigger as the entities to decode are no longer there, or it just would decode those in htmlentities, but that would actually break the html, thus this is also less likely to be done by someone. The other case is that somebody wants to use a meta to do something, lets say fill the author footer with the author meta. Also in that case it should be no problem as the encoding of the meta dn the footer is on the same page, thus the same encoding.

Summarized: I can see very rare edge cases where backwards compatibility might be hit, and even less cases where it affects more than actually display. And even those might be happy to see that the change makes it better for the page.

@Fabien: if you disagree, please revert the change

(In [9969]) 1.0: changed escaping of metas (and title) from htmlspecialchars to htmlentities to preserve intended encoding. added unit test. aligned to what 1.1 does. as well fixes #2860

(In [9970]) 1.1: added test to check that metas haven't incorrectly escaped. refs #2860

i am very sorry, but this is still open, I missed that the responsible code is inside the sfViewConfigHandler.class.php which still does use the wrong code. Ill continue to check this and hopefully its finally resolved in next release

(In [9982]) 1.0: next shot at #2860. Some code duplication inside the sfViewConfigHandler caused me to overlook the htmlspecialchars that I actually wanted to put in for this ticket. fixes #2860