Doku-Hotline

Bei Views in Drupal gibt es zwei beliebte Fragestellungen, die vom Module selbst nicht gelöst werden:

a) Der Apply-Button sollte besser ein Search-Button sein.

b) Es sollte einen Reset-Button geben, der die Suche zurücksetzt.

Meine ursprüngliche Lösung für den Search-Button war eine Implementation über die template.php.

function theme_preprocess_views_exposed_form(&$vars, $hook) {
// Change the text on the submit button
$vars['form']['submit']['#value'] = t(’Search’);
// Rebuild the rendered version (submit button, rest remains unchanged)
unset($vars['form']['submit']['#printed']);
$vars['button'] = drupal_render($vars['form']['submit']);
}

Die Frage des Reset-Buttons kam später auf, und ich beschloss, lieber ein eigenes Custom-Module dafür zu nutzen.  Dabei war natürlich erstmal nichts sichtbar - logisch, wenn Module und template.php versuchen, das gleiche zu überschreiben. Also löschte ich den Search-Button aus der template.php und implementierte beide Buttons über ein Custom Module views_formalter.

Das folgende wäre der Code, um für alle Views einen Reset-Button zu liefern:

<?php
/**
* Implementation of hook_form_alter().
*/
function views_formalter_form_alter(&$form, $form_state, $form_id) {
if ($form_id == 'views_exposed_form') {
$reset_button_value = t('Reset');
$current_display = $form_state['view']->current_display;
$form['submit']['#value'] = t(’Search’);
$form['reset'] = array(
‘#type’ => ‘markup’,
‘#value’ => ‘<input class=”form-button” type=”reset”
value=”‘. $reset_button_value . ‘ ” onClick=”javascript:window.location=\”.$GLOBALS['base_url'] .’?q=’. $form_state['view']->display[$current_display]->
display_options['path'] .’\';” />’,
);
}
}
?>

Bei onclick wird der Pfad des Views aufgerufen. Sah zunächst prima aus - dann fiel mir auf, dass das Suchfeld in organic groups ebenfalls ein exposed filter view ist, nämlich og_search. Also eine zusätzliche Abfrage eingebaut:

$exposed_views = array('og_search');
if (!in_array($form_state['view']->name, $exposed_views)) {
$reset_button_value = t(’Reset’);
…
}

Ursprünglich war diese Abfrage so formuliert, dass explizit diejenigen Views angegeben werden mussten, für die ein Reset-Button gezeigt werden sollte. Da in meinem Projekt die meisten Views den Button zeigen sollten, habe ich die Abfrage umgedreht.

Der Hintergrund der Entwicklung war der Wunsch, Seiten auf “outdated” setzen zu können und auf dieser Basis dann einen Hinweis in der Seitenausgabe zu haben. Das ließ sich als ein CCK-Feld namens “field_outdated” schnell einbauen, doch wie themen? Der Freund des Analysten ist an dieser Stelle ein strategisch in page.tpl.php platziertes:

<?php print_r($GLOBALS); ?>

Damit ist relativ schnell zu sehen, dass field_outdated ein Objekt der Node ist. Die Abfrage läuft dann auf folgendes hinaus:
Wenn outdated gesetzt ist UND die Eigenschaft ‘view’ empty ist (nämlich bei hidden), dann soll die von mir definierte Variable field_outdated_formatted gesetzt werden, und zwar mit HTML meiner Wahl. In diesem Fall möchte ich “Outdated” erscheinen lassen.

Code für die template.php
function THEME_preprocess_page(&$variables) {
if (!empty($variables['node']->field_outdated) && (empty($variables['node']->field_outdated[0]['value']))) {
$variables['field_outdated_formatted'] = ‘<span class=”outdated”>OUTDATED</span>’;
}
}

Code in page.tpl.php, beispielsweise hinter den Node Title einzugeben:
<?php print $field_outdated_formatted; ?>

Es gelten die üblichen Format-Caveats im Blog hier (demnächst ist wirklich ein neues Theme dran.)

Wenn das Exportfile einer MySQL-Datenbank ein wenig größer wird und die Timeouts beim Import zunehmen, kann man den Import automatisieren.

a) Anlegen einer Datei “import cmd” mit z.B. diesen Kommandos (in einer Zeile):
c:\xampp\mysql\bin\mysql.exe ––no-defaults ––user=username ––password=password ––database=datenbankname

im selben Verzeichnis wie mysql.exe.

b) Doppelklick auf die import.cmd-Datei. Dies öffnet eine Konsole in Windows.
c) Dort eingeben:
\. filename.sql und RETURN.

