file bugs

destiny · Post by **destiny** » Fri 14. Nov 2003, 18:04

Mozilla lädt die Dateien mit der Endung .php herunter.
Gibt es keinen Weg, das zu Umgehen? Ich verstehe, dass die Dateien dynamisch aus der Datenbank gezogen werden, und temporär erstellt werden.

Das ist besonders für pdf Dateien sehr ungünstig, da man sie eigentlich sonst direkt im Browser anschauen könnte.

Auch habe ich ein Problem mit dem FTP Takover Skript. Es gibt bei der file_mime_type oder image_mime_type einen Fehler (Zeile 108 glaube ich). Das könnte an meiner PHP Version liegen, aber der Rest vom Skript funktioniert einwandfrei. Ich habe die Zeile auskommentiert, und es funktioniert gut ohne sie. (wo $file_type).

Ausserdem versagt IE beim herunterladen der pdf Datei ganz. Aber das kann auch daran liegen, dass sie vorher einen Fehler beim FTP Takeover hatte. Ich werde versuchen die Datei nochmal hochzuladen.

destiny · Post by **destiny** » Fri 14. Nov 2003, 18:12

Ausprobiert, die andere datei hochzuladen (auch pdf) ohne filetakeover bug (nach meinem fix) ... funktioniert unter dem IE nachwievor nicht. Er zeigt ein Icon wie bei einem fehlenden Bild in der linken oberen Ecke an und alles. Kann sein, dass er Plugin mässig in der Hinsicht schlecht konfiguriert ist.

Ausserdem ist es irgendwie störend, dass sich die Downloads im Mozilla Firebird in einem leeren Fenster öffnen, dass man danach wieder schliessen muss. Lässt sich das nicht umgehen, indem man die Datei temporär auf dem Webspace erstellt (evtl. gecached, oder als Option) ... in welchem Skript wird das ganze gesteuert? Ausser download.php in inc_act habe ich nichts in der Art gefunden.

Ich habe auch versucht, ".pdf" anzuhängen (Skript modifiziert), aber das wird vor dem ".php" angehängt. Es scheint also nicht im Quellcode reparierbar zu sein, ausser man geht vielleicht ganz andere Wege?

Post by **Oliver Georgi** » Sat 15. Nov 2003, 10:52

Hi,
das ist so ein für und wider. Ich habe mich bewußt dafür entschieden, dass Download = Download ist. Du hast sicher eine ungünstige Konfiguration - ich habe gerade eben nochmal durchgespielt - keinerlei Probleme mit dem Diwnload in Mozilla (1.5). Und Dir steht bei jedem Download frei zu sagen: Öffnen mit... - oder so.

Das Öffnen in extra Fenster kann man ändern - im Artikel-Renderer.

Oliver

destiny · Post by **destiny** » Sat 15. Nov 2003, 11:01

D.h. er zeigt Dir im Download Fenster nicht x.pdf.php sondern x.pdf an? Der download funktioniert bei mir ja auch, bloss, dass er die Datei als x.pdf.php aich auf der Festplatte ablegt. Man muss sie dann erst umbenennen, aber es funktioniert.

Ich habe im Firebird keine Einstellung gefunden, wie ich das ändern könnte. Im IE werden die zip Dateien als solche erkannt, aber bei der pdf Datei kommt eben nur dieses "Bild" Symbol.

Ich werde mir den Quelltext des Downloads anschauen und einfach wohl die Datei direkt verlinken, da mir das Download Symbol gefällt, ich aber die Datei auch z.B. in Google indexieren lassen möchte. (weil sie wohl sonst die Leute die sie brauchen könnten nicht finden werden)

Benutzst Du den reinen Mozilla? Ich benutze ja Firebird, vielleicht wird es daran liegen.
Hängt das GD Image Unterstützung mit dem FTPFileTakeOver Bug den ich erwähnte zusammen?

Im Artikel - Renderer, damit meinst Du im Quelltext? (welche Datei?)

Achja noch eine Anmerkung. Von Deiner Seite habe ich die .zip Datei der neuesten Version auch nur als .zip.php auf der Festplatte.

Nachdem ich Firebird nun gesagt habe das .pdf.php mit AcroRd32 zu öffnen schlägt er das bei den .zip.php Dateien auch vor ...

Es ist natürlich sehr unangenehm die Datein immer von Hand zu verlinken, da Du ja so ein schönes Skript dafür geschrieben hast (Größe, etc.) ... wäre es sehr schwer die Lagerung der Dateien von Datenbank auf FTP Storage umzustellen? Es ist für mich vielleicht sogar eine Frage der Datenbankgröße bei meinem Anbieter.

Post by **Oliver Georgi** » Sat 15. Nov 2003, 11:26

