DJ's "How to Validate Your vBulletin" for Beginners
 

So, someone has told you that your site doesn't "validate" or that it's giving off "validation errors" and you have no idea what the blazes they're talking about. What's worse, they have suggested that those errors may be the cause of the problem that you've just asked about in the forums. What do you do?

The following article will attempt to explain what validation is, and help you to root out validation problems with your forum. Just be aware that you're going to have to learn some new stuff that you didn't know before, and maybe you didn't think mattered. But it does matter, and I'll try and help you understand why.


What is Validation, Anyway?
What are you browsing this forum with, right now? If you're just using the stock browser that came with your computer, then you're probably using Internet Explorer or Safari. Maybe you decided to use a popular free browser, like Mozilla Firefox? Google Chrome? Opera? Maybe you're browsing the internet using something a little lesser known, like Flock or Konqueror. Whatever your poison, for whatever reason you have, you're using a browser made by one of many different developers. And because they're all different, they each have a way of rending the code in your webpage a little bit differently then the others. That's where W3C comes along.
[imgrft]http://www.cogonline.net/forums/images/articles/W3C.png[/imgrft]
The World Wide Web Consortium (W3C) exists to make sure there is a standardized way of writing code, so that browsers across the board will render your webpage the way you intended it. You see, just like technology, sometimes code can become outdated. Some code is supported by one browser, and not by another. But by using the W3C standards, you can check to see if your website is using up-to-date code that will render the way you intended it to, across the vast spectrum of internet browsers.

And this is partially what we mean by validate. W3C provides a nifty little validation service at http://validator.w3.org. Here you can put the URL (URI) to any given webpage into the Validator, and it will let you know if your site passes validation:


Or if you've got problems you need to work out:


The Validator also lets you validate pages using the source code (Direct Input) of your web page or by uploading an HTML document directly. When validating vBulletin, you're most likely only going to want to use URI and Direct Input.

Validation isn't only just for making sure your site renders across web browsers. Validation is also for making sure your code is correctly formatted. Sometimes, an error that you just can't figure out is because you have an improperly formatted HTML tag somewhere in your document. Maybe more than one. The Validator will let you know if you do. It's also a way of making sure your website is accessible to people with disabilities, say, people who have to surf the web using a reader.

OMG! WHAT DO I DO NOW???!!!
More than likely, if your a new vBulletin owner and know nothing about HTML, and you've just checked your site in the Validator as a result of this article or an instruction on the forums, then you're noticing you have a LOT of errors. First thing to do, is to calm down and stop typing in all CAPS. Second thing to do is to read on. You've got problems and you need a clear, calm and patient head if you're ever going to work them out.

Using The Validator
The first thing you'll want to do is to pick a Document Type Declaration (DOCTYPE). The DOCTYPE begins the HTML of your web pages and will tell the Validator which version of HTML it should check it against. More than likely, and to keep this article simple, we'll assume you need XHTML 1.0 Transitional. By default, this is what your vBulletin has as its DOCTYPE anyway, and for the purposes of this article we'll assume you want to keep it this way. There's other reasons why you'd want to choose other DOCTYPEs, but you can learn about those on your own once you feel you need to and have picked up the basics. I would venture to say it's the most common DOCTYPE chosen for your type of website anyway.

vBulletin lets you edit your DOCTYPE via the Admin CP pretty easily. The DOCTYPE is displayed per style, so you have to check each of your styles to make sure they each have the DOCTYPE you want.

It's in the same location in both vB3 and vB4, but the final destination looks a little different. Simply go to Admin CP ? Styles & Templates ? Style Manager ? ??SELECT STYLE? ? StyleVars ? HTML Doctype to check it out:


In addition, you may find that some of your templates are missing the required XMLNS attribute for their root element. Simply put, the XMLNS attribute for your HTML tag should look like this: xmlns="http://www.w3.org/1999/xhtml". Therefore, your templates' opening <html> tag should look like this:

