Permalink

Drupal 7: Views und die Titel der Gruppierungen

Derzeit beschäftige ich mich wieder einmal mit den Views (Ansichten) in Drupal. Bei einem View wollte ich gleich zwei Gruppierungen anwenden. Diese kann man (wie bekannt sein dürfte) bei den Einstellungen des Formats festlegen:

Gruppierungen in Views

Wenn man nur eine Gruppierung festlegt, dann wird über jeder Gruppe der Gruppenname (also der Titel) angezeigt. Hier wird er idealerweise von den „<h3>“-Tags umgeben. Fügt man nun, wie im Bild zu sehen, eine weitere Gruppierung hinzu, dann erhalten die Titel der zweiten Gruppierung die „<h3>“-Tags. Bei der ersten Gruppierung wurden sie aber nun durch ein „<div>“ ausgetauscht. Dies ist ziemlich ärgerlich, wenn man eine vernünftige Struktur haben möchte.

Anstatt nun einfach den CSS Markup anzupassen, kann man das Template für die Gruppierung anpassen. Zuständig hierfür ist das Template „views-view-grouping.tpl.php“, welches auch das angesprochene „<div>“ enthält. Um dies nun zu ändern, erstellt man innerhalb des Themeordners eine Datei mit einer der folgenden Namen:

  1. views-view-grouping–viewnamedisplayid.tpl.php
  2. views-view-grouping–displayid.tpl.php
  3. views-view-grouping–viewname.tpl.php
  4. views-view-grouping.tpl.php

Welcher Dateinamen gewählt wird, ist davon abhängig, wo dieses Template so überschrieben werden soll. Entweder soll das überall passieren (4.), bei allen Anzeigetypen der speziellen View (3.), bei allen Views mit dem speziellen Anzeigetyp (2.) oder bei der speziellen View mit dem speziellen Anzeigetyp (1.). Die fett markierten Stellen müssen entsprechend angepasst werden. Wenn man mit der Maus auf den Anzeigenamen drüber geht, dann sieht man anhand der entsprechenden URL die jeweiligen Namen (im folgenden Bild ist viewname gelb und displayid rot markiert):

Namen der View und die Display ID

Als Inhalt der neuen Datei nehmen wir den von der Originaldatei „views-view-grouping.tpl.php“:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<?php
/**
* @file
* This template is used to print a single grouping in a view.
*
* It is not actually used in default Views, as this is registered as a theme
* function which has better performance. For single overrides, the template is
* perfectly okay.
*
* Variables available:
* - $view: The view object
* - $grouping: The grouping instruction.
* - $grouping_level: Integer indicating the hierarchical level of the grouping.
* - $rows: The rows contained in this grouping.
* - $title: The title of this grouping.
* - $content: The processed content output that will normally be used.
*/
?>
<div class="view-grouping">
  <div class="view-grouping-header"><?php print $title; ?></div>
  <div class="view-grouping-content">
    <?php print $content; ?>
  </div>
  </div>

Hier kann man nun die HTML-Tags in Zeile 20 entsprechend austauschen.

Die Darstellung des zweiten Titels kann man mit Hilfe der Designausgabe ändern (Erweitert -> Andere -> Theme: Information).

Permalink

Eclipse Kepler: Abstürze unter Linux

Seit einiger Zeit ist mir die IDE Eclipse ständig abgestürzt bzw hat sich einfach beendet – ohne dass eine Fehlermeldung angezeigt wurde. Seit den letzten Updates in Eclipse beendet sich das Programm bei jeder Kleinigkeit, womit nicht mehr produktiv arbeiten kann.

Nun scheine ich wohl eine Lösung gefunden zu haben. Wie es aussieht, ist hier Webkit der Verursacher. Bei der beschriebenen Lösung wird für den Browser in Eclipse Webkit durch xulrunner (Runtime Environment von Mozilla) ausgetauscht.

Hier die Lösung:

1. Zuerst muss man eine passende xulrunner Version herunterladen. Die unterstützten Versionen für die eigene Eclipse Installation findet man in der FAQ von Eclipse. Xulrunner kann von dem FTP Server von Mozilla heruntergeladen werden. Ich habe hier die Datei „xulrunner-10.0.4esr.en-US.linux-x86_64.tar.bz2“ genommen. Nach dem Herunterladen muss diese Datei nur noch entpackt (tar -xjf xulrunner-10.0.4esr.en-US.linux-x86_64.tar.bz2) werden. Bei mir befindet sich xulrunner nun im Homeverzeichnis.

2. Nun muss in der eclipse.ini nur noch der Austausch eingestellt werden. Hierzu fügt man folgende Zeilen hinzu. Der Pfad in der zweiten Zeile muss entsprechend Schritt 1 angepasst werden.

