Blogix

Gestern brauchte ich schnell eine PHP-Funktion um Zufallspasswörter zu erzeugen. Auf TotalyPHP wurde ich auch fündig. Ich habe die Funktion dann noch ein wenig optimiert. Hier meine Version:

Source code

<?php
function createRandomPassword( $laenge ) {
 
	// $chars enthaelt alle Zeichen, die zur Erzeugung des Passworts benutzt werden. Kann beliebig angepasst werden.
	// In meinem Beispiel sind nur Kleinbuchstaben und Zahlen drin. Leicht zu verwechselnde Buchstaben habe ich entfernt.
	$chars = "abcdefghkmnpqrstuvwxyz23456789";
	srand((double)microtime()*1000000);
 
	$pass = '' ;
 
	for ($i=0; $i <= $laenge; $i++) {
		$pass .= substr($chars,  rand(0,strlen($chars)),  1);
	}
	return $pass;
}
 
?>

Bildbearbeitungen unter PHP sind mit der bekannten GD-Lib schon lange möglich. Auch die Bibliothek ImageMagick ist eigentlich ein alter Zopf. Trotzdem war es (für mich) nicht ganz einfach auf meiner lokalen XAMPP-Entwicklungsumgebung unter Windows Vista diese schöne PHP-Extension zum Laufen zu bringen.

Wenn man so was nicht regelmäßig macht, dann steht meiner einer erst mal vor einigen Fragezeichen. Welche Version von welchen DLLs gehören wo hin? Wie aktiviere ich das in meiner PHP-Version? Welche PHP-Version muss es sein?

Folgendes Vorgehen führte bei mir letztlich zum Ziel:

1. Frische XAMPP-Version (1.7.4) installieren. Wichtig war hier, dass mindestens PHP Version 5.3.x oder besser enthalten ist. Unter Windows Vista ist noch wichtig, XAMPP nicht in den üblichen Programme-Ordner (z.B. C:\Program Files) zu installieren. Das kann zu Problemen mit der Vista Rechtesteuerung führen. Ein gute Alternative ist C:\xampp.
   (Man kann übrigens auch mehrere XAMPP-Installationen parallel auf dem Rechner haben solange man die Komponenten (Apache, MySQL-Server etc.) nicht als Dienste betreibt).
2. Die eigentliche XAMPP-Bibliothek als DLL-Datei für Windows (Binary Release) von http://www.imagemagick.org/script/binary-releases.php#windows herunterladen. WICHTIG: die “dynamic at 16 bits-per-pixel”-Version nehmen. Ob Win32 oder Win64 hängt dann von der Windows-Version ab.
   Auch hier sollte man die Installation NICHT in das vom Installer vorgeschlagene Windows-Programme-Standardverzeichnis vornehmen. C:\ImageMagick ist prima
   Beim Installieren die Option zum Anlegen der Pfade unbedingt aktiv lassen – sonst kann die PHP-Extension später nix finden. Windows sollte man nach der Installation einmal neu starten.
3. Jetzt braucht man noch die richtige DLL-Datei, die die imagick-PHP-Extension enthält. Denn nur diese kann mit der ImageMagick-DLL sprechen. Auch hier ist man als “Laie” zunächst überfordert. Gibt es doch von offizieller Seite leider kein konkretes vorgehen für Windows.
   Man muss sich Quellen wie dieser bedienen: http://www.sk89q.com/2010/03/vc6-windows-binaries-for-imagick-2-3-0/. Hier findet sich eine passende DLL, die in das Verzeichnis \ext\ der PHP-Installation (die bei XAMPP wiederum in \php\ zu finden ist) legen. Bei mir war das dann der Pfad C:\xampp2\php\ext\.
   Hinweis: Die meisten Quellen verweisen auf die Kompilate von valokuva.org. Diese DLLs sind aber nicht kompatibel zu der XAMPP-PHP-Kompilierung für Windows. Beim Start von XAMPP kommt dann die nebenstehende Fehlermeldung. Offensichtlich ist VC6 was anderes als VC9. Mehr habe ich auch nicht verstanden
