You are here

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:

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.

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

[code]AddType x-mapp-php5 .php AddHandler x-mapp-php5 .php[/code]

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

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.

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.

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?

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.

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.

Seiten

Subscribe to RSS - Drupal