Drupal

Migration einer Webseite von Joomla 1.0.x nach Drupal 6

Von einem Content Management System (CMS) zu einem anderen zu wechseln, ist in der Regel schon eine aufwändige Sache. Manchmal läßt es sich aber nicht vermeiden. Bevor man es ernsthaft angeht, empfiehlt es sich, den Ablauf einmal durchzuspielen, damit es später, wenn es ernst wird, keine bösen Überraschungen gibt. Hier der Testlauf einer Migration einer schon etwas älteren Joomla-Installation (Version 1.0.15) zu Drupal. Zunächst einmal sollte es nur Drupal 6 sein, da teilweise benötigte Module noch nicht für Drupal 7 verfügbar sind.

Für die Migration einer Joomla-Installation zu Drupal gibt es zwei Module Joomla To Drupal und Joomla-to-Drupal Converter. Das erstere war zum Zeitpunkt des Testbeginns noch im Alpha-Stadium und schien seit Dezember 2009 nicht mehr weiter entwickelt worden zu sein. Eine Version für Drupal 7 gab es noch nicht (seit einigen Tagen gibt es hierfür eine erste Alpha-Version). Das zweite Modul gab es immerhin in einer Beta-Version, allerdings nur für Drupal 5 und 6, und in einer sehr aktuellen Dev-Version. Letzteres kam dann bei dem Test zum Einsatz. Die Dokumentation ist sehr knapp gehalten und reicht nur für die Durchführung der Datenmigration. Worauf man vorher und nachher achten muss, wird nicht beschrieben - und es gibt diverse Stolperfallen. Und so sind wir vorgegangen:

Im ersten Schritt legt man eine frische Drupal-Installation an und bereitet diese für den Import der Joomla-Daten vor. Auf folgendes muss man dabei unbedingt achten:  weiterlesen »

Nach Update auf Drupal 6.19: CSS-Optimierung verliert CSS-Files

Ein sehr unangenehmer Bug kann nach dem Update einer Drupal-Installation auf die Version 6.19 auftreteten. Bei aktivierter CSS-Optimierung (unter "Einstellungen >> Leistung >> CSS-Dateien optimieren") kann es passieren, dass einzelne CSS-Dateien von Modulen nicht geparst werden und in der ausgelieferten CSS-Datei fehlen. Das kann dann zu einer verunstalteten Website führen. Der Grund für dieses Verhalten ist ein Bug in Drupal 6.19, der verhindert, dass CSS-Dateien, die nicht im UTF-8-Format vorliegen, zusammengefasst werden. Um den Fehler zu beseitigen gibt es mehrere Möglichkeiten:

  1. CSS-Optimierung deaktivieren. Das ist aber immer dann problematisch, wenn die Zahl der zu ladenden CSS-Dateien 31 übersteigt. Dann kann der Internet Explorer diese nicht mehr laden und stellt die Seite fehlerhaft dar. Dieser Bug tritt mindestens noch bis zum IE8 auf.
  2. Betroffene CSS-Dateien in UTF-8-Format konvertieren. Dazu lädt man diese einfach in einen geeigneten Texteditor (z.B. PSPadPro). Beim Laden zeigt dieser die aktuelle Codierung an. Unter "Format" kann man diese dann einfach auf UTF-8 umstellen und die Datei wieder speichern. Das ist bei einer größeren Zahl von Modulen mit eigenen CSS-Dateien allerdings etwas mühsam.
  3. Zum Glück gibt es einen einfacheren Weg: Die seit kurzem verfügbare Version 6.20 von Drupal hat diesen Bug nicht mehr. Also einfach die Website updaten und das Problem ist behoben.

Wer noch eine ältere Drupal-Version im Einsatz hat, ist von diesem Fehler nicht betroffen und solte die Version 6.19 einfach überspringen.

Upgrade auf Drupal 6

Nach rund 3 Jahren wird es an der Zeit mein Blog auf eine neuere Drupal-Version upzugraden. Schließlich erscheint in wenigen Tagen Drupal 7 und damit sind die Tage von Drupal 5 doch gezählt. Auch das Layout soll aufgehübscht werden. Die ganze Aktion läuft neben der normalen Arbeit und so kann es sein, dass das Blog heute und morgen vorübergehend nicht erreichbar ist und das neue Layout wird auch nicht gleich morgen da sein. Vorübergehend gibt es also erstmal ein Garland-Theme oder sowas in der Richtung Standard-YAML Theme. Ich hoffe es stört den Lesespaß nicht allzu sehr. ;-)

