Archiv des Autors: Sascha Presnac

php Codesniffer und CI , Zeilenlänge und Windows Zeilenumbruch setzen

Windows, Continous Integration, 16:10 Bildschirme und phpcs.

Dies alles passt im Standard nicht zusammen, zumindest nicht mit unseren internen Regeln, daher hier die notwendigen Anpassungen, um zumindest die Zeilenlänge auf ein erträgliches Maß von 120 zu 160 zu bekommen (nicht mit dem Blutdruck verwechseln) und den Codesniffer an Windows-like Zeilenumbrüche von \r\n zu gewöhnen.

Meine phpcs.xml sieht dann in etwa so aus:

<?xml version="1.0"?>
<ruleset name="PHPCS Rules">
 <description>Using Zend Rules</description>
 <rule ref="Zend">
  <exclude name="Generic.WhiteSpace.DisallowTabIndent" />
  <exclude name="Generic.Functions.OpeningFunctionBraceBsdAllman" />
  <exclude name="Generic.PHP.DisallowShortOpenTag" />
  <exclude name="Generic.Files.LineEndings" />
 </rule>
 <rule ref="Generic.Functions.OpeningFunctionBraceKernighanRitchie" />
 <rule ref="Generic.Files.LineLength">
  <properties>
   <property name="lineLimit" value="120"/>
   <property name="absoluteLineLimit" value="160"/>
  </properties>
 </rule>
</ruleset>

PHP XML Daten in einer Session speichern

Beim Versuch, SimpleXML Objekte in eine Session zu speichern solltet ihr folgendes Wissen.

Ein trivialer Ansatz wie

if (!isset($_SESSION['xml'])) {
  $xml = simplexml_load_string($myxmlstring);
  $_SESSION['xml'] = $xml->someNode;
}
var_dump($_SESSION['xml']);

wird fehlschlagen. Im ersten Moment sind die Daten in der Session offenbar gespeichert, beim nächsten Aufruf der Seite werden allerdings alle values verschwunden sein, d.h. der xml-Key der $_SESSION ist zwar vorhanden (weshalb auch das Neuladen übersprungen wird), aber $_SESSION[‚xml‘] = null.

Ihr umgeht das Problem, in dem ihr jeden Wert, den ihr speichern wollt, vorher explizit Typkastet und dann erst in die Session einbringt:

