phpschnipsel

PHP 5.2.* unter einem 64 bit Linux installieren

tobi — Fri, 20 Apr 2007 11:57:12 +0000

Die Installationsanleitung für 5.2 für SuSE 9.3 funktioniert leider nicht wie gewollt unter einem 64bit System. Das Configure-Script bricht spätestens beim Versuch die Headerfiles der GD zu finden mit der Fehlermeldung

PLAIN TEXT

CODE:

configure: error: libpng.(a|so) not found.

ab.

Dies liegt nicht daran, dass die entsprechenden Dateien nicht gefunden werden können, sondern an einem (alten) Bug (PHP4) im Configure-Scripte, der meiner Meinung nach einfach mitgeschleppt wurde.
Selbst beim Versuch die GD testweise herauszulassen, bekommt man dies mit der Fehlermeldung quittiert, dass die mySQL-Header nicht gefunden wurden.

Workaround:

Man lege 2 Links von /usr nach /opt

PLAIN TEXT

CODE:

ln -s /usr/include /opt/include
ln -s /usr/lib64 /opt/lib

und gebe diesen Pfad im Configure-String mit

PLAIN TEXT

CODE:

--with-jpeg-dir=/opt \
--with-png-dir=/opt \
--with-mysql=/opt \

Nun kann der Script die die Dateien auch finden. Natürlich müssen die entsprechenden Develpackete auch installiert sein:

Zur Erinnerung hier nochmal eine Checkliste der von PHP gebrauchten Pakete:

Bison
Flex
OpenSSL devel
OpenSSL Doc
ZLib devel
cURL devel
libxml
libxml devel
libxslt devel
libpng devel
freetype
freetype 2
freetype 2 devel
libcrypt devel
libmhash
libmhash devel
sablot devel
mysql devel
autoconf

meine Meinung zum “websitebaker”

tobi — Sat, 10 Mar 2007 14:44:11 +0000

Durch einen Kundenauftrag bin ich letzte Woche mal mit dem Websitebaker in Berührung gekommen und muss sagen, dass ich von dem u.a. in der InternetPro hoch gelobten CMS ziemlich enttäuscht bin.
Da ich PHP schon standardmäßig mit error_reporting E_ALL konfiguriere, war durch eine Notice (eine doppelte Konstante) bei der Installation und der nachfolgenden "header already sent"-Fehlermeldung schon Schluss. Erst nachdem ich manuell im Code nachgeholfen habe, ging die Installation reibungungslos von statten.
Bis auf die Startseite jedoch in fast jedem Module Notices wohin das Auge reicht, von undefinierten Offsets bis hin zu undefinierten Konstanten oder wie oben schon mal passiert eben doppelten Konstanten. Wie mag solch ein Code ausschauen? Genau so wie das Frontend: Scheußlich! Weder HTML und CSS(in eleganter Tabelle) noch PHP und mySQL sind frei von Fehlern und Sicherheitslücken.
Ich kann nur eines raten: Finger weg!

Mircosoft Firefox 2007

tobi — Thu, 18 Jan 2007 10:15:05 +0000

Was nicht zu töten ist, wird aufgebohrt und viel besser gemacht. Eine Microsoft-Philosophie die jetzt auch in die Browser-Entwicklung eingeflossen ist. Nach dem unglaublichen Erfolg von IE 7 kommt nun der MS-Firefox 2007. Natürlich nur für Nutzer des einzigen und besten Betriebssystems aller Zeiten. Ist dies das Ende der IE-Engine?
Viel Spaß mit Mircosoft Firefox 2007!!

Firefox 3.0 schafft den Acid 2 Test

tobi — Thu, 14 Dec 2006 10:13:53 +0000

Die Mozilla Foundation hat die offizielle Alpha des Firefox 3.0 released und schafft es damit erstmals den nicht unumstrittenen Acid 2 Test zu bestehen. Die Entwickler setzen damit einen weiteren sehr wichtigen Meilenstein vor ihren Hauptkonkurrenten Internet Explorer 7. Browser wie Opera oder Safari bestehen den Acid 2 Test schon seit Längerem. Bleibt abzuwarten wann der endgültige Release-Termin ist. Ich persönliche schätze diesen nicht vor Herbst nächsten Jahres ein.
mehr dazu

mod_rewrite unter SuSE (Apache) aktivieren

tobi — Thu, 16 Nov 2006 14:41:03 +0000

Es ist beim SuSE-Apachen immer das gleiche: Man will etwas Spezielles nachinstallieren, fügt es hinzu und beim nächsten Apache-Neustart ist die entsprechende Zeile auch schon wieder überschrieben. Genauso erging es mir mal wieder beim Hinzufügen von mod_rewrite, denn der liebe SuSE-Apache hat so seine Tücken.
Möchte man ein Modul hinzufügen oder wegnehmen braucht man dies nur in der Datei /etc/sysconfig/apache2 zu tun. Dort stehen in der Variable APACHE_MODULES alle zu ladenden Module. Einfach das benötigte Modul hinzufügen und fertig:

