DJ's "How to Validate Your vBulletin" for Beginners
by
03 Jan 2011
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 http://www.microsoft.com/windows/internet-explorer/default.aspx or http://www.apple.com/safari/. Maybe you decided to use a popular free browser, like http://www.mozilla.com/en-US/firefox/? https://www.google.com/chrome/intl/en/landing_chrome.html?hl=en? http://www.opera.com/? Maybe you're browsing the internet using something a little lesser known, like http://flock.com/ or http://www.konqueror.org/. 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. http://www.w3.org/ (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. HTML Code:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
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: HTML Code:
<html xmlns="http://www.w3.org/1999/xhtml" dir="$stylevar[textdirection]" lang="$stylevar[languagecode]">
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: HTML Code:
<table> <tr> <td>Table Title</td> </tr> <tr> <td>Table Content</td> </tr> </table> 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: HTML Code:
<table> <tr> <td>Bad Table</td> </tr> <!-- Lots of code--> <table> <tr> <td>Good Table</td> </tr> </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, http://www.w3schools.com/html/default.asp 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:
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 http://jigsaw.w3.org/css-validator/, 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. http://validator.w3.org/check?uri=http://www.cogonline.net/forums/&charset=(detect+automatically)&doctype=Inline&ss=1&group=0&user-agent=W3C_Validator/1.1Once 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: HTML Code:
<if condition="$bbuserinfo[userid] == X"><div class="thead" style="float:left"><a href="http://validator.w3.org/check?uri=referer" target="_blank">Validate</a></div></if> 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? http://blackwidows.co.uk/resources/tutorials/xhtml/common-errors.php http://htmlhelp.com/tools/validator/problems.html http://line25.com/articles/10-common-validation-errors-and-how-to-fix-them http://www.alistapart.com/articles/flashsatay/ http://wave.webaim.org/ http://validator.w3.org/docs/help.html |
Similar Mods
Integration with vBulletin DJ's Living Avatars User CP/Admin CP "Integration" | vBulletin 3.8 Add-ons |