24th Annual Scientific Research Poster Session

This semester our team will be contributing our work on Drupal to the 24th Annual Scientific Research Poster Session. The session is an opportunity for students at College of Charleston to display long term research projects that they have worked on throughout their undergraduate career.  Below is an abstract I wrote descibing our work and detailing our main goal of the project. This abstract is also being submitted for the poster session. (details here)


Applications of Open Source Software in Computer Science Education
Matthias Burrell, Stephen Davidson, Jennifer Green, James Rajabi, and Tatiana Taylor, Department of Computer Science

Open source software has a wide variety of popular uses within culture today, but education is not one of them. Most schools rely on capstones or smaller projects to teach software engineering techniques and experiences. The purpose of this project is to demonstrate how working on software of a significantly large scale, namely open source projects, provides a better learning experience for the student. This project also exposes the student to a greater variety of challenges and obstacles, much more than standard computer science education methods. Our open source experience came from the use of the website management software, Drupal. By experiencing the open source process first hand, our team was able to collectively show the advantages of open source style eduation in the software engineering fields. The experience we had provided substantial evidence for the benefits of open source. Through community involvement within Drupal, submitting bug fixes and patches, and discussing Drupal issues within the community’s IIRC channels, we accrued a brevity of experience that will be invaluable for all of our team members into the future. We saw this project as proof that open source software is an effective method for teaching student software engineers the core principles of engineering.


Back on Track!

After a nice spring break, and a good recharge it is time to get back on track. Our main project Drupal is buzzing and busy as always and took no rest, so I took a chance to review some of the bugs from our time line and see if anything has changed. Sure enough, one of the documentation bugs, Bug 1444650, was fixed by the community. They went ahead and tidied up the documentation. Then, Bug 1431512  was reclassified as a non-Drupal related issue and cannot be patched within Drupal itself.

A few lessons are learned from this experience. For one, I learned to be more assertive in tackling bugs. I should go ahead and be more forthright in assigning bugs to myself to prevent other users from patching before me. Also I must be more proactive in addressing bugs so that they are not fixed before I have a chance to look at them. Basically it is all a matter of time management. Bug fixing like all software engineering must be a well-timed and organized process. Without this focus in mind efficiency is sacrificed in both the project and project community.

Thankfully there was one more bug left of my three that had not been looked at yet. So for this post we will focus on this one. Bug 1438990 details a language error that occurs within Drupal. Essentially when a node contains page translations, if the translations are a subset of the entire sites languages then instead of using the default language for the page, the node will use the first language within the array subset. The bug reporter provides some good screen shots to demonstrate the problem.

Notice the array for the node; the language default is set to english:


Now notice that the language is not English but Bulgarian:


In my next post I will provide bug injection details and possible fixes (if time permits). Also I will be reviewing other possible bugs to add to my new revised list. Until then, keep on programming!

Bug Exercises Part One

While working on the team bug to be submitted Monday, each of us needed to complete some exercises in our open source online textbook. These exercises correlate directly with our team’s project and will prove valuable in becoming better at managing open source projects.

6.4 Find the oldest bug that’s still open in your chosen project. Write a blog entry describing the problem, with a theory about why the bug hasn’t been resolved yet. (Bonus points if you can actually resolve the bug.)

There is a bug that is 6 years and 27 weeks old. The bug is with the bug reporting system itself within a drupal project. Each bug can be classified in various ways. When it is classified as “patch (ready to be committed)” the bug is removed from the issues list. The bug was resolved in the comments but left open because of other issues discussed within the comments.

6.5 Figure out how to create a new account on the bug tracker of your chosen project. You’ll need that account very soon.

I had actually created an account a few days ago to post about a bug I saw. The name of the account is steveo1490.

6.6 Go through your project’s bug tracker and find a bug that you think you might be able to reproduce — and then try to reproduce it in the latest build. Take careful notes. Report your experiences as a comment to the bug. If you can reproduce the bug, great! Give as much information as you can. If you can’t reproduce the bug, great! Give as much information as you can, and ask the original reporter if there are other steps you might be able to take to reproduce the bug.

A bug I was working on this past weekend I was able to successfully reproduce. When in the administrative theme, the edit, add, revision, and delete pages will not come up properly if you change the lettering into anything other than all lowercase. I tried quite a few combinations such as Edit, EdIT, and EDIT. Each version did not show the administrative theme which shows the bug’s existence.

