Lorem Ipsum Ges.m.b.H. » Code

Doctrine 2 SQL Profiler in Debugleiste

Daniel Leeb — Wed, 21 Dec 2011 15:12:17 +0000

Auch wenn es sich um ein sehr spezielles Thema handelt, möchte ich hier kurz zusammenfassen, wie man einen Doctrine 2 SQL Logger/Profiler in einer Zend Framework Umgebung umsetzen kann. Da die Kombination aus ZF und Doctrine 2 durchaus beliebt zu sein scheint, zumindest wenn man von Blogeinträgen und Tutorials im Internet ausgeht, könnte dieser Beitrag für manch einen hilfreich sein. Vorweg möchte ich auch noch auf eine praktische Lösung hinweisen, um Doctrine 2.x mit dem Zend Framework 1.x zu verbinden: Und zwar Bisna von Guilherme Blanco, zu finden in seinem GitHub Repository. Danach lässt sich Doctrine mittels Zend_Config (ini, xml, etc.) konfigurieren.

SQL Queries in der ZFDebug-Leiste

Nach der Integration von Doctrine in unsere neue Webapplikation basierend auf dem Zend Framework fehlte uns noch eine einfache Möglichkeit SQL Queries anzuzeigen. Da wir bereits ZFDebug verwenden, lag ein zusätzliches Plugin für die Ausgabe in der Debugleiste für uns nahe. ZFDebug wurde leider seit Mitte 2009 nicht mehr aktualisiert, funktioniert jedoch immer noch sehr gut, liefert hilfreiche Informationen rund um die Webapplikation und lässt sich sehr einfach erweitern. Daher werde ich hier zeigen, wie man den Doctrine 2 Profiler in einem ZFDebug Plugin verwenden kann.

Profiler

Doctrine bietet mit Doctrine\DBAL\Logging\SQLLogger bereits ein Interface um einen Logger mit einer Datenbank-Verbindung zu verknüpfen. Wir implementieren dieses Interface mit den beiden Methoden startQuery() und stopQuery() und speichern einfach alle Queries in ein Array das wir später in der Debugleiste ausgeben werden.

DoctrineExtensions/Profiler/ZFDebugProfiler.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
25
26
27
28

namespace DoctrineExtensions\Profiler;

class ZFDebugProfiler implements \Doctrine\DBAL\Logging\SQLLogger
{
public $totalTime = 0.0;
public $queries = array();

protected $_curQuery = null;

public function startQuery($sql, array $params = null, array $types = null)
{
$this->_curQuery = new \stdClass();
$this->_curQuery->sql = $sql;
$this->_curQuery->params = $params;
$this->_curQuery->time = \microtime(true);
}

public function stopQuery()
{
$executionTime = \microtime(true) - $this->_curQuery->time;
$this->totalTime += $executionTime;
$this->queries[] = array(
'time' => $executionTime,
'sql' => $this->_curQuery->sql,
'params' => $this->_curQuery->params
);
}
}

Nun müssen wir Doctrine noch mitteilen, dass unser Profiler verwendet werden soll. Wird Bisna eingesetzt, kann dies ganz einfach in der Konfiguration (hier beispielsweise in einer ini-Datei) erledigt werden:

1	resources.doctrine.dbal.connections.default.sqlLoggerClass = "DoctrineExtensions\Profiler\ZFDebugProfiler"

Im Hintergrund wird der Konfiguration der DBAL-Verbindung eine neue Instanz unseres SQL Loggers übergeben:

1
2
3

$configuration = new Doctrine\DBAL\Configuration();
$configuration->setSQLLogger(new DoctrineExtensions\Profiler\ZFDebugProfiler());
$connection = Doctrine\DBAL\DriverManager::getConnection($connectionParams, $configuration);

Natürlich lässt sich statt des ZFDebugProfilers auch einfach ein LogProfiler oder FirebugProfiler implementieren, welche die Queries direkt in eine Datei schreiben bzw. im Firebug ausgeben. Wir verwenden unseren Profiler hingegen, um die SQL Queries in einem ZFDebug Plugin aufzulisten.

ZFDebug Plugin

Nachdem der SQL Logger an Doctrine übergeben wurde, werden alle SQL Queries, deren Parameter und die Dauer der einzelnen Queries gespeichert. Ausgeben wollen wir das Ganze in unserer ZFDebug Leiste, wir erstellen also zunächst ein Plugin, indem wir das Interface ZFDebug_Controller_Plugin_Debug_Plugin_Interface implementieren:

ZFDebug/Controller/Plugin/Debug/Plugin/Doctrine.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
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76

