Blog O Stu

I have been trying to work with some web developers that have been hired to create a new site for one of the departments at the University (where I work as a programmer).

I was amused by the first request for FTP and control panel–I’m guessing this means CPanel–access to our Drupal site. We don’t use FTP–it is unnecessary  it with Drupal–and we certainly don’t use CPanel! My first estimation of the skill-level of the person making the request was quite low. I guess these folks are used to charging big bucks to set up an eight page web site using cheap shared hosting.

FTP? Seriously?!? Universities dropped plain-text password FTP protocol years ago in favor of SSH. While FTP and SFTP (via SSH) were useful back in the static HTML days, they seem useless for CMS-based sites, like those we build with Drupal and WordPress.

<aside>I understand that I am quite a snob when it comes to computers and web sites: I write web apps using vim.; I compile Apache and PHP myself, in order to tune them for the hardware and ensure that my installs have only the modules I actually need. Hell, this blog lives on a VPS machine as opposed to some silly hosting-with-training-wheels server.</aside>

OK, back to the request. The third part of the request was access to our Drupal site. Since we’re a largish public institution, we have tons of rules, laws and policies. This request was subject to our web policy, which requires that all Drupal users be vetted by the website leadership team. Of course, the team unanimously said, “no!” Partly because we have no way of knowing the skill set and trustworthiness of the individual(s) requesting access. The biggest reason was that access to the Drupal site would be little help in copying the site. It would be much easier to rip the site using wget–or whatever the Windoze equivalent might be–than trying to wade through and copy the content via the Drupal interface.

In lieu of this, in case it was beyond their mad skillz,  I offered to provide the content of the pages ripped to HTML files and zipped, guessing that .tar.bz2 and .tar.xz are meaningless to them. They asked for the rip ‘n’ zip. (Why am I not surprised?)

I wrote a script to grab the page content from the MySQL database from which Drupal generates the site and create a directory full of HTML files. Then I began an audit on the published pages, to see which ones are used and which are outdated, left-over, redundant or otherwise useless. Before I could finish the audit, I receive a message demanding the files and threatening to charge the department for whom the site is being built for copying the 100+ pages.

100+ pages? WTF?

Here I am looking that the 76 pages that are published on the site. Fine . . . no problem . . . I sent the .zip file with the 76 pages plus and index generated by my script and a couple .css files to make it all a bit prettier. Then I proceeded with my audit.

Sure enough, after my audit, my unofficial page count was 53 useful pages. I decided that, perhaps, the venerable website professionals were confused by the 59 course pages.  I attempted to explain that these pages are all generated by a single script. I can see how the appearance confused them: there are 59 different URLs.

Well, well, well . . . perhaps I should share the magic. Not with them, just yet. Rather, I’ll share it with you!

Apache web server can do really neat tricks with mod_rewrite. What I did was write a PHP script that will display information on a single course using information stored in a MySQL database. Then, using a couple of Apache configuration commands, got mod_rewrite to make this script appear as different URLs.

RewriteCond %{REQUEST_URI}  ^/DEPARTMENT.*
RewriteRule ^course/COURSE_PREFIX1(.*) /DEPARTMENT/courses?course=COURSE_PREFIX1$1 [L]
RewriteCond %{REQUEST_URI}  ^/DEPARTMENT.*
RewriteRule ^course/COURSE_PREFIX2(.*) /DEPARTMENT/courses?course=COURSE_PREFIX2$1 [L]

So, one script and two rules provides 59 URLs (not 59 different web pages).

It gets crazier: we have 7 departments. My single script along with 11 RewriteRules–one for each of the 11 course prefixes–provides 506 URLs with distinct output. But that’s not all. By adding another 11 RewriteRules, another 506 URLs display the same content with different wrapping in the “all courses” section of the college site!

So, one file on the server along with 22 RewriteRules and a database table with 506 records show up as 1012 URLs. Man, I do love PHP and Apache! (Back in the days of static HTML, this would have taken 1012 files on the server.)

I laugh at your 100+ files!

The response I received to my attempt to explain the groovy data-driveness was, “Oh, yes, I’m sure the new site won’t have any content at all. Just some graphics and happy face cartoons.” Smell the professionalism!

For the time being, I responded with a thank you for the sarcasm with the request, “Please remove me from this project and continue without my disruption.’ Then I logged on to the project management site and attempted to delete myself from the project. This, of course, was not possible.

So, I created a new alias on our mail server (devnull@oursite.edu), forwarded it to my junk mail collector account and set it as my email address on their brain-dead project management system.

It seems every day I become a bit more like the BOFL!

Update: It looks like our web professionals have decided to break university computing policy and are logging in using a faculty member’s credentials. I wonder if they figured out that I told them the truth yet!?!

So, do you ever get those emails from constantcontact.com? The spammy stuff from that wonderful company that requires clients to use opt-in-only?

I finally got fed up with messages from places like United Way of the Bluegrass and The Lane Report who added me their lists without my permission.  Sure, I clicked the unsubscribe link in the messages, but it seemed like I was getting added to a new Constant Contact list every week.

I decided to do something: I called Constant Contact using the toll-free number on their web page. After a short wait, I spoke to Derek (no last name) and explained to him that Constant Contact clients were adding my work email address to their lists without my permission. I asked if there was a way to have my email address removed from all of their client’s lists. He told me “yes,” and transferred me to customer care.

Another short wait later, I spoke to Mike (again, no last name–perhaps they are brothers!). I told Mike that I wanted to be added to the do-not-spam list. Of course, he had never heard of this and assured me that no such list exists. Ever helpful, he suggested that I click the unsubscribe link in the messages.

I explained that I seemed to get added by yet another Persistent Prattle customer every week and that I was growing tired of the unsolicited messages.

Again, he assured me that Constant Contact does not have a do-not-spam list.

I suggested that, being postmaster@where-I-work, I should block all mail from Constant Contact. He pointed out that I might, in the future, want to receive messages from Constant Contact clients and again suggested that I should just click the oh-so-easy unsubscribe link. I told him that my work email address is for work and that if I ever did choose to be spammed by Constant-Pain-in-the-Ass, I would use my personal email address. Again, I said that the obvious answer was to block all messages from Constant Crapola on our server. Using his mad skillz in customer care, he said that he would gladly give me the list of the servers from which Constant Blah Blah Blah sends messages if only I would give him my email address. I laughed!

I carefully explained to him that I was calling to stop the email from Alliterate Annoyance and that it seemed counter-productive to give my email address to the very source of the messages I wished to terminate. I offered my assurances that I could use whois all by myself to get the netblocks I needed to shun. Once again, he asked for my email address in an heroic effort to save me the trouble of opening a shell and typing. I declined.

After saying our fond farewells, I looked at the header of the most recent message I received from Everlasting Burden and grabbed the server IP: 208.75.123.135

Using whois, to locate the netblocks, I set our mail server to reject everything from the following:

205.207.104.*
205.207.105.*
205.207.106.*
205.207.107.*
208.75.120.*
208.75.121.*
208.75.122.*
208.75.123.*

For the sane and rational among you, that is the end of the story.

For the rest . . . well . . .