Reinen Mozilla - Da ist übrigens eine Eigenart von Mozilla, die ich auch schon beobachtet habe. Nutzt Du die neuste version von phpwcms - ich habe zwischendrin mal die Download-Funktion angepaßt - ist aber schon etwas her. Möglicherweise hilft Dir im Quellcode der Download.php eine Anpassung der Header Infos, die gesendet werden. Normalerweise wird in der Dateiverwaltung auch der mime-code hinterlegt. Aber viele Systeme haben da Probleme, deswegn der reine Download.

destiny · Post by **destiny** » Sat 15. Nov 2003, 19:39

Auskommentieren der Zeile
//header("Content-type: application/force-download");
ändert den attacheten Dateiendung von php zu htm. (unter Firebird)

Entfernen aller header gibt die Datei als Text aus... (unter Firebird)
Unter IE wird gefragt ob die Datei download.htm gespeichert werden soll.

Dann habe ich die Headers folgendermassen angepasst:

//if possible file format (PDF/JPG...)
$att = (stristr($_SERVER['HTTP_USER_AGENT'],"MSIE")) ? "" : "attachment; ";
//header("Content-type: application/force-download"); /* changed by StarD */
//header("Content-Disposition: ".$att."filename=".$download["f_name"]);
header("Content-Disposition: attachment; filename=".$download["f_name"]);
header("Content-Length: " . filesize($dl_path.$dl_filename));
//header("Cache-control: private");
//header("Pragma: public");
header("Content-type: application/pdf");
// It will be called downloaded.pdf
@readfile($dl_path.$dl_filename);

Das ermöglicht das die pdf Dateien richtig heruntergeladen werden. Aber zip Dateien zeigt der "schlaue" firebird als .pdf an (wegen content-type application/pdf) ....
Unter dem IE läuft bei mir der Download / das Anzeigen der Dateien jetzt auch richtig.

Wenn man den Type header ganz wegmacht, dann versucht der Firebird es einem als ".htm" anzudrehen.

Unter IE wird nach einem Download ... Dialog dann der richtige Name angezeigt und gefragt, ob gespeichert oder geöffnet werden soll . Sogar wenn man die $att = (stristr($_SERVER['HTTP_USER_AGENT'],"MSIE")) ? "" : "attachment; "; Zeile auskommentiert.

Ich werde mal weiter rumexperementieren. Wie kann man den MIME Type auslesen? Dann würde Firebird hoffentlich den Download richtig starten.

Ausserdem würde es mich interessieren ob Google z.B. solche Links dann überhaupt richtig indexieren kann und als pdf's erkennt? ...

Vielleicht könnte man im PHPWCMS anbieten, die pdf Dateien direkt anzuzeigen, anstatt sie nur zum Download zu stellen...

Auf jeden Fall danke für Deine Antworten, ich komme jetzt mehr oder weniger zurecht (pdfs statisch verlinken, zips über anpassen der Header).

destiny · Post by **destiny** » Sat 15. Nov 2003, 19:42

Achja ich benutze die neuste Version
phpwcms_1.1-RC1_2003-11-12.zip

Post by **Oliver Georgi** » Sat 15. Nov 2003, 19:55

P.S. Du hast so ziemlich alles falsch eingestellt, was man da falsch einstellen kann.

Versuch das hier mal:

Code: Select all

//Downloads must downloaded to harddisk
//are not opened and showed inside browser
//if possible file format (PDF/JPG...)
$att = (stristr($_SERVER['HTTP_USER_AGENT'],"MSIE")) ? "" : "attachment; ";
//header("Content-type: application/force-download");
header("Content-type: ".(($download["f_type"])?$download["f_type"]:"application/force-download")."\n");
header("Content-Disposition: ".$att."filename=".$download["f_name"]);
header("Content-Length: " . filesize($dl_path.$dl_filename));
header("Content-Transfer-Encoding: binary\n");
header("Cache-control: private");
header("Pragma: public");

Oliver

destiny · Post by **destiny** » Sat 15. Nov 2003, 21:49

Danke!

Das funktioniert unter Firebird wie ein Traum ... keine .php Anhänge mehr, zumindest bei den getesteten .pdf und .zip Dateien.
die Sache mit dem neues Fenster öffnen würde ich aber gerne noch ändern. Du hast gemeint im Article Renderer. Welche Datei?

Unter dem IE gibt es mit der PDF Datei nach wie vor Probleme. Ich probiere es Mal von einem anderen PC (Server) aus (vielleicht falsch konfiguriert?)

Funktioniert auch nicht. (zuerst "Download von" in Statusleiste dann "Fertig" o.ä. dann kleines Symbol, wie bei einem nicht geladenen Bild. Der AcrobatReader ist installiert und funktioniert bei Aufruf der "standardmäßig" mit Dateinamen verlinkten pdf Datei)

Aber die zip Dateien gehen ok.

