I'm just finishing my second year of an IT degree at the University of Technology, Sydney. Over the course of the past few months, I was working on a major assignment in which our grade was split up into teams of 10, each of which had to complete a full software development project, involving everything from requirements analysis, to design, to coding, to testing and documentation.

During this project, our team developed what may well be the lightest version of Drupal core ever created. Upon this ultra-light but still useful code base, we developed our system.

The project

Our project brief was to develop a 'Casual Academic Register': a web-based system to facilitate the following things within the University's Faculty of IT:

  1. People interested in casual teaching positions should be able to look for subjects, and find information such as current teaching vacancies in relevant subjects, timetable lists, and contact details for staff co-ordinating subjects within the faculty;
  2. They should also be able to lodge an application online, giving their personal details as well as the subjects and positions that they're interested in teaching;
  3. After lodging an application, University staff may approve or reject their applications, and they may come back and update their applications at a later date;
  4. University staff can search for people who have submitted an application, filtering by relevant subjects, classes, etc, and should be able to contact applicants by email, and to view the employment history of applicants who have already worked for the faculty;
  5. DB administrators can add to and can update the list of subjects in the database.

The choice of development tools was up to us, as long as they worked in the University environment, which was: *NIX (Solaris) server; MySQL 3.x; Apache; Perl / Python / PHP / JSP. Our team chose PHP, and after some persuasive talk from me, we also decided to use Drupal as the foundation of our code.

Giving Drupal the biggest makeover of all time

As can be seen in the brief above, this project is not exactly what Drupal was designed for! In fact, this project may be the most unique use of Drupal as an applications framework to date. As such, I had to transform Drupal radically before it was ready to be used as the code base for our project. In particular, an enormous amount of code that was not in any way needed had to be deleted from the code base.

First, I checked out Drupal HEAD from CVS (checkout performed on Oct 1 2005 - about a week before the Forms API was committed, I think). Then, I deleted the /misc directory, and everything inside it (good bye and good riddance, drupal.css!). Next, I deleted 30 of the 31 core modules from the /modules directory, leaving absolutely nothing but user.module. That's right: I successfully removed block.module, filter.module, watchdog.module, and even system.module, and still had a reasonably well-functioning code base. I then had to go through all of the .inc files in /includes, and remove all dependencies on these core modules (mainly watchdog).

The next big task was to make Drupal core object-oriented. I didn't do this because I'm in love with the OO way of doing things, or because I'm trying to make a statement that Drupal should be OO; I did it because my team had decided that the whole system would be OO, so that's how it had to be done. It was simply a question of following the specification. All I did was wrap the contents of each core file in a class, and convert all the function calls to method calls. This was a boring and tedious job, and certainly not one that I'd recommend to anyone. More discussion on this later on, though.

I also removed some other important core functionality, such as caching, URL aliasing, localisation support (yes, I completely removed t() from the code base - way more trouble than it's worth), and the xmlrpc library. I re-introduced the PEAR library, in place of database.mysql.inc and database.pgsql.inc (once again, team decision); and I removed the core themes and theme engine (bluemarine and co. + phptemplate), replacing them with the Smarty theme engine and the box_grey_smarty theme from contrib (again, team decision).

After all that, I was left with the lightest and most bare copy of Drupal known to man. But it worked!

Building a completely custom web app with Drupal

Once we had our 'Drupal Lite' code base ready to go (and committed to our own SVN repository for versioning), we started coding our application according to the project brief. The entire project was coded in 8 modules, which were separate from the core just as Drupal modules always are. This included access.module (the access control parts of user.module, moved to a separate module), and user.module, which we heavily modified to fit our brief.

Most of our code was fairly standard CRUD stuff (Create / Read / Update / Delete). Our code base only had 5 module hooks left in it (init, exit, menu, perm, and user), and of these, we only really used _menu and _perm in our modules. However, you cannot underestimate just how beneficial it was, even using only these two hooks!

The theming system was, of course, a huge time saver. The entire presentation layer of the system was coded using Smarty, with the {theme} and {url} (and some other) functions provided by the Smarty theme engine. The ability to override the default theme('page') template, by simply print'ing your own template and returning nothing, was also helpful when we made popup pages. These pages were outputted using their own (extremely spartan) template, without the need for an entirely separate theme. Before long, our template design crew had transformed box_grey_smarty into the 'uts' theme, which closely resembled the design of the UTS IT Faculty web site.

Major problems encountered

While Drupal was an enormous help to our team in getting the 'CAR' system coded, it was not without its problems. The major problems that we faced included:

  • Learning curve too steep for other team members. Even in its stripped-down ultra-light form, Drupal was still a very complex application for the team to learn. The other programmers in the team had experience with PHP, but not with a system as large or as 'uniquely architected' as Drupal. Core concepts such as the menu building system, the theming system, and the access control mechanism took longer than expected to learn.
  • Lack of understanding of benefits of Drupal as an app framework. Many team members didn't fully appreciate just how much Drupal was doing under the surface, and often suggested that 'the whole thing would be easier' without Drupal.
  • Extensibility not always as easy as it should have been. User.module in particular required hacking in many parts in order to get it to fit our project brief (e.g. locking a user out after 3 login attempts), where ideally such things could have been done through hook_user().
  • Many parts of code inadequately commented. Once again, this problem was most evident in user.module, where there are many functions that have no doxygen comment header at all. This didn't make life any easier for the rest of the team, who were struggling with Drupal as it was.
  • OO conversion not worth the hassle. The only real benefit of having an OO Drupal is that the functions are given proper namespaces, and so can be browsed more easily within an IDE. We didn't do a "proper" OO conversion - i.e. we didn't actually create constructors, move global variables to be properties, etc. - we just wrapped each file inside a class.

But all in all, our project was amazingly successful! We received high grades for our work, we successfully gave a live demo to our tutor, and the University is even going to be piloting our system (as well as those of some other teams), with the possibility of it actually being used within the Faculty of IT.

Conclusions

It is possible to get good grades by using Drupal for your assignments! ;-)

