Php - Stefan Wienert's Blog

Drupal Modulentwicklung - I - Einführung und Hello World

2010-09-03T06:40:00Z

Beruflich habe ich recht viel mit Drupal zu tun, einem in PHP geschriebenem CMS. Das Plugin-System, Module genannt, ist recht umfangreich und bietet vielfältige Möglichkeiten, fast jede Stelle des CMS’ anzupassen, ohne wirklich am Kerncode rumzuhacken.

Das ganze ist recht durchdacht, und bei weitem besser als nacktes PHP. Desweiteren bin ich kein großer “Fan” von den beiden Modulen “Views” und “CCK”, die sehr oft verwendet werden, um Modelle und SQL Statements nachzubilden. Ich bevorzuge aber Code, und nicht das Zusammenklicken dessen.

Voraussetzung für das Tutorial:

installiertes Drupal 6
PHP/SQL Erfahrungen

Hello World Modul

Drupal bietet zwei Ordner an, in die wir unsere Module packen können: ./modules und ./sites/all/modules. Der Konvention nach, sollten selbstgeschriebene Module in den letzteren, beides arbeitet aber korrekt.

In einen der beiden Ordner legen wir nun einen neuen Ordner an:

./modules/helloworld bzw. ./sites/all/modules/helloworld

In der Regel heißt der Ordner des Moduls so, wie das Modul selbst. Das muss aber nicht so sein. Auch können noch beliebige weitere Unterordner vorher folgen, um z.B. alle Module einer gewissen Funktionalität zu bündeln.

Ein Drupalmodul hat mindestens 2 “magische” Dateien, also Dateien, die per Definition eine besondere Rolle haben.

./helloworld/helloworld.info
./helloworld/helloworld.module

helloworld.info

./helloworld/helloworld.info ist nur eine Datei, wo Metainformationen über das Modul stehen, und woraus die Informationen für die Modulseite entnommen werden. Der Aufbau ist vorgegeben und recht kurz:

; $Id$
name = Hello World Modul
description = ...
package = StWienert
version = 1.0
core = 6.x
dependencies = user

Damit definiere ich, dass mein Modul vom Modul user abhängt, also nicht ohne dieses aktiviert werden kann, und in der “Package” StWienert, d.h. einer gesonderten Gruppierung “StWienert”, in der Modulübersicht zu finden ist.

helloworld.module

Dies ist eine PHP-Datei, die erst aufgerufen wird, falls unser Modul aktiviert ist. Hier der Code für ein Hello world:

<?php
function helloworld_menu() {
  $items = array();
  $items['test/helloworld'] = array(
    'title' => 'Hello-World Site',
    'page callback' => '_helloworld_page',
    'access arguments' => array('access content'),
    'type' => MENU_CALLBACK,
  );
  return $items;
}

function _helloworld_page() {
  return "hello World";
}
# kein schlie?endes ?> notwendig, da die Datei inkludiert wird

Nun können wird das Modul aktivieren, und die Seite “example.com/test/helloworld” aufrufen, und sollten unser Hello World sehen.

Drupal basiert auf einem Callbacksystem. Funktionen, mit einem genau spezifizierten Namen, werden zu bestimmten Zeitpunkten aufgerufen und können Einfluss nehmen. Diese besonderen Funktionen werden “Hooks” genannt, wovon es eine ganze Menge gibt.
Hier verwenden wir den sogenannten hook_menu. Anstelle von “hook” müssen wir den (internen) Namen des Moduls einsetzen, also denselben Namen, den unsere Dateien .info und .module führen.

Ein paar der interessanteren Hook-Funktionen werde ich in einem folgenden Blogpost vorstellen, ansonsten ist ein wenig Stöbern in der Übersicht angebracht.

Addendum

Must-have-Module

Hier noch die wesentlichen Basis-Developer-Module, die ich nicht mehr missen möchte. Was hätte ich an Zeit gespart, hätte ich gleich das alles gewusst :)

admin_menu Fügt ein JS Menü am oberen Bildrand, mit denen man sehr schnell an den benötigten Funktionen ist, und sich auf Dauer Fantastillarden an Klicks erspart. Ausserdem gibt es einen “Cache leeren” Button unter dem ersten Menüpunkt. Dieser ist wichtig, um z.B. den hook_menu unseres Moduls nach einer Änderung noch einmal aufgerufen wird. Sonst wird u.a. die Menüinformation gecacht.
devel Fügt zwei für mich wesentliche Dinge ein; eine Funktion “dpm($variable)”, die wie das print_r von PHP funktioniert, aber das ganze wesentlich übersichtlicher. Zweiteres einen Error-Backtrace. Also statt “Whitescreen of Death” gibt es detaillierte Fehlerinformationen, neben einer Fehlermeldung und exakter Ort des Auftretens auch alle Variablen des aktuellen Kontextes. Quasi ein Debugger für Arme. Das Modul hat noch viele Features mehr, ein Blick lohnt.
drush Drupal-Shell. Dies ist kein Drupalmodul, sondern ein externes Programm, das eine neue Schnittstelle zu Drupal eröffnet, nämlich die Kommandozeile. Dies kann natürlich nur installiert werden, wenn man Shellzugriff auf seinen Server hat. Hier ein paar Leckerbissen:

drush dl admin_menu && drush en admin_menu
# Ladet das Modul admin_menu herunter, entpackt es 
# nach sites/all/modules, dann wird das gleich aktiviert (enabled)
drush cc
# leert den Cache
drush eval "echo 'hello world'"
# Führt beliebigen PHP Code im Kontext des Drupals aus

CRE

Der Chaosradio-Radio-Express Podcast hat eine Sendung zum Thema Drupal. Hierbei geht es aber nicht um die Modulentwicklung, sondern um das Ökosystem allgemein.
Interessant ist das Fazit von Tim Pritlove: “Es ist ja nicht so, dass es [Drupal a.d.R.] sich anbiedern würde”. Ja das stimmt, Drupal haut nicht vom Hocker, und gerade die Features der z.B. DatenbankAPI nicht gerade auf Höhe der Zeit. Aber es ist was grundsolides und sehr flexibles.

Bessere PHP Shell, ähnlich wie Rubys irb

2010-02-08T11:06:00Z

Nachdem ich bei Ruby von der recht mächtigen und gut tunebaren Interactive Ruby Shell (HIRB und Wirble seien hier anzumerken) verwöhnt wurde, war ich auf der Suche nach einer ähnlichen Lösung für PHP.
Leider ist die eingebaute CLI Shell mit “php -a” relativ nutzlos, da man Output selbst ausgeben muss, es keine Autocomplete gibt usw.

Allerdings gibt es die php-shell welche recht interessant wirkt und ich heute mal runtergeladen habe.

Unter Ubuntu muss man noch php pear nachinstallieren:

sudo apt-get install php-pear php5-cli php5-dev
sudo pear install http://jan.kneschke.de/assets/2007/2/17/PHP_Shell-0.3.1.tgz

# Jetzt kann die shell mit:
php-shell.sh
#gestartet werden

Das reduziert den PHP-Schmerz schonmal ein ganzes Stück :)

PHP - Die beste Wahl für's Web?

2009-12-16T21:37:00Z

Eines vorneweg: PHP war mein Einstieg in die Webprogrammierung. Die ersten Schritte haben, aufgrund der C-ähnlichen und mir damit bekannten Syntax, sogar sehr Spaß gemacht.

Nicht ganz ausschweigen sollte man den Fakt, dass eine Skriptsprache ganz gleich welcher Rubrik natürlich nicht das Allheilmittel jeglicher Softwareprojekte ist, weshalb ich mich hier ganz klar auf Sprachen für (private und kleinkommerzielle) Webentwicklung beschränken möchte.

Story

Wenn man wie ich von PHP kommt, ist bei Ruby und Rails vieles am Anfang ungewöhnlich, und es braucht seine Zeit, bis man sich an den Fakt, das alles ein Objekt ist, gewöhnen muss. Dies schafft aber auch erstklassige Möglichkeiten, Programmtext effizient und damit übersichtlich zu gestalten.

Im Gegensatz zu PHP wo ich bei trivialsten Dingen jedesmal das Rad neu erfinden muss (Ich denke nur an DateTime Handling, fortgeschrittene Stringfunktionen) hat Rails und Ruby eine sehr ausdrucksstarke Bibliothek dabei.
Schön finde ich diese Grafiken. Hiernach wurden für PHP-Projekte deutlich mehr Line of Codes am Gesamtkuchen gezählt, die meiste Zunahme an Projekten überhaupt gegeben hat. Also man für eigentlich alle Projekte unter PHP eine Wagenladung Code mitbringen muss. DRY FTW.
Auch die extrem bunte Bibliothek von PHP, die scheinbar über die Jahre aus C-Sprachen zusammengeklaut wurde, mit total uneinheitlichen Verhalten von Funktionen: usort verändert sein Argument und gibt nichts zurück, str_replace belässt es und gibt das Ergebnis zurück.

Die Syntax — Showdown

Der Fakt der C-Abstammung ist für mich einer der größten Kritikpunkte, denn intuitiv ist was anderes (strstr zum Finden eines Strings…, bei Ruby: find).
Wenn ich mal wieder ein etwas größeres Modul in Drupal beginn, vergesse ich so manches mal ein “;”.
Das nervt und ist absolut unnötigt. Mehr als eine Anweisung ist nur für Obfascuation-Wettbewerbe geeignet. Desweiteren ist das “;” trotzdem unter Ruby optional nutzbar.

Warum diese extreme Anlehnung der Syntax an den C-Sprachen? Ist sie für betriebssystemnahe Anwendungsfälle recht angebracht, da minimal abstrakt, führt sie beim Anwendungsfallszenario “Webentwicklung” doch mehr Hürden denn Erleichterungen.

Warum wie ein Computer denken? Wenn ich doch wie ein Mensch denken kann? Für ein kleines µ mehr an Performance? Dafür mit einer deutlich angestiegenen Fehleranfälligkeit, teilweise unüberschaubaren Programmfluss und einer grottigen Wartbarkeit?

Klar ist es toll, wenn man vorher C, C++, Java oder was auch immer programmiert hat, kurz mal PHP sieht, und denkt “Hey, das ist ja genau das gleiche!”. Auch ich hatte diesen Aha-Effekt (Im Rückblick nichts, gegen den Aha-Effekt, den ich z.B. bei der ersten Nutzung der script/console, dem ersten scaffold oder der Validate <—> Formularfehlermeldung hatte :D)

PHP ist in meinen Augen als Websprache absolut ungeeignet.

Viele gute PHP-Frameworks wie CakePHP, Zend oder auch auch in erweiterter Bedeutung Drupal, können meiner Ansicht nach nicht über diesen Aspekt hinwegtäuschen.

Hier ein paar Auszüge meiner Lieblingshassobjekte:

1234	htmlspecialchars <---> h$this-> <---> Warum muss man diese Redundanz innerhalb einer Klasse mit sich herumschleppen? Warum "weiß" die Klasse nicht direkt über ihre Methoden?

Weitere Vorteile ergeben sich aus der kompletten Objektorientierung:

12	str_replace("a","b","Hallo"); <---> "Hallo".gsub("a","b")preg_match("/../",$source,$target); <---> target = /.../.match(source)

Im Endeffekt ist PHP sowas von laberlastig und ausdrucksschwach, dass ich z.B. bei der Entwicklung von Drupal-Modulen ohne Snippets überhaupt nicht mehr klarkommen würde. Klar liegt es vielleicht auch ein stückweit an Drupal, nichsdestotrotz bietet die aufgepfropfte Objektorientierung auch hier keine Erleichtung.

But it’s a complex language that contains a lot of advanced idioms which will be very hard for PHP and Visual Basic programmers to absorb.

Sometimes, too much magic is too much magic, and it can definitely be the case that the flow of code is too direct or too clever to be understandable by regular developers. Developers were able to do the jump from imperative to object-oriented programming, but it was a hard fight.

Quelle

Die vielerorts kritisierte scheinbar komfortable Konvertierung von PHP hat auch bei mir schon zu so manchen erstaunlichen Programmverhalten geführt.

Durch Rails habe ich aber auch die korrekte Benennung meiner Modelle und Datenbanktabellen gelernt. Also wenn ich eine Nutzer-Tabelle habe, dann heißt sie “users”, der Primärschlüssel “id”, ein Nutzerfremdschlüssel einer anderen Tabelle würde “user_id” heißen.
Warum? Bei Rails wird man für die korrekte Benennung “belohnt”, indem einige Dinge komplett automatisch passieren, sollte man sich an die Konventionen gehalten haben. Dazu zählt: Benutzung von “partials” (Also eines View-Code-Schnipsels, dass für jedes Item eines Objekts einmal ausgeführt wird),

Manch einer mag anführen, dass Syntax Geschmackssache ist, und bei der Bewertung einer Sprache nur einen Teilaspekt darstellen sollte. Dem stimme absolut nicht zu. Je mehr Sonderzeichen ( “{ } ; $”) im Textfluss sind, desto schwerer lässt es sich lesen.

Rails Fanboy for life?

Auch bei Ruby oder Rails ist (natürlich wie immer in meinen Augen) nicht alles perfekt: neidisch blicke ich auf die Einrücksemantik von Python, spart sie mir doch die Blockschlüsselwörter. Oder das von Haus aus installierte “erb” finde ich durch “haml” erst erträglich gemacht :).

Auch habe ich ständig das Gefühl, dass ich erst einen Bruchteil der Sprache voll ausschöpfe. Insbesondere die funktionalen Aspekte wie procs habe ich bisher nur selten verwendet.
Auch die sehr mächtigen Testmöglichkeiten durch gems wie rspec, cucumber oder silenium habe ich bisher eher akademisch benutzt.

In vielen Foren habe ich auch von einem fast schon spürbaren Hass auf Rails-Nutzer bemerkt; da wird von “Latte-Machiatto schlürfende” “Fanboys” geredet, die nur “oberflächliche” Anwendungen programmieren [können]. Kein Vergleich mit JavaEE, C, whatsoever. Das mag sein, dass ein Railsprojekt nicht unbedingt als System für eine Forbes 100 Firma geeignet ist, aber für sehr viele Anwendungsfälle, insbesondere bei überschaubaren Websites, mit nicht ganz 100% mainstreammäßigen also individuell Anforderungen (“Blog”, also Wordpress, Mini social Community Drupal, usw) ist es in vielerlei Hinsicht eine bessere Wahl als… PHP.
Schön gesagt von xaviershay auf github:

No ugly PHP Stylings burning your eyeballs.

Quelle

Ganz ausgelassen habe ich hierbei Django/Python, dass ganz oben auf meiner Liste der zu begutachtenden Frameworks steht.

Fazit?

Ja ich bin subjektiv.
Vielleicht liegt es an dem gut gemachten Screencast von Ryan Bates und teach-me-code? Oder der per Plugins (wirble, hirb) aufgemöbelten Liveshell irb bzw. script/generate, die mir so manchen “Ausprobier”-Lauf erspart hat (Kein Vergleich mit php -a )? Oder an dem teils humorig geschrieben Buch von O’Reilly? Oder an der Wahl der Namen? (“god” das Monitoring Tool, “sass:Syntactically awesome Stylesheets”, “YAML”: Yet another markup language", hpricot also wie Aprikose…)?
Ruby/Rails verbreitet einfach eine andere Grundstimmung – Die Leute haben Spaß beim Programmieren!

3 Links zum Thema Rails

2009-08-18T08:47:00Z

Einen interessanten Artikel aus dem t3n-Magazin zum Thema Rapid-Prototyping gibt es hier:
t3n-rapidprototyping

Weiterhin, für alle Rails-Jünger natürlich unverzichtbar sind die Screencasts von Ryan Bates, die einfach nur Spaß machen, und meiner Meinung nach zu den besten (frei erhältlichen) Screencasts im Netz gehören!
railscasts

Als Umsteiger von PHP fand ich diese Seite auch noch recht interessant, in der äquivalente Rails/Ruby-Konstrukte gängige PHP-Funktionen abgebildet werden :)
rails4php

Notenübersichts-Bot in PHP

2009-08-14T08:49:00Z

Vor zwei Wochen kam mir beim Überprüfen der aktuellen Notenergebnisse die Idee in den Sinn, das Ganze zu automatisieren und als Feed zur Verfügung zu stellen, um es in meinen Feedreader mit einzubinden und so immer auf dem aktuellen Stand sein zu können ;).

Der Einfachheit halber hab ich PHP/Curl genommen, da ich kurz mal in Ruby reingeschaut hatte, mir die HTTP-Bibliothek aber nicht zweckdienlich erschien.

Teil 1: Den Quelltext der Webseite holen

Dazu mal mit Firefox und LiveHTTP-Headers-Addon schauen, was man beim Login zu alles schickt. In unserem Fall muss man danach noch einen Klick auf “Notenübersicht” machen.

Das ganze dann in cURL gießen und eine cookies.txt schreibbar bereitstellen:

  $username="Meine Matrikelnummer"
  $passwort="Mein Passwort ;)"
  $ch = curl_init();
  //Variablen setzen
  $url="https://wwwqis.htw-dresden.de/qisserver/rds?state=user&type=1&category=auth.login&startpage=portal.vm";
  //$url="https://wwwqis.htw-dresden.de/qisserver/rds?state=user&amp;type=1&amp;category=auth.login&amp;startpage=portal.vm";
  $arrSubmit="username=$username&submit=%C2%A0Ok%C2%A0&password=$password";
  $cookies="cookie.txt";
//Session Optionen setzen
  curl_setopt($ch, CURLOPT_URL,$url);
  curl_setopt ($ch, CURLOPT_POST, 1);
  curl_setopt($ch, CURLOPT_POSTFIELDS, $arrSubmit);
  curl_setopt($ch, CURLOPT_HEADER, 0);
  curl_setopt($ch, CURLOPT_COOKIEJAR, $cookies);
  curl_setopt($ch, CURLOPT_COOKIEFILE, $cookies);
  curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
  curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
//Ausf?hren der Aktionen
  curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
  $result=curl_exec($ch);
  curl_close($ch);

In unserem Beispiel des HIS-QIS gibt es noch eine Art zweiter Session-ID, die ausgelesen werden, und mit übergeben werden muss:

12	preg_match("/asi=([^\"]*)\"/",$result,$treffer); $asi=$treffer[1];

Dann der Zweite durchlauf mit der asi:

 $url="https://wwwqis.htw-dresden.de/qisserver/rds?state=htmlbesch&moduleParameter=Student&menuid=notenspiegel&asi=$asi";
  $ch = curl_init();
  curl_setopt($ch, CURLOPT_URL,$url);
  curl_setopt ($ch, CURLOPT_POST, 0);
  curl_setopt($ch, CURLOPT_HEADER, 0);
  curl_setopt($ch, CURLOPT_COOKIEJAR, $cookies);
  curl_setopt($ch, CURLOPT_COOKIEFILE, $cookies);
  curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
  curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
  curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
  $result=curl_exec($ch);
  //echo curl_error($ch);
  //Session beenden
  curl_close($ch);

Damit ist der Text in der Variablen $result
Extraktion der wichtigen Zeilen mit XPath

Mittels Firebug schauen, wo die Prüfungsergebnisse drinstehen und die XPaths kopieren bzw. analysieren. Damit erhalten wir eine NodeList die wir ausgeben/speichern können:

$Doc = new DOMDocument();
$Doc->loadHTML($result);
$Doc->preserveWhiteSpace = false;
$Doc->normalizeDocument();
$XPath = new DOMXPath($Doc);
$NodeList = $XPath->query("//tr[@bgcolor='#EFEFEF']");
foreach ($NodeList as $node)
{        
  echo $node->nodeValue;
  ...
}

Schon fast fertig, was fehlt noch?

Die Datumswerte auslesen, nach Sekunden umwandeln um danach die Noten danach zu sortieren.

Einfacher Caching Algorithmus à la “Wenn unsere cache-datei älter als 30 minuten ist, dann erstelle sie neu [durchlaufe den Algorithmus] und schreibe das Ergebnis in die Cache-Datei; andernfalls gib nur die cache-Datei aus”

Ausgabe als RSS-Feed, einfach mal die Spezifikation googlen ;)