Webentwicklung

Im Verlaufe eines Projektes gibt es immer wieder mal neue Anfragen des Kunden, oftmals in Form von Emails. Hat man dann mehr als ein Projekt gleichzeitig am Laufen, so wird das durchblättern des Email Postfaches schnell zur Qual. Man verliert auch selbst schnell den Überblick über den Nachrichtenwust, ganz davon abgesehen das die eigenen Kollegen keinen Schimmer davon haben, welcher Kunde jetzt zuletzt welche Anfrage gestellt hatte. Ein zentraler Verwaltungspunkt für Aufgaben/Bugs/Feature Requests muss also her.

In den kommenden Blogeinträgen haben wir uns entschlossen, einmal eine Case Study zu unserem mitlerweile doch recht mächtigen Intranet, welches wir ausschließlich mit Drupal realisiert haben, zu veröffentlichen. Dabei werde ich in meinem ersten Blogeintrag grob die wichtigsten Features und Funktionen anreißen, wir werden das Erwähnte dann in weiteren Blogeinträgen im Detail erklären.

Drupal, wie auch viele andere CMS, sind in ihrer Standardinstalllation meist recht wenig performant. Die hohe Flexibilität, die man gerade bei Drupal geboten bekommt zahlt man mit dem Preis einer Vielzahl an Datenbank-Querys und Festplattenzugriffen. Gerade wenn man "Alleskönner" wie Views und CCK einsetzt und viele weitere Drupal-Module aktiv hat, die die Seite um wertvolle Funktionen ergänzen, kann man schnell mit 100-200 Querys pro Seitnaufbau rechnen. Ist die Seite dann noch sehr gut besucht, kommt der Server schon ganz schön ins Schwitzen. In diesem Beitrag möchte ich das Drupal-Modul Boost vorstellen und zu Beginn einige weitere Maßnahmen nennen, die die Performance deutlich verbessern.

In der Softwareentwicklung gibt es sowohl für den Auftragnehmer als auch für den Kunden zwei Arten, Softwareprojekte abzuwickeln: Das Wasserfallmodell mit starren Prozessen im Anforderungsmanagement und der agile Ansatz mit sehr flexiblen Strukturen, der Änderungen und neue Anforderungen im Projektverlauf effektiver und schneller abwickelt als das herkömmliche Wasserfallmodell. Natürlich ist auch je nach Projektmodell die Kostenstruktur und die Form der Zusammenarbeit unterschiedlich. Wird nach dem Wasserfallmodell entwickelt, ist ein detailliertes Pflichtenheft mit einem Festpreisvertrag meist die Regel.

Wer Drupal einmal für ein Webprojekt verwendet hat, ist sich sicher dessen großen Vorteilen auch im Vergleich zu anderen CMS bewusst. Drupal ist ein schlankes CMS mit einer ausgefeilten API und einer sauberen Modulschnittstelle. Neben mehr als 5000 Modulen, die für das CMS in der Version 6 aktuell verfügbar sind, ist es durch die vorhandene Modulschnittstelle ebenfalls möglich, eigene Module mit besonders individuellen oder performanten Funktionen zu entwickeln.

Wer schon einmal größere Webprojekte mit Drupal entwickelt hat, wird sicher das Problem kennen, wenn Pfade zu Bildern im Body nicht mehr stimmen. Das ist dann der Fall, wenn man z.B. den FCK Editor in einer Multisiteumgebung im Ordner sites/all liegen hat, und den PHP-Conector so angepasst hat, dass er für jede Domain der Installation einen eigenen Ordner anlegt. Das macht ja auch auf jeden Fall Sinn. Wird die Seite jedoch zuvor unter der Entwicklungs-URL wie z.B. dev.meineseite.net entwickelt und später unter meine-seite.de live geschaltet, stimmen die Bild-Pfade im Body der Nodes nicht mehr.

Leider bietet Magento von Haus aus weder die Unterstützung für den Import noch für den Export von konfigurierbaren Produkten. Dieses Dokument erklärt, wie es uns gelungen ist, dies dennoch durchzuführen, da wir von einem alten Entwicklungsstand, der bereits online war, auf einen neueren migrieren mussten und dazu der Produktkatalog übernommen werden musste.

In Drupal werden Fehlermeldungen standardmäßig als Liste meist oben auf der Seite dargestellt. Bei Validierungsfehlern in Formularen, die mit der Drupa Form-API (FAPI) erstellt wurden, werden zusätzlich die fehlerhaften Felder je nach Theme mit einem roten Rand markiert. Oft ist es jedoch üblich und in meinen Augen auch benutzerfreudlicher, wenn man statt einer Fehlerliste die Fehlermeldungen direkt am betroffenen Formularelement sieht. Da ich bisher kein Modul gefunden habe, das dies relisiert, habe ich meine Funktionen in ein Modul gepackt und möchte es anderen zur Verfügung stellen. Für interessierte Entwickler werde ich das Vorgehen, das mir den gewünschten Effekt gebracht hat, hier kurz beschreiben.

Dank der in die Form-Api von Drupal integrierten AHAH - Library ist es für Modulentwickler ohne großen Aufwand möglich, AJAX in Webanwendungen zu integrieren und die Weboberfläche für Benutzer schnell undd dynamisch zu halten. Die Anwendung geht hierbei von einfachen Text-Reloads auf der Seite (AJAX-Validierung von Formularen direkt nach der Eingabe mit onBlur oder onChange) bis hin zu komplexen Ersetzungen von Formularelementen innerhalb eines Formulars. Aufgrund des integrierten Form-Caches in Drupal, der maßgeblich für die Sicherheit und die Performance bei der Arbeit mit Formularen in Drupal (FAPI) verantwortlich ist, kommt es jedoch gerade beim dynamischen Austausch von Formularelementen per AHAH zu Komplikationen. Um anderen Entwicklern das mühsehlige Aufsuchen der verantwortlichen Fehler zu ersparen, hier eine Anleitung, wie man Formulare in Drupal mit zusätzlichen Formularelementen per AHAH-Reload erweitert.

Da es für Bildergalerien in Drupal eine wohl recht hohe Nachfrage gibt, das Angebot an Tutorials jedoch recht klein ist, möchte ich hier eine kurze Anleitung veröffentlichen, die Ihnen dabei hilft, schnell eine Bildergalerie auf Ihrer Drupalwebseite zu erstellen. Diese Bildergalerie unterstützt Alben und Unteralben und zeigt die Bilder in der Lightbox2 an. Zur einfacheren Administration wird ein Batchupload zur Verfügung gestellt, der es gestattet, alle Bilder eines Ordners als Massenupload in eine Galerie zu importieren. Dieser Massenupload ist sehr hilfreich, da sonst mit dem Image-Modul jedes Bild einzeln der Galerie hinzugefügt werden müsste.