Im folgenden wird in aller kürze beschrieben, wie man PEAR unter
OSX 10.5 Leopard installiert. Dies sollte unter den vorherigen OSX
Versionen sicher ähnlich funktionieren.

Auf meinem lokalen System habe ich PHP5 von entropy.ch am laufen, da
ich unbedingt die GD-Lib benötige. Dies hat nur Einfluss auf die Ablage
der php.ini. Dies muss eben von den auf dem jeweilig auf dem System vorhandenen
Gegebenheit abhängig gemacht werden.

Wir werden in /usr/local/ installieren, und dem System gestatten die TEMP-Files
in /usr/local/temp abzulegen.



Im nächsten Schritt wird go-pear ausgeführt.



Hier muss bei den Pfaden der 1. auf /usr/local geändert werden.
Alle anderen Einstellungen können in der Regel beibehalten werden.

Während der Installation kommt dann die Warnung, dass der PEAR Pfad
noch nicht in der php.ini vorhanden ist, und es deswegen zu Problemen
mit der Verwendung von den PEAR Scripts kommen kann.

Hier kommen wir an den Punkt wo es wichtig ist, zu wissen, wo die
Konfigurationsdatei des Webservers liegen muss. Dies kann man einfach
über ein kurzes Script herausfinden:



Im Browser die Datei ansehen und nach folgender Zeile suchen.



Hier muss die php.ini für den Webserver liegen, die php.ini für
das Command-Line-Interface (CLI) unabhängig davon in /etc/

Standardgemäß ist eine php.ini.default in /etc/. Diese kopieren
und modifizieren wir zunächst.



Nun nach dem Eintrag include_path suchen und diesen um "/usr/local/share/pear"
ergänzen. Bei mir sah dies nach der Anpassung so aus.



Ist eine php.ini in dem Config-Path des Webservers vorhanden bearbeiten
wir diese, ansonsten kopieren wir die Datei /etc/php.ini an die gewünschte
Stelle



Abschließend muss noch der Webserver neu gestartet werden, dann ist PEAR
einsatzfähig.



Anmerkung: Kann PEAR von der Konsole nicht mit dem Befehl pear aufgerufen werden,
ist /usr/local/bin nicht korrekt in den SHELL-Pfaden eingetragen, und sollte nachgetragen
werden. Tipp: echo $PATH zum überprüfen in der SHELL eingeben.

Ich wünsche allen meinen Lesern ein frohes und erfolgreiches Jahr 2008.

Ich werde ab Februar 2008 wieder mein Engagement in diesem Blog verstärken.

Als kleinen Vorgeschmack gibt es einen Artikel über PEAR unter OSX Leopard.

Stay tuned...

Wer sich wundert wieso die Texte der erzeugten Graphen mittels jpgraph
in kryptischen Buchstaben dargestellt werden, obwohl gültige Daten in UTF-8
angeliefert wurden, ist nur einen kleinen Schritt von der Lösung entfernt.

Die Ursache des Problems liegt darin dass die Standardschriftarten von jpgraph
kein UTF-8 darstellen können.

Daher kann man sich einfach wie auch auf der jpgraph Seite angegeben ein
entsprechendes Schriftpaket herunterladen. Ich hab mich in meinem Fall für
Verda entschieden.Dies bekommt man hier: http://www.gnome.org/fonts/

Die Schirften lädt man sich herunter und lädt Sie in ein beliebiges Verzeichnis.

Nun muss nur noch das Verzeichnis der Library bekannt gemacht werden:



Nun muss man noch mittels SetFont angeben, wo welche Schrift eingesetzt werden
soll. Mir ist es allerdings nicht gelungen die Schriftart für die Beschriftung in den
Netzdiagrammen (jpgraph_radar.php) festzulegen, daher musste ich manuell
die Standardschrift ändern, indem ich in jpgraph.php und jpgraph_radar.php FF_FONT1
durch FF_VERA ersetzt habe.

Nun sollten alle Umlaute auch angezeigt werden können.

Nachdem ich in einem früheren Blog Eintrag empfohlen habe, alle Daten aus
Speicherplatzgründen die im UTF-8 Format sind in z.b. dem latin1 charset abzulegen,
muss ich dem nun komplett wiedersprechen.
Bei einem durchschnittlichen Projekt lädt man sich deutlich mehr Ärger auf,
als dass man dadurch Vorteile durch Speicherplatzersparnis erzielt.

In meiner Situation sah das dann so aus, dass ich ca. 8 Stunden damit beschäftigt
war, alle Datenbanken meiner Kunden umzustellen, was enorm händische Arbeit
erforderte.

Im Ist-Zustand war es nun auch so, dass mittels phpMyAdmin logischerweise
alle Umlaute kaputt angezeigt wurde, und man nicht oder nur mit hohem manuellen
Aufwand direkt die Daten bearbeiten konnte.

