Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hi,
currently drupal hardcodes the http-equiv Content-Type to text/html in includes/common.inc
Can you please add support for other content types like for instance application/xhtml+xml?
Right now the user could still change it in THEME_preprocess_page()
with some ugly string replacement, but that isn't even always possible (in D6) like stated in #451304: Drupal outputs two meta content-type tags.
Thanks,
Antonio
Comment | File | Size | Author |
---|---|---|---|
#2 | drupal_support_preferred_content_types_d7_v1.patch | 2.02 KB | ao2 |
Comments
Comment #1
ao2 CreditAttribution: ao2 commentedWill something alog the lines of [#56733] (link here) be accepted?
Another way of doing it here.
Some more references here.
I mean, also the real http header sould be set appropriately, not only the http-equiv meta element, right?
Regards,
Antonio
Comment #2
ao2 CreditAttribution: ao2 commentedA rough patch to show the basic idea is attached, it has been tested with FF and IE and no trivial problems showed up.
It needs to be improved to support client-side preference as in the references above and to get better integration and provide an API to set the content type the theme prefers to be served with. But here I need some help.
Comments?
Regards,
Antonio
Comment #3
ao2 CreditAttribution: ao2 commentedChanging the status.
Comment #4
ao2 CreditAttribution: ao2 commentedJust a supportive argument for adding this functionality: it helps to spot bad-formed output which pass unnoticed with text/html, you can see examples in #478856: Unterminated entities in taxonomy module break page validation. and #478908: SEO checklist output is not valid..
Thanks,
Antonio
Comment #5
ao2 CreditAttribution: ao2 commentedSome more references:
Also, my current patch breaks ajax in drupal, maybe because of jquery using
document.write
and friends? I'll post an update as soon as I figure out how to solve that.Comment #6
gaele CreditAttribution: gaele commentedYou can use
drupal_set_header('Content-Type: application/xhtml+xml');
in e.g. template.php. This will replace the default text/html header.
Then change the http-equiv from page.tpl.php.
Comment #7
apadernoThe hard-coded value has been added to avoid issues in the case a theme doesn't set it; for what I remember, the problem is not setting the encoding to UTF-8.
I am looking for the issue reported about that for another report; I will add here the link.
Comment #8
Damien Tournoud CreditAttribution: Damien Tournoud commentedGiven the amount of Javascript that
application/xhtml+xml
breaks, it's safe to bump that to D8. By the time D8 is released, HTML5 will probably have taken off, which will make this feature request moot.Comment #9
ohnobinki CreditAttribution: ohnobinki commented+1
XHTML doesn't seem worth it unless if the browser is actually interpreting the pages as XML and following standards instead of using quirks mode. Drupal appears to be ``half compliant'' which really means no compliance.
Also, jQuery().html() breaks with application/xhtml+xml.
Comment #10
kabarca CreditAttribution: kabarca commentedYou can use the php str_replace() function to replace the string. See the example below that changes
Comment #11
ohnobinki CreditAttribution: ohnobinki commentedtag
Comment #12
ohnobinki CreditAttribution: ohnobinki commentedNowadays IE9 + jquery-1.5 finally seem to work with
Content-Type: application/xhtml+xml; charset=utf-8
so hopefully this bug's fix isn't too far away....Comment #13
ao2 CreditAttribution: ao2 commentedBump, I wanted to know what the opinion is on this one these days.
Comment #14
Damien Tournoud CreditAttribution: Damien Tournoud commentedDrupal 8 is now serving HTML5 by default.
Comment #15
ao2 CreditAttribution: ao2 commentedI'll try to reopen the issue, tagging it WSCCI as it might be pertinent to that initiative.
Let's see what people interested in WSCCI think about the mime type issue, and if it is totally pointless even from their perspective with HTML5 as the default format.
If the issue will be closed again I won't complain, I promise :)
Thanks,
Antonio
Comment #16
Crell CreditAttribution: Crell commentedPresumably WSCCI should make it possible to serve any arbitrary requested mimetype. xhtml is not a specific target we're concerned about, though, as it is basically incompatible with any site that accepts user-entered content.
Marking this won't fix as it's not a primary task, but more of a convenient side-effect.
Comment #17
ao2 CreditAttribution: ao2 commented@Crell, OK.
Could you just elaborate a little more on what you mean by “[xhtml] is basically incompatible with any site that accepts user-entered content”? Isn't user submitted content usually filtered anyway to be made secure and valid? Maybe you refer to the fact that in XHTML there are restrictions about changing the DOM dynamically?
Thanks,
Antonio