6.7 Find five bug reports in the newstate, and attempt to triage them according to the rules above. Your goal is to do as much as you possibly can, in a short period of time, to make those bug reports as useful as possible to the developer to whom they are assigned. (Note: be sure to follow any triage rules that your project may have defined. If there are no set triage rules, be sure to announce your intentions on the project’s mailing list, so that developers can provide you some guidelines if they choose.)

After reviewing some of the newer bugs. I noticed most of the bugs are triaged into the correct categories. The only slip ups I noticed that might make development and bug fixing more difficult is prioritizing. The Drupal bug tracker has four priorities: normal, minor, major, critical. Almost all new bugs were categorized as normal and some of the major bugs I looked at were either dupes, which I commented on and reduced the priority on, or were just not a functional issue. Being a nonfunctional bug lowers the priority down to at least the normal to minor level. I manged to change the priority on a few which I hope will give developers the right glimpse at what bugs need to be fixed now rather than later.

These exercises gave me a significant amount of experience with the bug tracker, as well as bug tracking organization. The triage techniques were also useful to learn, so I can use them in my future computer science projects that involve code maintenance. This Friday I will be posting about even more exercises that help foster my bug fixing talents.

Step 1 Building the Project Code

Time has finally come to begin our team’s main project. The first step is to build and install the source code for the project. In this case Drupal. After going online to Drupal’s installation site our team decided that Drupal 7.10 was the best choice for bug development. The latest development version is 8.00 but 7.10 still needs plenty of polishing so we picked the more stable choice. Once on the site I reviewed the thorough installation instructions regarding Drupal installation.

Drupal allows you to download either a tar or zip file of the source code to begin with. Then the code must be placed on a website which will act as your testing environment. For this step, James gave us use of his fusionro website and created a subdomain for the team. He placed these files onto the web page so that we can upload our bug fixes to it to test out and demonstrate. In order to move files however, we needed to choose a file transfer system. For this task we chose filezilla.

After opening filezilla, I logged on to the site using the credentials provided by James to look over the source files and php files to see what all Drupal contained. It was my first look at a FOSS project’s source code in PHP as well as my first time seeing source code from such a well maintained project.

But we are required to have the code built ourselves, and more importantly we need to be able to do it on our own in case we do not have an internet connection or because we want to play around without messing up with the official version. To do this we have to setup a home server to play with Drupal.

As mentioned on the wiki I took the following steps on my Linux computer.

  1. Download and install LAMP. (Vertrigo is a LAMP package)
  2. Download Drupal.
  3. Unzip the archive and rename the extracted folder to “drupal”.
  4. Open terminal and copy the “drupal” folder to “/var/www”.
  5. Open an internet browser and enter the URL:
  6. Enter the user and password that you created through step 1. Under “Create New Database”, type in “Drupal” and hit “Go”.
  7. Open and internet browser and enter the URL:
  8. Follow the instructions form the wizard and it will finish the setup for Drupal automatically.

I performed all these steps without any stumbling blocks along the way. Drupal completed its setup and the code was built. Step 1 of our main project was complete. Time to find our first bug fix.

Reporting in

This weekend our team met on Saturday and discussed our plans for Drupal. We constructed a team report and developed ideas about what we could pursue within Drupal as a main project. Below is a copy of the team report posted to our team’s wiki.


Drupal is an open source, CMS (Content Management System) for websites. Websites that are “content heavy” such as news, blog or media sites usually rely on a CMS in order to post, organize and update their content. The genius of Drupal, which sets it apart from other CMS’s is that it is very dynamic and flexible yet remains simplistic. Drupal uses what the developers have termed modules that serve as plugins to the website that perform specific functions such as updating news stories or posting blogs. However, Drupal is based on “manageable abstraction” which basically means that these modules, because they have all been written with certain standards in mind and connect to an underlying interface, can easily be taken apart like puzzle pieces and then put back together in order to create a completely new and original module. This allows the website developers to easily and effectively combine plugins in interesting ways with functionality that otherwise would not be possible without creating (or hiring someone else to create) a new plugin.



  • Dries Buytaert (Also the founder of Acquia and Mollom)

The rest of the members are purely within the community. There are no core developers or managers of Drupal at this time.


In the year 2000, a Dutch student, Dries Buytaert, decided to create a message board as a way for him and his friends to communicate at his university. Once Dries graduated in mid-2000 he wanted to maintain the message boards so his uni friends could stay in touch. So Dries decided to rename the site to “dorp.org” but due to a type named it “drop.org”. After the change of name, more and more people started posting on the message boards and slowly but surely the discussion of the boards turned towards web development. After a few months, these discussions turned into hard projects and were tested out on “drop.org”. Then in January 2001, Dries released these experiments in web design as an open source software package known as “Drupal” under a GNU license. The name is derived from the Dutch word “druppal” which means drop. As of today the latest version of Drupal is 7.10 released December 25th of 2011.

