Wer Module für Drupal schraubt, bekommt es früher oder später mit zum Teil relativ großen und unüberschaubaren Arrays zu tun. Beim gezielten Ändern dieser Arrays verliert man oft den Überblick und die Ausgabe per print_r() hilft wegen der schieren Größe nur bedingt weiter. Auf der Suche, nach einem Tool, welches es möglich macht die Ebenen der Arrays ein- und auszuklappen, bin ich auf Sublime Text 2 gestoßen.

Sublime Text 2 ist nicht nur ein schöner Editor, sondern klappt auch alles, was nur irgendwie geht ein und aus. Damit hilft er nicht nur die Übersicht in Arrays zu behalten, sondern lässt sich auch relativ einfach als Outliner (miss)brauchen. Der Editor ist kostenlos uneingeschränkt benutzbar und meldet sich hin und wieder mit einem Popup, dass weggeklickt werden will, man durch Einwerfen von 59 $ los wird. Außerdem gibt es den Editor für Windows, Linux und den Mac. Da ich ST2 im Moment nur zur Ansicht von Arrays benutze, habe ich bis jetzt vom Kauf abgesehen. Sollte ich ihn irgendwann für mehr benutzen wollen, zahle ich auch gerne dafür.

Somehow I feel stupid writing this at this time. I should have cared about this earlier and it isn't hard either but now it's time.

During a project one tries several different approaches to solve problems which won't make it into the final product and that's ok. With Drupal this often means trying out several different modules which won't make it into the final product. Many modules lead to a bloated site so for the final product I turned them off and deleted them and more or less thought everything's ok with that.

Sometimes it is but many modules (not all) make changes in the database such as adding tables. Mostly you recognize these tables by there names which should have the module's name inside. You could delete them by hand but there my be additional changes and the obvious path is different.

The uninstall tab contains every module that has an uninstall function and is turned off. If you uninstall the module using this function though this tab everything is done for you. You can try out what you want without cluttering your database. I reduced my number of tables from 206 to 192 in a recent project by uninstalling all the junk that I just tried out.

Irgendwie komme ich mir dämlich vor das jetzt erste bemerkt zu haben, aber ich hab es jetzt bemerkt und trage es hiermit in die Welt hinaus.

Während eines Projekts probiert man unweigerlich diverse Dinge aus, die wieder verworfen werden und sich im finalen Produkt nicht wiederfinden. Das ist ganz normal und dabei installiert man im Fall von Drupal diverse Module, die sich im finalen Produkt nicht wiederfinden. Viele Module, bedeuten viel Balast und bis jetzt hab ich für den finalen Einsatz der Seite einfach die überflüssigen Module deaktiviert und gelöscht und dachte alles war gut.

Kann es auch sein, ist es wahrscheinlich jedoch nicht, denn viele (nicht alle) Module verändern die Datenbank. Legen z.B. zusätzliche Tabellen an. Diese sind am Namen in der Regel dem jeweiligen Modul zuzuordnen und könnten auch per Hand gelöscht werden, aber eigentlich ist der Plan ein anderer.

Im "Deinstalieren"-Reiter werden alle Module aufgelistet die deaktiviert sind und eine Deinstallationsroutine anbieten. Damit sind die vom Modul vorgenommen Änderungen schnell getilgt und das Modul lässt sich Rückstandslos entfernen. Auf diese Weise hab ich die Zahl meiner Tabellen in einem Projekt von 206 auf 192 reduziert.

Aus mir nicht völlig transparenten Gründen begrüßte mich diese Fehlermeldung, als ich in einer lokalen Drupal 6 Installation auf die Blockadministration zugreifen wollte. Anschließend dann auch ausgeloggt auf der Startseite. Kurzes Stöbern im Interweb förderte schnell den Tipp zu Tage, dass man doch den Wert von max_allowed_packet in der MySQL-Konfiguration erhöhen solle.

Während dieser Wert für das Gros der Webdeveloper in der Datei my.inianzugeben ist, half mir dieser Vorschlag auf dem Mac mit MAMP wenig weiter. Hier fand sich zwar eine my.cnf, doch Einstellungen hier hatten keine Wirkung. In der knappen Doku auf deren Webseite fand sich nichts hilfreiches. An anderer Stelle war zu lesen, dass man die Datei nach MAMP/Library/ kopieren muss, damit die Einstellungen Wirkung zeigen. Auch auf diesem Weg blieb die Wirkung bei mir aus.

