Tipps und Tricks

In diesem Artikel wird ein leicht nachvollziebares Grundgerüst für die Automatisierung eines einfachen Workflows für das Deployment eines Web-Projekts mit Hilfe von Grunt.js unter Windows vorgestellt. Dabei wird nur die Grundstruktur implementiert, so dass spezielle Anforderungen, wie z.B. Minification, SASS-Compilierung, die Unterstützung von Test-Driven-Design oder Mobile-Cross-Platform-Development vom Entwickler je nach seinen speziellen Bedürfnissen hinzugefügt werden können.

Eine einfache Möglichkeit in Drupal Popup-Fenster zu erzeugen, bietet das Drupal-Modul Colorbox, das auf dem gleichnamigen jQuery-Plugin basiert.

Dies wird in folgendem Beispiel anhand eines einfachen Szenarios gezeigt.

Bei einem größeren Projekt entstehen höhere Anforderungen an die Organisation und Dateistruktur der Sourcen. Diese Anforderungen gelten sowohl für die Modul- als auch die Theme-Entwicklung. Dazu muss man sich in jedem Projekt Gedanken machen,

• wie man den Source-Code innerhalb eines Moduls oder Themes auf verschiedene Ordner und Dateien verteilt,
• wie man Teile des Source-Codes über mehrere Module hinweg gemeinsam nutzen kann und
• wie man Ordner-, Datei-, Klassen- und Funktionsnamen so wählt, dass der Source-Code am Ende gut lesbar ist.

Drupal bietet hierfür verschiedene gestufte Ansätze, die je nach Komplexität des Projekts mehr oder weniger in Frage kommen. Insbesondere empfiehlt es sich, bei jedem nicht-trivialen Projekt das Autoloading zu nutzen.

Im folgenden werden die Möglichkeiten der Sourcecode-Strukturierung in Drupal kurz diskutiert, um dann ausführlicher auf das PSR-4 Autoloading einzugehen, das für Drupal 8 den aktuellen Standard darstellt und für das es in Drupal 7 das Modul X Autoload gibt.

Wer ein Portal entwickelt, benötigt Test-Content. Drupal stellt hierfür im Rahmen seines Devel-Moduls das leistungsfähige Sub-Modul Devel Generate zur Verfügung.

Damit lassen sich Lore Ipsum-Texte, Random-Bilder (s. Bild links), Lore Ipsum-Taxonomien sowie Inhalte für alle Felder für alle Content-Typen erzeugen.

Die Flexibilität dieses Moduls reicht allerdings nicht aus für anspruchsvollere Konfigurationen und Entwicklungen. Dafür sind programmtechnische Eingriffe erforderlich.

Agile Programmierung ist zur Zeit ein großer Hype im Bereich der Software-Entwicklung. Es gibt kaum ein Unternehmen, welches sich noch nicht mit dem Thema befasst hat. Traditionelle Projektformen - wie das Wasserfallmodell - sind in der Vergangenheit aufgrund zunehmender Komplexitäten an ihre Grenzen gestoßen. Man denke an viele öffentlich bekannt gewordene Projekte, deren Budgets am Ende hoffnungslos überzogen wurden.

Man steht vor der Aufgabe, selbst programmierte Inhalte in einem eigenen Block in Drupal auszugeben. Drupal stellt hierfür die Block-Api zur Verfügung. Für ein rudimentäres Block-Modul benötigt man zwei Hooks.

Im Artikel zum Drupal-Symfony-Modul hatte ich darauf hingewiesen, dass es möglich ist, Symfony komplett schon in Drupal 7 zu integrieren und dass ich dies in einem späteren Artikel darstellen würde. Man muss also nicht Drupal 8 abwarten, um loslegen zu können.

Nun macht es aber Sinn, sich vorher zunächst einmal mit Symfony selbst zu befassen, um zumindest den grundlegenden Workflow bei der Entwicklung von Anwendungen kennenzulernen.

Im folgenden wird deshalb ein einfaches Symfony-CRUD-Bundle unabhängig von Drupal erstellt, das die grundlegenden Aktionen zur Manipulation einer Tabelle wie Create, Read, Update und Delete von Datensätzen enthält.

Ziel ist es, sich zunächst mit dem Konzept von Symfony vertraut zu machen, bevor es in einem späteren Artikel um die Integration in Drupal geht. Dort sind die Erkenntnisse dann von Nutzen.

Viele Drupal-Projekte benötigen Email-Funktionalitäten, sei es für die Registrierung von Nutzern oder für Benachrichtigungsdienste, z.B. um Nutzer über neue Beiträge oder Kommentare zu informieren.

Da Entwickler häufig mit einer lokalen Drupal-Version arbeiten, benötigen sie zum Testen einen SMTP-Mail-Server, mit dem das Drupal-System Emails an Test-User verschicken kann.

Dies ist nicht so einfach, wie es zunächst aussieht. Mail-Server-Software ist in der Regel ziemlich sperrig und wer sich nicht gerade für den geborenen Administrator hält, kommt hier leicht ins Schwitzen.

Viele Seiten im Internet haben einen Bereich für Jedermann und einen für Mitglieder, z.B. Vereins- und Verbandsportale oder Shops, die spezielle Seiten und Services nur für registrierte Mitglieder anbieten. Solche Seiten kann man als Community-Portale bezeichnen.

Freilich wird die Bezeichnung Community-Portal auch für wesentlich komplexere Portale verwendet, die zum Beispiel eine an sozialen Netzwerken wie Facebook orientierte Funktionalität aufweisen. Hierzu gehören Timelines, Gruppen-Mitgliedschaften, Blogs, Wikis und gemeinschaftlich nutzbare Kalenderfunktionen usw. Diese sind hier nicht Gegenstand des Artikels. Wer sich dafür interessiert, der sei auf das Commons-Projekt und das Organic-Groups-Projekt verwiesen.

Im folgenden geht es hauptsächlich darum, wie man eine Menu-Struktur einrichtet, die eine saubere Trennung von internem und externem Bereich ermöglicht.

Im folgenden wird ein Grundgerüst für ein Drupal-Report-Modul vorgestellt. Zwar benötigt man für viele Reports in Drupal nicht unbedingt ein selbstentwickeltes Modul, weil man sich Reports mit dem Modul Views konfigurieren kann. Allerdings gelangt man mit diesem Modul manchmal an seine Grenzen vor allem, wenn komplexe User-Interaktionen von dem Report erwartet werden. In einem solchen Fall ist es einfacher, seine Anstrengung auf die Modulentwicklung zu konzentrieren. Einen Report zu entwickeln gehört dabei nicht unbedingt zu den schwierigsten Problemstellungen.