Adding new functionality to legacy Drupal 6 site fjvu.dk

3 minutters læsning

fjvu.dk is a knowledge database for people working with central heating. They established a website a couple of years ago written in Drupal 6.12. Now we needed to improve the document handling system. A primary focus were improved usability and a better structure of the documents.

Version control

First we got the legacy system into version control on github.com. We created a drush make file and an install profile with all the installed modules. We had to do some spring cleaning of the system, as the modules had been scattered around in different directories (e.g. some contrib modules were in the core module folder). Then we updated the current version to Drupal 6.22 and upgraded all the modules to their newest versions. Everything went smoothly after cleaning the cache a lot of times and running upgrade.php.

Trimmed down the system

Then we started reviewing the installed modules and removed all the modules which were not really used. Turned out to be quite a lot. We also removed unused taxonomies and content types. The existing system had some functionality built with cck and views, which we also wanted to get into version control, so we installed features and strongarm. After that it was a breeze to export the current functionality as features and put them into version control as well.

New functionality

That took a little more than a day before we were ready to start building the new feature for documents. After reviewing the currently used modules and the modules we wanted to use, we choose to stik with Drupal 6.x for the time being. However, it should be fairly easy to upgrade when all the modules have matured.

Building the content type. We decided that we wanted to put the documents on Scribd. Luckily Drupal already had a cck scribdfield, which automatically uploads the documents to Scribd from within Drupal. Due to the limitations of Scribd, we had to settle for a regular filefield without the eyecandy. Along with isbn and some regular cck fields we easily built our content type. We used taxonomies for fields like author, publishing year, category and so on.

Showing the documents. We had some iterations before we came up with the way we wanted to show the documents.

1) First, we tried to utilize the a taxonomy hierarchy as categories, and we wanted the category pages to make an easy access to the database. The default is not sufficient. We wanted something better. We saw the videocast Crazy-Awesome Taxonomy pages and read Drupal: show taxonomy term description on page, and we decided to do as follows. To override the default layout, we created our own template file taxonomy_term_page.tpl.php as explained in the other articles.

2) Second, we just used a search box based on exposed filters from views.

We ended up choosing solution 2 with exposed filters for views. We used views to make lists of the documents. We needed a custom search that only searched the documents content type. It is easily accomplished by clicking expose, when you add a filter in the views ui. We needed a search box that searched all the content, and it was conveniently placed under search in the filter dialogue box. We are still struggling to create an empty list of documents when search has not been initiated, but that can not be accomplished in Views 2 unless hacking some templates, so we will implement that when a newer version of Views is released.

Usability improvements

The experience of the user interface is better with vertical tabs, admin menu and contextual (which are all in core for Drupal 7). We just kept the standard garland layout, but I subthemed garland so I had easy access to override some templates.

Messing around with taxonomies and vocabularies

In the standard Garland theme the terms from all vocabularies are just outputted in one list like this:

<span style="display: none;"> </span><?php print $terms<span style="display: none;"> </span>; ?>However, I wanted to change that. So how do I separate drupal taxonomy terms output by vocabulary? I simply followed the advice in the article, and it worked like a charm. I had to mess around with it a little, as I wanted machine names instead of ids, but that was fairly easy with a small function:

fjernvarme_get_vocabulary_machinename_by_vid()See the entire method at github.

That is basically what we did to make a better system. Now it is time to get some content into the database.

Kommentarer

Skriv en kommentar

Din e-mail bliver ikke offentliggjort. Obligatoriske felter er markeret *

Indlæser...