With room to grow once again, I’ve been working on the other features I planned for W3Counter back in the fall. The main task, which I hope will allow me to sell to bigger customers than my normal $5/month individual webmaster, is providing private instances of the entire service. The plan is to have three distinct products in the next six months — the hosted, individual service; a white-label private instance for designers, service providers, and networks of many websites; and a white-label version of the entire service for resale.

The last is something I haven’t discussed before, but not a huge leap from the white-label instances. With a billing module that allows an administrator to plug in their Authorizenet API key and PayPal account instead of using my own, someone could sell W3Counter under their own name at their own price easily. With the new architecture, their instance can scale as easily as mine by adding servers as needed.

I don’t want to maintain 3 separate code-bases though. That would be a major hassle to maintain, porting bug fixes and features between the three each time a change is made. I’d much rather have just one which can act as necessary through a simple configuration switch I’d only have to make when the instance is created for a new customer.

I’m doing this with Symfony’s filter chain. The settings for the main W3Counter instance upon which all the normal accounts run are set in the application’s settings file (app.yml in Symfony). These include things like the name of the site, logo image, colors, rows per page in reports and time zone. They also include switches related to whether the application is running in ‘W3Counter mode’, ‘private instance mode’, or ‘reseller mode’, such as whether the account area includes the ability to upgrade a plan and whether the signup form is enabled.

By adding a filter class to the chain before the execution stage, I can look up overriding settings in a configuration file or in the database. On the main W3Counter instance, these won’t exist, and the ‘W3Counter mode’ settings will remain in effect. On a private instance, they will be present, and the filter class can call the sfConfig class methods to set new values for all the settings before they’re read during execution or rendering phases.

In the future, another link in the filter chain can do the same for individual user settings. An individual user can override some of the application and instance settings with their own, such as their local time zone and preferred rows per page or color scheme.

A nice side-effect of writing the code for all this is that I finally have a back-end administration area for myself. I never take the time to write them for my own use; I just muck around with the database directly. Now I’ll have an interface for managing users, plans, and application options too.