Ausgangssituation
Datenbank mit latin1 als Standardcharset, alle Tabellen latin1, und UTF-8 Daten darin gespeichert.

Ziel
Datenbank & Tabellen UTF-8, und alle Inhalte UTF-8
Ich habe mich für utf8_general_ci entschieden, der unterschied zu utf8_unicode_ci liegt nur in
der Abhandlung von Sortierreihenfolgen. Dies kann man aber im Detail dem MySQL Manual entnehmen.

1.) Datenbank Backup erstellen
Gehen wir einfach mal auf nummer sicher, um die Daten auch sicher nicht
endgültig zu zerstören.

2.) Umwandeln aller Tabellen voll automatisch, und davon sollen auch alle
Text und Varchar Felder umgewandelt werden. Manch einer wird hier noch anpassungen
vornehmen müssen, da ich keine Char Felder umwandle, da die nicht benötigt
werden. ACHTUNG! Das Script basiert wie alle meine Code Snippets auf adodb,
kann aber Problemlos auf die von MySQL zur Verfügung stehenden Funktionen
portiert werden.



3.) Manuelles Umwandeln der Datenbank
Ich habe mich dazu entschieden die eigentliche Datenbank händisch umzuwandeln,
da ich mich eh mit der Datenbank verbinden musste. Dazu habe ich dann folgendes
SQL Statement eingegebn



4.) Exportieren der Daten
Nun werden die Daten der kompletten Datenbank exportiert, nicht aber die
Struktur. Dies wird für die meisten am besten mittels einer grafischen Oberfläche
wie phpMyAdmin erledigt. Hier kann man dies mit weigen Mausklicks erreichen.

5.) Umwandeln des Datendumps
Nun wandeln wir einfach noch die "kaputten Zeichen" zurück in UTF8.
In meinem Fall und in den meisten wird folgendes Script hinreichend sein.
Dazu muss eine Datei data.sql im gleichen Verzeichnis wie das eigentliche
PHP Skript sein.



6.) Abschließende Arbeiten
Um die ganze Aktion abzuschließen, muss nur noch die Datenbank geleert werden,
un der neue Dump eingelesen werden. Dann sollte man die Umlaute alle
im entsprechenden Format in der Datenbank haben.

Nun werden einige aber sicher zerstörte Umlaute in der Ausgabe haben,
und sich wundern warum. Dies liegt an der MySQL Verbindung die einen
Befehl zu beginn benötigt um UTF8 sauber zu behandeln.



Nun sollte es endlich geschafft sein, und man sollte sich nun hoffentlich
wieder wichtigeren Dingen widmen können

Achja, heikel ist dann auch das string handling an manchen stellen, daher sollte man auf
die mb_* funktionen von PHP zurückgreifen.

Möchte man z.b. ausweisdaten, seriennummern oder ähnliches per HTML
Formular abfragen, möchte man es vielleicht erreichen, dass der Cursor
direkt von Feld zu Feld springt, nachdem die ausreichende Anzahl Zeichen
eingegeben wurde. Dies kann einfach mittels JavaScript erreicht werden.

Als ich heute gefragt wurde ob der FCKedit auch das Löschen von Dateien
ermöglicht war ich ganz erstaunt, dass er das nicht kann, und hab ihn dann
gleich in meinen Sourcen anhand der Erläuterungen von Bramus
ergänzt. Da sich allerdings einige Kleinigkeiten verändert haben, wollte ich
die einzelnen Schritte noch einmal auflisten.

Die Erweiterungen basieren fast komplett auf den Erklärungen von Bramus,
der dies in seinem Blog alles erwähnt. Danke hierfür.

1.) Ablegen eines entsprechenden ICONS in



2.) Anpassen der Datei frmresourceslist.html



Suchen der Zeile:


Danach folgende Zeile einfügen.


Dann folgenden Block:



durch diesen ersetzen. Hier wird das Bild dann eingefügt.



Zuletzt in der Datei bevor



folgenden Code Block einfügen



3.) Nun geht es an die PHP Funktionen in der commands.php

In der folgenden Datei



muss nur der folgende Code am ENDE vor den ?> eingefügt werden.



4.) Anpassen des Connectors

Im Connector muss noch das Switch Statement angepasst werden.



Sollte nur um folgendes ergänzt werden:



In der 2.4.3 sieht das ganze dann so aus



Viel Spaß damit!

Wenn man einen Laptop abgibt, ist man immer wieder vor dem Problem,
dass alle Daten unbedingt weg sein sollten, wenn der Laptop dann weg ist.

Apple hat hier eine einfach Lösung Parat. Einfach von der mitgelieferten CD
booten (Beim starten die [alt] Taste gedrückt halten) und dann das Festplatten-
Dienstprogramm starten, das man unter Dienstprogramme im Menü findet.

