So I’m trying to create a subscriptions feature for the new Manna website that I’ve been overworking myself on for the past several months. Seriously, if I applied my hourly rate from my last job to the number of hours I’ve spent on that site, I’d have made about… $28,000. Yikes, I just calculated that and even I’m surprised. Anyway, back to the topic. The website has user generated content– blogs, wall (think facebook), photos– and I wanted to allow users to subscribe to content from other users. The steps involved:

1. Creating a database for subscriptions data (easy)
2. Creating a front-end for users to add/modify/delete subscriptions (time consuming but straightforward)
3. Checking new content against the subscriptions table and sending out emails accordingly.

For this last step, there were two methods I could take:

• Write a hook for the classes that save new content to the database
• Write a stand alone script that periodically checks new content in the db, and add the script to a cron job

I started with the first option, but soon realized that because users can set a future “publish date” for their items, the hook idea wouldn’t work, since it can only take action at the time that the content is created or modified. The idea is for subscribers to be notified whenever content is “published,” which does not have to coincide with when they are created.

So, I had to pursue the second option. The funny thing about Princeton’s server is that the user account does not have access to its own database. (Right now you should be saying, “wtf?!”) Apparently the user accounts are stored on one server, and httpd, mysql, and other web services are run off another server. The user accounts on the first server have access to the second server via a pseudo clone account, which gives you a home directory and lets you edit files, etc. However, only accounts native to the second server (i.e. apache) have access to the database. That means any script you add to your cron (which is stored on the first server) will not have permission to access the database, which makes option (2) impossible. Unless, of course, I’m a genius (haha, ok, I’m not, but let me gloat here for once. I’ve just realized I’ve given up over $28k for something I’m basically doing pro bono, and it’s making me feel nauseous, so I’ll take whatever delusional ideas of self grandeur I can that will take my mind off that.) Anyway, my solution was to use wget to make apache run the script instead of the local user, and add the wget to the cron. That way, the script is always run by apache which does have access to the database. Problem solved.