-Dorg.eclipse.swt.browser.DefaultType=mozilla
-Dorg.eclipse.swt.browser.XULRunnerPath=/home/username/xulrunner/

Das war es schon. Dies funktioniert bei mir bisher ohne Probleme.

Permalink

Migration von OpenVZ zu Xen

Ein neuer Server – eine neue Technik. Bisher haben ich für die Virtualisierung der Server OpenVZ eingesetzt. Das gute daran war die einfache Bedienung. Und da sich der Hostserver und die virtuellen Server den Kernel teilen, ist der Overhead gering. Nun wollte ich aber bei einem neuen Server Xen verwenden. Zum einen gefällt mir hier, dass die virtuellen Server besser getrennt sind (man kann den vServern festen Speicher zusichern und bei der Zuteilung der CPUs ist Xen auch flexibler). Zum anderen enthält das Debian Repository bereits einen aktuellen Xen Kernel. Bei OpenVZ muss man immer einen etwas älteren 2er Kernel aus einem externen Repository benutzen.

Nun habe ich die Umstellung gewagt. Der Xen Beginners Guide war eine große Hilfe. Nur kurz der Hinweis: Ich hatte zum einen Probleme mit den xen-tools. Diese habe ich mit dem Paket von Debian sid ausgetauscht. Wie das geht, hatte ich schon mal im Artikel zu duplicity erklärt. Außerdem gibt es den Bug (im Code habe ich die Ursache noch nicht gefunden), dass der Gateway im neuen vServer nicht gesetzt war, obwohl ich diesen dem Befehl „xen-create-image“ übergeben hatte. Daher war der vServer auch nicht von außen erreichbar. Also falls ihr das Problem habt, dann müsst ihr ihn unter „/etc/network/interfaces“ selber setzen (am besten da wo die leere Zeile ist ^^).

Nun aber zur Migration: Ich hatte keine Lust die vServer neu aufzusetzen. Der Vorteil war, dass der bisherige vServer unter Debian wheezy lief und der neue das ebenfalls tun sollte. Das ist auch die Vorraussetzung für eine erfolgreiche Migration. Nun aber zu den Schritten:

1. Auf dem neuen Hostserver den neuen vServer erstellen (xen-create-image). Bei Bedarf das Netzwerk noch fixen (siehe oben).

2. Den neuen vServer wieder stoppen.

3. Den neuen vServer mounten (hier gehe ich davon aus, dass LVM benutzt wird):

mount /dev/vg0/servername-disk /mnt

4. Auf dem alten Hostserver habe ich dann eine Datei angelegt (/root/exclude.txt), wo ich eingetragen habe, was alles nicht übertragen werden soll:

/etc/fstab
/etc/securetty
/boot
/etc/inittab
/etc/network
/proc
/lib/modules
/sys
/etc/resolv.conf
/etc/hosts
/tmp
/dev
/var/lock
/etc/mtab

5. Dann habe ich während der alte vServer noch läuft, folgenden Rsync gestartet (muss entsprechend angepasst werden – es macht Sinn den Befehl in „screen“ laufen zu lassen):

rsync -azvP --delete --exclude-from="/root/exclude.txt" -e "ssh -p $port" --numeric-ids /var/lib/vz/private/$vservernummer/ root@neuerhostserver:/mnt/

6. Anschließend habe ich den alten vServer heruntergefahren und anschließend den vorherigen rsync-Befehl noch einmal ausgeführt (für die in der Zeit geänderten Dateien).

7. Zum Schluss brauchte ich nur noch die Partition aus Schritt 3 unmounten (umount) und den Server starten. Nun sollte alles funktionieren. Man sollte hier alles testen ehe man den alten vServer entsorgt. Außerdem sollte man nicht die DNS Einträge vergessen bzw. an z.B. die IP beim externen Monitorings anpassen. 😉

Das war es eigentlich schon. Diese Anleitung habe ich mir aus folgenden Quellen zusammengestellt:

Permalink

Piraten und #nixgate – meine Meinung

Mal meine Meinung zu dem #nixgate:

Zu aller erst: Bitte nicht immer alles so total ernst nehmen. Die Welt ging nicht unter als Frauen ihre Brüste gezeigt haben und sie wird jetzt auch nicht untergehen, wenn mal ein paar Dienste nicht funktionieren. Einfach mal etwas anderes machen und weniger aufregen.

Dann zur Sache: Erst einmal kann ich die Aktion verstehen. Es ist ein Versuch zu zeigen, dass Teile der IT und Verwaltung nicht mehr mitmacht, wenn es so weiter geht.

Andererseits finde ich, dass das kein Streik ist. Streik ist eigentlich etwas passives – also man macht etwas nicht mehr. Aber anscheinend sind die Server zu Menschen geworden und machen auch nichts mehr. Ich hätte es ja verstanden, dass eine Woche nicht mehr gebucht wird, keine Austrittsanträge angenommen werden oder sich die IT nicht um Serverprobleme o.ä. kümmert. Aber so haben sie nun doch etwas gemacht: destruktiv. Gut, so hätte man von dem Streik bestimmt weniger mitbekommen.

