(So, so tired of trying to figure out why I can't post these long-winded explanations at times. Context here.)
On a certain level, it is how the web is built. And along the same lines, a class in Drupal (or any other CMS) would be like taking a class on MS Word. Practically useful in that you might gain expertise in a common application, but there are whole areas that it locks you off from learning about that might be more applicable in a different type of course.
When I think about the number of web-related things I either helped develop or currently support on a regular basis, they cover a huge range of toolsets and complexity (obviously the development ones are much, much simpler):
- Guild’s CMS: I didn’t write this either, but I have to know which buttons to press when, and which settings to fix to allow people to post their own items to the front page. The decision of which CMS to go with ended up being the one that was an addon to the already-selected forum software. I had gotten tired of buggy modules that would combine the authentication lists from the forum and the CMS, and decided that a standalone CMS just wasn’t worth it.
- Guild’s roster: I wrote an initial set of bank pages there. Raw PHP and SQL, starting from a similar set of pages used for personal inventories.
- Personal site/blog: all in WordPress. I mostly want the site for the blog; other types of pages are less important, and can mostly be done in WordPress.
- Work site: almost entirely done in the Plone CMS. Why a CMS at all? Because I wanted full-text indexing of all the content so that people could search for “MATLAB” and get some relevant documents back, without relying on Google like the main university site does. And so that I wouldn’t have to go to a lot of effort to get a consistent page layout and focus on writing the page content. Why Plone? Because at the time I started getting into this, the usual PHP-based CMS systems were constantly getting compromised with buffer overflows and other security problems.
- Work blog: WordPress again. I could get a blog for Plone, and it would have the advantage of putting all the content into one big searchable database, but Plone doesn’t have anything as good as Spam Karma 2 to keep the spammers away.
- Site at work that lets Helpdesk workers preview large-format plots before releasing them to the plotter, or deleting them outright: good old Perl CGI and HTML for the front-end, and a slightly oddly-configured Apache server that has permissions to manage the printer queues on the server. I did use a Perl module to help write out the HTML rather than hard-coding it all in regular print statements. Why Perl instead of PHP? Because there are a grand total of two pages on this entire site, CGI is good enough for the limited things it needs to do, and at the time, my PHP was much rustier than my Perl.
- Site at work that lets selected students and faculty view still images and animations from Axis IP cameras in their labs: Python code that grabs images, converts them to FLV format, and writes out an XML playlist for a Flash-based media player. Also a PHP file that makes a page including links to all the still images, shows the video player, etc. Why Python? Because it’s much cleaner looking than Perl, and I stand a better chance of reading it in the future. Why PHP for the front-end? Because I know it enough to get the job done, and these pages aren’t that complicated.
The point of all that rambling is that a CMS isn’t everything, but has its place. And being able to write stuff outside of a CMS is important at times. And that you’re not likely to use the same toolset for 10 years at a time.