Wherein I disqualify myself for work as a “drupal developer”
Self indulgent history part
Way back in 1999 when I started out writing web apps, Embperl seemed like the logical tool to use – so I’m used to having direct access to every step in the request-to-response process. In years since, I’ve progressed through a bunch of different tools and approaches, which have included writing a few rudimentary content management systems and using a bunch of prexisting ones.
Over the last few years I’ve become a big fan of ruby on rails, so if a site does much of anything (simple, recent example: The Food Project’s online summer program application), that’d be my starting point.
so, why use Drupal?
Even so, when a site is basically about some content that’s written and edited on an ongoing basis by other folks, Drupal starts looking like a reasonable tool. It’s pretty easy to get it to generate semantic output with reasonable URLs, and the editor-facing UI does a fair job of offerring a large degree of control and customizability without being overwhelmingly complex.
Despite having done some custom work on a few live Drupal sites, I still get confused about the best way to do some of the arbitrary web interaction tasks that were so straightforward back in the Embperl days. There are a billion modules in the Drupal ecosystem, but I often find that it takes more time to figure out if there is an appropriate one for my task & if it works with the current version of Drupal than it would to code up a solution on my own. Also, while I’ve made several attempts to solve programming tasks in what I understand to be the Drupal way, wrapping my head around all the relevant APIs (which can totally change every 6-12 months, with each Drupal release) similarly tends to take more time than bypassing Drupal’s functionality & handling things in Plain Old PHP.
Here’s a common approach I’ll take, then. I have no interest in extensive coding through a web browser (i.e. putting a bunch of PHP in a node or block), so I’ll set up a Drupal module to hold my application’s arbitrary php functions. Then I’ll create a page at the desired URL and enter a line of PHP to route the GET and/or POST to my code, as appropriate.
Example
I’m working on an email list signup that needs to communicate with a FileMaker database. An HTML form POSTs to http://thefoodproject.org/mailing_list_signup, which is just a Drupal page using the PHP input filter (which you now need to turn on via admin settings) containing <?php tfp_process_list_signup($_POST); The code for that function lives in sites/all/modules/tfp/tfp.module, and does the normal PHP things to pull information out of the POST & hand that info off to the FileMaker database. Here’s a bit of it:
function tfp_process_list_signup($POST) {
$reply = '';
$sent_plausible_address = FALSE;
if ($POST['email']) {
$supplied_email = $_POST['email'];
if (preg_match(PLAUSIBLE_EMAIL, $supplied_email)) {
$sent_plausible_address = TRUE;
$reply = "Thanks! We'll add your to our mailing list.";
} else {
$reply = "'$supplied_email' doesn't look like an email address to me. ";
}
//. . .
}
return $reply;
}
On the upside, this is quick & easy. The downside with this approach vs. writing a module the Drupal way is that I’m losing out on Drupal’s form API and its associated validation, antispoofing, etc. services. On the upside, last time I checked the linked documentation for the form API, it said
Warning - this page has only been partially updated for the Drupal 6.x API
Until it has been fully updated, reference this page as well: Drupal 5.x to 6.x FormAPI changes
so I’m quite happy to not have to wade through all of that!
]]>
Beware; there is a lot of enterprisey phraseology thrown around this space. In my more cynical moments I wonder if there’s a there there, or just a bunch of selling. One challenge is that it is often unclear what people mean when they use a phrase such as “Digital Asset Management”, “Enterprise Content Management”, or even good ol’ “Content Management”. Wikipedia’s ECM page seems like a good overview of what I take to be the bigger problem space.
over the last few weeks. It may be the most mind-blowing thing I’ve ever read, certainly in the last few years, if not decades. But I think I’m going to recommend reading another book instead.
If you are a public health professional, endocrinologist, or the like, GCBC is well worth the effort, because it would be important for you to see all the gory details where your profession went wrong, and what the evidence actually says. But for everyone else, I’m guessing there’s more profit to be had by checking out Taubes’ newer, shorter book