That slows me down but it’s not currently the main issue with paste2.org.

The issue I’m having right now is a design nightmare. I’m not a designer, a long way off it, I like to work on complex backend problems and design work doesn’t suit me in any way. I did the current design for paste2.org originally, back in 2006. The problem is it’s not really holding it’s own now, and it needs replacing.

I did a new design for the new code but quite a lot of people who saw it complained that the design was too bright when they’re working with consoles mainly – the white/grey design that everybody but paste2 uses – it seems isn’t up to scratch for people who spend most of their time in a white on black console.

I didn’t know this at the time I first put paste2 together, don’t think for a second it was a genius design decision – it just seems like it may have been a happy accident.

So anyway, I’m trying to put together a design that works and is dark but isn’t a catastrophe like the current one is, ideally I’d like a dark and light design so people can have a choice, like the new highlighter offers a choice of colours too.

The good news is that actually the code is actually fairly close to done, then I’ll need to write a migration script. Once I have this new code done and running on the site I’ll be happier about adding new features, like the collaborative editing I’ve been talking about for so long now!

One of the obvious changes between the old code and new will be the URLs, which will change from a sequential number system to an 8 (+ if ever needed) case-sensitive alphanumeric system that is randomly generated. This means a bigger key space (shorter URLs because there will be 6,000,000,000 possible pastes instead of 99,999,999 possible pastes in 8 chars) and it will stop people from trawling for pastes so much.

The other change with URLs will be the removal of the /p/ from paste URLs. All pastes will be accessed by http://paste2.org/<tag> rather than http://paste2.org/p/<number>. Old pastes will redirect (301) to the new URLs, so there will be no need for users to change anything.

The next update here I’m planning related to paste2 will be a public beta test.

I return a value so the class which calls this can replace the value back in the form if there is an error, and it actually replaces it in the data that is used (sent to the DB or whatever), I also use a custom validation exception class, these are all things that will need to be considered if anybody who sees it plans on using. Caveat emptor and whatnot.

What it does is sends the value to the PHP filter functions for validating as looking remotely like an email address, which is handy but it will validate local addresses and for domains that don’t exist.

What my code does is check if there is a remote address part and then if it is an IP just allows it, if it’s a domain it checks if the domain has MX records using checkdnsrr() – if that’s all good it allows it.

What could be improved? It doesn’t work so well at preventing local IP addresses going through. It also won’t tell you if the user is legit at a given domain or if the user has any association at all, so address validation will be a must in some circumstances, but it will prevent the standard dfgdf@dfdgdf.com type stuff. At least you’ll know if the domain part looks even close to reasonable, which is one of the ‘failings’ (read: missing features?) of FILTER_VALIDATE_EMAIL if you want internet-only addresses entering.

	public function email_address($value) {
		$result = filter_var($value, FILTER_VALIDATE_EMAIL);
		if($result == false) {
			throw new validateException("Invalid email address");
		}
		$domain = explode("@", $value, 2);
		if(filter_var($domain[1], FILTER_VALIDATE_IP) !== false) {
			return $value;
		}
		if(checkdnsrr($domain[1]) == false) {
			throw new validateException("Email domain doesn't seem to exist or is incapable of recieving mail");
		}
		return $value;
	}