DC Doc Sprint

Submitted by Barrett on Sun, 11/09/2008 - 07:06
DC Doc Sprint

Yesterday I headed into the city for the DC Doc Sprint. We had some difficulties because the library had assigned us a room which didn't have wi-fi, but we migrated up to lobby of the Black Studies section and got going there.

My focus was on checking the PHP snippets in the handbook for compliance with formating standards. I used the Coder module with a stub module I wrote to do the checking. Since Coder can't check arbitrary code, I copied the snippets from the documentation pages into my stub module and ran Coder against that module. It worked well enough, but it would have helped a lot if Coder had an interface to allow someone to input arbitrary code for it to test. I've put in a feature request on the Coder issue queue. Maybe it'll make the grade and get implemented.

All in all, the event wasn't as interactive as I had hoped (I had gone as much for the networking as the actual work, being in the common area of the library just didn't support much conversation I felt) but definitely worthwhile. I got a crash course in the Drupal coding standard, learned about the documentation editing and creation process, and met some good people. I'll definitely be going again.

Barrett Sun, 11/09/2008 - 07:06

Tags

Blocking inappropriate usernames

Submitted by Barrett on Thu, 10/23/2008 - 08:26
Blocking inappropriate usernames

A question came up in one of the forum posts on drupal.org about a module to prevent inappropriate usernames.  A couple options were discussed, including using access rules and the abuse module.  Mostly as a learning exercise, I decided to try my hand at writing a module to handle the issue. The code I came up works with Drupal 5.x and uses the validate operation of hook_user to check for inappropriate names and return an error.

The module is not without problems, of course.  Specifically, it relies on a defined blacklist of names to block and won't match permutations of those names which would be obvious to people but which are not specifically defined in the blacklist (e.g., "b4dw0rd1" would be accepted).  On the other side, though, making the code more robust in terms of name blocking runs an increasing risk of false positives being blocked.  Also, in a production quality module, the blacklist contents and the error message returned should be defined through an administrative form rather than hard coded.  As a learning exercise, though, I count the module as a complete success.

Barrett Thu, 10/23/2008 - 08:26

Tags