This project was an experiment to see just how flexible Drupal is, and to see if it can do things that it's (probably) never done before. The number one thing that this project proved is that Drupal is extremely well-designed: in particular, it is ultra-modular. Drupal can work without blocks, without filters... hell, it can even work great without nodes! Nodes are often considered an integral part of Drupal core, but in fact, few users may notice that node.module can be turned off within any Drupal install. The node system is written completely within the modules, and is not mentioned even once within a single .inc file. This level of separation between core and modules is what allowed it to be used for such an unusual and unique application as this, without too many hiccups.

This project was not in any way trying to alter the future direction of Drupal core development, or to suggest that anything should be coded differently in Drupal. It was purely an attempt to make development of a University project easier, as well as an attempt to prove, to myself and to the Drupal community, that anything is possible with Drupal. In all of the above aims, I believe the project was successful. On behalf of my team, thankyou to all Drupal core developers for the amazing work that you've done and that you continue to do!

Get the source

I've set up a live demo of our finished project at this address, which anyone can look at and play around with (logins as listed on the front page may be used):

http://sdpcar.greenash.net.au/

The full source code of the project is also available as a .zip file, at this address:

http://sdpcar.greenash.net.au/source/sdpcar.zip

Details of accessing the team's SVN repository may be available upon contacting me (SVN repository may not stay online for much longer, though). The source code is fully released under the GPL: this includes the code derived directly from Drupal core (automatically GPL'd), plus all module and theme code that our team developed separately.

The code is made available primarily for informational purposes (i.e. for people who are just curious), and for anyone else who may want to re-use it for similar projects. The code is a fork of Drupal, and an un-maintained one at that. It is not intended for use within the real Drupal code base, or within any project that uses the real Drupal code base.

Comments

venkat-rk’s picture

Now we know why the category module is yet to see the light of the day;-)

Even to a complete non-programmer like me, this sounds too good not to be on the front page of drupal.org

Jaza’s picture

I think it would be safe to say that this project is to blame for the category module being stalled! :-p (as for the front page... I have my doubts, this post may be too geeky to make it up there)

Jeremy Epstein - GreenAsh

Jeremy Epstein - GreenAsh

lennart’s picture

If I were to make a system that could establish connections between tutors and tutees - could I use this as a framework, or would it be better to develop some custom modules for a normal Drupal install?

Best regards,
Lennart - forsker.net

Best regards,
Lennart

Jaza’s picture

I would encourage you and everyone else NOT to use this system as the base for further work!! If you need an entire site which is a custom web application, like the CAR system, and if a super-lightweight core is essential, then perhaps consider it. But if you need to use any of Drupal's usual features (and chances are you WILL), such as the node system, taxonomy, blocks, etc, then stick with developing for Drupal!

Bear in mind that this was a project with extremely unique and specific needs - very few projects will require an entirely re-written version of Drupal to satisfy their needs. I do not want to start a whole new spawn of Drupal, that is not my intention at all! Now that this project is finished, I am abandoning it and returning to Drupal itself for all my development. Keep developing stuff as Drupal modules. Drupal is a continuously maintained, constantly evolving framework that will keep pace with modern trends in web development, and that will meet your needs now and in the future. My little project will not!

I hope I've made my point clearly enough. Now, having said all that, I am still quite proud of what I've made. :-)

Jeremy Epstein - GreenAsh

Jeremy Epstein - GreenAsh

lennart’s picture

You made it very clear !

Anyway, thanks for sharing your experience with Drupal as an application framework.

Best regards,
Lennart - forsker.net

Best regards,
Lennart

Dr.Katte’s picture

links are dead, I can't download the source codes