NOTE: This is presuming that your template starts the HTML in your web page. Just like the DOCTYPE, it's not necessary for it to exist in every single template. Only those templates that create the first lines of your web pages.

Now that you've done that, we've got one more step before running a validation check. Go to your Admin CP ? vBulletin Options ? vBulletin Options ? General Settings ? Add Template Name in HTML Comments and set it to Yes. What this does is add <!--HTML Comments--> to your website's source code. If you know anything about your template system, you know that each of your templates are like the pieces of a big puzzle making up all the content of your forum. With this enabled, your forum's puzzle pieces, or rather, your templates, are now marked where they start and where they end with comments in the HTML source code. You see, now that we can tell where our templates begin and end, we'll more easily be able to find which templates have our errors:


Now you're ready to run the Validator against the pages of your website. Pick a page and enter the URL into the Validate by URI tab, or open up the source code of your web page and copy and paste it into the Validate by Direct Input tab. The reason you'd chose Direct Input over just using the URI is because the Validator can only check the HTML it can see. That means it can't see all the HTML that will be generated in a web page when a Registered User is logged in or has special permissions. Anything that a User might see that a Guest would not will determine when you want to validate using Direct Input. So keep that in mind. A webpage might validate just fine for a Guest, but have errors when displayed to someone who is logged in.

Before you hit that Check button, open up the More Options arrow just below the Validator and check the box called Show Source. We'll need that enabled if we're going to track down our errors.

Understanding the Validator
Now comes the hard part. You've clicked Check. And you've got errors. Maybe hundreds of them. The first time I ever ran the Validator against my home page I ranked OVER 600 ERRORS! Again, don't panic and stop typing in all CAPS. I'll show you some common errors and how to go about fixing them.


If you look at the image below, you'll see that all the errors are pretty much listed in the order they were detected and marked by the line they appear on in the source code. And because Show Source was enabled, the source code to your web page is being displayed at the bottom of the page under all the error results. Clicking one of those numbers will jump to the line in the source code where the Validator thinks the error begins.


Notice I said, where it "thinks" it begins. You see, the Validator only detects the first place where the code doesn't look right. Any thing after that might display as an error solely because the code before it isn't correct. For example, this is a basic table tag:

Properly written code will ensure that tags don't overlap. Tags open and close like this: <TAG></TAG>. So in the example above, the TRs are neatly opened and closed inside the TABLE tags, and the TDs are properly opened and closed inside the TR tags. In other words, they're all properly nested.

Now let's say you goofed and have an open <table> tag. You forgot to put in the closing </table> tag for that table. Way down at the bottom of the page is a closing </table> tag, but for a completely different table, one that is properly opened and closed:

The Validator will look at the opening table tag and expect it to close at some logical point. So it knows that certain other types of tags should not appear before that </table> tag does. If that does indeed happen, the Validator will stop right at a character and mark the line and character where it believes the code has started to loose its way. Your webpage, however, will try to make sense of the error, and the result will be the upper table trying to merge with the lower table.

Take a look at this example on my website. It's constructed with two tables, but like in the scenario above, I've neglected to include the closing </table> tag for the first table.

http://www.cogonline.net/forums/invalid.php

Did you click the link at the bottom of that page? What did you notice when you ran that page through the Validator? Well, you probably noticed that there were 10 errors on the page. But the only thing I did wrong on that page was leave out one closing tag. Now click here to see that exact same code again, only with the missing </table> tag in place.

http://www.cogonline.net/forums/valid.php

Now what did you notice when you validated the page? It went through just fine, didn't it? I only fixed the one mistake. One mistake. Ten errors.

Now this is the part you'll need to wrap your head around. Go back and look at invalid.php's validation results again. Since the closing </table> tag wasn't there, the Validator could only assume it was going to show up at the proper place. When it didn't, it branded the very next HTML tag it found as incorrect. The <br /> tag. What you'll need to learn to do when looking for errors on your pages is, to not only start with the first error, but to look above that error and see what is actually missing or incorrect. Errors cascade, so the Validator simply marked the place where the code stopped making sense. In my case, I didn't include code that should have been there, so I had to use my noggin' to figure out what was wrong in the lines above it. This would have required some searching on my part if I had a lot more code than in this example.