Source: Drupal History

How Drupal Works

Drupal uses a layered system shown below.

external image drupal_flow_0.gif
image reposted from: http://drupal.org/node/265726

  1. The first step are the nodes, which is essentially your input data.
  2. Above this layer are modules. These modules are used to modify and mold the data into a usable mechanism such as a clock or a calculator.
  3. The blocks and menus layer is the GUI of your modules. It provides outputs for modules and displays menu options for the end user.
  4. The fourth level is a security related level. In permissions the ability of which users are allowed to see your content is set.
  5. The final layer is template. The template is where the format and visuals of your entire site go. It is also where all these pieces of your site such as modules, menus, xhtml, css sheets, and php come together to form your final product.

Source: Drupal Overview

More on Nodes

Nodes are a key concept in Drupal’s design. It is Drupal’s way of storing information. Each detail such as the price of a car or the author of a blog post is considered a node. Because the data of each Drupal site uses the node system. Modules can easily manipulate the data and are much more portable in nature. They can be used in a variety of manners instead of being limited to a specific purpose. This uniformity is one of the great features in Drupal.

Source: Drupal Overview

Project Ideas

Our team has agreed that the best option for this term due to time constraints is bug fixing. Drupal uses modules as add-ons for websites essentially. These modules many times contain bugs that need fixing, which will be our teams main focus. We hope to use these bug fixes as a way to become familiar with the program and the process of communicating with the developers. Once we begin to feel comfortable, we plan to either create our own module to contribute to Drupal, or add on to an existing module.

Setting up Drupal

Installing Drupal is very simple. In order to even run Drupal there needs to be a dedicated web server. The web server needs several different applications such as MySQL, PHP, and Apache. Once these programs are installed, the source to Drupal needs to be pushed over to the web server. The source comes bundled together in a ZIP archive or can be downloaded from Drupal’s repository. Once this is done, using a web browser and directing yourself to the location of the Drupal server leads you to the install wizard. The wizard will make sure the required programs are installed and are at good versions, that the file structure is correct, and continue to ask for further user input to complete the install. The wizard will also help create an administrator account (nick named root) which will be used to manage the site.
The modules and the core on Drupal have separate CRON jobs which check for updates. The installation of modules is also a simple task. The administrator has two options, to either upload the ZIP archive from the computer or provide the link to the ZIP archive. Drupal will decompress the file, read it, and install it automatically. Just as you would uninstall a program from a computer, Drupal gives the options to disable or either uninstall modules.

Source: Drupal Installation Guide

This week we will decide which module we will fix a bug for to meet our deadline for our first bug fix. I will update our progress on determining a module this Tuesday.

IRC and Mailing Lists

Today’s task was to become a more active member in the community of our team’s selected project. In the last post I described how we had chosen Filezilla as our main project. Since then, our team has decided to move into a new direction and try Drupal instead. The reason for this switch is because Filezilla was causing too many problems during setup. Building the source correctly was more complicated than anticipated. Due to these constraints we all opted to go to our number two choice, Drupal.

As per the header of this post, IRC is one of the main goal’s of becoming involved in a FOSS community. IRC allows for quick communication between developers and contributors in the open source software development process. Using MIRC, I registered to the freedom node, and joined into a few of the Drupal IRC channels. The main channels I entered were the #drupal, which is the lounge channel, and #drupal-contribute, which is the channel for contributors. So far though the channels have been quiet. I am sure a part of this reason is that I am joining at about 12am when a lot of folks have most likely gone to bed. I will be trying again tomorrow afternoon to see if the traffic is busier.

The second step to becoming a part of the Drupal community was registering for the mailing list. Luckily, Drupal has categorized all of their mailing lists based of the needs of the user. The mailing list I joined was the development mailing lists, which lets you post threads and send mail straight to Drupal core developers. This tool will be very helpful in getting advice on advanced issues that may arise while coding. Below is a confirmation email showing my addition to their mailing list.

“Welcome to the development@drupal.org mailing list!

To post to this list, send your email to:


General information about the mailing list is at:


If you ever want to unsubscribe or change your options (eg, switch to
or from digest mode, change your password, etc.), visit your
subscription page at:


You can also make such adjustments via email by sending a message to:


with the word `help’ in the subject or body (don’t include the
quotes), and you will get back a message with instructions.”

Next time we will be taking a look at Drupal in more detail, and delving into ideas about specific project ideas, check back this monday for an update on project progress!