4. Als letzten Schritt muss man noch die neue PHP-Extension in der php.ini aktiviert werden. Die php.ini liegt im \php\-Ordner von XAMPP und sollte natürlich nur mit einem Texteditor wie Notepad++ bearbeitet werden.
   Jetzt gibt es zwei Möglichkeiten. Entweder die Extension ist schon als Zeile vorhanden, aber auskommentiert oder sie fehlt komplett. Einfach mal nach “php_imagick” suchen. Findet sich eine Zeile der Art
   ;extension=php_imagick.dll
   dann muss nur das Semikolon am Zeilenanfang entfernt werden um die Extension zu aktivieren. Fehlt diese Zeile komplett, dann muss diese (ohne Semikolon) ergänzt werden (am besten unter dem Block wo sich auch schon die ganzen anderen extension=… Eintragungen befinden.
5. Als letztes XAMPP starten und testen. Hier noch ein kleines Testscript, dass als Ausgabe ein kleines Bild generiert:

   <?php

    /* How wide is our image */

    $image_width = 200;

    /* Give zero for autocalculating the height */

    $image_height = 200;

    /* Specify the text */

    $text = "Lorem ipsum dolor sit amet, consectetuer adipiscing elit.

    Mauris lectus mi, mattis non, euismod vel, sagittis nec, ipsum.";

    /* Instanciate imagick */

    $im = new Imagick();

    /* Create new image using caption: pseudo format */

    $im->newPseudoImage( $image_width, $image_height, "caption:" . $text );

    /* Put 1px border around the image */

    $im->borderImage( 'black', 1, 1 );

    /* PNG format */

    $im->setImageFormat( "png") ;

    /* Output */

    header( "Content-Type: image/png" );

    echo $im;

    ?>

PHP-Caches sind nicht immer nur für massive Performance-Gewinne, sondern manchmal auch für unerklärliche Fehler verantwortlich. So vertragen sich z.B. Horde und eAccelerator nicht. Die generierte Fehlermeldung lässt andere Fehlerquellen vermuten, an eAccelerator denkt man dabei aber vorerst nicht:

Warning: IMAP_Tree::require_once() [function.IMAP-Tree-require-once]: open_basedir restriction in effect. File(Horde/SessionObjects.php) is not within the allowed path(s): (/usr/share/php:/usr/share/pear:/usr/share/horde3:/etc/horde:/usr/lib:/usr/sbin:/var/log) in /usr/share/horde3/lib/Horde/IMAP/Tree.php on line 311

Fatal error: Can’t load Horde/SessionObjects.php, open_basedir restriction. in /usr/share/horde3/lib/Horde/IMAP/Tree.php on line 311

Man erhält also eine “open_basedir restriction”-Fehlermeldung, wie man sie schon häufig gesehen hat. Erste Vermutung ist natürlich, dass die in der php.ini konfigurierten Pfade für open_basedir nicht korrekt sind. Also sucht man zuerst nach der Datei “Horde/SessionObjects.php” und erkennt, dass sich diese an “/usr/share/horde3/lib/Horde/SessionObjects.php” befindet – dieser Pfad ist lt. open_basedir-Einstellung “…:/usr/share/horde3:…” aber eindeutig erlaubt. Die Suche geht weiter und weiter und… bis man auf die Idee kommt, dass man vor ein paar Tagen einen PHP-Cache installiert hat. Sofort nach der Deaktivierung desselbigen funktioniert wieder alles problemlos. Wie meine weiteren Recherchen herausgestellt haben, tritt dieses Problem nicht nur mit eAccelerator auf, sondern auch mit APC, usw.

Am Anfang des Jahres habe ich begonnen mich ein wenig mit PHP Frameworks auseinanderzusetzen, habe einige getestet und habe den Entschluss gefasst, dass ich mir das Zend Framework genauer ansehen und damit entwickeln möchte. Am leichtesten fiel mir der Einstieg zwar mit dem Yii PHP Framework, das ich deshalb auch im Hinterkopf behalten werde, leider ist es (immer noch) Beta. Wichtige Auswahlkriterien für mich waren, dass es objektorientiert (keine Altlasten durch Kompatiblität zu PHP 4), zukunftssicher (Weiterentwicklung sichergestellt, auch wenn der Chef-Entwickler das Projekt verlässt), weit verbreitet (große Community für schnelle Hilfe und viele umgesetzte Projekte – schließlich will man das Erlernte auch irgendwo einsetzen), gut dokumentiert, flexibel (andere “Module” einfach integrierbar), umfangreich (viele häufig benötigte “Operationen” enthalten) und stabil (gut getestet, etc.) ist. Alle soeben genannten Punkte sind meiner Meinung nach beim Zend Framework eindeutig gegeben, weshalb ich mich schlussendlich dafür entschieden habe.

In den letzten Wochen hatte ich keine Zeit mich weiter mit dem Zend Framework zu beschäftigen. Durch die im Newsletter angekündigte neue Version wurde ich wieder darauf aufmerksam gemacht und mein erster Schritt mich voll und ganz in das Vergnügen zu stürzen war nun, dass ich mir das Buch “Das Zend Framework: Von den Grundlagen bis zur fertigen Anwendung (Partnerlink)” bestellt habe. Die rasante Weiterentwicklung des Zend Frameworks wird es nie gestatten, dass es ein Buch für die aktuelle Version zu kaufen gibt, aber die Änderungen sind hoffentlich nicht zu groß und das Buch trotzdem brauchbar. Aber mehr dazu im nächsten Beitrag zum Zend Framework.

Wenn man mittels AJAX Daten von TYPO3 laden möchte, stößt man auf das Problem, dass TYPO3 grundsätzlich immer das Template rendert und somit eine Ausgabe von reinen Daten (z.B. XML oder JSON) nicht ohne weiteres möglich ist. Da aber die Ausgabe von reinen Daten (ohne Template) des Öfteren benötigt wird, stellt TYPO3 bereits ein Feature namens eID bereit. Sobald in der URL der Parameter eID vorkommt, wird eine alternative Rendering-Engine benutzt und es kann eine reine Daten-Ausgabe mit PHP erzeugt werden, ohne auf die gewohnten Funktionen aus dem TYPO3-Framework verzichten zu müssen.

Um dieses Feature nutzen zu können, muss man wie folgt vorgehen (analog zu TYPO3 CLI):

1. Erstellen eines Ordners namens “eid” im Ordner der Extension (z.B. in “typo3conf/ext/extensionkey/”)
2. Erstellen einer Datei (z.B. “class.tx_extensionkey_eid.php” – Name grundsätzlich egal) im in Schritt 1 erstellten Ordner “eid” mit dem Inhalt [1]
3. Erstellen (sofern noch nicht vorhanden) der Datei “ext_localconf.php” im Ordner der Extension (z.B. in “typo3conf/ext/extensionkey/”) mit dem Inhalt [2] (vorhandenen Inhalt nicht überschreiben, sondern nur hinzufügen)
4. Aufrufen des Skripts (z.B. “http://localhost/?eID=extensionkey”)

[1]:

<?php
/***************************************************************
*  Copyright notice
*
*  (c) 2009 Your name <email@example.com>
*  All rights reserved
*
*  This script is part of the TYPO3 project. The TYPO3 project is
*  free software; you can redistribute it and/or modify
*  it under the terms of the GNU General Public License as published by
*  the Free Software Foundation; either version 2 of the License, or
*  (at your option) any later version.
*
*  The GNU General Public License can be found at
*  http://www.gnu.org/copyleft/gpl.html.
*
*  This script is distributed in the hope that it will be useful,
*  but WITHOUT ANY WARRANTY; without even the implied warranty of
*  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
*  GNU General Public License for more details.
*
*  This copyright notice MUST APPEAR in all copies of the script!
***************************************************************/
if (!defined ('PATH_typo3conf')) 	die ('Access denied: eID only.');
require_once(PATH_tslib . 'class.tslib_pibase.php');

class tx_selfadmin_eid extends tslib_pibase {
	var $prefixId      = 'tx_extensionkey_eid';		// Same as class name
	var $scriptRelPath = 'eid/class.tx_extensionkey_eid.php';	// Path to this script relative to the extension dir.
	var $extKey        = 'extensionkey';	// The extension key.

	function eid_main() {
		$GLOBALS['TSFE']->fe_user = tslib_eidtools::initFeUser();
		tslib_eidtools::connectDB();
		var_dump($GLOBALS['TSFE']->fe_user);
	}
}

$extensionkey = t3lib_div::makeInstance('tx_extensionkey_eid');
$extensionkey->eid_main();

?>

Möchte man in diesem Skript nun auf Funktionen (z.B. Datenbank) aus dem TYPO3-Framework zurückgreifen, so muss man für die Instantiierung selbst sorge tragen. In der Datei “typo3_src/typo3/sysext/cms/tslib/class.tslib_eidtools.php” findet man vorgefertigte Methoden um auf die Daten eines FE-Users oder die Datenbank zugreifen zu können (Verwendung siehe im Code oben).

[2]:

<?php
  ## Adding alternative output engine to eID mechanism
$TYPO3_CONF_VARS['FE']['eID_include'][$_EXTKEY] = 'EXT:'.$_EXTKEY.'/eid/class.tx_extensionkey_eid.php';
?>