Pathauto: Vorsicht bei der Generierung automatischer Aliase!

Suchmaschinenfreundliche URLs sind für Drupal kein Problem. Allerdings ist das Core-Modul Path doch eher unkomfortabel und daher wird man wohl immer Pathauto und Token dazunehmen. Im Zusammenspiel können so sehr schöne lesbare URLs erzeugt werden und das vollautomatisch beim Anlegen einer Node. Pathauto gestattet dabei z.B. die Verwendung von Taxonomiebegriffen und unterschiedliche Pfade für verschiedene Inhaltstypen. Und genau hier lauert eine Falle.  weiterlesen »

Probleme beim Hosten von Drupal-Websites bei 1&1

Eine neue Website, die mit Drupal6 arbeitet, sollte bei 1&1 gehostet werden. Okay, das klang jetzt erstmal nicht nach einer größeren Herausforderung. Ein Blick in das Kunden-Backend zeigte, dass es sich um ein Hosting-Paket "1&1 Business 5.0" für knapp 15 € pro Monat handelte. Die vorhandene Website und diverse Dokumente für den Download belegten nicht einmal 20% des vorhandenen Speicherplatzes. Also noch reichlich Reserve. Drei MySQL-Datenbanken waren ebenfalls noch verfügbar. Leider werden PHP-Skripte standardmäßig mit PHP4 ausgeführt - was ja jetzt nicht mehr so ganz zeitgemäß ist. Eine Möglichkeit, dass im Backend umzuschalten gibt es wohl nicht, zumindest fand ich auch nach längerem Suchen keine. Die "Hilfe"-Seite gab die lapidare Empfehlung, die PHP-Skripte mit der Endung .php5 zu versehen, da sie dann vom Server mit PHP5 aufgerufen würden. Tolle Empfehlung, benennen wir doch einfach die zahllosen PHP-Dateien von Drupal um! An dieser Stelle kamen mir dann erste Zweifel, ob dieses Hosting-Paket wirklich für professionelle Anwendungen geeignet ist. Oder ob das ganze nicht eher für Kunden gedacht ist, die sich ihre Website mit dem 1&1-Baukasten zusammenbasteln. Dabei gibt es eine naheliegendere Möglichkeit, das PHP-Problem zu lösen. Der folgende Eintrag am Anfang der htaccess erzwingt die Ausführung von Skripten mit der Endung .php durch PHP5

AddType x-mapp-php5 .php AddHandler x-mapp-php5 .php

Drupal würde zwar auch mit PHP4 laufen, aber empfehlenswert ist das nicht, denn nicht alle Module machen da mit.  weiterlesen »

Drupal-Mails an andere E-Mail-Adressen umleiten

Wenn man eine Website mit Drupal entwickelt, kann es sein, dass man dafür reale Datensätze vom Kunden bekommt. Zunächst einmal ist das je kein Problem. Die Website, die entwickelt wird, befindet sich in einer Testumgebung und was auch immer mit den Daten passiert, es hat keine Auswirkung auf die reale Welt - mit einer Ausnahme: werden reale E-Mailadressen verwendet, so kann es passieren, dass Drupal diesen während der Tests eine E-Mail sendet. Module oder Funktionen, die dies tun, gibt es jede Menge. Schon das Löschen oder Anlegen eines neuen User-Accounts kann eine solche Mail erzeugen. Das kann man zuar unterbinden, aber zum einen ist es ja unter Umständen erwünscht, dass eine Mail erzeugt wird und zum anderen vergisst man schnell mal, die betreffende Funktion abzuschalten.Schöner wäre es daher, wenn man das Versenden der Mails global unterdrücken oder diese wenigstens an eine andere Mail-Adresse umleiten könnte.  weiterlesen »

Spannende Tage in München - Drupal Dev Days 2010

Am 8. und 9. Mai fanden in München die Drupal Dev Days statt. Es wurde ein sehr interessantes aber auch anstrengendes Wochenende. Samstag früh hin, Sonntag Abend zurück und dazwischen ein randvolles Vortragsprogamm. Aber es hat sich gelohnt.

Das Ganze war gut organisiert, nur das Einchecken verlief etwas zäh - zumindest wenn man nicht die Vorregistrierung am Freitag Abend nutzen konnte. Damit es nicht allzu hektisch wurde, hatte man kurzerhand die Eröffnung auf später verschoben und die gewonnen Zeit reichte dann für die Registrierung. Gleich danach ging es auch schon mit dem Programm los. In der Regel liefen jeweils vier Vorträge zeitgleich, so dass die Auswahl manchmal schwer fiel.