PLAIN TEXT

CODE:

APACHE_MODULES="mod_perl rewrite access actions alias auth.......

utf-8 Umstellung in einer Lamp Umgebung

tobi — Tue, 17 Oct 2006 14:21:17 +0000

Bei der Umstellung von PHP-Scripten oder ganzen PHP-Anwendungen inklusive Datenbank-Anbindung und deren Ausgaben, von Latin1(iso-8859-*) auf utf-8 (Abk. für 8-bit Unicode Transformation Format), gibt es vieles zu beachten.
Weil iso-8859-1 bzw -15(mit €) in den meisten Fällen ausreicht, sollte dieser Zeichensatz für deutsch bzw englischsprachigen Seiten auch Verwendung finden. Wenn aber kyrillisch oder gar chinesisch auf der Seite angezeigt werden muss, liegt ein Multibyte Zeichensatz wie utf-8 nahe, da er all diese Zeichen anzeigen kann. Das W3C empfiehlt übrigens generell die Benutzung von utf-8 auf HTML-Seiten. XHTML ist grundsätzlich utf-8, wenn man nichts anderes vorgibt.
Da man den utf-8 Zeichensatz bei allen möglichen Gelegenheiten(in PHP, in mySQL, in XHTML, in CSS und im Browser) um- und einstellen kann, ist bei der Umstellung also einiges an Aufmerksamkeit gefragt, denn eine vergessene Einstellung kann schon das Scheitern des Vorhabens bedeuten.

Viele der folgenden Einstellungen mögen doppelt vorkommen, meine Erfahrung bei der Umstellung ist jedoch, dass man hier sehr gewissenhaft vorgehen muss um Fehler und Folgefehler zu vermeiden.
Der wohl wichtigste Part beschäftigt sich mit der Konfiguration von mySQL, da gerade beim Daten speichern sehr viele Fehler auftauchen können.
Schritt 1 - Das Dokument an sich
Die Kodierung des verwendeten Editors(z.B. Dreamweaver) auf UTF-8 umstellen. Alle Dokumente sollten direkt als utf-8 erstellt werden. Hier ist zu bemerken, dass es eine sog. "BOM" gibt, eine Markierung für die Byte-Reihenfolge bei UTF-* Dokumenten, die es dem Client ermöglicht auszulesen ob das Dokument ein UTF-* Dokument ist. ~~Diese Option im Editor also aktivieren.~~ Die Funktion sollte bitte nur mit Vorsicht aktiviert werden, denn nicht jede Applikation kommt damit klar. Gutes Beispiel ist, dass durch die BOM anscheinend schon ein Header gesendet wird. Somit wird durch eine nachfolgende header()-Anweisung unter PHP ein "headers already sent" Warning ausgelöst. Ich bin momentan dabei dieses Problem zu lösen.
Schritt 2 - Das HTML
(X)HTML Header anpassen. Damit der Browser weiß dass er das Dokument in utf-8 anzeigen soll, muss er dies gesagt bekommen .

PLAIN TEXT

HTML:

http-equiv="Content-Type" content="text/html;charset=utf-8" />

Schritt 3 - CSS
Das CSS wird mit dieser kleinen Anweisung zu utf-8. Wichtig: Wenn man in Stylesheets eine BOM verwendet, dann kann man nicht zugleich die @charset-Regel benutzen, denn die muss immer die allererste Zeichenkette im Dokument sein.

PLAIN TEXT

CSS:

@charset "utf-8";

Schritt 4 - php.ini
Damit php die Scripte als utf-8 ausliefert, sollte man auch die php.ini entsprechend anpassen.

PLAIN TEXT

CODE:

default_mimetype = "text/html"
default_charset = "utf-8"

Schritt 5 - Apache-Webserver
Damit der Webserver Dokumente als utf-8 ausliefert, muss er entsprechend konfiguriert werden. Entweder man tut dies direkt in der http.conf oder in einer htacces Datei. alternativ kann diese Direktive auch nur in speziellen vhosts vorgenommen werden.

PLAIN TEXT

CODE:

AddCharset utf-8 .css .html .xhtml .php .php4 .php5

Schritt 6 - mySQL
Um Daten in einer mySQL Datenbank als utf-8 zu speichern ist grundsätzlich eine Version >4.1 erforderlich. In Versionen darunter ist eine Unicode-Unterstützung nicht implementiert. Will man Daten als utf-8 abspeichern muss die Datenbank und die Tabelle in dieser Kollation angelegt sein. "Jeder String in MySQL ist mit einem Encoding und einer Kollation markiert. Für Datenbankobjekte geschieht dies auf der Spaltenebene: Eine Spalte mit CHAR, VARCHAR oder einem TEXT-Typ ist immer auch mit einem CHARSET und einer COLLATION versehen.(JK)"
Dies macht man z.B. so:

PLAIN TEXT

MySQL:

