snippet

Das Testen von Drupal-Installationsprofilen ist relativ mühselig, da sich ein Teil der Schritte, bis man überhaupt erst zum Testen der eigentlichen Funktionalität kommt,
mit dem Build-Prozess beschäftigt.

Diesen muß man eigentlich für jede Änderung erneut durchlaufen...

1. Drush make (das macht es im Falls des Feature-Server-Installations-Profiles)
   
   1. Drush make mit distro.make aus dem Git-Repository
   2. Download des Drupal-Cores
   3. Klonen des in distro.make hinterlegten Repositories für das Installationsprofil
   4. Rekursive Suche nach weiteren Drush-Makefiles,
      runterladen der Drupal-Module und des Themes, die im gefundenen Makefile drupal-org.make spezifiziert sind
2. Sybolischer-Link vom erstellten Build auf die DocumentRoot des für Testzwecke angelegten VirtualHosts
3. Drop auf alle Tabellen in der Zieldatenbank
4. Installation von Drupal und einem bestimmtem Installationsprofiles, hier fserver_profile

In der scheinbaren Routine des manuellen Durchlaufen dieser Schritte entsteht zudem auch mal schnell ein Fehler.

So habe ich beim gefühlt 100sten Mal des Durchlaufens dieser Prozedur versehentlich in der falschen Datenbank alle Tabellen ge-dropt-t und dachte mir, Automatisierung muss her, schreib ein Shellskript...

In der Regel kann man eine Drupal-Site mit einem Projekt gleichsetzen, Projekte nutzen eine Versionsverwaltung, immer häufiger ist dies Git.

Je mehr ich Git nutze, je weniger nutze ich die Möglichkeiten der klassischen Drupal-Multisite-Funkionalität, dem Teilen von Drupal-Core und Contributed-Modules über viele Drupal-Sites hinweg.

Im folgenden möchte ich diese (Verzeichnis-)Struktur innerhalb des Git-Repositories beleuchten und in diesem Zusammenhang Ansätze von spezielleren Drush-Konfigurationsdateien zeigen, welche sich in Drupal-Projekten für mich etabliert haben, ein Teil hiervon ist Drupal-7 spezifisch.

• drupal

  Die Drupal Code-Basis und DocumentRoot des Webservers.

• dumps

  Hier liegen die Datenbankdumps

• etc

  Projektrelevante Konfigurationsdateien, relativ zur Wurzel des Dateisystems.

• privatefiles

  Dateien die über Drupal verwaltet werden, (Ziel beim Hochladen: Private Dateien).

• salt

  Beinhaltet in der Datei salt.txt, den aus settings.php ausgelagerten Salt

Rudimente für ein Drupal-Deployment mit

• Lokaler Entwicklungumgebung
• Stage-Umgebung
• Live / Produktionsumgebung

unter Verwendung, der in Drupal-7 neu eingeführten Multisite-Features in der Datei sites.php, Drush-Aliases
und einer speziellen settings.php,
die in diesem Fall versioniert wird.

sites.php -- Verzeichnis Aliase in Drupal 7.x

Die in Drupal 7.x neu eingeführte Datei sites.php stellt erstmalig Verzeichnis-Aliase für Drupal-Multisites zur Verfügung.

So ist es jetzt möglich mit verschiedenen Domains bzw. VirtualHosts ein bestimmtes Verzeichnis innerhalb von sites anzusprechen,
ohne über z.B. Symbolische Links zu gehen, was in vorgigen Drupal-Versionen zur Folge haben konnte, daß Datei- oder Modulpfade beim "umbiegen" von der Dev-Site example.mydomain.de auf die Live-Site example.com divergent sind.

Nach dem Wochenende habe ich bemerkt, daß die Ubuntu-Updates, die ich am Freitag davor durchgeführt habe wohl etwas "verschlimmbessert" haben.

So begrüßt mich am darauffolgenden Montag, direkt eine Kernel-Panic.

Alles im Grunde nichts gravierendes, aber...

1. Root-Partition ist verschlüsselt
2. Home-Verzeichnis ebenfalls verschlüsselt

Nunja...

Nach einer Woche HOND am Laptop und ziemlich zeitintensiver Suche, hier der zusammengetragene, komplette Lösungsweg.

Befehl: git config

Git-Konfigurationsdateien: /etc/gitconfig, ~/.gitconfig, .git/config

Auswertungsreihenfolge:

1. /etc/gitconfig
   Systemweite Git-Konfigurationsdatei
2. ~/.gitconfig
   

Bei der Erstellung von Formularelementen,
welche eine Jquery-Datepicker-Funktionalität bereitsstellen sollen
besteht die Möglickeit auf Date Popup, ein Submodul des Date / Date API Moduls zurückzugreifen.

Der Zugriff auf diese Funktionalität erfolgt über Drupals FAPI.

Htaccess mit Authentifizierung an einer MySQL basierten Drupal-Installation.

Installation des benötigten Apache Moduls

Aktivierung des authmysql-Moduls

Dieses Snippet in die jeweilige Apache-VirtualHost-Datei einfügen

Htaccess mit Authentifizierung an einer MySQL basierten Drupal-Installation.

Installation des benötigten Apache Moduls

Aktivierung des authmysql-Moduls

Gestern wurde drush in der Version 2.1 herausgegeben.

Neben zahlreichen Bug Fixes gibt es zwei signifikante Änderungen, die ich hier beschreiben möchte.

1. Die Entfernung des Shebang's in drush.php.
2. Die Einführung von Aliases.

Ähnlich wie hier, kam auch ich letztens in die Situation einen oder mehrere Blöcke in einem Block anzeigen zu müssen.

Der obige Ansatz hat erst nach hinzufügen eines weiteren Parameters, nähmlich delta funktioniert.

So kommt man an den Block

Parameter 1, module besagt zu welchem Modul der gewünschte Block zugehörig ist.
Parameter 2, block und 3, view sind in diesem Fall hingegegen fix, da es sich hier ja mit block um Block als Modul dreht und view die Operation ist, die auf den Block angewandt werden soll, siehe auch http://api.drupal.org/api/function/hook_block.
Die Parameter 4,delta und 5, bid, die Block-ID sind wiederrum blockspezifisch, diese werden wie module in der Tabelle blocks festgehalten.