Lösung war es schließlich im Startskript MAMP/bin/startMysql.sh den Wert durch die Option --max_allowed_packet=12M zu setzen. Den Erfolg dieser Aktion kann man schließlich nicht nur daran sehen, dass die Fehlermeldung verschwindet, sondern auch, indem man im Terminal den MySQL-Server aufruft ./Applications/MAMP/Library/bin/mysql aufruft und sich dann mit den Befehl SHOW VARIABLES; die Werte sämtlicher Variablen angeben lässt.

Das Neustarten des Servers zur Übernahme des Parameters ist obligatorisch.

Update:

Nach einem Update auf MAMP-Pro bin ich in das selbe Problem gelaufen. Hier lässt sich die Einstellung in der Datei ./Applications/MAMP PRO/MAMP PRO.app/Contents/Resources/my.cnf ändern, in der eine Variable für max_allowed_packet bereits existiert und nur geändert werden muss.

Hm, where to go? The primary topic of this spot on the net should be Drupal. I want to collect my personal findings during my interaction with Drupal. So this should be a place for me to re read things I once learned just to forget them again. Especially in the filed of developing my own modules I'm at the beginning right now so there should be a few things that are new to me about which I'll probably write, but this knowledge might be helpful for anyone else on the interwebs. We'll see.

So this is a place for me to reread things. Perhaps others may find help to and with a bit of luck people from around the web will correct me in places I am wrong or help me out with bits an pieces I am missing.

It's sure I am going to display code so it might be a good idea to add syntax highlighting on these pages. In theory there's a module for that (there's always a module) which is already installed. If it's working you should be able to see in the next paragraph ; )

<?php
print("Hello World.");
?>

Zugegeben, Beispielcode zu finden, der tut, was ich im Folgenden beschreibe war nicht sonderlich schwierig. Die Lösung war aber so erleuchtend, dass ich jetzt einfach diesen Artikel darüber schreiben muss.

Folgendes Problem

Ich möchte eine Node beliebigen Typs speichern. In meinem Fall war es eine Kontainer-Node, die eigentlich nur Referenzen (Node Reference ist eine Untermodul von CCK, welches entsprechende Felder zur Verfügung stellt) auf 4 andere Nodes speichert. Den prinzipiellen Ablauf hatte ich vorher mit Formulardaten bereits kennen gelernt und läuft für Formulardaten wie folgt:

1. Man wandle das Array mit den Daten aus dem Formular in ein stdClass-Objekt
2. Man übergebe dieses Objekt an node_save()

Aus dem Formular-Array kommt jetzt außer den eigentlichen Daten des jeweiligen Content-Types noch jede Menge anderes Zeug mit (User, Datum, Menüoptionen ...). Wenn ich also jetzt einen Content-Type habe, der über 4 Node-IDs 4 Nodes referenziert, muss ich mir dann selbst ein Objekt bauen, dass den ganzen Datenwust schon mitbringt?

Folgende Lösung

Glücklicherweise nicht, denn der ganze Datenwust um die eigentlichen Felder herum wird von node_save() automatisch hinzugefügt wenn er fehlt.

Hier ein bisschen Beispielcode, der das Vorgehen verdeutlicht:

<?php
global $user;
$container = new stdClass();
// node-type angeben
$container->type ='node_container';
// node-title angeben
$container->title = 'node-container_'.$user->uid.'_'.time();

// node_reference felder befüllen
$container->field_1 = array(
0 => array( 'nid' => $node_1->nid )
);
$container->field_2 = array(
0 => array( 'nid' => $node_2->nid )
);
$container->field_3 = array(
0 => array( 'nid' => $node_3->nid )
);
$container->field_4 = array(
0 => array( 'nid' => $node_4->nid )
);
// speichern des Kontainers
node_save($container);
?>

$node_1 bis $node_4 sind dabei die Nodes, die in $container gespeichert werden.

Nachdem ich im ersten Blog-Post schon den Versuch gewagt hatte das Code-filter-Modul zu nutzen, um Code zu highlighten (entsprechende Syntaxelemente bunt einfärben, um die Lesbarkeit von Code zu erhöhen), schlug dies eine ganze Weile kläglich fehl. Die Version des Moduls für Durpal 7 war zur Zeit der Installation auch noch beta. Ein Blick in die gemeldeten Bugs zeigte mir heute die Lösung des Problems.

