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 »
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 »
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 »
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:
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 »
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.
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
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:
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:
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 »
Es kommt vor, dass Besucher auf eine Seite zugreifen wollen, die nicht mehr existiert, z.B. weil die Seite gelöscht wrde, in den Indizes der Suchmaschinen jedoch noch aufgeführt wird. Oder es soll auf eine Seite zugegriffen werden, die für sie gesperrt sind. Dies führt dazu, dass das System die Fehler 404 (not found) bzw. 403 (access denied) meldet.
Nun sollte eine (speziell erstellte) Fehlerseite immer wie eine normale Seite des Internetauftritts aussehen, d.h. den normalen Seitenkopf, und -fuß sowie ein Menü enthalten. Das erleichtert den Besuchern die Navigation zurück zu den Inhalten. Auf der Fehlerseite sollte deshalb zumindest ein kurzer Hinweis erscheinen, dass die gewünschte Seite nicht länger erreichbar ist. Darüber hinaus können dort weitere Kontaktinformationen wie eine Mailadresse oder eine Telefonnummer angegeben oder sogar eine Suchfunktion angeboten werden.
Das Gleiche gilt für die Fehlermeldung "Zugriff verweigert" (403). Lassen Sie Ihre Besucher wissen, dass sie eine geschützte Seite aufrufen möchten. weiterlesen »
Häufig findet man ein schönes Modul für Drupal, das genau die Funktion bietet, die man gerade sucht. Leider sind diese Module nicht immer eingedeutscht. Für Testumgebungen spielt das in der Regel keine Rolle, aber wenn das gewählte Modul in einer Produktivumgebung zum Einsatz kommt, wird der Kunde - zumindest im deutschsprachigen Raum - doch in aller Regel die Ausgaben dieses Modules in Deutsch sehen wollen. In solchen Fällen kann man entweder darauf warten, dass jemand anderes die Übersetzungsarbeit macht - was meistens einen ungewissen Projektendetermin zur Folge hat, oder man legt selbst Hand an, und übersetzt das Modul. Für die Versionen 5 und 6 von Drupal gibt es das Modul Translation template extractor, das eine .po-Datei liefert, die man direkt mit z.B. poEdit bearbeiten und übersetzen kann. Das geht ganz einfach: weiterlesen »
Wo war ich im letzten Teil stehen geblieben? Ach ja, bei den Keywords. Einen Ort, wo man zumindest ein oder vielleicht sogar zwei seiner Keywords unterbringen kann, hätte ich da noch: den Domainnamen! Natürlich sind dem Grenzen gesetzt, denn viele Keywords sind natürlich schon in unzähligen Kombinationen für Domains verbraucht worden. Aber ein Versuch kann nicht schaden. Kommen wir nochmal auf den fiktiven Carsharer in Frankfurt zurück. Wie wäre es zum Beispiel mit carsharing-frankfurt.de? Ob diese Domain noch frei ist, kann man leicht über seinen Provider herausfinden - oder direkt über die Domainabfrage bei der DENIC. Und siehe da - die Domain ist noch frei! Natürlich kann (und sollte) man zusätzlich noch eine Domain mit seinem Firmennamen reservieren. Aber als zusätzliche Domain ist die andere nicht schlecht, enthält sie doch zwei relevante Keywords. Und das verspricht zusätzliche Besucher auf der Webseite. weiterlesen »
