Weblog von kauschke

In diesem Video zeige ich euch, wie man in einem frisch installierten Drupal Commerce Kickstart V2 einen neuen Produkttyp anlegt.
Danach füge ich diesem Produkttyp Felder hinzu, die es erlauben, dass meine Produkte unterschiedliche Farben und Formen haben können.
Ich erstelle ein Produkt mit vier Varianten, und erlaube dem User der Webseite, beim Kauf die Farbe und Form seines Produktes mit komfortablen Dropdown-Listen auszuwählen.

Google Analytics ist ein oft genutztes Tool, um die Analyse des Benutzerverhaltens auf einer Webseite zu tracken. Dazu wird in der Regel ein Javascript-Schnipsel auf der zu trackenden Webseite eingebunden. Das gestaltet sich relativ einfach und ist mit keinem hohen Aufwand verbunden.
In seltenen Fällen ist dies jedoch nicht möglich, da auf der Webseite vielleicht kein Javascript geladen wird, oder man das Analytics Tool vielleicht zu anderen Zwecken verwendet.

Hier hilft der Google Analytics PHP Client.

Die mächtigen Fähigkeiten des Feeds-Moduls hatten wir in dem Blogeintrag Externe Datenquellen, Drupals 6ter Sinn schon einmal ausführlich aufgezeigt.
Manchmal ergibt es sich jedoch, das auch die vielen vorhandenen Plugins nicht für den speziellen Anwendungsfall ausreichen. Im heutigen Beispiel hatte ich das Problem, das ein Import einer sehr großen CSV-Datei in eine Drupal-externe Datenbank erfolgen sollte.

Wie schon in dem Artikel Ein Drupal Workflow mit Continuous Integration: Teil 1 beschrieben, nutzen wir für unseren Workflow ein eigen-entwickeltes Tool: Der Updatescript Prozessor. Er hilft beim Deployment dahingehend, das er es ermöglicht,
kurze Konfigurationsscripts zu schreiben, die dann auf dem Zielsystem einmalig ausgeführt werden.

In den letzten beiden Monaten haben wir unsere interne Infrastruktur und auch unseren Workflow an Drupal 7 angepasst, da wir ab jetzt neue Projekte nur noch mit D7 umsetzen wollen.

Viele Drupal-Entwickler und Entwicklerteams kennen sicher das Problem: Man arbeitet mit mehreren Personen gemeinsam im Team, und die einzelnen Workstations haben einfach nicht den gleichen Entwicklungsstand, da jeder so ein bisschen andere Daten und Einstellungen in "seinem" Drupal hat. Ein anderes Problem ist es, eine bestehende Webseite mit viel wechselndem Content updaten zu müssen, ohne das der manuelle Deployment-Aufwand überhand nimmt. Jetzt schreien sicherlich viele "Aber dafür gibt es doch Features und Drush, und XYZ", und das ist auch korrekt.

Die Benutzung von Session Variablen ist gang und gäbe. Man benutzt sie zum Beispiel, um Einkaufswagen in Shopsystemen zu erschaffen, da PHP und HTML zustandslos und somit "vergesslich" zwischen zwei Seitenaufrufen sind.
In Drupal gibt es ein sehr komfortables Session-Handling, um das sich der Programmierer in der Regel keine Gedanken machen muss, da alles von Drupal gemacht wird.
In diversen Projekten ist es gelegentlich schon passiert, das nach einem Überspielen der Datenbank die anonymen Benutzer plötzlich keine Session Variable mehr hatten.

Am letzten Wochenende hatte die Cocomore AG zum Codesprint geladen. Und viele kamen!
Ziel des zweitägigen Ereignisses war die Portierung vorhandener Drupal 6 - Module auf Drupal 7.
Anfangs wurde - nach einem ausgiebigen Frühstück - vorgestellt, wer gern welche Module portieren möchte. Da viele der Anwesenden noch nie ein Modul portiert hatten, gab Karsten Frohwein zuerst eine kleine Einführung dazu, indem er das Vorgehen mittels des Coder-Moduls und der Drupal-Api Dokumentation demonstrierte.

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.

Wer schon einmal mit dem Node-Reference-Field gearbeitet hat, hat vielleicht festgestellt, das die Standardwidgets für dieses Feld oftmals suboptimal bezüglich Usability sind. Vor allem wenn man aus einem größeren Pool von Nodes auswählen muss. Eine Dropdown Liste mit einigen hundert Einträgen - unpraktikabel. Ein Autocomplete Feld vielleicht ... wie hiess der Beitrag doch gleich, den ich referenzieren wollte?

Automatische Tests, und warum wir sie brauchen

Wie bei jeder guten Software müssen auch Webanwendungen ausreichend getestet werden. Testen ist immer aufwändig, zeitraubend, anstrengend, entwicklungsintensiv und meistens auch noch einfach nervig. Niemand mag es wirklich, aber es ist absolut nötig und unvermeidbar, will man ein akzeptables Produkt auf die Beine stellen. Die großen CMS-Frameworks (wie z.B.