class ZFDebug_Controller_Plugin_Debug_Plugin_Doctrine implements ZFDebug_Controller_Plugin_Debug_Plugin_Interface
{
protected $_identifier = 'doctrine';
protected $_profilers = array();

public function __construct(array $options = array())
{
if (isset($options['profiler'])) {
$this->_profilers = $options['profiler'];
}
if (!is_array($this->_profilers)) {
$this->_profilers = array($this->_profilers);
}
}

public function getIdentifier()
{
return $this->_identifier;
}

public function getTab()
{
if (!count($this->_profilers)) {
return 'No Profiler';
}
foreach ($this->_profilers as $profiler) {
$profilerInfo[] = count($profiler->queries) . ' in ' . round($profiler->totalTime * 1000, 2) . ' ms';
}
return implode(' / ', $profilerInfo);
}

public function getPanel()
{
$html = '';
if (!count($this->_profilers)) {
return $html . 'No Profiler';
}
foreach ($this->_profilers as $index => $profiler) {
$html .= '

Profiler ['.$index.']

;

foreach

(

$profiler

queries

$query

)

{

$html

[' . round($query['time'] * 1000, 2) . ' ms] ';
$html .= $this->highlightSql(htmlspecialchars($query['sql']));

if (!empty($query['params'])) {
$html .= '
bindings:' . $this->listBindings($query['params']);
}
$html .= '

;

}

$html

';
}
return $html;
}

private function listBindings($bindings)
{
$html = '

;

foreach

(

$bindings

$binding

)

{

$html

';
if (is_array($binding)) {
$html .= $this->listBindings($binding);
} else {
$html .= $binding;
}
$html .= '

;

}

return

$html

';
}

private function highlightSql($sql)
{
$statements = array('SELECT', 'UPDATE', 'INSERT', 'FROM', 'WHERE',
'LEFT JOIN', 'JOIN', 'ORDER BY', 'GROUP BY',
'OFFSET', 'LIMIT', 'SET', 'VALUES');
return preg_replace('/('.implode('|', $statements).')/', '\1', $sql);
}
}

Da wir auch ein wenig Wert auf die Formatierung legen, ist der Code des Plugins etwas umfangreicher ausgefallen. Wichtig sind die getTab() und getPanel() Methoden, welche die HTML Ausgabe für den Titel des Plugins in der Debugleiste und für detaillierte Informationen im Panel beim Ausklappen des Plugins zurückgeben.

Nun muss das Plugin noch in den Optionen von ZFDebug eingetragen werden. Beim Bootstrapping der Applikation erstellen wir das ZFDebug_Controller_Plugin_Debug und registrieren es beim Frontcontroller. Zunächst gehen wir jedoch sicher, dass die Doctrine Ressource bereits existiert und erstellen eine Liste der Profiler aller DBAL-Verbindungen, die wir anschließend unserem Plugin übergeben. In den ZFDebug Optionen tragen wir unter Plugins unsere Klasse ZFDebug_Controller_Plugin_Debug_Plugin_Doctrine mit dessen Konfiguration ein:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

$this->bootstrap('doctrine');
$container = $this->getResource('doctrine');
$profilers = array();
foreach ($container->getConnectionNames() as $connName) {
$profiler = $container->getConnection($connName)->getConfiguration()->getSQLLogger();
if ($profiler instanceof DoctrineExtensions\Profiler\ZFDebugProfiler) {
$profilers[$connName] = $profiler;
}
}
$options = array(
'plugins' => array(
'ZFDebug_Controller_Plugin_Debug_Plugin_Doctrine' => array(
'profiler' => $profilers
)
)
);
$debug = new ZFDebug_Controller_Plugin_Debug($options);
$this->bootstrap('frontController');
$this->getResource('frontController')->registerPlugin($debug);

Nun lassen sich alle Queries von Doctrine und deren Performance übersichtlich in ZFDebug anzeigen. Zu beachten ist vielleicht, falls man Bisna verwendet, dass durch den Aufruf von $container->getConnection($name)… die DBAL-Verbindungen tatsächlich gestartet werden. Ansonsten würden sie nicht unbedingt bereits beim Bootstrapping, sondern erst bei der ersten Verwendung gestartet. Da ZFDebug aber sowieso nur im Debug-Modus laufen sollte, muss diesbezüglich nur auf den Unterschied zwischen Debug- und Production-Modus geachtet werden.

Verwendete Versionen:
- Zend Framework 1.11.11
- Doctrine 2.1.5
- ZFDebug 1.5

Zend Framework 2

Da ZF2 wohl noch einige Monate auf sich warten lässt, kann man im Moment leider noch keine vollwertige Webapplikation darauf aufbauen. Spätestens zum Release wird aber eine Umstellung fällig werden, sollte die zweite Version das einhalten was sie momentan verspricht. Es wäre daher interessant zu wissen, ob ZFDebug auch für ZF2 erscheint, was wenn man sich die Projektaktivität ansieht eher zu bezweifeln ist – oder es vielversprechende Alternativen dazu gibt?

Magento: Verschiedene Preise in StoreViews

Peter Hasitschka — Fri, 26 Aug 2011 09:55:51 +0000

Magentos Shop-Hierarchie ist in 3 Ebenen aufgebaut: Website – Store – StoreView. Letztere wird im Allgemeinen dazu verwendet, um mehrere Sprachen auf einen Shop anzuwenden. Je nach Einstellung können Felder global oder StoreView-spezifisch gesetzt werden. Außerdem kann man ohne Probleme verschiedene Währungen angeben.

Unser Kunde hatte jedoch den Wunsch, für ein spezielles Land eigene Preise festsetzen zu können. Leider bietet Magento out-of-the-box keine Möglichkeit das Preisattribut auf StoreView Ebene zu setzen, sondern nur global.

Abhilfe bietet das Modul Store Price[1] von ZenPrint. Es wandelt den Preis, der in der Datenbank als Decimal-Attribut gespeichert ist, von einem fixen globalen Attribut in ein frei wählbares um. Es lässt sich über Magento Connect Version 1.0 installieren, bzw. in neueren Magento Versionen problemlos manuell einspielen.