Die gewünschte Partition/Festplatte auswählen, und dann auf das Register Löschen
klicken. Unter Sicherheitsoptionen kann man nun wählen, wie man die Platte
löschen möchte.

Ich hab immer die 7-Fache Löschung bisher beorzugt.

In den meisten Quellcodes die man so liest ist eine Id Zeile am Dateianfang zu finden,
die ungefähr so aussieht:



Dies bedeutet dass man die datei test.cpp sieht, zuletzt geändert in Revision 3 um 12:28 am 08.07.2007 von dem Benutzer peterrehm.
Dies ermöglicht einen schnellen Überblick über die Datei.
Die Information wird von Subversion selbst verwaltet.
Damit Subversion das tut, sind ein paar kleine Einstellungen notwendig.

1. Aktivieren der Keywors für die gewünschten Dateien



2. Definieren eines Platzhalters in der Quelldatei

Dazu einfach einen Code wie folgt in die Datei einfügen, je nach
Programmiersprache eben in entsprechender Kommentierung.



3. Datei committen

Mit dem nächsten Commit wird dann automatisch die eingefügt Zeile ersetzt.
Dies wird auch bei jedem weiteren Commit passieren. Die Id Zeile ist aber nicht
für SVN diffs relevant, auch wenn man selbst versuchen sollte die zu ändern,
also wenn man das Datum ändert, wird das nicht mit übertragen.

Die Dateiinformation bleibt solange bestehen bis man eine neuere Version committet,
oder ein anderer Benutzer des SVN Repositorys das übernimmt. Allerdings wird die
Zeile dann auch erst mit dem nächsten update aktualisiert.

Als letzte Information bleibt vielleicht noch zu nennen, dass ein $Log$ Keyword von
den SVN Entwicklern ausdrücklich nicht implementiert werden. Darauf wird in der
FAQ verwiesen.

Update: Fehler wurde behoben, Danke Sebastian!

Neulich wurde ich gebeten, mir "kurz" ein kleines PHP Skript anzusehen,
und bei der Fehlersuche zu helfen. Dabei ist mit allerdings sehr schnell
aufgefallen dass einige grundlegende Unschönheiten zu finden sind.

Daher will ich anhand des mir zugesandten Codes einige Tipps zur PHP Entwicklung
geben.

1. 
   register_globals
   

   Ein immer wieder auftrendes Problem ist die register globals Geschichte,
   da PHP einem lange Zeit die Freiheit ließ, auf die POST Variable 'test' auf
   zwei Arten zuzugreifen. Entweder als $test, oder per $_POST['test'].
   Nutzt man erstere Variante kann man sich nie sicher sein, woher der
   Inhalt der Variablen eigentlich stammt, und man vergisst leicht einen
   vielleicht gefährlichen Inhalt zu escapen. Sofern die Möglichkeit besteht
   ist es sogar empfehlenswert register_globals auszuschalten. Aber man
   sollte es sich zumindest immer angewöhnen, auf POST/GET/REQUEST variablen
   immer mittels den dafür vorgesehenen superglobalen Arrays zuzugreifen.

   
   


2. 
   SQL Injections
   

   Eine große Gefahr stellen vor allem im Zusammenhang mit register_globals
   die SQL Injections dar, über die nicht gewollter SQL Code eingeschleußt
   werden kann. Um hier nicht auszuschweifen sollte man sich immer angewöhnen,
   Inhalt der manipuliert sein kann, zu escapen. Eine einfach Möglichkeit
   hierzu bietet mysql_real_escape_string(). Man sollte sich wenigstens
   angewöhnen den Inhalt immer zu escapen. Es empfiehlt sich auch eine
   eigene Funktion dafür zu nehmen, dass man später auch noch andere
   Verfahren einsetzen könnte, indem man nur eine Funktion überarbeiten
   muss. Hier ein Beispiel:

   
   
   
   CODE:
   /**
   * easy accesible handle to escape all db strings
   * @param string $string string which should be escaped to be put into an sql statement
   * @return string returns the escaped string
   */
   function escapeDB($string)
   {
   global $run;
   if(is_numeric($string))
   {
   return $string;
   } else {
   return $run['db']->qstr($string,get_magic_quotes_gpc());
   }
   }
   
   
   


3. 
   Variablen
   

   Man sollte Variablen immer klein schreiben, und Umlaute sollten nicht
   eingesetzt werden. Es ist meist auch recht angenehm die äquivalente englische
   Bezeichnung für Variablen zu verwenden. EIn unschönes Beispiel:

   
   
   
   CODE:
    '$Arbeitsverhaeltnis', '$Kündigungsfrist', '$Sonstiges'
   
   
   