Der Import wird dann zeilenweise ausgeführt und kann in der Konsole verfolgt werden.

Als mir vor einer Weile in meinem Projekt auffiel, dass einige Nodes nicht gefunden wurden, war ich zunächst auf dem Holzweg und dachte, dass es etwas mit den vielen CCK-Feldern dieser Nodes zu tun hätte.

Aber weit gefehlt - es stellte sich nach mühsamer Suche heraus, dass das Problem durch den Import dieser Nodes hervorgerufen wurde. Offensichtlich erkennt Drupal nur dann Nodes als zu indizierend an, wenn “node_save” durchlaufen wird, was bei einem Import mit dem Node Import Module nicht geschieht. (Für lange Winterabende lohnt sich auch die Lektüre von Roberts Artikel Drupal Search: How indexing works.)

Eine Quick-and-Dirty-Lösung dafür ist, die betreffenden Nodes einmal kollektiv z.B. auf “published” zu setzen und dann manuell den Cron-Job für den Suchindex anzustoßen. In meinem Projekt kein Problem, allerdings nicht empfehlenswert, wenn z.B. viele Subscriber bei diesen Nodes mitlesen, da ein “published” zu einer Mailflut führen könnte ;)

Besser wäre es, entweder das Node Import Module umzuschreiben oder das im Hintergrund arbeitende Force Search Index Module (im Netz aufgestöbert) auf D6 umzuschreiben.

P.S. Tolle Sache mit einer Edel-Suche über Tomcat/Solr, aber auch diese setzt immer auf dem Drupal Search Index auf. Wenn also dort Probleme auftreten, hilft das nicht weiter.

Eine typische Anforderung bei einer Liste von z.B. ungelesenen Artikeln ist die Möglichkeit, diese per Checkbox und Knopfdruck auf gelesen zu setzen.

In Drupal kann für solche Massenaktionen über Views das Views Bulk Operations Module (VBO) genutzt werden. Der Haken hierbei war leider, dass es für “set to read” keine Action gab. Diese musste daher selbst programmiert werden. Das geschah ausgehend vom Node-Module im Core und mit einem Blick auf Advanced Forum, in dem es eine analoge Funktion für ganze Foren gibt.

“Set to read” bedeutet effektiv, dass der Timestamp-Eintrag in der Tabelle “history” für diese nid und uid geändert wird. Dies würde mit einem Replace gehen, aber da beide andere Codestellen mit Delete/Insert arbeiten, habe ich es analog implementiert.

Der gesamte Integrationspfad ins Drupal-Projekt ist:

1. Ein set-to-read Module anlegen und in der Modules-Liste unter admin/build/modules aktivieren.
2. Unter admin/settings/actions/manage prüfen, ob das Module aktiv und die Node-Action “Set to read” verfügbar ist.
3. Ein Seite mit einem “Bulk Operations” View bauen, und als Action “Set to read” auswählen. Bei sofortigem Abarbeiten sieht der User wenig Effekt, bei der Batch API erscheint der blaue Fortschritsbalken (meiner Meinung nach weniger schön). Auf eine Sicherheitsabfrage und eine Rückmeldung habe ich in meinem Projekt verzichtet, da es sich um keinen kritischen Schritt wie z.B. Löschen handelt.
4. Dann den View speichern und im Projekt prüfen.

Code für set_to_read.module-Datei (Achtung, beim Insert gibt es zwei unschöne Zeilenumbrüche):

<?php
/**
* Implementation of hook_action_info().
*/
function set_to_read_action_info() {
return array('set_to_read_noderead_action' => array(
'description' => t('Set to read'),
'type' => 'node',
'configurable' => FALSE,
'hooks' => array(
'nodeapi' => array('presave'),
'comment' => array('insert', 'update'), )
)
);
}
/**
* Implementation of the actual function set_to_read_noderead_action()
*/
function set_to_read_noderead_action(&$node) {
global $user;
if ($user->uid) {
$sql = 'delete from {history} ' .
"where nid='" . $node->nid . "' ".
"and uid='" . $user->uid . "'";
db_query($sql);
$sql = 'insert into {history} (nid,uid,timestamp) ' .
"values ('" . $node->nid . "', '" . $user->uid . "', unix_timestamp()) ";
db_query($sql);
}
}
?>


Da sich inzwischen doch einiges an Know-how und auch ein wenig Code angesammelt hat, wird es hier in Zukunft mehr Drupal-Beiträge geben. Dabei ist mir mal wieder aufgefallen, dass mein Blogdesign extrem untauglich für Code-Publikation ist, da ständig die Zeilen schlecht umgebrochen werden. Da wird wohl in absehbarer Zeit mal ein Redesign fällig.

