Entwicklung

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.

In den bisherigen beiden Symfony-Artikeln wurde gezeigt,

• wie man das Symfony-Modul von Drupal 7 aktiviert und
• wie man mit Synfony ohne eine Zeile Source-Code zu schreiben, eine simple Blog-Anwendung entwickelt.

Im Folgenden soll das simple Blog aus dem Tutorial als vollwertiges Modul für ein Drupal 7 - Portal entwickelt werden.

Man kann mit dem Symfony-Modul für Drupal 7 zwar auf Symfony-Klassen zugreifen, aber nicht den gewohnten Workflow von Symfony nutzen, insbesondere nicht die Scaffolding-Möglichkeiten auf Basis des Console-Interface app/console. Das Symfony-Modul ist also nicht mehr als ein Proof of Concept, wie die Autoren selber schreiben.

Wie man die vollwertige Integration erreicht, wird im folgenden gezeigt. Damit können dann Entwickler ähnlich wie bei Typo3 Vers. 4.7 mit der Extension Extbase für das MVC-Framework Flow3 im Falle Drupal 7 Module auf Basis des MVC-Frameworks Symfony entwickeln, die später leichter auf Drupal 8 portiert werden können. Eine solche Möglichkeit fehlte für Drupal 7 bisher. Es kann sich also für die nähere Zukunft schon lohnen, Module für Drupal auf Symfony-Basis zu entwickeln und man braucht dafür nicht zu warten, bis sich Drupal 8 etabliert hat.

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.

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.

Ein Blog wie dieses, das praktische Lebenshilfe für die Softwareentwicklung leisten möchte, benötigt einen Syntax-Highlighter für den Wysiwyg-Editor, denn sonst wäre der Zugriff auf Code-Snippets ziemlich unhandlich für einen Leser.

Dafür gibt es in Drupal das Modul Syntax Highlighter. Installationen für Drupal im Umfeld des Wysiwyg-Editors sind leider immer etwas problematisch. Deswegen wird im folgenden die Installation ausführlicher beschrieben. Hierfür muss sogar ein eigenes kleines Modul entwickelt werden, denn sonst ist das Ergebnis sehr unbefriedigend.

Wer das Modul "Workbench" oder Vergleichbares zur Einrichtung von Workflows in Drupal einsetzt, kommt schnell in die Verlegenheit, dass das Modul keine Möglichkeit bietet, den Zugriff auf Menü-Bereiche abhängig von den Rollenberechtigungen zu begrenzen. Will man z.B. einem Redakteur die Möglichkeit einräumen, nur in einem bestimmten Bereich des Hauptmenüs Einträge für seine Artikel vorzunehmen, so hat man ein Problem. Das verfügbare Drupal-Modul "Menu Admin per Menu" ermöglicht nur, den Zugriff auf das komplette Menu zu begrenzen, nicht auf einen Teilbereich davon.

Eine Recherche ergab, dass es zur Lösung dieses Problems keine speziellen Module gibt. Wenn, dann läßt sich das Problem höchstens mit komplexen generischen Modulen, wie z.B. Rules, lösen.

Ich habe deshalb das Modul menurolerights entwickelt, das es ermöglicht, Regeln für den Zugriff auf einzelne Menuabschnitte beliebiger Menus für beliebige Rollen festzulegen. Damit kann man z.B. dem für Kochrezepte zuständigen Redakteur erlauben, Menüeinträge unterhalb des Eltern-Menüpunkts "Rezepte" beliebig hinzufügen, zu löschen und zu ändern.

Wer ein neues Drupal-Portal aufsetzt, möchte außer dem Login häufig keine User-Registrierung ("Create new account") und eventuell auch keine Passwortanfrage ("Request new password") zulassen.