if (!isset($_SESSION['xml'])) {
  $xml = simplexml_load_string($myxmlstring);
  $_SESSION['xml'] = array(
    'someNode' => (int)$xml->someNode,
    'otherNode' => (string)$xml->other->node[0]->attribName,
}
var_dump($_SESSION['xml']);

Nun erhaltet ihr die Werte bei jedem Aufruf und könnt die eingelesenen Werte in der Session transportieren.

Zend Framework im Zend Server CE updaten

Der aktuelle ZendServer 5.6 kommt mit vorinstalliertem ZendFramework 1.11.11.
Dies ist aber veraltet, eine automatische Aktualisierung gibt es leider nicht; allerdings ist der Update-Vorgang nicht so schwer.

Von der Zend Framework Download Seite holt ihr euch das aktuelle Zend Framework (bei mir 1.11.13 minimal) und entpackt dieses irgendwohin. Von diesen entpackten Dateien braucht ihr nun das Verzeichnis „Zend„, welches ihr in „/library“ findet.

Das kopiert ihr euch in den Pfad „ZendServer\share\ZendFramework\library“ eures ZendServers, bei mir ist das „C:\zend\ZendServer\share\ZendFramework\library“ (yep, immer noch Windows).

Der Server benötigt keinen Neustart und ihr könnt nun direkt die neue Version benutzen.
Viel Erfolg!

Vorsicht bei mysql_connect und Vielfachverbindungen

Eine der automatischen „Goodies“ bei mysql_connect (wen man es denn schon nutzen muss, warum auch immer), ist, dass, wenn man mysql_connect mit den gleichen Informationen bestückt, diese Funktion die gleiche Verbindungsid zurückgibt wie beim ersten mal … es wird also keine zweite Verbindung aufgebaut.

Das Problem ist nun leider, dass der, der die zweite Verbindung öffnen möchte, diese Informationen _ganz genau_ braucht, denn sonst erhält man unter Umständen trotzdem eine zweite Verbindung, obwohl man die vermeindlich gleichen, aber nicht selben Parameter benutzt.

Beispielcode:

$dbserver1 = '127.0.0.1';
$dbserver2 = 'localhost';

$dbuser1 = 'root';
$dbuser2 = 'Root';
$dbpass = '';

$db1 = mysql_connect($dbserver1, $dbuser1, $dbpass);
$db2 = mysql_connect($dbserver2, $dbuser2, $dbpass);
$db3 = mysql_connect($dbserver1, $dbuser2, $dbpass);
$db4 = mysql_connect($dbserver2, $dbuser1, $dbpass);
$db5 = mysql_connect($dbserver1, $dbuser1, $dbpass);

var_dump($db1, $db2, $db3, $db4, $db5);

Ausgabe:

resource(7) of type (mysql link)
resource(9) of type (mysql link)
resource(11) of type (mysql link)
resource(13) of type (mysql link)
resource(7) of type (mysql link)

Hier zeigt sich, dass insg. 4 verschiedene Connection-Ids zurück gegeben wurden, $db5 ist zur Kontrolle und zeigt, dass nur die exakt selben Parameter zum gewünschten Ergebnis kommen, nämlich die selbe ID zu benutzen, die schon bei $db1 erzeugt wurde.
Im Realfall würde dies nun 4 Prozesse bedeuten, von denen 3 überflüssig sind und nur den Server belasten … pro Aufruf im schlimmsten Fall.

webEdition: Bestehende Datenbankverbindung nutzen

In webEdition kann man viel machen, es ermöglicht einem wirklich sehr große Freiheit. Der große Vorteil diese Freiheit hat aber auch einen großen Nachteil: Man muss sich im System auskennen, um damit wirklich gute Seiten bauen zu können; ganz schnell kann man auch sehr langsame Seiten erstellen, die dann nicht nur den Besucher, sondern vor allem den Kunden verärgern.

Aus einem aktuellen Projekt stelle ich eine wirklich böse Fehlerquelle vor: Die mehrfache Datenbank Verbindung. Im Template ist es recht einfach, eine neue DB-Verbindung mit der bekannten (und veralteten) Funktion

$db = mysql_connect(...);

zu erstellen. Aber warum sollte man das machen? Wohl nur aus Unwissenheit, dass webEdition bereits eine Datenbankverbindung eröffnet hat und diese auch dem Entwickler bereitstellt.

Also, liebe webEdition-Entwickler, die bestehende, persistente und performantere DB-Verbindung könnt ihr recht einfach für eigene Zwecke benutzen:

$db = $GLOBALS['DB_WE'];
$stmt = $db->query('SELECT * FROM tblUser');
while ($data = mysql_fetch_assoc($stmt)) {
Zend_Debug::dump($data);
}

Muss man dann doch mal eine zweite Verbindung aufbauen – was im Einzelfall manchmal wirklich sein muss – dann ist dem Entwickler ja meist bewusst, was er da macht und ich hoffe, er benutzt dann dafür nicht die alten, langsamen MySQL-Funktionen, sondern entweder die MySQLi-Pendants oder eine PDO-Schnittstelle.

Leider stellt webEdition keine Instanz von Zend_Db bereit, so dass zwar die Generierung des Querys OOP stattfindet, aber es dannach mit den bekannten mysql-Funktinen weitergeht. Das ist ein recht großer Nachteil, da es die Möglichkeit nimmt, auf einem modernen (aktuellen) Niveau zu arbeiten und ich hoffe, dass dieses Manko bald durch ein aktuelles Release behoben wird.

include oder require?

Was soll der PHP-Entwickler benutzen, include oder require bzw. include_once oder require_once?
Und wo liegt da eigentlich der Unterschied?

Die Frage kommt oft, deshalb an dieser Stelle mal ganz klipp und klar und kurz:

require bzw. require_once benutzen, denn: Sowohl include wie auch require binden eine Datei ein, aber, sollte ein Fehler in der includierten Dateie sein, so bricht require mit einem E_COMPILE_ERROR ab, während include fröhlich mit einer WARNING weitermacht.

Im Sinne der Vermeidung von code-smells fällt eure Wahl also auf require bzw. require_once.

Schneller in PHP und MySQL mit JOIN

Mittels einfacher Kentnisse seiner Datenbank kann der Entwickler auch aus Legacy-Anwendungen sehr viel mehr Geschwindigkeit herausholen, als er vielleicht weiß.
Der Grund ist simpel: Meist bleibt der Code gleich, aber die Server Software wird aktualisiert. Während die Erstellung noch im guten alten PHP4 + MySQL4 von Statten ging, rennt der Code heute mit PHP5 + MySQL5 zwar immer noch, könnte aber dank kleiner Kniffe sehr viel schneller sein.
Ich möchte euch einen Weg dazu zeigen, die JOINs in MySQL. Es gibt sicherlich noch mehr Möglichkeiten, aber das sind auch andere Themen. Fangen wir heute mal mit alten Querys an.

Zunächst versuchen wir eine Stelle zu finden, an der wir ansetzen. Bei den meisten Legacy Codes wurde mit solch einem oder einem ähnlichen Konstrukt die Daten für „Zeige neue Blogbeiträge mit Namen des Autors“ abgerufen, wobei „autor“ und „blog“ zwei verschiedene Tabellen sind.

$_res = mysql_query("SELECT * FROM blog ORDER BY datum DESC");
while ($row = mysql_fetch_array($_res)) {

  $_resAutor = mysql_query("SELECT * FROM autor WHERE autorid = ".$row['autorid']);
  $autor = mysql_fetch_array($_resAutor);
  // Stelle Blogbeitrag mit Autor dar
}

Das ist nicht nur in der Hinsicht des Datenabrufes schlechter Code und vor lauter „code-smells“ könnte einem glatt schlecht werden. Trotzdem gibt es sowas „da draussen“ und dummerweise funktioniert das leider immer noch.

Was kann man verbessern? Zum einen fällt auf, dass es zwei Querys sind. Das muss nicht nur nicht sein, dass ist auch noch ganz schlecht, denn jede Verbindung zur Datenbank braucht Zeit und die sollten wir uns sparen. Argumente wie „mysqli / PDO benutzen“ lasse ich ganz bewusst aussen vor, es soll um Prinzip gehen (sicher wäre die Verwendung eines PDO oder ORM wie Doctrine besser, ganz klar).

Sparen wir uns also den zusätzlichen Query:

$_res = mysql_query("SELECT b.*, a.* FROM blog b, autor a WHERE b.autorid = a.autorid ORDER BY b.datum DESC");
while ($row = mysql_fetch_array($_res)) {
  // Stelle Blogbeitrag mit Autor dar
}

Schon viel besser, aber noch nicht gut genug. Was passiert, wenn ein Blogbeitrag existiert, aber der Autor nicht? Bei so einer Legacy-Anwendung fast schon der Normalfall. Der ganze Beitrag fehlt. Doof, also brauchen wir eine Mechanik, die trotz fehlendem Autor den Blog Beitrag noch anzeigt.
Ganz kurz: Das machen JOINs – und ehe ich nun von vielen gesteinigt werde: JOINs machen noch viel mehr, aber das würde hier den Rahmen sprengen und außerdem möchte ich dazu noch mehr schreiben.

Das ganze nun mit einem LEFT JOIN:

$_res = mysql_query("SELECT b.*, a.* FROM blog b LEFT JOIN autor a ON (b.autorid = a.autorid) ORDER BY b.datum DESC");
while ($row = mysql_fetch_array($_res)) {
  // Stelle Blogbeitrag mit Autor dar
}

Es ändert sich nicht viel, aber nun erscheinen auch alle Blogbeiträge ohne Autor und als kleines Extra arbeitet der letzte Query auch noch etwas schneller als der zweite; super für Legacy-Code, der schon ähnlich wie in Beispiel Zwei aufgebaut ist, denn dort muss man nicht – oder nur wenig – an den PHP Code ran und kann sich auf die reine SQL-Optimierung konzentrieren.

Diese Art der Optimierung alter Legacy-Anwendungen macht relativ wenig Arbeit und bringt dafür recht viel. Vor allem im Bereich von SQL-Code, wo Beispiel eins mehrfach vorkommt (Grundquery, dannach werden viele Querys gestartet die Detaildaten zum Grundquery abrufen, dannach wird gerechnet und wieder neue Querys abgerufen usw.) und damit die Anwendung an dieser Stelle nur sehr langsam ist, kann ein Umstieg auf JOINs und u.a. Verlagerung von Arbeit von PHP in den Query sehr viel Geschwindigkeit herausholen.

Allerdings – und das sollte ganz klar sein – kann dies keine schlechte Architektur ersetzen. Legacy Code kommt irgendwann an den Punkt, an dem ein Optimieren keinen Sinn mehr macht und man sich lieber auf die Neukonzeption konzentrieren sollte. Als Hilfsmittel, um z.B. langsame Bereiche zu beschleunigen, sollte man die Kentnisse allerdings auffrischen. Vor allem, da bei modernen Methoden (PDO, OML, …) die JOINs eine zentrale Rolle spielen.

No reference from table X to table Y

Referenzen der Datenbank im Zend Framework über das Model abzubilden ist ja eine gute Idee. Schnell ist das entsprechende Skelett des Model erstellt und die Doku lehrt uns: „Definier die $_referenceMap und alles wird gut.“. Dachte ich auch … aber

Wer das schon einmal ausprobiert hat, der weiß: Im aber steckt der Wurm im Apfel bzw. die Titelmeldung auf dem Schirm. Aber langsam und zum mitmachen:

Gegeben sind 2 Datenbanktabellen „news“ und „author“, news hat u.a. ein Feld authorId. Den Rest könnt ihr euch vorstellen.

class myApp_Model_News extends Zend_Db_Table_Abstract {

protected $_name = 'news';
protected $_primary = 'id';

protected $_referenceMap = array(

'TrouperId' => array(

'columns' => array('author_id'),
'refTableClass' => 'author',
'refColumns' => array('id')

)

);

}

Instinktiv benutzt man das und hier meldet sich auch gleich eine Fehlermeldung:
No reference from table myApp_Model_News to table myApp_Model_Author
Aber warum? Wir haben doch alles richtig gemacht.

Prinzipiell ja, laut Doku, aber nicht laut programmiertem Code, dafür muss man nämlich nicht den Tabellennamen in die $_referenceMap eintragen, sondern den Namen des Models!!!
Also so:

class myApp_Model_News extends Zend_Db_Table_Abstract {

protected $_name = 'news';
protected $_primary = 'id';

protected $_referenceMap = array(

'TrouperId' => array(

'columns' => array('author_id'),
'refTableClass' => 'myApp_Model_Author',
'refColumns' => array('id')

)

);

}

Besonders mal auf „refTableClass“ sehen, dort steht nun nicht mehr der Tabellenname wie er in der Datenbank steht, sondern der Name des Models, dass für diese Tabelle zuständig ist.
Und nun funktioniert das ganze auch mit

$news = new myApp_Model_News();
$myNews = $news->fetchRow();
$newsauthor = $myNews->findDependentRowset('myApp_Model_Author');