Nach der Installation muss das Attribut unter System->Configuration->Catalog->Catalog noch auf die StoreView Ebene gesetzt werden (Siehe Screenshot).

Aktivieren des Store Price Moduls

Nun können beim Wechsel des Store Views in der Backend-Produktansicht verschiedene Preise eingegeben werden.

: Store View spezifischer Preis

BugFix: Falls im Frontend die Preise in der Kategorieansicht plötzlich als SpecialPrices erscheinen muss noch schnell ins Template eingegriffen werden:
Unter app\design\frontend\[path_to_templates]\template\catalog\product\price.phtml findet man etwa in Zeile 43 folgenden Code:

1	$_product = $this->getProduct();

Diesen erweitert man um eine weitere Zeile, die das Produkt vollständig lädt:

1
2
3

$_product = $this->;getProduct();
$_product = Mage::getModel('catalog/product')
->load($_product->getId());

Schlussendlich sind im Frontend für jeden StoreView respektive Sprache verschiedene Preise verfügbar.

Preis im StoreView 1

Preis im StoreView 2

Links:

[1] http://www.magentocommerce.com/magento-connect/bott/extension/976/zenprint-store-price

WordPress 3.1 Pluginbugfixing bei Kategorielinks

Ing. Karl Kowald — Thu, 24 Feb 2011 21:43:58 +0000

Seit gestern wird WordPress 3.1 als stable ausgeliefert, jedoch scheinen einige Plugin-Anbieter ihre Software nicht damit vorabgetestet zu haben, denn bei einigen treten seltsame Fehler auf, betreffend der mod_rewrite-Funktion für sprechende URL’s und Kategorielinks

Kategorielinks verweisen auf Artikel oder 404-Fehlerseite

Ob man ein Plugin mit solch einen Fehler hat bemerkt man eigentlich sehr einfach. Klickt man auf einen Kategorielink und wird automatisch auf einen Artikel der Kategorie oder eine 404 Fehlerseite weitergeleitet, anstatt in der schönen Kategorieübersicht zu landen hat man ein nicht kompatibles Plugin dabei.

1 Zeile auskommentieren als Sofortmaßnahme

Erstaunlicherweise lässt sich das in den meisten Fällen jedoch recht einfach lösen. Einfach nach folgender Zeile suchen:

1	$wp_rewrite->flush_rules();

Diese Zeile einfach auskommentieren oder löschen und schon funktionieren die Kategorielinks wieder korrekt. Trotz dieses Eingriffs funktionieren die Plugins alle noch korrekt (bisher 3 Plugins auf diese Art bearbeitet). Dies ist zwar keine sinnvolle Dauerlösung, jedoch werden in den nächsten Tagen und Wochen die meisten Pluginentwickler adequate, getestete Lösungen via Updates nachreichen.

Betroffene Plugins via Linux-Shell finden

Betreiber von Blogs mit sehr vielen Plugins können mit diesem Aufruf in der Linuxshell rasch und effizient herausfinden in welche Plugins von diesem Problem betroffen sind.

1	grep -rl 'flush_rules' /pathtowordpress/wp-content/plugins/

Mit diesem Aufruf erhält man eine Liste betroffener Dateien zurück, dort muss nur noch der entsprechende Eintrag auskommentiert werden.

WordPress Adminbar für Usergruppen global deaktivieren

Ing. Karl Kowald — Wed, 23 Feb 2011 19:30:25 +0000

Seit heute ist WordPress in der Version 3.1 veröffentlicht. Mit diesem Release kam unter anderem ein Feature namens Adminbar, für Benutzer von wordpress.com bereits eine bekannte Kopfleiste im Frontend von WordPress um schneller Backendfunktionen auch im Frontend nutzen zu können.

Adminbar für registrierte Benutzer global deaktivieren

Grundsätzlich eine sinnvolle Sache für Admins und Redakteure, jedoch für registrierte Leser meist unnötig und nicht ins Designkonzept passend. Mit einem kleinen aber feinen Eintrag in der functions.php des aktivierten Designs kann man dem aber Abhilfe schaffen – alternativ kann man das natürlich auch via Plugin aktivieren:

1
2
3

if(!current_user_can('edit_posts')) {
add_filter( 'show_admin_bar', '__return_false' );
}

Mit diesen Zweizeiler kann man auf einfachste Weise die Adminbar für gewisse Usergruppen deaktivieren. In diesem Beispiel gilt das nur für registrierte Benutzer, da diese die einzige Gruppe ist, die keine Artikel editieren kann.

edit_posts

Neues WordPress Plugin: Affiliando Vergleichsrechner 1.0

Ing. Karl Kowald — Mon, 17 Jan 2011 19:55:47 +0000

Seit heute ist unser neues WordPress-Plugin, der Affiliando Vergleichsrechner für WP auch direkt unter wordpress.org verfügbar. Damit können auch Updates der Software nun für einfachen Klick übernommen werden.

Wozu das Plugin?

Das Plugin integriert die PHP-Include-Version des Affiliando Vergleichsrechners mittels Shortcode auf jede beliebige WordPress-Seite. Zusätzlich cached das Plugin alle Dateien und Bilder lokal, sodass sowohl die Besucher als auch Suchmaschinen keine Daten mehr von einer fremden Domain nachladen müssen (Ladezeitverbesserung und SEO-Verbesserung).