Für den ersten Tages hatte ich mir folgende Themen ausgesucht:

  • Drupal-Themes dynamisch mit ThemeKey steuern
  • Jquery und Drupal: Kleine Library, grosse Wirkung
  • Drupal-Entwicklung für Nicht-Entwickler
  • Keynote "Warum PHP sich rechnet"
  • Power Panels - Der richtige Einsatz von Panels
  • Khairn - Projekte managen mit Drupal (2+))
  • Nicht-englischsprachige und mehrsprachige Suche mit Apache Solr Multilingual

Zwischendrin gab es natürlich eine Mittagspause. Die war hervorragend organisiert. Zur Auswahl gab es vier Suppen oder Eintöpfe - alle in ordentlicher Qualität und ausreichender Menge, dazu Brot oder Brötchen und zum Nachtisch Obst oder Plundergebäck. Für Getränke war auch gesorgt: Fruchtsäfte, Mineralwasser und Kaffee bis zum Abwinken. Das ganze war in der enthalten. Danke an die Sponsoren, wie z. B. die Kelterei Walther GmbH & Co. KG.  weiterlesen »

Calendar-View zeigt falsche Woche an

Ich dachte mich tritt ein Pferd! Ende Dezember hatte ich eine Kundenwebsite mit Drupal 6 entwickelt, die unter anderem verschiedene Kalenderansichten enthält: Monats- und Wochenkalender - bereitgestellt vom Views-Modul -, die verschiedene Inhaltstypen anzeigen. Alles funktionierte einwandfrei. Nun war also der Kunde am Zuge, sich alles anzuschauen, ggf. letzte Änderungswünsche zu äußern und dann die Seite freizugeben. Dies ist mittlerweile passiert und heute wollte ich die letzten Änderungen einarbeiten. Aber was war das? Die Wochenkalender zeigten plötzlich nicht mehr die aktuelle, sondern die vergangene Woche an! Und das, ohne dass irgendetwas an der Seite geändert worden wäre, kein Update, keine neun Module, nur ein paar neue Inhalte.

Nach einer kurzen Recherche war das Problem dann gefunden. Die Ursache liegt darin, dass es in Europa und USA unterschiedlichen Verfahren zur Bestimmung der 1. Kalenderwoche (KW) eines Jahres gibt.

  • USA: jene Woche, in die der 1. Januar fällt
  • Deutschland/EU: die erste Woche, in die mindestens vier Tage des neuen Jahres fallen (DIN 1355-1 / ISO 8601)

Außerdem beginnt hierzulande eine Woche am Montag in den USA dagegen am Sonntag. Schaut man auf den Kalender, so sieht man, dass nach US-Zählung die erste KW schon am 27. Dezember 2009 begonnen hatte, hierzulande aber erst am Montag, den 4. Januar 2010. Damit sind wir heute in der KW 6, nach US-Zählung aber schon in der KW 7. Nun wäre das an sich noch kein Problem, denn der verwendete Kalenderview soll nicht die Nummer der KW ausgeben, sondern nur die 7 Tage dieser Woche auflisten. Dummerweise verwenden die beiden Module, die hier zusammenarbeiten sollen (Date und Calendar) unterschiedliche Zählweisen und so gibt der Kalender-View nicht die laufende Woch sondern die Vorwoche aus.