Außerdem finde ich es schade, dass es gerade jetzt (also gestern Nacht) passiert ist. Im Mumble bin ich öfters mal zu dieser großen Bundesrantgruppe rübergeswitcht und hatte das Gefühl, dass Leute nicht nur rumranten, sondern auch überlegt haben, wie es besser werden kann. Die Leute haben da angefangen vernünftig miteinander zu sprechen bzw. es gab da auch endlich mal vernünftige Stimmen, die gegen Parolen argumentiert haben.

Das wurde leider gestern durch den Shutdown kaputt gemacht. Ich möchte gar nicht wissen wie es danach auf anderen Mumble Servern weiterging.

Und wie soll nun dieser Shutdown helfen? Mumble und diverse Mailinglisten sind down. Als ob Leute sich jetzt über direkte Kontakte oder über das Telefon zusammenfinden. Die Alternative ist ja Twitter. Da wissen wir mittlerweile, dass man mit 140 Zeichen keine Diskussion durchführen kann. Jetzt weichen die Leute auf andere Dienste aus, was diese ganze Sache eh torpediert.

Ich hoffe mal, dass diese Aktion bald endet und diese nicht zu sehr geschadet hat.

Vielen Dank für das bis zum Ende lesen.

Permalink

GIT Merge bei einem reverteten Merge

Habt ihr den Titel verstanden? Ja, das ist verwirrend. Hier die Erklärung:

Für ein Uni Projekt wurde von einem GIT Projekt (nennen wir es „A“) ein „Fork“ („B“) erstellt, auf dem alle Änderungen commitet werden. Da GIT dezentral ist, hat natürlich jeder Projektteilnehmer lokal ein GIT Repository („C“). Die Commits von C werden ständig auf B gepusht und von B auf C gepullt.

Ab und zu möchte man nun die Änderungen aus A auch in B und C haben. Hierzu fügt man in C das Repository A als Remote hinzu (sofern noch nichts geschehen):

git remote add $remotename $remoteurl

Nun kann man einfach die Änderungen von A bei C pullen (natürlich sollte C vorher alle Commits von B haben) und dann auf B pushen:

git pull $remotename master
git push orgin master

Zwischen den beiden Befehlen kann es passieren, dass der Merge nicht automatisch durchgeführt werden kann, sondern es müssen ein paar Konflikte gelöst werden. Entweder macht man dies manuell oder benutzt beispielsweise:

git mergetool

Nachdem man dort die Konflikte beseitigt hat, fügt man diese Dateien per

git add $dateiname

zum Tracking hinzu. Am Ende committet man die Änderungen wie gewohnt per

git commit

Nun kann es aber passieren, dass in A beispielsweise der Code gerade kaputt ist, die Probleme nicht beseitigt bekommt und man lieber doch den Stand von B haben möchte. Hierzu verwendet man

git reset --hard origin/master

Nun kann es aber passieren, dass man die Commits von A in C gemergt und sofort auf B gepusht hat, aber erst danach feststellt, dass der Code in A kaputt war. Die sauberste Lösung hierbei ist es, den Merge Commit zu reverten. Dabei wird ein neuer Commit gemacht, bei dem alle Änderungen zurückgeändert werden:

git revert -m 1 $commit_id

Natürlich muss man das dann noch auf B pushen.

Nach der langen Erklärung bin ich nun endlich bei meinem Problem angelangt: Zwischenzeitlich wurden die Fehler bei A gefixt, aber auch weitere Änderungen bei B und C durchgeführt. Wenn man nun wie oben von A pullt, dann gibt es Probleme beim Lösen der Konflikte. Dort werden dann Stellen als geändert markiert, die man selber gar nicht angefasst hat, sondern noch vom missglückten Merge bzw. dem Revert sind. Den Merge brechen wir erst einmal ab:

git merge --abort

Die Lösung des eben beschriebenen Problems ist eigentlich ziemlich simpel, wenn man sie erst einmal sieht: Man reverted einfach den Revert des Merges. Haha. ^^ Also per „git log“ den Revert raussuchen und den Revert reverten:

git revert $commit_id

Hier kann es passieren, dass die ersten Konflikte auftreten, die aber je nach eigenen Änderungen relativ einfach gefixt werden können (so vorgehen wie oben: git add und git commit). Dann kann man wie oben von A pullen. Dort sollten die Konflikte einfacher zu lösen sein. Danach natürlich noch zu B pushen.

Übrigens sollte man nach jedem Merge schauen, ob noch alles funktioniert, ehe man diesen pusht. 😉