Das Plugin ist Gratis?

Natürlich stellen wir das Plugin kostenlos zur Verfügung. Der Vergleich selbst stammt weiterhin aus der Feder des Affiliandobetreibers Zieltraffic, nur die spezielle WordPress-Integration ist von uns hinzugefügt worden. Updates von Zieltraffic für den Rechner werden wir natürlich zeitnah integrieren damit das Plugin jederzeit ready2use ist. Wenn euch das Plugin gefällt freuen wir uns natürlich über Danksagungen und Verlinkungen zu uns

Der eigene Javascript Event Handler

Daniel Leeb — Mon, 17 Jan 2011 09:09:15 +0000

Besonders bei umfangreicheren Javascript-Umsetzungen zahlt es sich aus, eine kleine Bibliothek aus Hilfs-Funktionen und -Objekten zu entwickeln. Vorausgesetzt man möchte auf die Integration größerer Bibliotheken verzichten, muss man sich selbst um gewisse Grundfunktionen kümmern. Zu diesen zähle ich auch einen Event Handler.
Im folgenden möchte ich eine einfache Möglichkeit zeigen, einen solchen vielseitig einsetzbaren Event Handler umzusetzen.

Vorab einige Anforderungen an einen Event Handler:
- Jedes Objekt soll als Event Handler agieren können: Erweiterung (bzw. “Vererbung”) um Event Handler Funktionalität.
- Beliebige Events.
- Mehrere Listener bzw. Callbacks sollen an ein Event gebunden werden können.
- Benutzerdefinierte Daten beim Auslösen eines Events an die Listener übergeben.
- Übergabe von Rückgabewerten der Listener an das Event.

Implementierung

Zunächst ist es sinnvoll, aber natürlich nicht notwendig, ein Objekt zu erzeugen, welches als eine Art Namespace agiert, zum Beispiel:

1	window.li = window.li \|\| {};

Ein leeres Objekt namens EventListener dient zum Identifizieren der Listener. Siehe dazu addListener() und deleteListener() weiter unten.

1	li.EventListener = function() {}

Nun kommt das eigentliche Basis-Objekt, welches später von Objekten “geerbt” wird.

1	li.BaseObject = function() {}

Wir verwenden das Javascript “prototype” Objekt, wodurch Instanzen von BaseObject um Methoden von dessen prototype erweitert werden.
Die erste Methode, defaults(), ist eine kleine Hilfsfunktion, um etwas komfortabler Default-Werte von Funktionsparametern setzen zu können.

1
2
3
4
5
6

li.BaseObject.prototype = {
defaults: function(parameter, defaultValue, type) {
if (typeof type === 'undefined')
return (typeof parameter !== 'undefined') ? parameter : defaultValue;
return (typeof parameter === type) ? parameter : defaultValue;
},

Nun kommen die eigentlichen Methoden des Event Handlers:
Mit der Methode addListener() kann einem Event mittels Name eine Callback-Funktion zugewiesen werden:

1
2
3
4
5
6
7
8
9
10

addListener: function(eventName, listenerCallback) {
this.__listeners = this.defaults(this.__listeners, {});
var listenerObj = new li.EventListener();
this.__listeners[eventName] = this.defaults(this.__listeners[eventName], []);
this.__listeners[eventName].push({
listener: listenerObj,
callback: listenerCallback
});
return listenerObj;
},

Um Events auszulösen und somit alle Listeners aufzurufen muss einfach die Methode trigger() mit dem entsprechenden Eventnamen aufgerufen werden. Optional können hier beliebige Daten an die Listener übergeben werden. Die Rückgabewerte der Callback-Funktionen der Listener werden als Array zurückgegeben.

1
2
3
4
5
6
7
8
9
10

trigger: function(eventName, data) {
this.__listeners = this.defaults(this.__listeners, {});
data = this.defaults(data, {});
if (typeof this.__listeners[eventName] === 'undefined') return;
var eventListeners = this.__listeners[eventName], retArr = [];
for (var index in eventListeners) {
retArr.push(eventListeners[index].callback.call(this, data));
}
return retArr;
},

Die folgenden Methoden dienen nun noch zum Entfernen von Listener: entweder alle Listener, alle Listener eines Events oder ein bestimmter Listener (addListener() gibt ein EventListener Objekt zurück, welches zum Identifizieren von Listeners dient und der deleteListener() Methode übergeben werden kann).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

deleteAllListeners: function() {
this.__listeners = {};
},
deleteListeners: function(eventName) {
this.__listeners = this.defaults(this.__listeners, {});
if (typeof this.__listeners[eventName] === 'undefined') return;
delete this.__listeners[eventName];
},
deleteListener: function(listenerObj) {
this.__listeners = this.defaults(this.__listeners, {});
for (var index in this.__listeners) {
for (var i in this.__listeners[index]) {
if (this.__listeners[index][i].listener === listenerObj) {
this.__listeners[index].splice(i, 1);
return true;
}
}
}
return false;
}
}

Um ein Objekt, im folgenden li.MyObject, um diesen Event Handler zu erweitern kann etwa die extend()-Methode von jQuery verwendet werden:

