Link Shorteners and a Call to Action

Some of you may know that I have a domain I use for link shortening: If you hit up the domain root, it redirects you to my blog. But if you go to a shortened URL, such as, it will redirect you to the proper page. I set this up using YOURLS because it seemed like the easiest way to get the domain up and running.

What you probably don’t know is that I have another domain that’s run off the same database. In any normal scenario, you’d probably want to split your databases on a per-service basis, i.e. separate personal from work, which is what this other project is. The reason I serve the same content is because I don’t shorten enough links to require two separate databases. And nobody can see the database anyway, so it doesn’t matter.

To achieve this, I symbolically link the work domain to Coincidentally, /www is also a symbolic link.

My vhost paths are strange, but they get the job done. The actual path for this domain is /var/www/ but that’s a different blog post.

/www/ looks like this:

And then nginx handles rewrites for any “directory.” If the path isn’t a directory (!-d) and it isn’t a file (!-f), then it rewrites to the YOURLS script. Note: this can be handled with one step using !-e.

YOURLS isn’t bad. In fact, it’s actually pretty cool. It records how many clicks links get, has a stats page with graphs for hits and traffic location, and there’s even a nifty plugin to make it produce links similar in format to other services, such as “pe4es” instead of “23,” the default format.

…What’s the problem?

While YOURLS is a pretty decent link shortener, there’s something about it not being mine that I don’t really know how to explain. Essentially, I think there are some improvements that could be made (both programmatically and aesthetically), so I might as well just write my own.

YOURLS follows what I would call a “Web 2.0” approach, a term which I think should have been shot before it was even incepted. Clients always say, “This design isn’t ‘Web 2.0’ enough.” or “Yeah, this is good, but can you make it more… ‘Web 2.0’?” These clients don’t even understand what “Web 2.0” is, they’re just trying to sound savvy and keep up with the latest “trends.” If crappy gradients / color schemes, extremely rounded corners, and ill-fitting typography is what it takes to fit in, then I want to be as far away from conformity as possible.

I digress. The YOURLS code is messy in my opinion. Understandably so, as I don’t think the project was originally intended to be as big as it is. But still another reason that it will be easier for me to start from scratch. I prefer an object-oriented approach. Plus, this way, I’ll be able to easily integrate the new system with my new CMS I’m working on… but that’s another blog post.

The “Call to Action”?

The world doesn’t have enough URL shorteners. So I’m going to create another. Most likely a PHP / Redis approach, because I’m looking for my first project using Redis. But it could easily end up a PHP / SQL project as well. It really depends on how my experiments with Redis go. (I’m not extremely fond of the idea of everything being in memory; I’m really just looking for a NoSQL approach.) It will have to have an import feature, though, so I can copy all of my YOURLS links into the new system. And some sort of API for plugin creation. I’d also like some sort of module-esque system (plugins) to enable features like public URL submits, a user system, etc.

Closing Irony

Some of you reading this clicked the short link, which is currently produced with YOURLS.

HTML, Javascript

The Search for an Efficient Form Validator

I’ve been working on a contact form for A6X. My plan was to do inline validation as well as serverside validation. Ideally, everything gets validated on the client end and the server just does a double check, instead of having to output an error message.

My conditions were:

  • the javascript validator needed to be HTML5-compatible
    • recognize html5 form elements, with graceful fallbacks
    • replaces built in html5 validation tooltips (i’m actually surprised at how bad these look in chrome…)
  • validate only after text is written, NOT specifically on blur/focus/click/mouseover(i’ve seen this before. why?!)/whatever
    • smart enough to not validate placeholder text
  • allows the option to either validate on submit or onblur (see above point)
  • ideally uses html5 validation methods whenever possible, with a fallback to inline js regex
  • submit button is disabled with javascript and enabled only when everything validates

Of course, I haven’t been able to find a single plugin which meets all of these conditions. Only one even comes close and I still have a lot of issues with it. For instance, I had to rewrite the phone regex because it was not flexible. The e-mail regex doesn’t even allow uppercase letters. Um, HELLO?!?! Lots of people add uppercase letters to their e-mail addresses to help distinguish specific words.


Tell me, which is easier to read? Exactly.

And I really don’t understand why most validation scripts validate directly on blur. Or on focus. Validation needs to work like this:

  1. Disable the form submit button on page load
  2. On input blur (input loses focus), check whether the input is a) blank or b) the placeholder text.
    1. If it’s the default text, do nothing.
    2. If it’s not the default text, validate it.
  3. If an input is determined to be invalid, it gets an invalid CSS class.
    1. You should be able to define how far up the DOM the class is added. I.e. parent or up the DOM until it finds a specific class/element/etc
    2. Any error message is enabled with this class as well.
      1. for example: .invalid .error-message {display: block;}
  4. If an input is determined to be valid, it either receives a valid class or does nothing
  5. Upon determining that everything is valid, the submit button is re-enabled.

No javascript? No problem. Since the submit button is disabled with javascript, any no-js browser will still be able to submit the form. And that’s where the serverside validation comes in.

Check out how the serverside validation would occur:

  1. With JS, you would either add/remove a hidden form element. In this case, we’ll add a hidden element called “uses-js”.
  2. When the form is submitted, serverside detection is used to see if a hidden element called “uses-js” is posted.
  3. If it is, the server assumes that the form is valid.
  4. If it isn’t, the server will validate.
  5. Once validated, the form gets its further processing (stored in database, e-mailed, whatever)

Obviously, this isn’t perfect. Any bot targeting the system directly could inject that input. And the form could be submitted using javascript from the console.

However, as long as you have some sort of anti-bot code and sanitize your data, you can just relax and move on. Note that I’m also a huge advocate for using alternative methods to CAPTCHA, but that’s for a different post.

I did just come across html5ifv which seems to be pretty extendable, but it still requires too much on my part to make it function the way I want.

It’s possible that what I’m asking for is very specific. But regardless, I think that’s essentially how form validation should be designed. I don’t think it’s difficult to achieve. I’ll probably end up creating something and posting it on github.

HTML, Javascript

The (almost) Perfect Phone Regex

While working on an inline form validation feature for A6X, I needed to be able to validate phone numbers. The phone regex with the plugin I was using was crappy and didn’t allow you to enter things such as an extension, or use (###) for the area code. Every validation plugin I used had, in my opinion, bad regex, which only took into account a small fraction of ways to type a phone number.

I wanted to be able to do things like:

  • Use (###) format for the area code
  • Add a +1 for a country code
  • Use . instead of –
  • Add an extension, etc

Yet for some reason, literally no regex that I found would allow for this in its entirety. So, obviously, I handcrafted my own.

This allows you to enter phone numbers in many different formats:

  • +1 is entirely optional, but still allowable
  • You can enter the area code with or without surrounding parentheses (###)
  • Numbers can be spaced with spaces, a . or a – (or nothing) – such as 123-4567, 123.4567, 123 4567
  • You can optionally enter an extension
    • Allowable formats: “ex”, “ext”, “extension” followed by a space, a . or a – (or nothing) and then some numbers

The only reason I say it’s “almost” perfect is because while loosely designed around US numbers, it may/may not validate for other countries. Any country with seven digit numbers should theoretically validate. And of course, there’s probably the case where someone wants to enter a weird character like a tilde (~) or something, which isn’t supported.

Regardless, though, I think this is the most effective regex for a phone number I’ve seen on the internet.