Auf dem Notebook ist IE 6.0.26 ... beides Standard Deutsche XP Installationen ... wo der IE dabei war.
Firebird ist v. 0.7, also auch die neueste... aber damit klappt es ja wunderbar, bis auf die "neues leeres Fenster" öffnen Sache, aber ich denke, dass das kein Problem darstellt.

Du kannst es Dir ja mal anschauen, vielleicht mache ich was falsch?
http://destiny.lavadots.com/index.php
In der "Testkategorie" ist die .pdf Datei (meine Facharbeit) normal, also PHPWCMS standardverlinkt
In Images & Text > Facharbeit ist die Arbeit als Datei verlinkt und weiter unten sind zwei zip Dateien.

(Die Arbeit ist ca 3 MB groß ...)

P.S. Mit einer meiner Kombinationen, die ich zugegebenermaßen auf gut Glück geschrieben habe, hat der IE funktioniert ... vielleicht ist das ein IE seitiger Bug, oder der IE ist falsch konfiguriert bei mir???

Post by **Oliver Georgi** » Sat 15. Nov 2003, 22:04

Du kannst ja mal versuchen das hier auszukommentieren:

Code: Select all

// header("Content-Transfer-Encoding: binary\n");

Das öffnen in Extra Fenster ändere in content.article.inc.php Zeile 337:

Code: Select all

$fxb[$key]["fname"]."\" target=\"_blank\">".

in

Code: Select all

$fxb[$key]["fname"]."\" target=\"_top\">".

Oliver

destiny · Post by **destiny** » Sun 16. Nov 2003, 10:07

Danke für Deine schnelle Antwort. Ich habe die Änderungen wie von Dir vorgeschlagen vorgenommen.

Firebird funktioniert jetzt perfekt, so wie ich es mir vorgestellt habe (das File wird in einem neuen Acrobat Reader Fenster geöffnet, es bleibt kein leeres Browser Fenster übrig) bei pdf und bei zip.

Internet Explorer dagegen funktiiniert nach wie vor nur bei den zip Dateien. (ohne Probleme)
Die pdf Datei die sich weigert, zu funktionieren ist unter
http://destiny.lavadots.com/download.php?id=3603910,9,1
verlinkt. Ich werde mal eine kleinere zu Testzwecken hochladen, da 3 MB doch ziemlich viel sind.

destiny · Post by **destiny** » Sun 16. Nov 2003, 10:17

Sorry, Oliver, mein Fehler

In IE funktioniert auch der Download von .pdf Dateien

http://destiny.lavadots.com/download.php?id=34415,12,1

(eine kleinere Datei.)
Ich muss nun untersuchen, warum die große Datei nicht heruntergeladen wird. Vielleicht weil ich sie per FTP TakeOver hochgeladen habe und da die eine Zeile auskommentiert habe:
in act_ftptakeover.php
Zeile 106

Code: Select all

//$file_type	= image_type_to_mime_type ($file_check[2]);
$file_type = 'fix';

Das 'fix' habe ich dazu gemacht, weil ich dachte, dass es eventuell zu Problemen kommen könnte... wenn der $file_type leer ist.

Das Problem für mich hier nun ist, ich bekomme so große Dateien anders als per FTPTakeOver nicht ins System ... und es ist auch für kleinere Dateien sehr zeitaufwändig.

Es war also gar kein Bug in Deinem Quellcode, sondern ein von mir eingeführter Bug, damit das FTPTakeOver funktioniert ...

Wie könnte man das Problem in den Griff kriegen?

Danke für Deine Hilfe soweit

ich hätte den Fehler zuerst durch sowas ausschließen müssen

Post by **Oliver Georgi** » Sun 16. Nov 2003, 11:46

Ja - genau das ist es - da war dann kein MimeType vorhanden

Du kannst ja mal probieren, was er Dir für einen MIME-Type anzeigt:

Nur temoprär im Download code hier dahinter:

Code: Select all

header("Content-type: ".(($download["f_type"])?$download["f_type"]:"application/force-download")."\n");
echo "MIME-TYPE: ".$download["f_type"];

Oliver

destiny · Post by **destiny** » Sun 16. Nov 2003, 13:08

Bei der "richtig" erstellten Datei im IE mimetype pdf (o.ä.)
Bei der falsch erstellten Datei (nach meinem ftp-"fix") MIME-TYPE: fix<br />

Es lag wirklich daran ... bloss, wie kann man dann den ftp-takeover "Fehler" korrigieren? Wenn ich die Originaldatei wiederherstelle, kriege ich Fehler ... (wie im allerersten Message beschrieben)

Post by **Oliver Georgi** » Sun 16. Nov 2003, 14:09

Das liegt an der FTP Takeover - da wird kein MIME gemeldet - nur für Bilder gibt es da ne Check Funktion - die läuft aber erst auf aktuellen PHP Versionen.

file bugs

file bugs

Weiteres

Experimente

!!!!