1	jQuery.extend(li.MyObject.prototype, li.BaseObject.prototype);

Beispiel

Mit diesen wenigen Zeilen Code erhält man einen simplen aber vielseitig einsetzbaren Event Handler. Zum Abschluss ein kurzer Beispielcode bei dem das Objekt li.MyObject wie oben beschrieben um li.BaseObject erweitert wurde und somit als Event Handler agieren kann:

1
2
3
4
5
6
7
8

Event Handler – Sourcecode

Rundungsfehler in Magento beheben

Peter Hasitschka — Fri, 26 Nov 2010 12:37:47 +0000

In Magento (1.4 oder älter), das als mächtiges Online-Shop-System bekannt ist, kann in verschiedenen Fällen ein unangenehmer Rundungsfehler aufscheinen, der sich aber leicht beheben lässt:

Anmerkung: Um den Core unberührt zu lassen, empfiehlt es sich, die geänderten Files in der gleichen Struktur in Ordner Local abzuspeichern.

Die beiden Änderungen bewirken eine genauere Rundung von Zahlen. Bei der bisherigen Rundung kann es bei der Aufsummierung von Zahlen zu einem Ungenauigkeitsfehler kommen, da sich die Rundung auf zwei Nachkommastellen beschränkt.
Mit den Änderungen rundet Magento auf vier Stellen genau – Dadurch werden obige Fehler vermieden.

Folgende Änderungen sind durchzuführen:

Erstellen Sie Duplikat der Datei:
/app/code/core/Mage/Core/Model/Store.php
und fügen Sie das Duplikat in folgendem Pfad ein:
/app/code/local/Mage/Core/Model/Store.php

Die Änderung betrifft die Zeile 715 der Datei:

public function roundPrice($price) { return round($price, 4); }

Erstellen Sie Duplikat der Datei:
/app/code/core/Mage/Adminhtml/Block/Catalog/Product/Helper/Form/Price.php
und fügen Sie das Duplikat in folgendem Pfad ein:
/app/code/local/Mage/Adminhtml/Block/Catalog/Product/Helper/Form/Price.php

Die Änderungen beginnen bei Zeile: 78

public function getEscapedValue($index=null) { $value = $this->getValue(); if (!is_numeric($value)) { return null; } return number_format($value, 4, null, ''); }

Beachten Sie, dass Sie niemals ein File bearbeiten sollten dass direkt in der Core-Struktur von Magento liegt. Die Core Files werden bei jedem Update von Magento überschrieben, sodass Änderungen nicht persistent sind.

Weiters sollten Sie speziell bei Systemen wie Magentocommerce eine genaue Dokumentation über geänderte / angelegte Files führen, um den Überblick zu behalten. Bei Magento – Versionssprüngen wie etwa von 1.3 auf 1.4 sind derartige Dokumentationen ein relevanter Zeitfaktor.

Integration von Doctrine in eine modulbasierte Zend Anwendung

Daniel Leeb — Fri, 22 Oct 2010 10:49:47 +0000

Eines der erste Dinge, die mir als Einsteiger in das Zend Framework auffielen, war die Vernachlässigung des M in Zends MVC Implementation. Views und Controller, wenngleich sie erst nach einer kleinen Einarbeitungszeit wirklich verständlich werden, bieten genau das, was eine komplexe Webanwendung benötigt. Jedoch fehlt eine wirklich umfangreiche Implementation von Models in Zend. Auch wenn diese im Moment in Arbeit ist, haben wir uns deshalb für Doctrine entschieden, welches genau diese Lücke für uns füllen soll. Es ist jedoch eine Herausforderung für sich, Doctrine in seine Zend Anwendung zu integrieren, zumal wir eine modulbasierte Struktur zugrunde liegen haben.

Doctrine und Module

Die folgende Anleitung soll eine Möglichkeit zeigen, wie sich Doctrine und eine modulbasierte Zend Applikation verbinden lassen. Da Tutorials meist nur die simple Integration von Doctrine und Zend in einer “einfachen” Anwendung ohne Module zeigen, möchte ich hier besonders auf Module eingehen. Natürlich könnte man auch, unabhängig von Modulen, die Models einfach in einen gemeinsamen Ordner unterbringen. Dadurch geht jedoch ein zentraler Aspekt des modularen Aufbaus verloren und wir haben uns deshalb um eine andere Lösung bemüht. Des Weiteren muss angemerkt werden, dass in unserem Fall die Models eines Modules auch Beziehungen zu Models anderer Module haben können. Eine unabhängige Behandlung ist daher nicht möglich. Wäre dies nicht der Fall, könnte man auch einfach jedes Modul als eigenständige Anwendung betrachten und die oben erwähnten Tutorials zu Rate ziehen.
Im Zuge der Anleitung werde ich auch gleich auf einige Vorzüge von Doctrine eingehen, empfehle jedoch die Doctrine-Einführung durchzuarbeiten.

Doctrine’s YAML Schema

Um seine Models von Doctrine generieren zu lassen, bietet sich das Erstellen einer YAML-Schema-Datei an. Diese kann entweder per Hand geschrieben oder aus einer existierenden Datenbank generiert werden:

1 2	Doctrine_Manager::connection("mysql://user:pw@localhost/dbname"); Doctrine::generateYamlFromDb('schema.yml');