Der folgende Patch behebt den Fehler und es wird wieder die laufende Woche angezeigt. Die Funktion get_default_argument befindet sich in der Datei (../sites/all/modules/date/includes/date_api_argument_handler.inc ab Zeile 144 (Version 2.4 des Date-Moduls)

/
   function get_default_argument($raw = FALSE) {
     if (!$raw && $this->options['default_argument_type'] == 'date') {
-      return date($this->format(), time());
+      $arg = date($this->format(), time());
+
+      $parts = $this->date_handler->arg_parts($arg);
+
+      if($parts[0]['date']['week']){
+        $year = date("Y");
+        $last_week_of_year = date("W",strtotime(($year-1)."-"."12-31"));
+        $last_day_of_year  = date("w",strtotime(($year-1)."-"."12-31"));
+        if ($last_day_of_year > 3 and $week != $last_week_of_year) {
+          $arg = date($this->format(),time()+7*24*60*60);
+        }
+      }
+      return $arg;
     }
     else {
       return parent::get_default_argument($raw);

Quelle: http://drupal.org/node/686394

Bestehende Drupal- und vBulletin-Installationen zusammenführen

Die Aufgabe klang zunächst einmal gar nicht so schwierig: Eine bestehende Phorum-Installation sollte auf vBulletin umgestellt werden und anschließend mit einer bereits bestehenden Drupal-Site verknüpft werden. Die Migration von Phorum zu vBulletin werde ich in einem eigenen Artikel beschreiben. Sie verlief relativ glatt, auch wenn das Skript, dass vBulletin für die Konvertierung bereitstellt nicht ganz fehlerfrei arbeitet und etwas Nacharbeit erforderte. Nach einigen kleineren Korrekturen lief dann alles einwandfrei und wir hatten ein funktionierendes vBulletin-Forum. Dieses galt es nun in Drupal zu integrieren, und zwar so, dass die gesamte User-Verwaltung über Drupal läuft. Dafür gibt es das Modul Drupal vB. Es bietet folgende Funktionen:

  • existierende und neue vBulletin-User können sich in Drupal einloggen
  • existierende Drupal.User können sich in vBulletin einloggen (nach einmaligem Export)
  • neue Drupal-User können sich in vBulletin einloggen
  • Update von User-Daten in vBulletin erfolgt automatisch bei einem Update in Drupal
  • User in vBulletin werden automatisch gelöscht, sobald sie in Drupal gelöscht werden.
  • Single-Login und Logout über Drupal

Die Installation des Moduls ist einfach. Es müssen keine Datein geändert werden, weder in Drupal noch in vBulletin. Eine kleine Installationsanleitung beschreibt, was zu tun ist, und nach kurzer Zeit waren die beiden Systeme miteinander verbunden. Sobald man sich jetzt in Drupal anmeldete, war man auch im vBulletin-Forum eingeloggt.
So weit so gut, aber ein Problem konnten wir damit nicht lösen: Die Usernamen in Drupal und vBulletin unterschieden sich. D.h. der gleiche User hatte in der Regel zwei verschiedene Usernamen für die Anmeldung. Wobei nicht jeder User unbedingt ein Login für beide Systeme hatte. Es traten also drei verschiedene Fälle auf:

  1. User hat Usernamen in Drupal und in vBulletin, z.B. DrupalUsernameX, vBulletinUsernameY
  2. User hat nur einen Usernamen in Drupal.
  3. User hat nur einen Usernamen in vBulletin

 
   weiterlesen »

Webform vs. Drupals Kontaktformular

Das schöne an Drupal ist, dass es von Haus aus alles mitbringt, um eine Website aufzubauen und zu pflegen. Gleichzeitig aber so flexibel ist, das man es fast unbegrenzt erweitern und sogar mitglieferte Module häufig ersetzen kann. Damit lassen sich Schwachpunkte einzelner Funktionen oft problemlos beseitigen.

Ein solcher Schwachpunkt steckt in dem Contact-Modul, das zu den optionalen Core-Modulen gehört. Es dient dazu, Kontaktformulare bereitzustellen, sowohl für die gesamte Website, als auch für den einzelnen User. Das Problem: wenn man es aktiviert, steht es den Usern immer zur Verfügung. Zwar kann man defaultmäßig einstellen, dass das Formular beim Anlegen eines neuen Users deaktiviert ist. Man kann jedoch nicht verhindern, dass der User es eigenständig in seinem Profil aktiviert. Nun kann man die Benutzung des Formulars noch auf bestimmte Rollen beschränken und so beispielsweise Gäste von ihrer Benutzung ausschließen aber das löst das Problem nicht immer. Bei einem aktuellen Projekt hat es sich jedenfalls als hinderlich erwiesen. Der Grund: für die Kommunikation der Mitglieder der Website sollte nicht das Kontaktformular eingesetzt werden, sondern das Modul Privatemsg, das es erlaubt seiteninterne private Nachrichten zu verschicken und die Empfänger auch per E-Mail über neue Nachrichten informiert. Soweit so gut. Um nun aber zu verhindern, dass die User ihr persönliches Kontaktformular aktivieren und die Kommunikation plötzlich über verschiedene Kanäle läuft, blieb als einzige Möglicheit, das Abschalten des Contact-Moduls. Damit fehlte dann leider das globale Kontaktformular, dass auch Gästen zugänglich sein sollte.  weiterlesen »

Inhalt abgleichen