DISCLAIMER: This post is in no way intended to promote HTML over XHTML or vice-versa. This is simply a solution to a problem for those who may find it useful.
Anyone who has used WordPress for any decent length of time probably knows that everything it outputs is in XHTML format. For those who prefer this, that’s just fine. However, for those of us out there that prefer to use HTML instead, we’re pretty much out of luck when it comes to WordPress. As it stands now, there is no easy way to make WordPress output in HTML format. But today I hope to help those people with this simple function I found around the web.
First, the code:
function HTMLify($buffer) {
$xhtml = array('/XHTML 1.0 Transitional|XHTML 1.0 Strict|XHTML 1.0 Frameset|XHTML 1.1|XHTML Basic 1.0|XHTML Basic 1.1/', '/xhtml1\/DTD\/xhtml1-transitional.dtd|xhtml1\/DTD\/xhtml1-strict.dtd|xhtml11\/DTD\/xhtml11.dtd|xhtml-basic\/xhtml-basic10.dtd|xhtml-basic\/xhtml-basic11.dtd/', '/\/>/', '/\/\s+>/', '/xmlns="http:\/\/www.w3.org\/1999\/xhtml"/', '/\s+xmlns="http:\/\/www.w3.org\/1999\/xhtml"/', '/\s+xml:lang="(.*)"\s+lang="(.*)"/', '/\s+>/');
$html = array('HTML 4.01', 'html4/strict.dtd', '>', '>', '', '', '', '>');
return(preg_replace($xhtml, $html, $buffer));
}Usage
- Paste the code above in a file called
functions.phpinside the theme folder of your currently active theme. - Go into the theme folder of the currently active theme, open the
header.phpfile, and paste this before any other code that outputs to the browser:
<?php ob_start('HTMLify') ?>
To use the default WordPress theme as an example, paste this code before the DOCTYPE declaration. - Save everything! That’s it! If you now look at the source code for your site you’ll notice that everything is HTML instead of XHTML.
Explanation
Basically, what the code does is, it takes the entire output of the page currently being requested and runs it through our function called HTMLify. The function looks for various XHTML-type code and replaces it with HTML-type code. Pretty simple.
The true beauty of it is the function happens after everything is output by WordPress. So, all of WordPress’s code AND any of your custom code is converted. So you could even continue to code in XHTML but have it output as HTML. Cool huh?
An Alternative
While looking around the web I also came upon this website which has a plugin for WordPress that does the same job. Those of you who prefer to use plugins may be more interested in this approach.
Anyway, that’s all there is to it. A little bit of code to solve a big problem. Enjoy!
XHTML syntax is the same as HTML syntax (with the exception of self-closing tags in the HEAD).
LOL, it’s like a health warning…if stuff displays right and loads fast then it does the job, html, xhtml, who cares…
Yeah, XHTML is almost perfectly backwards compatible, I thought. Especially since HTML is such a weakly typed specification, and doesn’t much care about closing tags properly and such.
All one should have to do is alter the XHTML output in your theme’s header.php.
Exactly!
does it do exactly the same as the plugin? cause that plugin didn’t fire/change on the site I tested it on 🙁
I’ve never heard of anyone wanting to not use XHTML, and isn’t XHTML just HTML in an XML type format anyway? So technically, you could do nothing, and call it an XHTML to HTML converter. 😛
The XHTML/HTML debate doesn’t bother me much these days. When I validate my code I try to validate it in as many standards as is feasible. XTML 1.0/1.1 & HTML 5 are usually easy to achieve but being able to tweak it into 4.01 strict makes things a bit more fun!!
That doesn’t make any sense. XHTML 1.1 is only available in a strict doctype and has much stricter syntax requirements than HTML4.
You didn’t mention what problem it does solve.
Both XHTML and HTML syntax are same…Exactly – nice post….
The problem I was seeking to address is using HTML with a system that outputs XHTML without any options to choose otherwise. My intentions were not at all to get into an XHTML vs. HTML debate. I just wanted to post some code that I’m sure at least some might find useful. Some people do actually prefer HTML even if it doesn’t seem that way.
Nothing wrong with that, it’s just that this code seems entirely unnecessary to me. The html header can simply be changed in the theme, and there’s no real need to convert the self closed tags, since they’re equally valid in html and xhtml.
You clearly have too much time on your hands.
xhtml/html…. do they do xxxhtml coding especially for ‘adult’ sites?
After checking some of the differences, it looks like you just have to follow some regular programming guidelines. It might be easier just to follow the same guidelines instead of adding more ontop of the WP core.
http://www.w3schools.com/XHTML/xhtml_html.asp has a quick recap.
Listen folks.
The ‘little function’ that this blog’s owner found is actually an existing wordpress plugin called XHTML-to-HTML that I wrote last year (though you wouldn’t know that as he removed the plugin credits and reproduced it here almost as if he did all the work 🙂 – which is more or less what the web has become these days I guess).
It seems most of you don’t understand the reasons why using XHTML isn’t a good idea. It’s to do with whether or not you care if your code is reproduced properly. Any of you who are web professionals SHOULD at least know about this issue. It is a bit subtle but shows why, in more than 99% of cases, it is a mockery for someone to claim to produce standards compatible work in XHTML.
IMPORTANT NOTE:
The plugin is still in development, which is why I’m a bit miffed that James has ripped it here without linking to the original work. The version he ripped here will cause issues with RSS feeds and Javascript and I strongly recommend YOU DO NOT USE IT. The newest version avoids these problems but is still not finished.
I strongly urge any of you who want to use the plugin to visit the original Plugin website http://www.kilroyjames.co.uk/2.....ss-plugin/ and get the latest versions from there.
You can also learn a bit about why it’s a good idea in the first place to use it.
John Kilroy
Just to amend my comment. I just noticed that it reads as if Im saying the that the blog author ripped the plugin or removed it’s credits. I didn’t mean that. I meant that the person who ripped the function out of the plugin did this. Apologies to the author here for any confusion.
Yes. Just so its clear, I had originally found the function as a response to a forum post. There was no link to any original author there. If there was I would have been more than happy to link to said author. I would have even asked permission first. I’m not one to steal things or anything like that. I was actually searching for a solution so I could use HTML on my personal site and that’s how I came about it.
I’m truly sorry if I have caused any harm. That was not at all my intention.
Hey no harm, I know how these things happen. It’s not an ownership issue by the way (though it’s nice when people credit your work) it’s simply that the function here is already outdated and the current plugin though not perfect is better. We plan a final release soon. Thanks Kenny 🙂
My only thing with the XHTML vs HTML when it comes to wordpress, is rather I use XHTML or HTML markup, my wordpress blogs NEVER pass validation! …and why is that?? because 99.9% of the “plugins” are NOT outputting correct XHTML, or HTML either one, which again FAILS validation. and its not like I want to go into every single plugin I have on my blog just to get my wordpress blog to pass validation.
No what they need a plugin to do, is a plugin that checks the code for bad XHTML/HTML coding, converting it to proper coding, so that it PASSES validation. Now “THAT!!” would be a useful plugin indeed! 🙂
especially for me, because I’m BLIND now, and can no longer read the code markup of my site and edit it to pass validation anymore, so such a plugin would be very useful to me.
all the plugin would have to do, is analyze the final output code of each page converting it to proper coding so it passes validation. it can be in HTML, XHTML it doesn’t matter, so long as it passes validation, so that I can put that “this site is valid HTML” button back on my sidebar.
Where is your site Bubazoo?
As I said, it’s not really practical to write such a general plugin for WordPress, though you could write one that worked on a specific site. But would it be any use to instead find a well-written, valid HTML 4.01 wordpress Theme, and start from there?
It’s a good point – plugins are often badly written. But that doesn’t mean you shouldn’t strive to make sure that the code you write is written well. Validation isn’t just a badge for a webpage to wear. Valid HTML 4.01 Strict, for example, puts almost all currently used browsers into “Standards Compliant” mode, rather than “Quirks Mode”. Standards Compliant and Quirks Mode are basically different layout engines – you should ALWAYS try to make sure your webpages do not put browsers into Quirks Mode, as all Hell breaks loose on your formatting and you stand almost no chance of getting a consistent layout across different browsers or even versions of browsers. That’s one reason to care about validation.
The second point is that many plugins write awful, invalid XHTML, but when that’s translated into HTML it is valid! For instance, the FORM field is not a valid XHTML tag, yet it’s valid in HTML and several plugins use it. It’s invalid XHTML to use inline tags and many plugins do that too. The list goes on, there are very clear advantages to using HTML with wordpress rather than XHTML – aside from the fact the XHTML 1.0 and 1.1 are obsolete markups and all the smart money (Mozilla, Apple, Microsoft et al) is on them being superceeded by HTML 5 not XHTML 2.
Your last point is unfortunately impractical. For many reasons a plugin that parsed your output code and tried to alter it to make it XHTML compliant would break most websites. Better to use HTML 4.01 and keep browsers in Standards Compliant mode, and allow the use of tags and methods that are not allowed in XHTML.
OK, the engine removed my HTML tags that I used for explanation 🙂
Para 2, Sentence 2 should be: FORM < INPUT NAME > field
Para 2, Sentence 3 should be: XHTML to use inline < SCRIPT >
Is it such a problem that it does this? I prefer XHTML to HTML, but everyone has their own opinion I suppose.
Dude if you don’t understand the issues what the hell are you contributing for? It is so not not a matter of opinion! Go learn some stuff, then come back…
A bit strong John, the comments are open for people to express their opinions.