Anschließend sollte das Schema jedoch nochmals überarbeitet werden, um eventuelle Anpassungen wie Klassennamen, Beziehungen, etc. durchzuführen. Es empfiehlt sich das Erstellen eines PHP Scripts für alle Doctrine Operationen. Auf die Erstellung eines solchen Skripts möchte ich jedoch hier nicht weiter eingehen, da dies bereits in der Doctrine Einführung und in diversen Tutorials ausführlich behandelt wird.

Ist das YAML-Schema erst einmal ausgearbeitet, lässt sich später auch die Datenbank daraus generieren. Änderungen im Datenbankdesign können also fortan direkt im YAML-Schema erfolgen, unabhängig von dem verwendeten Datenbanksystem.
Aus der YAML-Datei lässt sich jedoch auch das Doctrine Model generieren, welches wir in unserer Webanwendung verwenden wollen. Hierfür müssen wir einige Einstellungen vornehmen, die Doctrine bei der Generierung berücksichtigen soll:

1
2
3
4
5
6
7
8

$options = array(
'suffix' => '.php',
'baseClassPrefix' => 'Orm_',
'pearStyle' => true,
'baseClassesDirectory' => '',
'generateTableClasses' => true
);
Doctrine::generateModelsFromYaml('schema.yml', 'models', $options);

Der Eintrag 'baseClassPrefix' => 'Orm_' erweitert den Klassennamen unserer Model-Basisklassen und erzeugt durch 'pearStyle' => true die Model-Datei im Ordner ‘Orm’ ohne jedoch Orm_ im Dateinamen – eben im PEAR-Namensstil. Durch 'baseClassesDirectory' => '' verzichten wir auf das ‘generated’ Verzeichnis und mittels 'generateTableClasses' werden zusätzlich Klassen, abgeleitet von Doctrine_Table, erzeugt.
Nehmen wir an, in unserer Datenbank bzw. im YAML-Schema befinden sich die Tabellen “user” und “appointment”. Der obige Code würde dann folgendes Erzeugen:

models\Orm\Appointment.php class Orm_Appointment extends Doctrine_Record
models\Orm\User.php class Orm_User extends Doctrine_Record
models\Appointment.php class Appointment extends Orm_Appointment
models\AppointmentTable.php class AppointmentTable extends Doctrine_Table
models\User.php class User extends Orm_User
models\UserTable.php class UserTable extends Doctrine_Table

Unsere Webanwendung ist in folgender (etwas vereinfachter) Verzeichnisstruktur aufgebaut, wobei die eben aufgelisteten Dateien im Ordner /doctrine generiert werden:

Nun kommt ein etwas unschöner Vorgang, denn wir müssen die eben generierten Dateien in die Model-Ordner unserer Module verschieben. Um beim obigen Beispiel zu bleiben, verschieben wir User.php und UserTable.php in das ‘Core’ Modul, also etwa modules/core/models/. Appointment.php und AppointmentTable.php verschieben wir nach modules/calendar/models/. Und den Orm Ordner können wir als Ganzes in unserem Application-Verzeichnis platzieren (wichtig ist nur, dass der Zend Autoloader die Dateien findet, mehr dazu gleich).

Autoloader

Da wir nun erfolgreich unsere Models generiert haben, können wir unserer Webapplikation mitteilen, wo diese zu finden sind. Folgende Methode kann zur Initialisierung von Doctrine in der Bootstrap Klasse (application/bootstrap.php) platziert werden:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public function _initDoctrine()
{
$this->getApplication()->getAutoloader()
->registerNamespace('Doctrine')
->registerNamespace('Orm')
->pushAutoloader(array('Doctrine', 'autoload'))
->pushAutoloader(array('Doctrine', 'modelsAutoload'));

$manager = Doctrine_Manager::getInstance();
$manager->setAttribute(Doctrine::ATTR_MODEL_LOADING, Doctrine::MODEL_LOADING_CONSERVATIVE)
$manager->setAttribute(Doctrine::ATTR_AUTOLOAD_TABLE_CLASSES, true)
$manager->connection("mysql://user:pw@localhost/dbname", "conn");

Doctrine::loadModels(array( APPLICATION_PATH . '/modules/core/models',
APPLICATION_PATH . '/modules/calendar/models'));
}

registerNamespace('Doctrine') sorgt dafür, dass die Doctrine-Klasse in Doctrine.php geladen werden kann, vorausgesetzt der Pfad zur Doctrine-Library wurde als Include-Pfad, zum Beispiel in der index.php, gesetzt. Sollte Doctrine.php direkt inkludiert worden sein, kann man auf diese Zeile auch verzichten. registerNamespace('Orm') ermöglicht das Autoloading der zuvor generierten Basisklassen Orm_User und Orm_Appointment. Der Ordner Orm muss dabei in einem inkludierten Pfad liegen, sodass er dem Zend Autoloader bekannt ist. Mittels den beiden pushAutoloader() Aufrufen registrieren wir die autoload() und modelsAutoload() Callbacks von Doctrine. Erstere ist für die Doctrine-Klassen zuständig, zweitere für unsere Models. Nun konfigurieren wir den Doctrine_Manager, sodass dieser unsere Models bei Bedarf (Conservative) und unsere Tables (UserTable, AppointmentTable) lädt. Mittels Doctrine::loadModels() teilen wir Doctrine die Pfade mit, in denen sich die Model-Dateien befinden. In der Praxis kann der Aufruf natürlich auch entweder in den speziellen Modul-Bootstrap-Klassen erfolgen, oder eine Methode verwendet werden, welche alle Model-Pfade der Module zurückgibt.
Nun können wir die erstellten Model Klassen beliebig um eigene Methoden erweitern und in unseren Controller_Actions und Views verwenden:

