Ich kann ja nie nachvollziehen, wie manche Leute versteckte Features in Hard- und Software herausfinden (ähnlich zu Easter Eggs gerne mal), aber Erica Sadun hat mit der neuen, noch nicht für die breite Öffentlichkeit verfügbare 3.0 Firmware für das iPhone endlich ein sog. Tethering hinbekommen: Mit dem iPhone über Bluetooth ins Netz.
Für den Einsatz in Deutschland mit T-Mobile hat Ortwin Gentz unter futuretap.com einen Erfahrungsbericht / ein How-To verfasst.
Großartig.
via Techcrunch.
Es gibt Dinge, die sich einem einfach regelmäßig wieder in den Weg stellen – so zum Beispiel Probleme mit Downloads von dynamisch generierten Dateien in PHP im Internet Explorer.
Das folgende Fehler PopUp der Internet Explorer 6, 7 oder 8 sind ein immer wiederkehrendes Ärgernis, wenn man versucht, einen Dateidownload mittels PHP zu realisieren:
Hierbei handelt es sich um ein dynamisch im Memory des Webservers generierten PDF Dokuments, das eigentlich als PDF_Preview.pdf betitelte Datei im Browser ankommen soll (und im Firefox, Safari, Opera und Chrome auch tut).
Zur Erzeugung wird der PDFLib Personalization Server genutzt, und am Ende des ganzen Erzeugungsprozesses steht ein Buffer (hier beispielhaft $pdf_buffer) des kompletten Dokumentes als Variable zur Verfügung.
Was für den Browser jetzt noch passieren muss: Per PHP header() Funktion wird dem Browser mitgeteilt, dass es sich um einen bestimmten Mimetype (ein Tool, um den MIME Type bei Dateiuploads herauszufinden gibt es hier) bzw. Datenstrom handelt (in diesem Fall handelt es sich um ein PDF, dass mit Content-type: application/pdf beschrieben wird). Weiterhin wird definiert, dass es als Dateidownload zur Verfügung gestellt werden soll, und der gewünschte Dateiname wird vom Script übergeben).
Um diesen Dateidownload (auch mit dem Internet Explorer) hinzubekommen, müssen zusätzlich diese zwei weiteren Headerinformationen mit angegeben werden:
[source:php]
header(‚Content-type: application/pdf‘)
header(‚Content-Disposition: attachment; filename=“PDF_Preview.pdf“‚);
// Folgende zwei Zeilen sind für den IE wichtig,
// alle anderen Browser brauchen sie nicht
// (stören sich daran aber auch nicht)
header(„Pragma: public“);
header(„Cache-Control: max-age=0“);
echo $pdf_buffer;
[/source]
Im Vorfeld (auf jeden Fall bevor der Buffer mit echo ausgegeben wird) sollte allerdings in jedem Fall die zu erwartende Dateigröße mittels
[source:php]
$pdf_buffer = PDF_get_buffer($p);
$len = strlen($buf);
header(„Content-Length: $len“);
[/source]
berechnet und ebenfalls per Header ausgegeben werden.
Vielleicht hilft dieser schnelle Artikel mir selbst auch beim nächsten Auftreten solcher Probleme als Gedächtnisstütze… 🙂
Sitze momentan im Nichtschwimmer auf dem aktuellen Webmontag.
Folgende Themen standen bisher auf der Tagesordnung:
1. iPhone Softwareentwicklung. Einige Infos über die verschiedenen Möglichkeiten (iUi, Dashcode, etc). Gehalten von @trimeton
2. Twitter „Overview“. Bin mir immer noch nicht sicher, was ich von dem Quatsch halten soll. Zum Zeitvertreib sicher gut, aber die Zeit hab ich irgendwie kaum…. aber: Alles zum Event gibt es hier, natürlich bei Twitter. Verrückte Welt.
Da xtCommerce generell auf iso-latin1 aufbaut und ich diese Kodierung für fehleranfällig und nervig halte (wieso nicht immer utf8? I don’t know!) folgt hier eine schnelle Anleitung, wie man die komplette xtCommerce Shop-Installation auf utf-8 umstellen kann:
Zuerst muss die Datenbank auf utf8 umgestellt werden. Hier beginnen wir mit der Gesamtdatenbank, die mittels
[source language=“:php“]ALTER DATABASE <datenbank>
DEFAULT CHARACTER SET utf8
COLLATE utf8_general_ci;[/source] auf UTF8 umgestellt wird. Leider müssen wir das gleiche Prozedere bei sämtlichen dort genutzten Tabellen vollziehen.
Der entsprechende Befehl pro Tabelle lautet
[source language=“:php“]ALTER TABLE <tabelle>
CONVERT TO CHARACTER SET utf8
COLLATE utf8_general_ci;[/source]
Für eine relativ standardmässige xtCommerce Installation mit den unzähligen Tabellen lautet die komplette SQL Befehlskette so wie in dieser Datei niedergeschrieben ist (für die schnellen: Runterladen, und copy paste soll helfen).
Danach folgt die Anpassung der Header Ausgaben (generell in der Datei /includes/header.php, etwa Zeile 35), damit im HTML Header korrekterweise [source language=“:html“]<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />[/source] ausgegeben wird. Im Quelltext steht dort allerdings bereits [source language=“:html“]<meta http-equiv="Content-Type" content="text/html; charset=<?php echo $_SESSION[‚language_charset‘]; ?>" />[/source] so dass lediglich der Wert für das Feld language_charset in der ‚languages‘ Tabelle auf utf-8 umgestellt werden muss, wie in diesem phpMyAdmin Screenshot zu sehen ist:
Zu guter Letzt muss der Datenbankverbindung noch mitgeteilt werden, dass sämtliche Gespräche mit der Datenbank in UTF8 ablaufen. Dies erfolgt in MySQL mit dem Befehl „SET NAMES ‚UTF8‘„, das am Besten dort integriert wird, wo die Datenbankverbindung aufgebaut wird, nämlich in der Datei inc/xtc_db_connect.inc.php:
Wie man sehen kann steht die mysql_query(); in dem Screenshot in Zeile 26 kurz vor der Auswahl der benötigten Datenbank.
Zum Schluss kann noch auf einige Unzulänglichkeiten beim Editieren von Bestellungen (orders_edit.php) und beim Senden von Nachrichten von der Webseite hingewiesen werden, über die ich momentan noch nicht gestolpert bin und somit auch noch nicht 100% getestet habe.
Für alle die Entwickler, die lieber für bestimmte Einsätze auf Flash / Flex zurückgreifen, habe ich eben im Google Blog (bzw. auf der Analytics Startseite) folgende Informationen über „Google Analytics within Flex/Flash Applications“ gefunden, die ich niemandem vorenthalten möchte:
Mittels der Google Analytics AS3-API kann auf alle Features von Google Analytics jetzt direkt aus Flex heraus zugegriffen werden, das Ding nennt sich „gaforFlash“. Getestet hab ich da noch nix, aber nachzulesen ist die Geschichte hier: Google Analytics within Flex/Flash Applications. Ich verabschiede mich kurz in einen spontanen, wohlverdienten Urlaub…..