Drupal in the corporate environment
I'm using Drupal as my framework to develop a whole bunch of web applications for my employer. For the most part, it has been really nice. There is a tremendous amount of leverage available by having so many parts of a web application already built for you.
The going has been a bit slow at times because of the challenge of debugging with Drupal's callback system for hooks, forms and theming. Often the smallest mistake results in a blank page. Or even more frustrating is when debugging SQL via db_queryd(), sometimes the output will be displayed and other times it gets swallowed in some never-neverland of Drupal that I've not yet been able to figure out.
The real items of interest in this topic are where the assumptions and limitations of Drupal run head-on into the reality in a corporate or other enterprise infrastructure. One such assumption is the requirement for each user to have a unique e-mail address. Drupal mostly works just fine with no e-mail address in the user record; I batch loaded all of my older framework's web users via SQL in the database, and the only columns I copied over were uid, username and password. So e-mail and everything else defaulted to whatever value the database table had specified.
This did mean all my users were blocked by default, which is actually what I wanted. But in order to administratively unblock a user, I'm forced by Drupal to provide an e-mail address. That's no good in my environment. I have no idea what my 4,500 users e-mail addresses are, and there is a good chance hundreds of them don't even have e-mail addresses.
I'll find a way to work around this problem. But it's assumptions like this which will be among the interesting problems I'm sure to encounter using Drupal as my enterprise-wide web application framework.
I hope to follow up with further postings about other quirks, limitations, assumptions and so forth which end up getting in my way.