If errors cascade, then that has ramifications with templates that repeat themselves on a forum page. If one error in a simple template like mine caused ten errors in the Validator, imagine what a similar error in forumhome_forumbit_level1_nopost would cause! That template is used repeatedly on your forum home pages. So not only is the error going to cascade, but its going to be compounded each time the template is used. Meaning even more cascades and more errors.

This is why you don't need to panic when you see 600+ errors on your forum. You may have to fix one problem, you may have to fix twenty. But because errors cascade, each time you address a problem, you just may find you've fixed a dozen or more. You should always start with the uppermost error and work your way down. This will ensure you don't work on something that isn't actually incorrect and wind up spinning your wheels on nothing at all.

OMITTAG NO? REFC delimiter? WTF?
Okay, so you you've probably come to the realization that you're probably going to have to learn a little HTML to correct some of your problems. Don't sweat it. HTML is the easier to learn of all forms of coding. In fact, W3CSchools has excellent, bare bones tutorials that will help you grasp all you need to know. Also, just use Google or your favorite search engine to find hundreds, if not thousands of guides and tutorials on the subject. In general, anyone running a vBulletin, even just for fun, should learn the basics of HTML. It will make life so much easier for them.

But what about this other stuff like OMITTAG NO and REFC delimiter and whatnot? Well, in most cases you're going to run into very common mistakes in HTML code. You've installed some modifications. You've downloaded some free custom styles. Or you paid some guy to make you a style for $20. Which means, you've set yourself up for some human error. A lot of developers write their code, but don't bother to check to see if it validates. So you may run into typos, errors, exclusions or just things the developer simply didn't know about.

For instance:

• Ampersands (&) should always be written as their HTML equivalent (&amp;). We call that an ampersand command and it can create problems if not used when including them in links in pages.
  
  HTML Code:

  ---

  INCORRECT:
http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=star+wars

CORRECT:
http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=star+wars

  ---

• Since HTML attributes use a lot of special characters like "" marks or single quotes ' or brackets <>, you should be using their ampersand command when they're part of text and not specifically being used as HTML code:
  
  Miranda said: "Are you going to stay on the computer all night, Mark?" <sigh>
  
  HTML Code:

  ---

  <span style="color:red">Miranda said: &quot;Are you going to stay on the computer all night, Mark?&quot; &lt;sigh&gt; </span>

  ---

• <img> tags should always be self closing. They don't have an opening and closing tag like the table tags we were looking at above. And they should always include an alt="" attribute, even if it's empty.
  
  HTML Code:

  ---

  <img src="images/forum_new.png" alt="" border="0" />

  ---

• Line breaks should also be self closing, not missing that ending slash.
  
  HTML Code:

  ---

  INCORRECT: <br>
CORRECT: <br />

  ---

• With the notable exception of your DOCTYPE, you shouldn't capitalize HTML code. (This is a common mistake, as a LOT of tutorials, especially older ones, use capital letters in their sample codes.)
  
  HTML Code:

  ---

  <SPAN>This is wrong!</SPAN>
<span>This is right!</span>

  ---

• Elements should be nested correctly. That means, you can't close one, before you've closed another that initially opened inside of it. In other words, they can't overlap:
  
  HTML Code:

  ---

  <i><b>This is wrong!</i></b>
<i><b>This is right!</b></i>

  ---

But Wait! There's Less!
I can't give you a full list of everything that can go wrong, but this should help a lot in getting you started. Also, the rules change a bit when you decide to use a different DOCTYPE, say one that has a more strict standard for HTML. There's also rules when dealing with more complex code like the <OBJECT> code for videos, or when including JavaScript code on a page. You can also validate your CSS, another aspect of web building goodie you should really read up on. It's also pretty easy to learn. But all that's for another tutorial. And you can find plenty more about any errors you may run into on the web. That's pretty much where I learned it, and where I continue to pick up new information.

