I got mail from another honest to god Accountify user today! w00t!

He pointed out that Accountify assumes it's okay to send emails "from" whatever the default from address is for PHP, and that this is wrong wrong wrong. So it is. So I fixed that and put out Accountify 2.02. Which also kicks the "obvious yellow error message background" fix from the World Birthday Web out there for other sites to use.

The point of Accountify is to enable webmasters to easily add accounts to their sites. Want people to be able to create accounts and log in? Want to easily associate information with the logged-in user and help them edit some custom account-specific settings and so on? I give you that.

Of course, the level of interest in this sort of thing isn't quite what it was before Facebook applications became such a popular option. Why build your own account system when Facebook users are already logged in? There are answers to that question ("because you want more control," "because you don't want to get totally pwn3d if Facebook clones your app internally," etc) but clearly a lot of designers don't find them compelling.

Nice to take a breather from Facebook develpoment for a few minutes. But I need to dive right back in. I have a lamentably frivolous and therefore popular application to write. (;

Tags: accountify, boutell.com, facebook, identity management, work

Yesterday and today I rewrote the World Birthday Web as a PHP-based site using Accountify. I needed a quick real-world test, and the WBW badly needed an overhaul. It was written in C, y'know. In 1994. And there were no user accounts. If you wanted something changed later... you emailed the webmaster!

Surprisingly, hardly anybody does email me about it, which is why I didn't get around to this sooner. But many users probably avoided it completely because they saw no way to make changes all by themselves.

Regarding aesthetics, I should mention that the World Birthday Web was always very basic. And yes, it's still pretty darn plain-lookin'. But hey, whaddaya want in this kinda time frame?

In the process, I found exactly one (1) Accountify bug. More accurately, it was a lame missing feature that I mistakenly thought could be lived with for a little while. Uh-uh: when accounts are deleted or closed, any session currently in progress should be invalid right away. So Accountify 2.01 is out, with that three-line fix.

The World Birthday Web has a population of roughly 12,000 people. So I should expect to hear from real live users if the WBW— and Accountify— don't work as they should.

We had 130,000 users when we shut it down in the late nineties due to the spam problem. Yes, when this thing was first set up, it was an open registry of birthdays with email addresses. We were all pretty naive in 1994. (: When I brought it back a few years ago, I altered it so that all greetings had to be sent through the system, thus keeping your personal email address a secret. This worked, but entering another darn CAPTCHA for every darn birthday greeting was a pain. Accounts should alleviate the need to be quite so... bruisingly strict. Though I should add per-day limits on birthday greetings sent by one account, and I'll do that soon.

Phew. A disgustingly responsible evening. I'm heading out to see the Dumpsta Players before this case of productivitis spreads to my appendix.

Tags: accountify, boutell.com, geek, wbw, web, work

Accountify 2.0 is out. Accountify is a PHP library for adding accounts (logins, identity management, whatever you wanna call it) to any web site built with PHP.

Accountify 2.0 does a whole lot of cool new stuff:

• Supports invitations, from you or from users of your site
• Lets you decide who has invitations to give out
• Allows both invitation-only and invitation-optional sites
• Makes it easy to collect extra information from the user at signup time
• ... And lets users edit that information later (if you want to let them)
• Well-thought-out system for validating, writing, and erasing that information
• "Wizard-style" account creation, "tabbed-style" account preference editing
• "Must be 18 / collect date of birth" and "terms and conditions" samples included
• Provision for callbacks when an account is closed or deleted
• Built-in session manager safe for use on shared hosting (easily disabled)
• Support for reopening closed accounts
• Freestanding pages for bigger tasks— no more overuse of "float: right"
• Cross-browser, cross-platform, excellent behavior when JavaScript is turned off
• Runs without warnings even in strict mode in both PHP 4 and PHP 5
• Allows for fields in $_SESSION that don't get stored with the account

... There's more. It rocks, IMNSHO. I am well pleased.

I've kicked this one out under a dual license: GPL 3.0 and my own commercial license. I did something similar with the CGIC library and that has been profitable over the years, though I'm offering slightly different terms with Accountify.

Two things I'd wish for: a more interesting demo and a more attractive "out of the box" look. But hey, the chrome files are all editable and I never claimed to be a graphic designer. Accountify is for people who know how to build web sites and even know PHP, but have no interest whatsoever in reinventing the wheel.

And now I have a social networking site to build! Based on Accountify 2.0, of course.

Elephants? Ticker tape? It's go time.

[Taps foot impatiently, remembers he's in an airport, stops tapping]

Tags: accountify, boutell.com, geek, web, work

A brief burst of geekspeak follows:

Accountify survived the PHP5 test.

Most of the time involved went into making sure I had all the required packages on my virtual Red Hat Enteprise Linux 5 box, then dealing with gajillions of warning messages generated not by my code but by PEAR and PEAR::DB... which are standard parts of the PHP puzzle. These need serious cleaning up, but not by me. I know I should be using the more modern PEAR::MDB2 instead of PEAR::DB, but I hear that spews warnings too. More importantly, using PEAR::DB allows my code to run on both PHP4 and PHP5, and I'm really not paying much of a price for it. That's particularly nice because boutell.com itself is still on Red Hat Enterprise 4, which means PHP4 and no MDB2.

To be fair, I'm writing Accountify with strict warnings turned on, and a distressing number of PHP programmers seem not to. This is just as valuable as the -w and use strict options in Perl and everyone should use it. Although I quickly wrote a wrapper function so that I can treat a missing POST form field as an empty POST form field without being verbose.

In addition to all of the annoying warnings produced by core components of PHP, I did find a few honest to god bugs in Accountify and fix them, thanks to PHP5's even stricter strictness.

Tags: accountify, boutell.com, geek, php, web, work

... Yeah, still a little ways to go.

Accountify's next release is looking good after heavy testing and tweaking today, but next I'm testing it under PHP5. And as the man says as he jumps into the garbage chute, I have a bad feeling about this.

Still, if it passes, it's conceivable that I'll release Accountify 1.3 (2.0?) today or Monday.

The big news is that this release allows you to easily add new pages to your web site's account creation process, pages which can also be reused when users edit their settings later.

Want to keep track of birthdates? Ask if they are 18? Make people agree to terms and conditions? Find out their shoe size before you let 'em on the dating site? Sure, go nuts. Write a few simple PHP functions specifically to do your thing and snap 'em right in. When the user moves back and forth between account creation pages, wizard-style, or moves from tab to tab while editing settings, Accountify makes that more or less transparent to you and re-presents the right form fields. If something the user has done while editing their settings requires a password, you can indicate that and they will be prompted once at the end of the editing process. If a page doesn't need to be displayed again once the user deals with it correctly, such as a CAPTCHA or checking "Yes, you may have my firstborn" on the terms and conditions" page, you can easily indicate that too.

Want Accountify to store all this extra data for you? Sure, that happens by default. Want to store it in your own database? No problem, add writer and eraser callbacks. Yes, of course Accountify helps you clean up after yourself. It wasn't coded in a barn, you know.

Birthdate and terms-and-conditions pages are included in the box as working examples of how to extend Accountify.

There are many, many, many other changes and improvements, notably strong support for invitation-only and invitation-optional sites. I'm excited. And it'll be done. Any minute now.

Tags: accountify, boutell.com, geek, web, work

( IE and Firefox love to submit forms for you when you press the Enter key. Corporate sysadmins love to needlessly disable JavaScript. Tom loves to throw heavy objects. CSS to the rescue. )

Tags: accountify, boutell.com, css, geek, html, web, work

( In which Tom wrestles with the inner PHP madness and adds an optional built-in session handler to Accountify 1.3. Which is STILL not out. )

Tags: accountify, boutell.com, geek, php, web

So I've been grinding away on the next release of Accountify. This thing has grown a bit, not catastrophically but it's a bigger project than I first imagined.

Little things, like support for invitations— both from the administrator, and from existing users— involve a surprising amount of complexity. Especially when they interact with other features. For instance, it's perfectly reasonable to want a site where existing users can invite people, but the admin must still approve the acount before it goes live.

Coping with invitations forced me to bite the bullet and generate independent pages for big tasks. They really shouldn't be squeezed into a "float: right" sidebar.

Also, in the process of adding support for changing the user's email address— I formerly tied accounts ferociously to email addresses, on the philosophy that verifying email addresses is something that slows spammers down a little and gives you a connection to your users— I noticed that I was requiring a confirmation email to do change your password or close your account. I wanted to block folks who sit down at someone else's terminal from easily swiping the account entirely. But simply requiring the user to re-enter their password on that form is equivalent, and a lot less work for both me and the user.

You can reset your password if you still have your email address; you can change your email address if you still know your password. But if you've lost both simultaneously? Um... no. Make a new account and don't be such a putz this time.

Seems reasonable to me, but I'm curious to hear other opinions on this policy.

When this release is done I plan to stop extending it and use it in a long overdue rewrite of the World Birthday Web, which has been a working example for one book already. I wouldn't be surprised if it soon appears in another. And then I have several wacky ideas for additional fun/useful Accountify-based sites.

Tags: accountify, boutell.com, geek, web

Edit: I renamed it "Accountify" upon realizing that no one can find "Accountable" easily via Google.

Accountify 1.2 is out. Accountify lets you add logins to a web site.

This version supports manual approval of accounts. That is, when you apply for an account (a login) on a web site that uses Accountify, it's possible to set things up so that you don't get access right away. (*) The administrator is notified, and then they decide whether to let you in or not.

In other words, Accountify is now suitable for private sites right out of the box.

I had imagined this was very easy for an individual webmaster to build on top of Accountify, but when an honest-to-god Accountable user asked how to do it, I realized there were too many fiddly bits involved and too many people who would need it. Time to bake it right into the pie.

I've also given Accountify a home page of its own, and made the list of requirements easier to find.

In the near future I'll be adding built-in support for membership invitations (admin-to-user and user-to-user), restriction of access to content (including images), and probably subscription payments as well. Hopefully I'm reaching a critical mass where enough people will be using Accountify and providing feedback on it for me to (a) know what people want to see added and (b) get some consulting gigs setting it up "Just So."

(*) In any case, Accountify always requires you to click a verification link in an email message before it lights up a new account. This increases the cost of doing business for spammers and ensures there is a valid means of communicating with the user. The new approval mechanism comes into play after the user verifies their email address, so admins don't get bombarded with emails about never-verified accounts.

Tags: accountable, accountify, boutell.com, geek, work