Register Arama Bugünkü Mesajlar Mark Forums Read

Reply
 
Thread Tools
DJ's "How to Validate Your vBulletin" for Beginners
vB.Org Poster
vB.Org Poster has disabled reputation
Kayıt Tarihi: Jul 2018
Mesajlar: 298

Show Printable Version Email this Page
yazar vB.Org Poster 10 Jul 2018, 16:39

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.


Kod Blok Kilitli:      (Kayıt veya giriş yapmalısın)  
Engellenmiş, kayıtlı olmayan veya onay bekleyen kişiler kodlara erişemezler.

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:


Kod Blok Kilitli:      (Kayıt veya giriş yapmalısın)  
Engellenmiş, kayıtlı olmayan veya onay bekleyen kişiler kodlara erişemezler.

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:


Kod Blok Kilitli:      (Kayıt veya giriş yapmalısın)  
Engellenmiş, kayıtlı olmayan veya onay bekleyen kişiler kodlara erişemezler.

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:


Kod Blok Kilitli:      (Kayıt veya giriş yapmalısın)  
Engellenmiş, kayıtlı olmayan veya onay bekleyen kişiler kodlara erişemezler.

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.

    Kod Blok Kilitli:      (Kayıt veya giriş yapmalısın)  
    Engellenmiş, kayıtlı olmayan veya onay bekleyen kişiler kodlara erişemezler.

  • 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>

    Kod Blok Kilitli:      (Kayıt veya giriş yapmalısın)  
    Engellenmiş, kayıtlı olmayan veya onay bekleyen kişiler kodlara erişemezler.

  • <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.

    Kod Blok Kilitli:      (Kayıt veya giriş yapmalısın)  
    Engellenmiş, kayıtlı olmayan veya onay bekleyen kişiler kodlara erişemezler.

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

    Kod Blok Kilitli:      (Kayıt veya giriş yapmalısın)  
    Engellenmiş, kayıtlı olmayan veya onay bekleyen kişiler kodlara erişemezler.

  • 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.)

    Kod Blok Kilitli:      (Kayıt veya giriş yapmalısın)  
    Engellenmiş, kayıtlı olmayan veya onay bekleyen kişiler kodlara erişemezler.

  • 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:

    Kod Blok Kilitli:      (Kayıt veya giriş yapmalısın)  
    Engellenmiş, kayıtlı olmayan veya onay bekleyen kişiler kodlara erişemezler.


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:


Kod Blok Kilitli:      (Kayıt veya giriş yapmalısın)  
Engellenmiş, kayıtlı olmayan veya onay bekleyen kişiler kodlara erişemezler.

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
Views: 18
Reply With Quote
Reply

Thread Tools

Şunları Yapabilirsin
Yeni Konu Açmak
Konuya Cevap Yazmak
Eklenti Eklemek
Düzenleme Yapabilmek

Forum Atla


New To Site? Need Help?

All times are GMT +3. The time now is 14:44.

Tasarım Özelliği | Genişlik: Geniş Renk: DJ's &quot;How to Validate Your vBulletin&quot; for Beginners DJ's &quot;How to Validate Your vBulletin&quot; for Beginners DJ's &quot;How to Validate Your vBulletin&quot; for Beginners DJ's &quot;How to Validate Your vBulletin&quot; for Beginners DJ's &quot;How to Validate Your vBulletin&quot; for Beginners