4. 
   Fehlermeldungen
   

   Fehlermeldungen sollte man am besten immer beherzigen. PHP kennt verschiedene
   Modi, je nach "wichtigkeit" eines Fehlers. Meist werden die NOTICE's
   ausgeblendet. Allerdings sind NOTICES oft auch recht hilfreich,
   da man erkennt wo man z.B. eine noch nicht initialisierte Variable
   verwendet. Es empfiehlt sich meistens alle Fehlermeldungen anzuzeigen.
   Die macht man wie folgt:

   
   
   CODE:
   error_reporting(E_ALL);
   
   
   

   Vor allem gefährlich ist das manuelle Unterdrücken von Fehlermeldungen
   mittels dem @ Operator. Diesen sollte man auch nicht einsetzen, da dadurch
   die Fehlersuche oft erschwert sein kann.

   
   

Dies mal nur als kurze Zusammenfassung.

Ich habe heute etwas mit Bootcam unter meinem MacBook gespielt. Alles lief nach Plan nur hatte ich nach der
Installation der Treiber auf einmal weder Tastatur noch Maus. Das rührt daher, dass man auf keinen Fall eines
der aufpoppenden Fenster mit der Aufforderung zur Treiberinstallation anrühren sollte.

Sobald man das macht, ist alles dahin

Die Fenster verschwinden automatisch wieder!

Hat man ein Element geklickt, und dadurch z.B. einen AJAX Request ausgelöst,
bleibt meist ein Focus auf dem Element. Dies wäre an sich nicht weiter schlimm.
würde der nicht so übel aussehen!



Diesen Focus kann man einfach mit der JavaScript Methode blur() entfernen.



oder wie in meinem Fall mit Prototype:

Bei einem aktuellen Projekt trat ein seltsames Problem auf.
In jedem Formular wird auf das erste Feld manuell ein focus() gesetzt,
dass man sehr benutzerfreundlich durch die Felder tabben kann und
sofort loslegen kann.

Nachdem ich wie gewohnt zunächst alles in Safari & Firefox entwickelt habe,
war ich sehr erstaunt, dass das focus() nicht an allen Stellen des Projektes
zu sehen war. Nach kurzer Zeit habe ich entdeckt, dass der Focus nur bei
den Seiten nicht angezeigt wird, wo der Inhalt per AJAX nachgeladen wurde.

Es gibt eine sehr einfache wenn auch sehr unschöne Lösung für das Problem.
Man kann den Focus einfach doppelt aufrufen, das habe ich dann in einer
Funktion implementiert, um es einfach wieder zu entfernen, wenn eine andere
Lösung möglich ist.

Kommentare sind wieder aktiviert!

Schon lange hab ich mich über die "komischen" Zeichen geärgert, die der Texteditor meines Vertrauens BBEdit am Anfang jeder UTF-8 Datei eingefügt hat. Ich hab dann sogar andere Texteditoren engesetzt, und irgendwie hatte ich immer das gleiche Problem.

Vor allem war ärgerlich, dass ich damit immer wieder nahezu unbrauchbare Dateien ausgeliefert habe, da der IE z.B. eine CSS Datei mit BOM auch einfach mal so ignorieren kann.

Heute habe ich des Rätsels Lösung gefunden. Eben das besagt BOM. Das Teufelszeug.

BOM = Bytereihenfolge-Markierung und wird dazu verwendet um z.B eine UTF-8 Datei als UTF-8 kodiert zu markieren.
Dies macht beim Datenaustausch sicher sinn, kann aber bei der Web oder C++ Entwicklung sich als sehr hinderlich erweisen. Die UTF-8-Kodierung des BOM besteht aus der Bytesequenz EF BB BF, die in den ISO-8859-1-Zeichen  erscheint.

Ich habe nun in BBEdit UTF-8 ohne BOM eingestellt und werde damit hoffentlich endlich Frieden finden

Seitdem ich viel unterwegs bin und täglich zwischen Hochschule und meinem Zuhause hin und her pendle,
musste ich jeden Tag zwischen 2 Umgebungen wechseln.

Das ist an sich nicht sehr problematisch, aber wenn man dann vergisst den Lautsprecher auszumachen ist
das eher doof.

Aber ich würde darüber nicht so berichten, wenn es noch keine Lösung geben würde
Die Lösung heisst Home Zone. Damit kann man einstellen, bei welcher Umgebung welche
Einstellungen vorgenommen werden sollen.

Man kann bisher folgende Werte einstellen Lassen: Netzwerkumgebung, Lautsprecher an/aus schalten, Eine Datei öffnen,
iTunes öffnen, Drucker einstellen und vieles mehr. Leider fehlt mir bisher noch das ausschalten
von Bluetooth.

Homezone bekommt Ihr hier: http://metaquark.de/homezone/