The Incredibly Lightweight, Amazingly Optimized CMS



  • I'm the sole, full-time website designer/develope for an international non-profit we'll call the Action Organization and this is a story about how NOT to build a web-based CMS System.

    I began working here in April of 2008. Back then there were two of us working on Action's website--I was hired as a part-time assistant. I spent my first two weeks sending out HTML e-mail blasts and setting up a small website for one of Action's projects, blissfully ignorant of the fate that awaited me. On the third week, it was time for my boss to train me on how Action's Content Management System and update Action's website.

    I had worked with several different CMS systems in the past (Joomla, Drupal, CMS Made Simple, etc.) and in college, I had also been a part of a team that developed the custom CMS used by every department at my large state university. So, with all of that experience under my belt, I assumed that learning how to use the CMS that controlled Action's 4000+ page website would be easy and fun. The CMS, I had learned, was a PHP/MySQL application which had been custom-developed especially for Action just last year. The work on it was done by programmers at our colocation facility in Canada, who I assumed, must be a top-notch bunch. And to control such a great and complex website, I thought it must be a really nifty piece of programming and I couldn't wait to get my hands on it.

    However, on that day, 3 weeks into my new job, I began to learn how very, very wrong I was. The first thing my boss explained to me was that

    From a user's perspective, I don't know how the CMS could get any more non-intuitive. My boss explained to me how there were 27 different templates and pages were categorized under those templates based on what sort of page they were (i.e. the Research department has one template while the Media department has another and different types of articles each have their own template.) You access the templates by clicking on the "buttons" at the top of the screen. Each button is round and red, about 40 pixels wide and has only enough space for 2 microscopic letters on it. So, using the CMS requires learning the meaning of 27 different (sometimes arbitrary) 2-letter combinations. If you're adding or editing a Research page you click the RP button, the Media pages are MP, events are EV, unencrypted forms are XU (don't ask me why) and so forth. Now, in the CMS there are also Values and Lists. Values are the different fields available to each template. Lists are groups of pages selected on the basis of specified criteria. For example, 5 latest articles or 10 upcoming events. Lists can be displayed anywhere in the website and you call them by using the ___list147___ keyword. (Replace the number 147 with the number of the list that you're using.) Sometimes lists had to do things to content, so they can have external PHP files attached. There are over 150 lists.

    By the time my boss finished explaining, my eyes were glazed over in disbelief. It was possibly the most ridiculous thing I had ever heard of. But, I mused as I went back to my cubicle, I probably just didn't understand. Probably, the code behind it was amazingly lightweight, and the database optimized incredibly well. It must be. Besides, I'd be able to learn my 27 letter combinations and my lists and values soon enough.

    Time passed, and soon I learned to differentiate my EVs from my XUs and IWs. The CMS and I were getting along well enough by the time my boss left the organization and I became the full-time website manager. About a month later, we decided to re-design the website. It would be easy, I assumed, just write a new HTML wireframe for the CMS, change the CSS files, and we'd be all set. And hey, it would be a great opportunity for me to figure out how the CMS works. I couldn't wait to start digging around in the CMS's amazingly lightweight guts.

    Only, as it turned out they weren't amazingly lightweight. I was horrified to discover that our year-old, "state-of-the-art" custom CMS was actually the most poorly designed program I had ever seen. In school I had been taught that Model-View-Controller was the holy grail of programming architecture and I assumed that most other programmers followed similar patterns, seperating business logic from display logic...but no. The developer who wrote this thing followed their own special brand of architecture which I can best describe as viewtroller. The business logic and the display logic (including lots and lots of inline CSS) were all mashed in together and then spread willy-nilly across about 15 different files, each of them hundreds or thousands of lines long, without a comment to be seen anywhere. ever. at all. I cried. And then I told my boss that the redesign was going to take a lot longer than I had originally estimated, and I set to work, trying to extricate the HTML and CSS and bring it into some semblance of an almost sane architecture. It was still ugly when I finished, but better than it was (and frankly, I still didn't now what half of it did so I was afraid to touch it.) And the upside was that while working on the project, I had spent some time getting to know the Canadian programmer who built the thing. Only, I found out that the programmer was a native Russian who just happened to live in Canada. In my phone conversations with the programmer, which were often hampered by the language barrier, the sources of the program's unweildy, awful design were often readily apparent.

    After the redesign, the CMS and I managed to get on tolerably well, until yesterday.

    Here in the office, we maintain an OS X Server running PHP/MySQL for internal use only. It runs an application that allows us to maintain a database of all media references to our organization (newspaper articles, blog mentions, et cetera.) Well, yesterday the IT guy and I decided it was time to update the OS and PHP/MySQL versions on that server, so we took it offline. About 15 minutes later, a co-worker poked their head in the door. "You know that the website is offline, right?" "Uhhhhhh...." I replied. No, I didn't know. I pulled up the website. Sure enough. It was displaying a lovely database error on every page. I checked other websites that were running from the same database--they were fine. Then it dawned on me. On about 4 of the 4000 pages in the Action website, we displayed some press clips. These were pulled directly from the downed Media server, by means of those lovely lists and external PHP files that I mentioned above. But still--why should the entire website be down, if the press clips only appeared on 4 of the 4000 pages? And how was I going to fix it? I called the Russian-Canadian programmer, but there was no answer.

    I fumbled around for about 15 minutes before realizing that every time a page loads, instead of selecting and processing just the lists that are displayed on that page, (because isn't that what any sane, normal programmer would do?) the CMS loads and processes all 150+ lists and their associated PHP files. This means that every time a page on our website was hit, our webserver in Canada made a MySQL connection to our media server here in the office and grabbed the 5 most recent articles (even though that information was only displayed about 2% or so of the time). And whenever that server disappears--whether it's because of an office network outage, power outage, or upgrading--our website goes down. It doesn't gracefully degrade, it doesn't just skip that part, it chucks a wobbly and falls flat on its face with face.

    I "fixed" the problem by completely removing all references to the media server.

    The punch line is that this morning, the programmer calls me back. "I am calling aboot your web problem," the programmer greeted me.

    "Yes," I replied. "Thanks for returning my call. Don't worry though, I got it fixed. There's no problem anymore."

    "Yeeees, ok, ok. Alright. OK but i am wondering--vhat vhas the problem?"

    "Well, it was a database error," I explained. "We took a server offline in the office for some upgrades and the website went down."

    "Ohhhhh, yes. Yes, yes. Right. It was your media server. Yes, the website--it, the CMS, is broken ven the media server, it is offline."

    !!!!!!!! By that time I wanted to scream. But I didn't. I told the programmer to have a nice day and hung up.

    Sometimes I daydream about moving the site to Drupal, or building my own CMS for it. But you see, I can't, because the database has 3 tables in it. Users, Keys, and Data. The fields all have names like field1, field2, field3, and so forth. Figuring out that mess and writing a script to import all 4000 pages into a different CMS would be horrible, it would be like...

    ...well, let's just say I wouldn't even wish that task on the Russian-Canadian programmer.



  • @websitediva said:

    However, on that day, 3 weeks into my new job, I began to learn how very, very wrong I was. The first thing my boss explained to me was that

    From a user's perspective, ...

    The suspense is killing me!



  •  Holy evil!

     

    I can feel the pain caused by slowly degrading into insanity...

     

    I would _definately_ start moving to drupal (or another OSS, community supported and living CMS of choice) no matter what. on the long run sorting out the data from the old db will be less troubling (plus it's a a job for a few interns who want to make money during the summer break, right?)



  • tl;dr





  • @websitediva said:

    It doesn't gracefully degrade, it doesn't just skip that part, it chucks a wobbly and falls flat on its face with face.
     

     For some reason that I can't articulate, I find this hilarious. I think "chucks a wobbly and falls flat on its face with face" is going to be my new phrase to scare users with.



  • @websitediva said:

    The punch line is that this morning, the programmer calls me back. "I am calling aboot your web problem," the programmer greeted me.
     

    Shouldn't that be "veb problem"? 

    Also, I'm now trying to picture what the South Park representation of a Russian-Canadian would be.  Floppy head with a Gorbachev splotch?



  • What a great story for some lunch-hour laughs. Thank you, websitediva.

    @websitediva said:

    If you're adding or editing a Research page you click the RP button, the Media pages are MP, events are EV, unencrypted forms are XU (don't ask me why) and so forth.

     Yeah, I worked with a UNIX schematic database where the directory structure used all TLA's.  Unfortunately, the TLA's were based on someone's idea of anglicanizations of the Chinese names for "Power supply", "Audio", "Radio", etc.  True confusion reigns.



  • @North Bus said:

    Yeah, I worked with a UNIX schematic database where the directory structure used all TLA's.  Unfortunately, the TLA's were based on someone's idea of anglicanizations of the Chinese names for "Power supply", "Audio", "Radio", etc.  True confusion reigns.

     

     

    True confusion reigns.

    Mysterious acronyms

    have unknown meanings.



  • @Kensey said:

    Mysterious acronyms

    have unknown meanings.


    Backronyms?



  • @Lingerance said:

    @Kensey said:

    Mysterious acronyms

    have unknown meanings.


    Backronyms?

    Unkronyms.



  • @North Bus said:

    Yeah, I worked with a UNIX schematic database where the directory structure used all TLA's.
     

    I used to work at a large pizza chain and the computer system used to use membrane keyboards. You'd press one button for a "large pizza" and then another for "Supreme", etc. But then the membrane keyboards "became unavailable" (I think really "too expensive to replace") so the operators had to learn all the codes the membrane keyboards sent as they got replaced with a 104 keyboard. (They were on wyse terminals with a single P166 running Linux as the server)

    Pretty much the only codes I remember are: NAZ was $5.95 voucher, PS for supreme, TS for extra cheese and TC for extra sauce (yeah good one fellas, but I think one letter was automatically added depending on the base: Thin and cripsy used 20g more cheese than deep pan, for example, to keep the varience under control), and GAR for garlic bread. As there were more than 26 toppings it was actually case sensitive so some things used lower case letters. Once you got used to it it was actually quicker but it did take time.

    Soon after I left they replaced the whole system (including backend) with a dozen Windows-based touchscreens - I wasn't involved but I bet there are lots of WTFs there as I heard mention of Access and the new system using 10x more database tables as the old system. Another fast food chain I know of used the same system and upgraded to Linux based touchscreens keeping the backend the same.


Log in to reply