Modify Lookahead to include Character Class

[doubledee]

Oh how quickly we forget?!

 

Here is a Regex including a Lookahead that someone helped me with a few months ago...

// ************************
// Check Username Format.	*
// ************************
if (preg_match('~(?x)								# Comments Mode
			^								# Beginning of String Anchor
			(?=.{8,30}$)						# Ensure Length is 8-30 Characters
			.*								# Match Anything
			$								# End of String Anchor
			~i', $trimmed['username'])){
	// Valid Username.

 

I would like to change this code so that a Username can only include Letters, Numbers, Underscore, Hyphen, Period.

 

I'm not sure, but I think what I need to do is change Line 7 above from...

.*

 

...to...

[a-zA-Z0-9_-.]

 

Does that sound correct?

 

 

Also, on Line 6, can someone refresh my memory as to why I have a Dollar Sign in there??

(?=.{8,30}$)

 

Thanks,

 

 

Debbie

 

[.josh]

Welp, to immediately answer your question with the path of least resistance, you will need to change:

 

(?=.{8,30}$)

 

to

 

(?=[a-z0-9_.-].{8,30}$)

 

 

can someone refresh my memory as to why I have a Dollar Sign in there??

 

Dollar Sign signifies end of string (or line, if you use the appropriate modifier).

 

But anyways...I'm kind of curious as to why you would use a lookahead for this in the first place (I know you mentioned you got help from someone else, so I'm not "blaming" you)...maybe there is some thing more involved here that you haven't provided in this post, but at face value you don't need a lookahead, can just use:

 

if (preg_match('~^[a-z0-9_.-]{8,30}$~i', $trimmed['username'])){
  // Valid Username.
}

[doubledee]

Welp, to immediately answer your question with the path of least resistance, you will need to change:

 

(?=.{8,30}$)

 

to

 

(?=[a-z0-9_.-].{8,30}$)

 

Okay.

 

But I tried this and it seems to work as well...

// ************************
// Check Username Format.	*
// ************************
if (preg_match('~(?x)								# Comments Mode
			^								# Beginning of String Anchor
			(?=.{8,30}$)						# Ensure Length is 8-30 Characters
			[a-z0-9_.-]*						# Match only certain Characters
			$								# End of String Anchor
			~i', $trimmed['username'])){

 

 

Thoughts?

 

 

can someone refresh my memory as to why I have a Dollar Sign in there??

 

Dollar Sign signifies end of string (or line, if you use the appropriate modifier).

 

Okay.

 

 

 

But anyways...I'm kind of curious as to why you would use a lookahead for this in the first place (I know you mentioned you got help from someone else, so I'm not "blaming" you)...maybe there is some thing more involved here that you haven't provided in this post, but at face value you don't need a lookahead, can just use:

 

if (preg_match('~^[a-z0-9_.-]{8,30}$~i', $trimmed['username'])){
  // Valid Username.
}

 

You know, that is a good question!!!     

 

I know it may sound funny, but being a newbie, I have TONS of code that works great, and yet when I go back and look at some of it I say to myself, "Why did you do it this way?!"  Usually I blame the people who helped me!!)  *LOL*

 

I remember that I had a pretty drawn out discussion on this topic, and there must have been some reason I not only chose Look-Aheads, but also the pretty format you see...

 

Does looking at this code help to explain why...

// **********************
// Check Email Format.	*
// **********************
if (preg_match('~(?x)								# Comments Mode
		^								# Beginning of String Anchor
		(?=.{0,80}$)						# Ensure Length is 0-80 Characters
		[A-Z0-9_+-]+(?:\.[A-Z0-9_+-]+)*@[A-Z0-9-]+(?:\.[A-Z0-9-]+)*\.[A-Z]{2,7}		# Check E-mail Format
		$								# End of String Anchor
		~i', $trimmed['email'])){
// Valid Email.

 

Or you know what, I think the reason I chose this code was because I NEEDED IT to check my Password, and I liked the format and stuck with it.  I'm pretty sure that is what it was...

 

Anyways, is that a bad thing?

 

 

You know on a related side topic, I am starting to question if I should be using Regex for Form Validation at all, because there is a "gotcha" with them...

 

In my OP, in the code if the Username fails, I have no easy way to tell a User...

 

- Your Username is too short

- Your Username is too long

- Your Username needs a Letter

- Your Username needs a Number

 

and so on, because we are doing all of those checks in ONE LINE of code.

 

Follow me?

 

Thoughts on this side point?

 

Thanks,

 

 

Debbie

 

[Jessica]

I agree with your last point, which is why I use strlen for the first two, then two separate checks for the last ones.

You shouldn't require a username to have a number though, that's just cruel. 

[.josh]

Well the lookahead bit looks ahead and verifies the format (without actually consuming anything) and then that .* afterwards is what actually matches (and consumes) the string.  So I guess *technically* you can swap the 2nd dot instead of the first, it effectively does the same thing.  TBH I'm not 100% sure which way is technically more efficient (would have to do some benchmarking) but my thought was this: You are effectively matching for stuff twice (sort of) so IMO the more validation put in the first match (the lookahead) would theoretically mean less double matching.  IOW, if the string is destined to match, it's going to have to go through two sets of matches (sort of), but if it fails, it will only go through one.  But lookaheads in general have a bit of overhead so it might turn out that it would be slower overall...again, only way to really know is to do some serious benchmarking against a bunch of strings.  But regardless, we're talking fractions of microsecond difference, so it doesn't *really* matter...

 

But on the point of it matching twice (sort of) ... yeah so that was my point about the lookahead being superfluous: you're basically performing the same match twice.  Sort of.  You kind of split it up between the two (the character length range in the lookahead, and the allowed chars in the following consuming match (in your version) .. and then both are looking for end of string with that $).  So for sure the MORE efficient thing would be to get rid of one of them.  Technically since you aren't actually trying to capture anything, you could move everything to one or the other (only have a lookahead, or else ditch the lookahead).  I'm fairly certain lookaheads are less efficient in general so I opted to remove the lookahead and put everything as a normal consuming match. 

 

But none of this is a "bad" thing per se...it mostly matters how much you want to nickle and dime efficiency and readability.  But since you seem to be a fan of readability (the comment mode), then it might be prudent for you to go ahead and simplify it.  On the note of comment mode: you can still leave that in if you want to, of course.  IMO it actually makes it less readable, but maybe that's just me...I am pretty used to reading regex.  Whatever floats your boat.

 

RE: Unrelated topic: 

 

Yes you are correct, having a single regex will prevent you from being able to give more specific form errors.  IMO that is okay.  I think most of the time people fail to use the proper format is because they fail to read the format instructions in the first place.  IMO listing a general error of what all could be wrong with it (that list you have above) is more than acceptable for allowing the visitor to figure out what they did wrong.  I rarely see clients or websites in general I've been to, be so granular in their error messages.  But at the end of the day, it's up to you.  If you really wanted to take the "scientific" approach to finding out which offers better UX, you could do some A/B testing on your forms (Omniture Test and Target, Google Optimize, etc..), see which ones lead to more people filling out forms.

 

But if you do decide to be more granular about it, then yes, you will need to separate the regex out into multiple conditions, addressing each format requirement.

 

 

 

.josh

[doubledee]

I agree with your last point, which is why I use strlen for the first two, then two separate checks for the last ones.

You shouldn't require a username to have a number though, that's just cruel.

 

No, numbers are not required.  (Bad prior example!)

 

 

Debbie

 

[doubledee]

Wow!  Long response!  Lots of love today!!  =)

 

 

Well the lookahead bit looks ahead and verifies the format (without actually consuming anything) and then that .* afterwards is what actually matches (and consumes) the string.  So I guess *technically* you can swap the 2nd dot instead of the first, it effectively does the same thing.  TBH I'm not 100% sure which way is technically more efficient (would have to do some benchmarking) but my thought was this: You are effectively matching for stuff twice (sort of) so IMO the more validation put in the first match (the lookahead) would theoretically mean less double matching.  IOW, if the string is destined to match, it's going to have to go through two sets of matches (sort of), but if it fails, it will only go through one.  But lookaheads in general have a bit of overhead so it might turn out that it would be slower overall...again, only way to really know is to do some serious benchmarking against a bunch of strings.  But regardless, we're talking fractions of microsecond difference, so it doesn't *really* matter...

 

But on the point of it matching twice (sort of) ... yeah so that was my point about the lookahead being superfluous: you're basically performing the same match twice.  Sort of.  You kind of split it up between the two (the character length range in the lookahead, and the allowed chars in the following consuming match (in your version) .. and then both are looking for end of string with that $).  So for sure the MORE efficient thing would be to get rid of one of them.  Technically since you aren't actually trying to capture anything, you could move everything to one or the other (only have a lookahead, or else ditch the lookahead).  I'm fairly certain lookaheads are less efficient in general so I opted to remove the lookahead and put everything as a normal consuming match. 

 

But none of this is a "bad" thing per se...it mostly matters how much you want to nickle and dime efficiency and readability.  But since you seem to be a fan of readability (the comment mode), then it might be prudent for you to go ahead and simplify it.  On the note of comment mode: you can still leave that in if you want to, of course.  IMO it actually makes it less readable, but maybe that's just me...I am pretty used to reading regex.  Whatever floats your boat.

 

If I choose to use Regex for things like Username, I think you said it best here...

...but at face value you don't need a lookahead, can just use:

 

if (preg_match('~^[a-z0-9_.-]{8,30}$~i', $trimmed['username'])){
  // Valid Username.
}

 

 

RE: Unrelated topic: 

 

Yes you are correct, having a single regex will prevent you from being able to give more specific form errors.  IMO that is okay.  I think most of the time people fail to use the proper format is because they fail to read the format instructions in the first place.  IMO listing a general error of what all could be wrong with it (that list you have above) is more than acceptable for allowing the visitor to figure out what they did wrong.  I rarely see clients or websites in general I've been to, be so granular in their error messages.  But at the end of the day, it's up to you.  If you really wanted to take the "scientific" approach to finding out which offers better UX, you could do some A/B testing on your forms (Omniture Test and Target, Google Optimize, etc..), see which ones lead to more people filling out forms.

 

But if you do decide to be more granular about it, then yes, you will need to separate the regex out into multiple conditions, addressing each format requirement.

 

 

 

.josh

 

Hmmm.....

 

Well, let's come at this from a different angle...

 

As Jane User, which of these Error Messages would be clearest to you...

$errors['username'] = 'Username must be 8-30 characters (A-Z0-9_- )';

 

$errors['username'] = 'Username can only use Letters, Numbers, Underscore, Hyphen, Period.';

 

$errors['username'] = 'Username can only use: a-z A-Z 0-9 _ - .';

 

$errors['username'] = 'Invalid Username. (see valid characters)';

 

 

In the past I used the format in #1 for all of my error messages, however I'm sure it confuses non-technical people.

 

Then again, what do you do when you allow slew of special characters??  There is no easy way to fit everything into one message without it wrapping, and thus, it seems like breaking Error Messages up might make sense, right?!

 

I mean, would you really want...

$errors['username'] = 'Username must be between 8 and 30 characters and can include Letters, Numbers, Underscore, Hyphen, Period, Plus Sign, Dollar Sign, Pound Sign, and don't forget the Equal Sign and a Space for good measure!!';

 

 

 

Debbie

 

[Jessica]

I personally would do the entire rules in a tooltip/small text, and then for the error specify which they broke.

IE:

Username: (box here)

Username must be 8-30 characters and contain only A-Za-z0-9.  (this is small text under it)

 

 

Then when they mess up

 

Username: (box here) *Username must be at least 8 characters * (bold/red)

Username must be 8-30 characters and contain only A-Za-z0-9.  (this is small text under it)

[.josh]

I mean I get what you're sayin' here:

 

$errors['username'] = 'Username must be between 8 and 30 characters and can include Letters, Numbers, Underscore, Hyphen, Period, Plus Sign, Dollar Sign, Pound Sign, and don't forget the Equal Sign and a Space for good measure!!';

 

But IMO there's no reason to list out the non-alphanumerics.  I'd personally do :

 

$errors['username'] = 'Username must be 8 to 30 chars and only contain letters, numbers, or the following chars: "_.-"'

 

...and add to the non-alphanumeric list as it grows. 

[.josh]

I personally like to do the error msg even more generic like "Username is invalid" or highlight the form field red or something, and then have a ? icon of some sort and when the visitor clicks (or hovers) on that icon, it gives a popup with the details, and the popup is not "in-line" so you don't have to worry about it breaking the flow of the rest of your form or w/e.  Which is present and available to click at all times (before visitor attempts to enter username, or after, if it fails

 

[pre]

Username: [                        ] (?)

[/pre]

 

 

 

[doubledee]

I mean I get what you're sayin' here:

 

$errors['username'] = 'Username must be between 8 and 30 characters and can include Letters, Numbers, Underscore, Hyphen, Period, Plus Sign, Dollar Sign, Pound Sign, and don't forget the Equal Sign and a Space for good measure!!';

 

But IMO there's no reason to list out the non-alphanumerics.  I'd personally do :

 

$errors['username'] = 'Username must be 8 to 30 chars and only contain letters, numbers, or the following chars: "_.-"'

 

...and add to the non-alphanumeric list as it grows.

 

The only problem is that for non-technical people they may get mixed up looking at symbols.

 

For example...

or the following chars: ".""

 

You and I could figure out what that means, but a lay person wouldn't get we meant...

or the following chars: period, double-quote

 

Yeah know?!

 

 

Debbie

 

[doubledee]

I personally like to do the error msg even more generic like "Username is invalid" or highlight the form field red or something, and then have a ? icon of some sort and when the visitor clicks (or hovers) on that icon, it gives a popup with the details, and the popup is not "in-line" so you don't have to worry about it breaking the flow of the rest of your form or w/e.  Which is present and available to click at all times (before visitor attempts to enter username, or after, if it fails

 

I like that idea, and I think jesirose was alluding to that as well.

 

Okay, let me show my true newbie colors here... 

 

How would I do that?

 

How would I make a simple pop-up window where I could spell things out in great detail?

 

Can I avoid using JavaScript?

 

And what if someone has "No Pop-ups" and "No JavaScript" set in their browser?!

 

 

Debbie

 

[.josh]

well then you could mark them up in a special format to "delimit" them (eg: different color, in bold, etc...).  crude example to get my point across:

 

$errors['username'] = 'Username must be 8 to 30 chars and only contain letters, numbers, or the following chars: <span style="make bold or colorful css rules here">_.-</span>';

[doubledee]

well then you could mark them up in a special format to "delimit" them (eg: different color, in bold, etc...).  crude example to get my point across:

 

$errors['username'] = 'Username must be 8 to 30 chars and only contain letters, numbers, or the following chars: <span style="make bold or colorful css rules here">_.-</span>';

 

That might do it.  (At least for sighted people.)

 

 

Debbie

 

[.josh]

How would I do that?

 

How would I make a simple pop-up window where I could spell things out in great detail?

 

Can I avoid using JavaScript?

 

And what if someone has "No Pop-ups" and "No JavaScript" set in their browser?!

Debbie

 

If you do want a no-js no-popup friendly version...well technically it can be done, but it will involve putting the logic server-side and outputting new content dynamically.  This increases requests to your server, bandwidth consumed.  The "better" no-js/popup route would be to stick to having the messages output in-line and work on making the message shorter, fit in with your overall design, as you have been doing.

 

But IMO...this isn't 1990.  Very few people actually have javascript disabled.  I would advise you not to care about people who have javascript disabled.  I work in the web analytics business.  I look at numbers like that all day long.  But take it as my own opinion, nonetheless.  And we're not talking about actual form validation w/ js...just the format/aesthetics.

 

If you want to move forward with doing it w/ JS, the "how" is kind of page-specific.  If you have a framework like jQuery on your page, there are a lot of (relatively) super easy ways to add this sort of thing.  But it basically boils down to having a js wrapper function called in an onclick attribute, which appends a css positioned/marked up div in place.  I would suggest asking for help on that in one of the other forums (html/css/js) if you wanna go that route though, because it's kind of a separate topic from regex

[doubledee]

But IMO...this isn't 1990.  Very few people actually have javascript disabled.  I would advise you not to care about people who have javascript disabled.  I work in the web analytics business.  I look at numbers like that all day long.  But take it as my own opinion, nonetheless.  And we're not talking about actual form validation w/ js...just the format/aesthetics.

 

I don't deny what you are saying, but I am very 1990's and so far my website uses NO JavaScript and it looks and runs better than those that do IMHO.

 

I am also a nut on "Accessibility" and I always worry about people who won't be able to use or understand my site because I made silly assumptions like "They can see red, they can see, they can see the pop-up warning, etc).

 

You may disagree with all of this, but I know tons of web designers who would probably agree with me.

 

 

I would suggest asking for help on that in one of the other forums (html/css/js) if you wanna go that route though, because it's kind of a separate topic from regex

 

Ha ha.  Yeah, I forgot what forum I was in since this is getting all mushed together?! 

 

I think for now I will focus on more concise messages...

 

Thanks,

 

 

Debbie

 

 

[.josh]

But IMO...this isn't 1990.  Very few people actually have javascript disabled.  I would advise you not to care about people who have javascript disabled.  I work in the web analytics business.  I look at numbers like that all day long.  But take it as my own opinion, nonetheless.  And we're not talking about actual form validation w/ js...just the format/aesthetics.

 

I don't deny what you are saying, but I am very 1990's and so far my website uses NO JavaScript and it looks and runs better than those that do IMHO.

 

You are entitled to your opinion, same as me.  I don't necessarily disagree that it would "run better" without javascript in the sense that it would technically run faster, since you don't have that overhead.  "Looks better" is certainly a matter of opinion and at the end of the day, neither of our opinions really matter, it's the client's opinion that matters (though if you ARE the client, then well..there you have it ).

 

I am also a nut on "Accessibility" and I always worry about people who won't be able to use or understand my site because I made silly assumptions like "They can see red, they can see, they can see the pop-up warning, etc).

 

Fair enough, but red is just one color out of many...and it's just one markup out of many... You can certainly pick "more accessible" color/markups and follow the same principles...

 

 

You may disagree with all of this, but I know tons of web designers who would probably agree with me.

 

I'm sure you can find many web developers who keep things like accessibility in mind.  But web designers/developers who throw out javascript completely?  Sorry, but no modern web developer should do that.  Even my biggest name clients who literally spend millions of dollars on web design, UX efforts, etc... do not care about non-js users, even for their mobile sites.  As I mentioned, I do web analytics for a living.  I see the numbers from sites, big and small.  I see the decisions made by those numbers.  You say you know a ton of web designers who probably agree with you...I have cold hard numbers backing up my opinions.  I mean no offense, but you are stuck in the 90's on that count, lol.  But at the end of the day, it is just opinion.  To each his own.  If you are makin' people happy and makin' a living off it, who am I to say it doesn't work for you?

 

 

[doubledee]

You are entitled to your opinion, same as me.  I don't necessarily disagree that it would "run better" without javascript in the sense that it would technically run faster, since you don't have that overhead.  "Looks better" is certainly a matter of opinion and at the end of the day, neither of our opinions really matter, it's the client's opinion that matters (though if you ARE the client, then well..there you have it ).

 

You misunderstood me.

 

I am saying that my website runs and LOOKS better - in my opinion - than most of the garbage online.

 

My website is minimalistic and focus on simplicity and quality content and not JavaScript popping up in your face everywhere.

 

 

I am also a nut on "Accessibility" and I always worry about people who won't be able to use or understand my site because I made silly assumptions like "They can see red, they can see, they can see the pop-up warning, etc).

 

Fair enough, but red is just one color out of many...and it's just one markup out of many... You can certainly pick "more accessible" color/markups and follow the same principles...

 

My point was you NEVER rely on any color to communicate a message - especially an error message. 

 

Saying, "Required fields in RED" doesn't do a blind person any good?!

 

Screen readers can't see red either.

 

So back to the "Accepted Field Characters" issue, you would want to use something that everyone could see and hear and understand, which is why it is trickier, and certainly better discussed in a different forum.

 

 

You may disagree with all of this, but I know tons of web designers who would probably agree with me.

 

I'm sure you can find many web developers who keep things like accessibility in mind.  But web designers/developers who throw out javascript completely?  Sorry, but no modern web developer should do that.  Even my biggest name clients who literally spend millions of dollars on web design, UX efforts, etc... do not care about non-js users, even for their mobile sites.  As I mentioned, I do web analytics for a living.  I see the numbers from sites, big and small.  I see the decisions made by those numbers.  You say you know a ton of web designers who probably agree with you...I have cold hard numbers backing up my opinions.  I mean no offense, but you are stuck in the 90's on that count, lol.  But at the end of the day, it is just opinion.  To each his own.  If you are makin' people happy and makin' a living off it, who am I to say it doesn't work for you?

 

Again, you misunderstood my comments.

 

I was saying any web developer worth his/her weight would never rely on JavaScript or Colors to communicate essential information.

 

(I didn't say the masses don't do it, but I did imply that people who know what they are doing don't build sites that break when JavaScript is off or not supported.)

 

Anyways, everyone has differing views. 

 

Thanks for your help!!

 

 

Debbie

 

[xyph]

He's trying to help you, please don't pick a fight.

 

Youtube, Facebook, Twitter and Google all use JS to communicate essential information. Each of them has a feature-reduced, non-JS version of their application.

 

Please, refrain for telling web developers, what web developers would do.

[.josh]

I don't misunderstand you at all DoubleDee.  We just have different opinions, based on different things backing us up.

[doubledee]

He's trying to help you, please don't pick a fight.

 

Oh, right, I forgot, I'm not allowed to have a different view around here.

 

Back to your same ol' self I see...

 

 

Youtube, Facebook, Twitter and Google all use JS to communicate essential information.

 

Lovely...

 

 

Please, refrain for telling web developers, what web developers would do.

 

Why is someone on a PHP site telling me what everyone I know who is a Web Designer/Developer would say about accessibility?

 

 

Debbie

 

[doubledee]

I don't misunderstand you at all DoubleDee.  We just have different opinions, based on different things backing us up.

 

Okay.

 

 

Debbie

 

[.josh]

Why is someone on a PHP site telling me what everyone I know who is a Web Designer/Developer would say about accessibility?

 

 

I mean, as you say, this is a php site, so what would we know about it?  And as you say, you know a ton of web designers.  And as you say, they would probably agree with you.  I'm not really sure what you mean by "probably"...can you help me out on that?  Does that mean you polled them and they haven't decided yet? Or are you just making assumptions about their opinions?  Can you please clarify what you mean when you say that you know a ton of web developers who will "probably" agree with you?  And if their "probable" opinions outweigh some random people on a php site, why are you on a php site asking for help on this topic? 

[doubledee]

Why is someone on a PHP site telling me what everyone I know who is a Web Designer/Developer would say about accessibility?

 

 

I mean, as you say, this is a php site, so what would we know about it?

 

Based on almost everything I have been told on here about HTML, CSS, web design, web layout, accessibility, and so on I would say that most people on here know very little about those topics.  That is abundantly clear.

 

By contrast, if I need help with PHP, OOP, Apache, Web Programming, etc what do I think?

 

Well, considering that I spend a lot of time here asking for help on THOSE topics, I would say that most people here are very knowledgeable in those areas.

 

 

And as you say, you know a ton of web designers.  And as you say, they would probably agree with you.  I'm not really sure what you mean by "probably"...can you help me out on that?

 

I meant to say that anyone who says you should rely on color or JavaScript to communicate important content/errors doesn't know anything about Web Standards or Accessibility.  (Any of the gurus I know in those areas would fall over laughing.)

 

I said "probably" because I don't want to speak for them, but I have known them long enough and already know what they would say to basically speak for them.

 

But I'm not here to debate that.  I know the right way to do those things.  How others choose to do them is up to them.

 

 

Does that mean you polled them and they haven't decided yet? Or are you just making assumptions about their opinions?

 

It also means I was hungry for supper and didn't choose the best words...

 

 

Can you please clarify what you mean when you say that you know a ton of web developers who will "probably" agree with you?  And if their "probable" opinions outweigh some random people on a php site, why are you on a php site asking for help on this topic?

 

See above.

 

I would never come to PHPFreaks for help with Web Design, UI, UX, Accessibility, Front-End Web Development (what I call a "Web Developer") and so on.

 

Just like I would never ask the experts I know in those areas about PHP, OOP, MySQL, Apache, etc.

 

Why?

 

Because different types of people excel in different areas.

 

One of the smartest people I know with CSS couldn't code a Hello World program in PHP.

 

And the reverse is true as well.

 

The bigger point is, I stated that disagreed with some suggestions made earlier because I know from experience, from web standards, and from a lot of gurus I know that those are not the best choices.

 

No one has to agree.

 

But voicing my views politely is my right...

 

 

Debbie

 

[Philip]

I'm going to end this thread before we digress anymore. The original post has been solved thus we are now going off-topic.

 

PS - I'd really love to meet some of the gurus you know someday.