1
2
3
4
5
6
7
8
9

// class User extends Doctrine_Record
$user = new User();
$user->username = "Admin";
$user->myMethod(); // eigene Methode in User Klasse
$user->save();

// UserTable
$usertable = Doctrine::getTable("User");
$usertable->myTableMethod(); // eigene Methode in UserTable Klasse

Falls sich das Schema ändert, sollte in den meisten Fällen ein Updaten des Orm Ordners ausreichen, dessen Dateien wir ohnehin nicht verändern wollen.

Schlusswort

Ob diese Variante, Doctrine in die eigene Zend Anwendung zu integrieren geeignet ist, hängt stark von den Anforderungen ab. Wir haben uns für diese Methode entschlossen, da wir zwar Abhängigkeiten zwischen den Models der Module haben, jedoch trotzdem eine prinzipielle Trennung vornehmen wollten. Jeder Teilbereich unseres Datenbankschemas wird in einer eigenen YAML-Schema-Datei definiert (also etwa core.yml und calendar.yml). Man könnte auch auf Packages (siehe Doctrine’s YAML Beschreibung) zurückgreifen, jedoch ändert sich dadurch die Namensgebung und eine weitere abstrakte Klasse wird für die Models erstellt. Der Aufwand die generierten Model-Dateien in die entsprechenden Ordner zu verschieben hält sich jedoch in Grenzen, weswegen wir uns für diese Variante entschieden haben.

Verwendete Versionen:
Zend Framework 1.10.8
Doctrine 1.2

3 Schritte zur Keyword SERP-Position mit Google Analytics

Ing. Karl Kowald — Thu, 30 Sep 2010 11:51:17 +0000

Die Suchbegriffe mit welchen Besucher auf unsere Seite gelangen kann man problemlos mit Google Analytics auswerten. Will man jedoch auch die eigene Position auf der Suchmaschinenergebnisseite (SERP) wissen, welche zum Klick des Besuchers geführt hat, muss man schon selbst nach dem Begriff googlen oder via Google WebmasterTools danach suchen. Leider gibt bei beiden Methoden Abweichungen die kein genaues Resultat ergeben, doch mit einer kleinen Änderung am Google Analytics Code kann dem abhilfe geschaffen werden.

Schritt 1: Referer Auswerten

Zuerst liest man einfach beim Seitenaufruf den Referer aus:

1
2
3
4

preg_match("/cd\=(\d+)/",$_SERVER['HTTP_REFERER'], $matches);
$str = $matches[0];
preg_match("/(\d+)/",$str,$matches);
$rank = $matches[0] ?>

Dadurch erhalten wir die Position auf der Google Suchergebnisseite von welcher der aktuelle Besucher kommt. Sollte die eigene Seite eventuell mit der $_GET Variable cd arbeiten wäre es Ratsam noch einen allgemeinen Filter über die Refererdomain laufen zu lassen um falsche Werte auszuschließen.

Schritt 2: Wert an Google Analytics übergeben

Hierfür nutzen wir die Möglichkeit via Javascript eigens definierte Variablen ans Google Analytics zu übergeben. Inmitten des Google-Codes fügen wir nun die Position mit einem eigenes kreierten Variablennamen “Google_Platz” ein, allerdings nur dann wenn auch tatsächlich ein Wert dafür vorhanden ist:

1
2
3
4

if ($rank != '' ) {
?> _gaq.push(['_setCustomVar',1,'Google_Platz','$rank; ?>',2]);

} ?>

Als Ergebnis sollte dann soetwas im Quellcode stehen:

1
2
3
4
5
6
7
8
9

