Upload Problem mit JPG
Upload Problem mit JPG
Ich habe bei einer 4.5.4-Installation folgendes Problem:
Die Dateiverwaltung funktioniert soweit normal, nur wenn ich ein JPG hochlade, dann bleibt der Dialog hängen. Wenn ich mit FTP auf den Server gehe, sehe ich, dass das JPG genauso wie alle anderen Dateien auch hochgeladen wurden.
Sobald sich aber ein solches JPG in einem Ordner befindet, kann ich nicht mehr in den Ordner wechseln, weil der Dialog (der die Files anzeigen sollte) hängenbleibt.
Ich habe weder in Contenido Fehlermeldungen noch im Apache-Error-Log. Auch ist GD die selbe Version wie auf einem anderem System, auf dem der Fehler nicht auftritt. Auch JPG Support ist enabled.
Ideen?
Gruss
Thomas
Die Dateiverwaltung funktioniert soweit normal, nur wenn ich ein JPG hochlade, dann bleibt der Dialog hängen. Wenn ich mit FTP auf den Server gehe, sehe ich, dass das JPG genauso wie alle anderen Dateien auch hochgeladen wurden.
Sobald sich aber ein solches JPG in einem Ordner befindet, kann ich nicht mehr in den Ordner wechseln, weil der Dialog (der die Files anzeigen sollte) hängenbleibt.
Ich habe weder in Contenido Fehlermeldungen noch im Apache-Error-Log. Auch ist GD die selbe Version wie auf einem anderem System, auf dem der Fehler nicht auftritt. Auch JPG Support ist enabled.
Ideen?
Gruss
Thomas
Offensichtlich produziert die Funktion uplGetThumbnail den oben beschriebenen Fehler. Bin da noch am suchen - habe aber zwei kleinere Bugs entdeckt:
In der Datei include.upl_files_overview.php habe ich in der class UploadList beim switch (getFileExtension($data)) - ca. Zeile 229 - für jpg's eine Sonderbehandlung eingebaut: uplGetThumbnail wird für jpg's nicht aufgerufen. (Achtung: das ist kein Fix! es erlaubt lediglich, dass ich mit der Dateiverwaltung arbeiten kann -> ohne Vorschaubilder)
Bug 1: Der switch wird nicht richtig abgearbeitet. Auch gif-Dateien (und andere Bildformate) gehen in den jpg-case rein. Ich sehe allerdings im code dazu keinen Fehler
Bug 2: Im case für wbmp werden in den return-Anweisungen zwar ein a-href-Tag eröffnet, aber nicht geschlossen.
Hier noch der Code - meine Änderungen sind nur im case jpg:
Man beachte auch:
http://contenido.org/forum/viewtopic.php?p=55750#55750 und
http://contenido.org/forum/viewtopic.php?p=57334#57334
In der Datei include.upl_files_overview.php habe ich in der class UploadList beim switch (getFileExtension($data)) - ca. Zeile 229 - für jpg's eine Sonderbehandlung eingebaut: uplGetThumbnail wird für jpg's nicht aufgerufen. (Achtung: das ist kein Fix! es erlaubt lediglich, dass ich mit der Dateiverwaltung arbeiten kann -> ohne Vorschaubilder)
Bug 1: Der switch wird nicht richtig abgearbeitet. Auch gif-Dateien (und andere Bildformate) gehen in den jpg-case rein. Ich sehe allerdings im code dazu keinen Fehler
Bug 2: Im case für wbmp werden in den return-Anweisungen zwar ein a-href-Tag eröffnet, aber nicht geschlossen.
Hier noch der Code - meine Änderungen sind nur im case jpg:
Code: Alles auswählen
/* If this file is an image, try to open */
switch (getFileExtension($data))
{
case "png":
case "psd":
case "gif":
case "tiff":
case "bmp":
case "jpeg":
case "jpg":
// änderung von thomas um zu sehen, ob jpgs probleme bereiten
if (is_dbfs($data))
{
return '<a target="_blank" href="'.$sess->url($cfgClient[$client]["path"]["htmlpath"]."dbfs.php?file=".$data).'">jpg-db: '.getFileExtension($data).'</a>';
} else {
return '<a target="_blank" href="'.$cfgClient[$client]["path"]["htmlpath"].$cfgClient[$client]["upload"].$data.'">jpg-dir: '.getFileExtension($data).'</a>';
}
break;
// ende änderungen thomas
case "bmp":
case "iff":
case "xbm":
case "wbmp":
if (is_dbfs($data))
{
return '<a href="JavaScript:iZoom(\''.$sess->url($cfgClient[$client]["path"]["htmlpath"]."dbfs.php?file=".$data).'\');"><img src="'.uplGetThumbnail($data, $this->size).'">';
} else {
return '<a href="JavaScript:iZoom(\''.$cfgClient[$client]["path"]["htmlpath"].$cfgClient[$client]["upload"].$data.'\');"><img src="'.uplGetThumbnail($data, $this->size).'">';
}
break;
default:
if (is_dbfs($data))
{
return '<a target="_blank" href="'.$sess->url($cfgClient[$client]["path"]["htmlpath"]."dbfs.php?file=".$data).'"><img src="'.uplGetThumbnail($data, $this->size).'"></a>';
} else {
return '<a target="_blank" href="'.$cfgClient[$client]["path"]["htmlpath"].$cfgClient[$client]["upload"].$data.'"><img src="'.uplGetThumbnail($data, $this->size).'"></a>';
}
}
http://contenido.org/forum/viewtopic.php?p=55750#55750 und
http://contenido.org/forum/viewtopic.php?p=57334#57334
Well, habe gesehen, das dieses Problem aus dem Bugtracker entfernt wurde. Bin aber doch der Meinung, dass es hier einen Bug hat.
System:
PHP Version 4.4.0
Apache/1.3.33
GD Version bundled (2.0.28 compatible)
Das passiert:
Die Funktion uplGetThumbnail ruft die Funktion capiImgScale (in functions.api.images.php)auf. Dort wird geprüft, welche Image-Manipulations-Möglichkeiten dass man hat (gd1, gd2, imagemagick).
Der dortige switch verzweigt korrekt zum case '2' (ja, ich habe gd2).
Dort wird $method = 'gd2' gesetzt und falls es ein gif ist, wird
$method auf 'failure' gesetzt.
Beim nächsten switch, dem für $method wird bei 'gd2' capiImgScaleHQ aufgerufen, bei 'failure' wird ganz einfach der Link zur Originalbilddatei zurückgegeben.
Schlussfolgerung:
Auf meinem System gibt capiImgScaleHQ leider nichts zurück. Darum bleibt der jeweilige Dialog hängen.
Bei GIF-Files geht es, weil GIF-Files gar nicht verkleinert werden. Eigentlich ist das ja auch ein Fehler - oder sehe ich das Falsch? Sollen Gif-Bilder keine Vorschau erhalten??
System:
PHP Version 4.4.0
Apache/1.3.33
GD Version bundled (2.0.28 compatible)
Das passiert:
Die Funktion uplGetThumbnail ruft die Funktion capiImgScale (in functions.api.images.php)auf. Dort wird geprüft, welche Image-Manipulations-Möglichkeiten dass man hat (gd1, gd2, imagemagick).
Der dortige switch verzweigt korrekt zum case '2' (ja, ich habe gd2).
Dort wird $method = 'gd2' gesetzt und falls es ein gif ist, wird
$method auf 'failure' gesetzt.
Der case ist auf Zeilen 506 bis 512...case '2': //gd2
$method = 'gd2';
if ($filetype == '.gif')
{
$method = 'failure';
}
break;
Beim nächsten switch, dem für $method wird bei 'gd2' capiImgScaleHQ aufgerufen, bei 'failure' wird ganz einfach der Link zur Originalbilddatei zurückgegeben.
Schlussfolgerung:
Auf meinem System gibt capiImgScaleHQ leider nichts zurück. Darum bleibt der jeweilige Dialog hängen.
Bei GIF-Files geht es, weil GIF-Files gar nicht verkleinert werden. Eigentlich ist das ja auch ein Fehler - oder sehe ich das Falsch? Sollen Gif-Bilder keine Vorschau erhalten??
Den habe ich nicht ganz verstanden:
Für .gif wird der Link zur Originalbilddatei geliefert. Und das ist zunächst korrekt, da etliche gd2-Installationen aus Lizenzgründen keine .gif-Manipulationen erlauben (die Lizenz ist zwar gerade ausgelaufen, aber bis alle ihre gd2-Installation aktualisiert haben, wird es wohl noch dauern).
Gruß
HerrB
Ok, $method = '2'Der dortige switch verzweigt korrekt zum case '2' (ja, ich habe gd2).
Ok, bei .gif $method auf 'failure' und Du hast ein .gif?Beim nächsten switch, dem für $method wird bei 'gd2' capiImgScaleHQ aufgerufen, bei 'failure' wird ganz einfach der Link zur Originalbilddatei zurückgegeben.
Wie kommt er denn zu capiImgScaleHQ?Auf meinem System gibt capiImgScaleHQ leider nichts zurück. Darum bleibt der jeweilige Dialog hängen.
Für .gif wird der Link zur Originalbilddatei geliefert. Und das ist zunächst korrekt, da etliche gd2-Installationen aus Lizenzgründen keine .gif-Manipulationen erlauben (die Lizenz ist zwar gerade ausgelaufen, aber bis alle ihre gd2-Installation aktualisiert haben, wird es wohl noch dauern).
Gruß
HerrB
Bitte keine unaufgeforderten PMs oder E-Mails -> use da Forum!
Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net
Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net
Problemlösung
Habe festgestellt, dass die gd-lib nicht richtig funktionierte. Der php-Befehl gd_info() lieferte zwar das gewünschte, imagecreatefromjpeg() aber nicht. Habe mich also an den Provider gewendet.
Seine Antwort (nach langem Suchen):
Seine Antwort (nach langem Suchen):
Jetzt läuftsEs war ein Apache-Modul, welches einen grafischen Zaehler implementiert
und eine eigene GD-Version eingebaut hatte die mit dem GD des PHP
konfliktierte. Den Zaehler habe ich ausgebaut, weil das sowieso keiner
mehr verwendet.
Keiner von Contenido.d.h. der Bug ist eigentlich keiner?
Wie es bei diesen steht weiss ich aber nicht:
http://contenido.org/forum/viewtopic.php?p=55750#55750 und
http://contenido.org/forum/viewtopic.php?p=57334#57334
Ich habe "meine" Lösung nur gepostet für all jene, die die selben Symptome haben. Ist ja auch nicht schlecht, wenn die Contenido-Community "Erfahrungsberichte" zu fehlerhaften Server-Configurationen hat. Somit ist man evtl. schneller am eigentlichem Problem.
Hier noch einen Tipp, wie man auf die schnelle rausfindet, ob gd funkt wie gewünscht oder nicht:
Man lege eine php-Datei auf den Server mit diesem Inhalt:
Code: Alles auswählen
<?php
var_dump(gd_info());
?>
Dies müssten eigentlich alle bekommen, ansonsten wären in Contenido unter System ja auch Fehler zu sehen...array(11) { ["GD Version"]=> string(27) "bundled (2.0.28 compatible)" ["FreeType Support"]=> bool(true) ["FreeType Linkage"]=> string(13) "with freetype" ["T1Lib Support"]=> bool(false) ["GIF Read Support"]=> bool(true) ["GIF Create Support"]=> bool(true) ["JPG Support"]=> bool(true) ["PNG Support"]=> bool(true) ["WBMP Support"]=> bool(true) ["XBM Support"]=> bool(true) ["JIS-mapped Japanese Font Support"]=> bool(false) }
Dann lege man eine weitere php-Datei an:
Code: Alles auswählen
<?php
function LoadJpeg ($imgname) {
$im = @ImageCreateFromJPEG ($imgname); /* Versuch, Datei zu öffnen */
if (!$im) { /* Prüfen, ob fehlgeschlagen */
$im = ImageCreate (150, 30); /* Erzeugen eines leeren Bildes */
$bgc = ImageColorAllocate ($im, 255, 255, 255);
$tc = ImageColorAllocate ($im, 0, 0, 0);
ImageFilledRectangle ($im, 0, 0, 150, 30, $bgc);
/* Ausgabe einer Fehlermeldung */
ImageString($im, 1, 5, 5, "Fehler beim Öffnen von: $imgname", $tc);
}
return $im;
}
$resultat = LoadJpeg("testimg.jpg");
echo $resultat;
?>
Als Resultat bekommt man im Browser:
(Die id kann natürlich eine andere sein) Wenn man ein Bild zurückbekommt mit einer Fehlermeldung dann fehlt das Bild testimg.jpg.Resource id #3
Wenn man NICHTS zurückbekommt, dann hat man genau das Problem, das ich hatte - und gute Argumente, den Provider zu überzeugen, dass ER ein Problem hat auf SEINEM SERVER. Evtl. ja auch ein Apache-Modul ...
Und wenn es der eigene Server ist, weiss man zumindest, in welche Richtung man zu suchen hat.
Also: Sorry timo, Du hattest recht, diesen "bug" aus dem Bugtracker zu nehmen.
Ach ja, wer übrigens gd 2.0.28 hat, der darf auch in der Datei functions.api.images.php folgendes machen:(ca. ab Zeile 506)-> der if(gif)dann(failure) ist auskommentiert
Warum?
Code: Alles auswählen
case '2': //gd2
$method = 'gd2';
/* if ($filetype == '.gif')
{
$method = 'failure';
}
*/
break;
Warum?
2.0.28 aber schonda etliche gd2-Installationen aus Lizenzgründen keine .gif-Manipulationen erlauben