I would use both client and server side checking, client side to help ease unnecessary server operations. It's the first I've heard of javascript being disabled you'd end up with crap in your database, but I guess when you use javascript as your only means of validation, which you should never rely just on.
Global variables don't exist from posted variables unless global register is on, that way information posted automatically become set. Using $GLOBALS['f_name']; suggests that $f_name; was created in the global scope. Nor are global variables the way to go about this, just the usual validation routine checking.
Validation should not be ended until it gets to the part where the action of the script would take place (e.g. stored in database or emailed, etc), in psuedo "if errors then return". This way you can notify the user of all errors, instead of asking them to fix 1 problem at a time. Doing that just means setting a status flag to say errors exist, as well as having a variable to contain all error messages unless you come up with a better error handling means.
Although mgraphic means well, Names can consist of more characters than what he allows for, I would rather hope someone knows their own name and just check for malicious content as well as making sure they meet the requirements.
His email pattern could do better too, even though I wrote the complete RFC821 specification as a pattern for validating emails, I had to write a more realistic pattern for what is currently being allowed by email companies. If I can track it down I'll post it, but I know I wrote a very simplistic one on another forum which started my journey into email validation techniques.
The problems with his email pattern reading from the start of it.
It doesn't conform to what email companies are allowing, you can't use numbers and other characters as the start of the email, when most companies only allow a letter first. There's no limit to it and doesn't allow for periods.
The domain name part again doesn't conform to what domains are allowed.
Next up, he's limited what the end could be, we can't use .tk because it's only 2 characters, not only that, we can't use .co.uk, .com.au, etc because he doesn't allow for a second period, also being limited 4 characters, I know there's some endings that are 5 characters long, in NZ .maori.nz and there could possibly be longer ones existing.
To easily bypass his email pattern, just do
-@-.aaa, but you'd probably want to do email confirmation to validate as well, but at least fix it up enough so that all correct emails can still get through and you don't waste your time trying to send emails that really don't exist because your validator didn't stop it at the start.
If I'm allowed to, I'll drop my validation class (js and php) in here too, which just works off basic types that you can configure the formatting for, to match what you like, e.g. telephone numbers in the format of (+##) #-###-#### etc.
Cheers,
MC