CREATE TABLE `test` (
`id` TINYINT( 64 ) NOT NULL ,
`TEXT` VARCHAR( 128 ) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL
) TYPE = MYISAM CHARACTER SET utf8 COLLATE utf8_unicode_ci;

Mit CHARACTER SET utf8 COLLATE utf8_unicode_ci wird der Spalte der Typ Unicode zugewiesen. Gibt man nicht explizit an welche Kollation verwendet werden soll, wird die in der Datenbank angebende weiter nach unten vererbt. Standard Encoding und Kollation lassen sich in der my.cnf angeben:

PLAIN TEXT

CODE:

[mysqld]
default-character-set=utf-8
default-collation=utf8_unicode_ci

Der Query
Auch wenn alles auf utf-8 umgestellt ist, wird man schnell feststellen, dass ein utf-8 String, der über ein HTML-Formular eingeben wird bei dem Weg zur Datenbank encodiert wird. Z.B. wird aus
فارسی in der Datenbank wieder Ø§Ù„Ø¹Ø±Ø¨ÙŠØ©. Woran kann das liegen? Auf dem Weg von HTML über http zu PHP zu mySQL wird der ursprünglich als utf-8 kodierte String also wieder encodiert. Dies geschieht, sofern man alles andere richtig eingestellt hat, bei der Verbindung von PHP und mySQL. Man umgeht das Problem indem man die Verbindung in utf-8 aufbaut:

PLAIN TEXT

PHP:

mysql_query("SET NAMES 'utf8'");
mysql_query("SET CHARACTER SET 'utf8'");

Quellen

http://www.columbia.edu/kermit/utf8.html

http://www.bueltge.de/wk-utf-8-konvertierung/130/

http://www.unicode.org/

http://blog.koehntopp.de/archives/1424-MySQL-Zeichensatz-Grundlagen.html

http://blog.antikoerperchen.de/beitrag/42/utf-8-und-die-entity.html

http://dev.mysql.com/doc/refman/4.1/en/charset-syntax.html

http://de.wikipedia.org/wiki/Utf-8

alles blog oder what?

tobi — Thu, 05 Oct 2006 11:07:01 +0000

Ja, ich habe mich nun doch endlich dazu überwunden statt meinem eigenen System eine Blogsoftware einzusetzen. Leider fehlt mir einfach die Zeit es so wie ich es möchte weiter zu entwickeln. Man kann eben nicht alles haben. Oder auch doch, denn Wordpress ist eine ganz feine Sache, die sich wunderbar erweitern lässt.

Die Codeschnipseldatenbank war ja total veraltet und mit teilweise völlig überflüssigem Code zugeschissen. Diese wird nun neu programmiert.

Lasst es krachen.

PEAR::DB und mysql_insert_id()

tobi — Tue, 05 Sep 2006 11:00:10 +0000

mysql_insert_id() gibt ja bekanntlich den letzen Autoincrement eines mysql-INSERTs bzw eines UPDATES an. Diese Vorgehensweise kann aber den Nachteil haben, dass z.B. ein Trackingsystem, das bei jedem Seitenaufruf Daten in die Datenbank schreibt, diese insert_id verfälscht. Dafür gibt man normalerweise den link indentifier mit, also den Connection-Handler. Wenn mann aber mit PEAR:DB arbeitet, muss man schon etwas suchen.
In der Klasse DB wird man fündig. Hier findet man die Eigenschaft $connection. Die Eigenschaft gibt man also seiner mysql_insert_id() einfach mit. Das ganze schaut dann etwa so aus: mysql_insert_id($db->connection). $db ist natürlich die entsprechende Objektinstanz.

PHP 5.2.* unter SuSE 9 installieren

tobi — Sun, 05 Mar 2006 11:09:50 +0000

Da es unter SuSE 9 keine offizielle PHP5 Version gibt, muss man sich selbst eine backen. Dieser Workshop zeigt wie und weist auf die Tücken hin, die bei diesem Update auftreten können. Dieses Tutorial funktioniert auf allen aktuellen 1&1 Rootservern mit SuSE 9.1 oder SuSE 9.3 [und PLESK], kann aber auch in höheren Versionen klappen, sofern die Apache-Version sich nicht geändert hat.
Zum Howto

mySQL-Backup über die Shell

tobi — Wed, 08 Feb 2006 10:07:43 +0000

Oft werden Datenbanken so groß, dass man sie nicht mehr über Webinterfaces wie phpMyAdmin backuppen und einspielen kann. Dazu sollte man die Datenbank über die Shell sichern und wieder einspielen.
Dieses Beispiel zeigt wie man ein Backup von mySQL macht, dieses als gzip-File packt und später wieder einspielt.

PLAIN TEXT

CODE:

->EXPORT
mysqldump datenbankname -u username -p[passwort]>sql_backup.sql
tar -czf sql_backup.tar.gz sql_backup.sql
->IMPORT
tar -xzf sql_backup.tar.gz
mysql -u username -p[passwort] datenbank sql