Drupal ist jedenfalls am Boomen. Nebeneffekt davon ist, dass hier die erste Projektanfrage gelandet ist (von einer Firma in Stuttgart, die wohl immer noch gerne Unterstützung hätte und zumindest gestern noch mit dem Stichwort “Drupal” bei Monster.de auftauchte). Trotz aller Versuche vor und nach Weihnachten konnte ich die “2-3 Tage vor Ort, Templates, Programmierung” nicht an andere Drupalisten weiterreichen, was vermutlich auch an der Mischung lag - die wenigsten fühlen sich in Design und Programmierung zuhause. Wenn die Firma in Hamburg gewesen wäre, wäre ich vielleicht mal einen Tag auf Verdacht vorbeigefahren, aber Stuttgart ist etwas weit für so eine Aktion. Schöne Arbeitswelt, die Arbeit nicht vergeben bekommt :)

Für das Drupalcamp in Essen im Februar bin ich inzwischen auch angemeldet, und freue mich sehr, alte und neue Gesichter zu treffen. Am Freitag abend wird es wohl ein Aufwärmtreffen geben, und bisher plane ich dabeizusein. Vielleicht biete ich auch einen Showcase an… aber das muss ich erst noch absprechen.

Wer einer alten Geocities-Seite nachtrauert, der kann bei http://www.geocities.ws/ nachschauen, ob diese dort zu finden ist.

Alternativ ist die WayBackMachine bei archive.org auch ein guter Start, um eine bestimmte Geocities-Seite zu suchen.

Geocities zeigt sehr schön die Gefahren eines Quasi-”single point of failures” - immerhin war Geocities über viele Jahre der größte kostenlose Webseiten-Hoster. Unmengen von alten Webprojekten hatten sich dort gesammelt, die z.T. nicht mehr betreut wurden, die aber die “Frühzeit” des Internet mitgeprägt haben und deren Verlust daher durchaus spürbar ist. Schön, dass es Archivierungsprojekte jenseits der eigenen lokalen Speicherung gibt - diese werden meiner Meinung nach in Zukunft auch immer wichtiger.

Tolle Jahreszahl, oder? Nicht, dass wir auch nur annähernd so weit wären wie in den Science-Fiction-Filmen, aber immerhin, wir drehen uns noch ;)

Was bringt 2010 für dieses Blog? Mehr Beiträge - wollja, es gibt mich noch. Vor allem zum Thema Drupal wird es mehr zu lesen geben, nicht zuletzt da meine aktuelle Entwicklungsarbeit (Firmen-Intranet) langsam aus den Kinderschuhen heraus ist.

Für mich gibt es hoffentlich auch dieses Jahr wieder interessante Projekte rund um Dokumentation und Webentwicklung, und vielleicht ein neues Notebook - ein leckeres MacBook oder das übliche Windows-auf-Dell, das ist grad noch die Frage.

Wer mich persönlich kennenlernen möchte, der wird weiterhin am ehesten glücklich bei Treffen der Drupal User Group Hannover (Mitfahrgelegenheit möglich) sowie sporadischer bei Treffen des Woman Entrepreneur Clubs, Untergruppierung Bremen.

Auf ein erfolgreiches Jahr 2010!

“Two hours of trial and error can save ten minutes of manual reading.”

Betrifft mich aktuell nicht, aber auch ich habe schon “fictitious documentation” verfasst:

Fictitious documentation refers to documentation that fails a lie detector test but which passes the project manager’s approval. (zum Artikel)

Idealerweise entspricht die Dokumentation dem Ist-Stand; realistischerweise ist regelmäßig ein Soll-Stand abgebildet, da z.B. nur eine unvollständige Software-Vorversion verfügbar ist. Auch das Verschweigen bestimmter Eigenschaften (besonders solcher, die potentiell Benutzer verärgern) ist nicht selten.

Der zitierte Artikel bezieht sich primär auf echte Bugs und die Frage, ob diese beschrieben werden sollen. Hier findet sich eine Stärke von Open-Source-Systemen - da für diese niemand Geld zahlt, ist es üblich, z.B. bei Modulen ausführlich zu warnen, wenn bestimmte Einschränkungen vorhanden sind. Bei Kaufsoftware dagegen, die zumindest scheinbar einen stabilen, geprüften, fehlerfreien Stand liefern soll, werden Bugs lieber nicht erwähnt, wenn es sich vermeiden lässt…