It is not my intention to sound rude, so please do not read this response as rude:
It was never my intention to annoy you (or anyone), sorry if I did so. I’m sorry if I come accross as acting as if I understand this all, when I don’t. I thought I could help, albeit just a little bit, - I didn’t want this to turn into an argument.
For any page you want to serve as "application/xhtml+xml" but don’t want to break in IE and any other browsers that may not be able to interpret, in the manager when you create or edit the page, you click on the "Page Settings" tab and choose "text/html" for the "Content type". This is what you would do for any page most people would refer to as a "Web page".
I agree completely this is what to do if working with your original plugin.
However, I created a custom type "applicatation/xhtml+xml" In Manager->Tools->Configuration->Site, and I set the content type for my pages to that. If left as that, I believe MODx would serve those documents as "applicatation/xhtml+xml" (in their HTTP header information), and that pages would break in IE. However, using the alternative code posted above, the content type would be changed (using the "header" function). Note that my code does not change anything in the document content, only the HTTP header. I don’t have a meta http-equiv tag in my html "head" section, as it seems a bit superfluous when setting the content type, with encoding, in the HTTP header. This is just for my own personal use, as I have a single page XHTML page that I would actually like served as text/html, and it seems that this is the only way to do it.
For other types of pages such as RSS feeds or Podcasts, you would select "text/xml" for the content type. For CSS pages, select "text/css", etc... etc...
I agree wholeheartedly.
When the plugin searches the document for the text line "text/html", do you imagine it would find an exact match?
The answer is no. It would not find an exact match.
This is where I think this is where the confusion is coming from. The str_replace function in the plugin does search for this "text/html", and only replace that (it seems like it would also replace the string text/html anywhere in the document content also, but this is a whole other discussion!). However, to quote from the original plugin:
if ( stristr($_SERVER['HTTP_ACCEPT'],'application/xhtml+xml') ) {
$content_type = 'application/xhtml+xml';
header("Content-type: application/xhtml+xml");
}
else {
$content_type = 'text/html';
header("Content-type: text/html");
}
The "header" function seems to change the HTTP header content-type. The else block is executed if the browser does not seem to accept application/xhtml+xml, and in the else block the HTTP header is changed to text/html. Thus, whatever the orignal content type of the document, be it text/html, text/xml, text/css - if it is served through this plugin, the content type in the HTTP header will be changed to text/html if the browser does not identifty itself as accepting application/xhtml+xml. This was my point I was trying to make.
However, come to think of it, I have now realised that the first "if" block also has a problem. There is no test on the original content type of the document. Thus if a RSS feed, set to text/xml in the manager, is served, but the browser says it _can_ accept application/xhtml+xml, then its content-type in the HTTP header is changed. I feel as though there has to be some test on the original content type, $modx->documentObject[’contentType’], or similar.
I’m sorry I just don’t see a flaw in my logic. I’m sorry if I’m being a bit slow and wasting your time. Perhaps I misunderstand what the "header" function does, but from my limited testing (with help of the livehttpheaders extension for Firefox, and access to a version of IE) it does seem to do what I think it does.