[IMGLFT]http://www.w3.org/Icons/valid-xhtml10[/IMGLFT]Once you get your shiny new web pages all transition-y and error free, the Validator will offer you some HTML code to put on your website for bragging rights. The code will put a badge on your page saying which version of HTML your site validates against, along with linking the image to the Validator. The link will automatically run the Validator using the referring URI, so if you put this code in your footer, people will be able to check your individual pages at a glance.

In fact, I took this code and tweaked it a bit to help me validate my own web pages when I wasn't using Direct Input:

I put this code at the very top of my header template, where X is my User ID. This puts an unobtrusive bar across the top of your web page that uses the same referrer link, so you can check your pages at a glance. The <if> conditional means only you'll ever see it. Again, this only uses the referring URI and not Direct Input.

Here's some additional resources that may also help you on your journey. HAPPY vBULLETIN-EN-EN-ING...er, or something. What did I tell you about writing in all CAPS?

Common XHTML Errors
Common HTML Validation Problems
10 Common Validation Errors and How to Fix Them
Embedding Flash While Supporting Standards
WAVE - Web Accessibility Evaluation Tool
Help and FAQ for the Markup Validator

This seems to be the most common error I'm getting

and in this case it's complaining about the user name colors from the user group manager which I have set to.

<span style='color:#000080'> = first box
</span> = second box.

Very nice! Thanks for this article.

a lot of details - great article :up:

it looks like a bug - have you updated your vbulletin installation to the latest?

Hmm curious to see if you change this:

To this:

Will help/resolve the error?

Thanks superman, I'll give that a shot as soon as I finish uploading some pics that I used Smush It! on.

That didn't work, infact it resulted in more errors. Also I'm using the mod:

Hasann - Username Html Markup

I was having a little trouble understanding your error message, and then I realized, the [PHP] tags you used to post the error message was keeping the formating from the Validator from parsing in your post. It was garbling the message, which should look like this:

[hr]2[/hr]…a4a5e890bb82a5a812da67f811ec6" title="<span style='color:#000080'>final kaoss<…

✉

This message may appear in several cases:

* You tried to include the "<" character in your page: you should escape it as "&lt;"
* You used an unescaped ampersand "&": this may be valid in some contexts, but it is recommended to use "&amp;", which is always safe.
* Another possibility is that you forgot to close quotes in a previous tag.[hr]2[/hr]

Yeah, it appears the mod isn't supposed to be used along with the vBulletin default markup. It's trying to add the color red to the title element mouseover. It's tucking code in the middle of a tag. If Hasann's modification already adds markup everywhere on the forum, as his description suggests, then I wouldn't think you need to add anything to the Usergroup Manager. Try using just his mod, or just the default Usergroup markup. But, clearly, both are not going to work together.

The reason I think it's doing this is because Hasann's modification is probably just using the [usertitle] variable in places it wouldn't ordinarily be (like in a title="" attribute). But vBulletin is coded to change the [usertitle] variable into the full HTML markup in your Admin CP. Hence the conflict.

--------------- Added [DATE]1294128352[/DATE] at [TIME]1294128352[/TIME] ---------------

For instance, say Hasann's user title's look like this in the templates:

So the HTML would look like this:

$post[usertitle] becomes Extreme Chaos Master!!!

But if you add markup in the Usergroup Manager, it get's included in the variable. So $post[usertitle] now turns into <span class="color:red">Extreme Chaos Master!!!!</span>

So when the varible in Hasann's code converts, it converts a SPAN tag, right smack dab in the middle of another SPAN tag, on top of that adding an additional nested SPAN tag, breaking the code and making a garbled mess.:

That's what I believe is happening.

Yeah you're right about his mod, garbling the code. But now on the homepage & showforum pages the user names aren't colored... (except for the who's online box). I'll try removing the injected $post[usertitle]