Weri's World

Ich finde es immer mühsam, wenn Dateien von Download-Links direkt im Broser geöffnet werden und das aktuelle Fenster "überschreiben". Eine unschöne Lösung finde ich auch, wenn Donload-Links jeweils mit einem "_blank" versehen sind und so ein neues Fenster geöffnet wird, welches je nach Browser dann leer stehen bleibt.

Optimal finde ich es, wenn immer der "Datei speichern" Dialog erscheint.

Grundsätzlich kann das im .htaccess sehr einfach mit einem Eintrag provoziert werden (z.B. für PDFs):

Das Beschreibungsfeld ist standardmässig eine Textzeile mit 128 Zeichen. Grundsätzlich reicht die Anzahl Zeichen um die Datei oder das Bild zu beschreiben. Will man aber mehr Text erfassen können, lässt sich dies leider nicht über das UI einstellen. Man kann dies aber sehr einfach über zwei Variablen setzen:

<?php
  variable_set('filefield_description_type', 'textarea');
  variable_set('filefield_description_length', 2048);
?>

So wird das Beschreibungsfeld als Textarea angezeigt und die Textlänge ist auf 2048 Zeichen vergrössert.
 

In einem aktuellen Projekt haben wir uns einige Gedanken dazu gemacht, wie wir mit wiederholenden Feldkombinationen (z.B. Überschrift, Bild, Nodereferenz) in den Inhaltstypen vorgehen wollen. Folgende Möglichkeiten konnten wir uns vorstellen:

1. CCK mit Felxfield
2. Implementation eines eigenen CCK Feldes/Widgets welches die notwendigen Daten aufnehmen kann
3. CCK 3 Dev Version mit Multigroup Feature

Nummer 1 ist schnell ausgeschieden, da das Flexifield noch immer Alpha ist und auf der Modulseite auf das CCK Multigroup-Feature verweisen wird.

Nun habe ich mir endlich Zeit genommen um den Wechsel vom FCKEditor zum CKEditor vorzunehmen. Die Umstellung auf das neue Modul ist sehr einfach und wenn man schon das FCKEditor-Modul verwendet hat, werden die Einstellungen sauber übernommen. Am besten man deaktiviert das FCKEditor-Modul gleich beim Aktivieren des CKEditor-Modul in Drupal.

Auf drupalcenter.de wurde ein neues Buch 'Best Practice - Drupal Sites - Guidelines' angelegt. Dieses Buch soll Guidlines zum Arbeiten mit Drupal bereitstellen. Es wäre toll, wenn du auch deine Erfahrungen und Anregungen beitragen würdest und diese jeweils als Kommentar hinzufügst. Rapsli wird diese dann einarbeiten, damit die Schreibweise im Buch einigermassen konsistent bleibt.

Ich hatte aktuell das Problem, dass der Zugriff auf Nodes für den Gast immer verweigert wurde. Ich überprüfte mehrmals die Berechtigungseinstellungen und alles war korrekt konfiguriert.

Nach längerer Suche bin ich auf das Problem gestossen. In der 'node_access'-Tabelle fehlte der Default-Eintrag. Ich weiss zwar nicht warum und wie der gelöscht wurde, aber dies war definitiv das Problem. Folgender Eintrag muss immer vorhanden sein:

Bei einem aktuellen Projekt habe ich im Projektspezifischen Modul ein paar Blöcke über hook_block() registriert. Anstatt dass diese Blöcke nun in der Auswahl erscheinen, waren alle Blöcke plötzlich verschwunden!

Nach ein bisschen Recherche war das Problem auch gefunden. Es lag daran, dass das verwendete Theme den selben Namen hatte wie das Modul (beide hatten den Projektnamen). Kurz war der Name des Moduls umgeschrieben und nach dem Löschen des Caches waren alle Blöcke wieder da.

Scheinbar ist das Problem bei Drupal 7 behoben, da andere Hooks verwendet werden.

Wenn der im Titel genannte SQL Fehler vorkommt liegt es meistens daran, dass der über die Funktion db_rewrite_sql($sql) automatisch hinzugefügte SQL Syntax erwartet, dass die "Haupt"-Tabelle der letzte Eintrag vor dem Join ist.
 
Zum Beispiel bei Abfragen von Nodes wird über den Aufruf von db_rewrite_sql($sql) ein Join zur 'node_access'-Tabelle hinzugefügt. Hier das Beispiel welcher zu dem genannten Fehler führt:

Im Moment beschäftigt mich das Thema ob man nicht am besten für die Drupal Entwicklung auf Linux wechseln sollte. Dann könnte man doch einige Problematiken aus dem Weg räumen (z.B. Drush läuft nicht wirklich unter Windows). Mein Kollege Rapsli hat auch was zu diesem Thema geschrieben.

Auf Golem gibt es einen interessanten Überblick über die verschiedenen Distributionen.

Es kommt immer wieder vor, dass die Standard-Ausgabe der Suchresultate nicht wie vom Kunden gewünscht daher kommt. Zwar kann man in den Feldeinstellungen des Inhaltstypen für die Suche bestimmen welche Felder für die Anzeige verwendet werden sollen, aber dies ist unzureichend wenn man spezifische Vorgaben für die Darstellung hat. Daher ist man darauf angewiesen, die komplette Node für die Anzeige auszulesen.

Nun ist es aus meiner Sicht nicht das optimalste, bei der Anzeige der Resultate die Node jeweils mit node_load() für die Ausgabe zu laden (Performance). Daher macht es Sinn, die wichtigen Informationen der Node gleich im Solr-Dokument mit abzuspeichern. Dies kann wie folgt eingerichtet werden: