Drupal

Teilnehmer fotografieren das Session Board #dcruhr18 an Tag 2 hat jeder das sessionboard fotografiert? #dcruhr18, © Ronald Krentz, twitter1

Ich glaube es war so im Sommer letzen Jahres, als mein Freund und Genosse2 Boris Runte mich fragte, ob ich nicht Lust hätte, das fünfte DrupalCamp Ruhr 2018 als UnConference bzw. BarCamp (was es soweit mir bekannt noch nicht gegeben hat) mit zu gestalten und den dazugehörigen OpenSpace3 zu halten.

Klar! Ich mag BarCamps, finde Konferenzen mit OpenSpace Technologie wirklich gut und habe schon selbst den ein oder anderen OpenSpace facilitiert4. Richtig gut fand ich die Idee aber, weil uns in der Drupal Community meiner Meinung nach ein Konferenzformat fehlt, in dem noch mehr Partizipation möglich ist und welches sich noch mehr an den Bedürfnissen ihrer Teilgeber orientiert. Nicht zuletzt würde hier durch Diversität, Offenheit und Interaktion der Teilgeber gefördert. Ich hatte echt Lust auf dieses Experiment und wollte da unbedingt mitmachen.

In diesem Artikel möchte ich meine Erfahrungen, Probleme und FuckUps bei der Organisation eines Drupal BarCamps teilen.


VIM mit Syntastic for PHP  and Drupal development

Abbildung 1, Vim mit Editor Tab und location list.
Bei der Statischen Code Analyse1 (englisch linting), welche den den White-Box-Test-Verfahren zugeordnet ist wird der Quellcode einer Software auf seine Beschaffenheit überprüft.
Hierzu gehört z.B. neben dem eigentlichen Linting, in PHP mit z.B. php -l oder dem Tool phplint die Überprüfung von Coding-Standards2 oder das Erkennen von potenziellen Problemem bzw. suboptimalen Code wie z.B. ungenutzen Variablen, Properties oder Funktionen, zu hoher Komplexität (z.B. in Zusammenhang mit Wartbarkeit) und die Erkennung möglicher Fehler.

In der Programmiersprache PHP werden hierfür die Werkzeuge PHP_CodeSniffer3 (squizlabs/PHP_CodeSniffer4) und PHP Mess Detector5 genutzt, welche sich bequem in IDE's wie PHPStorm integrieren lassen6. Aber wie schaut es mit einem scheinbar betagtem und angestaubtem UNIX-Editor wie dem VIM aus?

Natürlich geht das auch im VIM! Wie zeigt dieser Post.

PHUnit und PEAR

Während der Installation von der benötigten Pakate für das PHING-Drupal-Template1, einer XML-Build-Datei für ein Phing-Build-System für Drupal-Projekte als zentraler Bestandteil eines PHING-Drupal-Jobs2 für den Continous Integration3 Server Jenkins4 lief ich in einer längere Fehlersuche. Zwei Pakete die durch pear.phpunit.de bereitgestellt werden, phpcpd5, ein PHP Copy n Paste Detector und phploc6, ein Tool für Code-Metriken sollen laut den Anforderungen7 via PEAR installiert werden.

pear channel-discover pear.phpunit.de

Aber schon die sog. "Channel discovery", vergleichbar mit einem apt-get update nach einer Erweiterung der Repositories schlägt fehl...

Error: No version number found in <channel> tag Discovering channel pear.phpunit.de over http:// failed with message: channel-add: invalid channel.xml file
Trying to discover channel pear.phpunit.de over https:// instead Error: No version number found in <channel> tag
Discovery of channel "pear.phpunit.de" failed (channel-add: invalid channel.xml file) </channel></channel>

Da es nicht mehr all zu lange dauert bis Debian 8 erscheint, bzw. bis Jessie den Status stable erreicht, haben wir bereits jetzt einige(in progress...) Drupal-Installationen auf eine Debian-Jessie-KVM migriert.

Von Debian 7 zu 8 hat sich nicht nur das Major-Release-Nummer von Debian erhöht, sondern auch der Webserver Apache hat einen Sprung gemacht, von Apache Version 2.2 auf 2.4.

Das bringt einige Implikationen mit sich...

Zur Dokumentation von Klassenvariablen, auch Properties1 oder Member genannt
wird in Doxygen2(u.a.) und PHPDoc3 (phpDocumentor 2) das Tag @var verwendet 4 5.

In PHPDoc wird die folgende Notation verwendet, diese wird so auch in Drupals Coding-Standards beschrieben6:

 
/**
 * Passed command line options
 * @var string
 */

protected $commandLineOptions;

...welche in Doxygen leider weder mit Typ noch mit dem zusätzlichen Kommentar angezeigt wird.

PHP Member Data Documenation within Doxygen, PHPDoc Notation

Bassets BoF, DCVIE 2013

© Karl Staudinger 1

Tobias und ich bei der Digital Asset Management mit Bassets BoF, November 2013, DrupalCampVienna.

Zu Besuch bei Reinblau Berlin

Gemeinsames arByten an Bassets, April 2013 bei Reinblau in Berlin.

In Zeile 6, registriere ich hier einen Menü-Pfad mit einer sog. Wildcard, also einem Platzhalter.

Das bedeutet in diesem Fall, dass während der Pfad-Anteil example/ fix ist, dass der zweite Pfad-Anteil %node_type_nid, wie hoffentlich schon durch seine Benennung deutlich wird, Node-ID's (nids) von Node-Typ example enthalten soll.

  1. /**
  2.  * Implements hook_menu().
  3.  */
  4. function example_menu() {
  5.   $items = array();
  6.   $items['example/%node_type_example_nid'] = array(
  7.     'title' => 'Example page title',
  8.     'description' => 'Example page description',
  9.     'page callback' => 'drupal_get_form',
  10.     'page arguments' => array('example_form', 1),
  11.     'access callback' => TRUE,
  12.   );
  13.   return $items;
  14. }
  • 404 bei Aufruf von example/123?
  • Wie bekomme ich es hin, dass der Pfad nur in Verbindung von Node-ID's vom Typ example valide ist?
  • ...vielleicht noch zusätzliche Validierungen?

Den Fallstrick und die Suche möchte ich euch ersparen...

db_like is the way to go

$result = db_query( 'SELECT * FROM person WHERE name LIKE :pattern', array(':pattern' =&gt; db_like($prefix) . '%') );

Das Testen von Drupal-Installationsprofilen ist relativ mühselig, da sich ein Teil der Schritte, bis man überhaupt erst zum Testen der eigentlichen Funktionalität kommt,
mit dem Build-Prozess beschäftigt.

Diesen muß man eigentlich für jede Änderung erneut durchlaufen...

  1. Drush make (das macht es im Falls des Feature-Server-Installations-Profiles)
    1. Drush make mit distro.make aus dem Git-Repository
    2. Download des Drupal-Cores
    3. Klonen des in distro.make hinterlegten Repositories für das Installationsprofil
    4. Rekursive Suche nach weiteren Drush-Makefiles,
      runterladen der Drupal-Module und des Themes, die im gefundenen Makefile drupal-org.make spezifiziert sind
  2. Sybolischer-Link vom erstellten Build auf die DocumentRoot des für Testzwecke angelegten VirtualHosts
  3. Drop auf alle Tabellen in der Zieldatenbank
  4. Installation von Drupal und einem bestimmtem Installationsprofiles, hier fserver_profile

In der scheinbaren Routine des manuellen Durchlaufen dieser Schritte entsteht zudem auch mal schnell ein Fehler.

So habe ich beim gefühlt 100sten Mal des Durchlaufens dieser Prozedur versehentlich in der falschen Datenbank alle Tabellen ge-dropt-t und dachte mir, Automatisierung muss her, schreib ein Shellskript...