Code filter wird als Filter im benutzten Text-Format (z.B. Filtered HTML) in die Kette der vorhandenen Filter eingefügt und muss nach dem "Limit allowed HTML tags"-Filter kommen, da dieser sonst die von Code filter fürs Syntax-Highlighting hinzugefügten Tags wieder entfernt. Kleine Änderung und schon funzt auch das Highlighting.

<?php
echo "Bunte Syntax";
?>

Gerade mal nachgeschaut, wie man denn in Drupal Browserweichen bastelt. Prinzipiell gehört solche Logik in eine "template.php"-Datei ins Themeverzeichnis. Dort (in der template.php) wird dann der User-Agent abgefragt und dementsprechend dann mit der Funktion "drupal_add_css()" eine spezifische CSS-Datei hinzugefügt.

Eine mögliche Implementierung, die den Weg von - "ich weiß theoretisch was zu tun ist" - zum - "hey, es funktioniert" hab ich auf dem WildKatana Blog gefunden. Dort wird borwsertechnisch alles abgefrühstückt, was gerade am Markt ist und was mach nicht braucht, ist schnell auskommentiert.

Drupals API-Referenz

Eine der wichtigsten Seiten, die ich mir nicht merken kann und die immer wieder gute Dienste tut, ist die API-Referenz, die auf api.drupal.org zu erreichen ist.

Hier sind zum nachschlagen alle Drupal eigenen Funktionen gelistet und zwar mit einer Beschreibung der Funktion, der Parameter, einer Liste der Funktionen, die diese Funktion aufrufen, sowie der Position in einer Drupal-Installation (Pfad und Zeile) und schließlich dem Quelltext.

Im Quelltext sind schließlich die meisten Funktionen und Konstanten klickbar und führen dann entweder auf die Entsprechende Drupal-API-Seite, oder auf die entsprechende Referenz auf php.net.

API-Referenz + X

Wer noch ein bisschen mehr will, der kann auch die Referenz auf api.lullabot.com ausprobieren. In meinem Fall habe ich gerade festgestellt, dass dort nicht nur die Drupal-Funktionen hinterlegt sind, sondern ich dort z.B. auch die Funktionen des CTools-Moduls finde.

Mit Lullabot bin ich bis jetzt noch nicht wirklich warm geworden. Irgendwie sind die in Sachen Drupal ganz groß, machen auch Podcasts etc. Ich für meinen Teil hab in den Podcast mal reingehört, wollte mir das aber schon wegen der Audioqualität nicht antun und bevor ich dort die API-Referenz gefunden habe, hat mir auch die Seite nie wirklich weiter geholfen. Gerade in Sachen Podcast war das aber jetzt nur eine kleine Stichprobe, von daher: You're milage may vary. ; )

Chaos Tools

Da ich CTools schon erwähnt habe noch 1-2 Sätze dazu. Bei CTools handelt es sich soweit ich weiß um eine Sammlung von Funktionen, die der "Macher" von Views und Panels geschrieben hat. So benötigt Panels beispielsweise CTools. Ich arbeite derzeit mit CTools, da es nützliche Funktionen bietet, die sowohl Multi-Step-Formulare, als auch das AJAX einfacher machen.

Ja, wo hin geht's? Primär soll es hier erstmal in Richtung Drupal gehen. Ich möchte hier die großen und kleinen Erkenntnisse im Umgang mit Drupal festhalten. Das Ganze natürlich für mich, aber auch für die Um- und Nachwelt. Gerade im Bereich der Modulprogrammierung, bei der ich noch relativ am Anfang stehe, gibt es davon reichlich.

So habe ich einen Platz zum Nachschlagen von Dingen, von denen ich weiß, dass ich sie mal wusste. Mit ein bisschen Glück helfe ich anderen so weiter und mit noch mehr Glück korrigiert jemand Ideen, die nur halb so großartig sind, wie sie mir erscheinen.

Dafür muss hier sicher Code wiedergegeben werden, der sich mit ordentlichem Highlighting besser liest. Theoretisch ist dafür schon ein Modul installiert und ob es seinen Dienst auch brav verrichtet zeigt sich im Nächsten Absatz ; )

<?php
print("Hallo Welt.");
?>