var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-xxxxxxxx-x']);
_gaq.push(['_setCustomVar',1,'Google_Platz','3',2]);
_gaq.push(['_trackPageview']);
(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();

In diesem Beispiel kam der Klick von der 3. Position.

Schritt 3: Auswerten nach Platzierung

Die Positionszahl die das Script übergibt

Nach einigen Tagen sollte man die ersten Ergebnisse bereits sehen und man kann mit der Auswertung beginnen. Leider werden eigene Variablen nicht standardmäßig von Google Analytics ausgewertet, weshalb man sich in die Benutzerdefierten Berichte wagen muss. Jedoch lohnt es sich, da man ab diesem Zeitpunkt wichtige Kennzahlen wie die Bounce-Rate oder Umsatzziele auch nach dem Ranking auswerten. Auch durchschnittliche Platzierungen von wichtigen Keywords kann man über einen langen Zeithorizont auswerten, wobei natürlich nur die Platzierungen bewertet werden, welche auch tatsächlich zu einem Besuch auf der Homepage geführt haben.

WordPress Plugin mit dieser Funktion

Wir arbeiten bereits seit einigen Tagen an einer kleinen Funktions- & Effektsammlung für WordPress welches wir an dieser Stelle veröffentlichen möchten. Diese Auswertungsoption wird darin von ebenfalls integriert werden. Für alle die somit noch einige Tage darauf warten können ein Hinweis damit Sie es nicht selbst in ihrem Code einfügen müssen.

Update: Auswertung nur mit Javascript

Alternativ kann man auch eine reine Javascriptauswertung machen, dadurch erspart man sich den Eingriff in PHP-Files.

1
2
3
4
5

if (document.referrer.search(/[\?|&]cd=/) != -1
&& document.referrer.search(/google\./) != -1) {
var rank=document.referrer.match(/[&|\?]cd=([\d]+)/);
_gaq.push(['_setCustomVar',1,'Google_Platz',rank[1],2]);
}

Rechteverwaltung – Alle Benutzer sind gleich, manche sind gleicher

Daniel Leeb — Mon, 06 Sep 2010 10:32:17 +0000

Jede Seite mit mehreren Benutzern benötigt eine mehr oder weniger umfangreiche Rechteverwaltung. Ein simples Blog unterscheidet bereits zwischen Autoren, registrierten Benutzern und einfachen Gästen. ACL – Access Control List – ist eine Technik mit der sich ein flexibles Rechtesystem aufbauen lässt, indem festgelegt wird, welcher Benutzer welche Aktionen ausführen darf. Die hier vorgestellte Variante ist nur eine von vielen Möglichkeiten ein ACL-System aufzubauen.

ACL Aufbau

Das System besteht aus Benutzern, Rollen, Regeln sowie speziellen Bedingungen (Assertions). Einem Benutzer sollen mehrere Rollen aber auch einzelne Regeln zugewiesen werden können. Rollen bestehen aus einer Sammlung von Regeln. Eine Regel bestimmt, welche Aktion erlaubt oder nicht erlaubt ist oder ob eine bestimmte Bedingung erfüllt werden muss. Eine Bedingung kann in diesem Zusammenhang etwa die Einschränkung auf eine bestimmte IP oder ein eingeschränkter Zeitraum sein.

ACL in der Datenbank

Folgende Tabellen werden in der Datenbank benötigt:

user
role
- name: z.B. “Admin”, “Guest”, …
- parent_id: Falls die Rolle die Regeln einer anderen Rolle erben soll.
- order: Werden einem Benutzer mehrere Rollen zugewiesen, bestimmt diese Rangordnung die Reihenfolge und damit Priorität der jeweiligen Rolle.
rule
- resource: Entspricht einem Controller; z.B.: „site“.
- pivilege: Entspricht einer Action eines Controllers; z.B.: „index“.
- assert_id: Falls die Regeln an eine Bedingung gebunden ist.
- permission: Wird die jeweilige Aktion erlaubt oder verweigert; z.B.: „Allow“/“Deny“.
Tabellen zur Zuweisung von Regeln: user_roles, user_rules und role_rules.
assert
- Classname: Der Name der Klasse, in der die Bedingung geprüft wird; z.B.: „IPAssertion“

ACL und das Zend Framework

Das Zend PHP Framework bietet mit der Zend_Acl Klasse bereits eine Implementierung eines ACL-Systems. Im Folgenden möchte ich die wichtigsten Funktionen vorstellen:

// Instanz von Zend_Acl mit welcher die Rechteverwaltung realisiert wird.

$acl = new Zend_Acl();
// Hinzufügen einer Rolle ‚guest‘.

$acl->addRole(new Zend_Acl_Role(‘guest’));
// Der Benutzer (hier repräsentiert als Rolle) ‚myUser‘ erbt die Rolle ‚guest‘.

//  Auf dieselbe Weise können auch Rollen Eigenschaften anderer Rollen erben.

$acl->addRole(new Zend_Acl_Role(‘myUser’), ‘guest’);
// Hinzufügen einer Ressource (Controller)

$acl->add(new Zend_Acl_Resource(‘site’));
// Deny All

$acl->deny(null);

// Setzen der Zugriffsrechte von Rollen auf Ressourcen/Privilegien mit Bedingung:

//  *Assertion sind Klassen, welche Zend_Acl_Assert_Interface implementieren.

$acl->allow(‘guest’, ‘site’, ‘index’);

$acl->deny(‘guest’, ‘site’, null, IPAssertion);

$acl->allow(‘myUser’, ‘site’, ‘index’, TimeAssertion);

$acl->allow(‘myUser’, ‘site’);
// Abfrage eines Zugriffsrechts

$acl->isAllowed(‘myUser’, ‘site’, ‘index’);

ACL im Einsatz

Um das oben beschriebene System zu implementieren muss also zunächst eine Zend_Acl Instanz erstellt werden. Dieser werden alle Rollen aus der Datenbank übergeben. Der Benutzer wird ebenfalls angelegt und mit seinen zugewiesenen Rollen übergeben (als zusätzlicher Parameter von addRole(), sodass deren Eigenschaften dem Benutzer vererbt werden). Anschließend werden die Ressourcen erstellt und übergeben. Mittels deny(null) können alle Zugriffe verhindert werden. Nun folgen die Regel-Zuweisungen via allow() und deny() Aufrufe, wodurch den Rollen die jeweiligen Ressourcen, Privilegien und Bedingungen zugewiesen werden. Beim Aufruf eines Controllers und dessen Action kann nun das Zugriffsrecht mittels der Methode isAllowed() überprüft werden.