Upload Problem mit JPG

[kypta]

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

[kypta]

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:

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>';        						
				}
}

Man beachte auch:
http://contenido.org/forum/viewtopic.php?p=55750#55750 und
http://contenido.org/forum/viewtopic.php?p=57334#57334

[annett]

also geht das jetzt bei dir mit der vorschauanzeige oder nich.
Verstanden hab ich es so, das es auch bei dir nicht geht, richtig?

[kypta]

Richtig - geht (noch) nicht.

[kypta]

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.

case '2': //gd2
$method = 'gd2';
if ($filetype == '.gif')
{
$method = 'failure';
}
break;

Der case ist auf Zeilen 506 bis 512...

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??

[HerrB]

Den habe ich nicht ganz verstanden:

Der dortige switch verzweigt korrekt zum case '2' (ja, ich habe gd2).

Ok, $method = '2'

Beim nächsten switch, dem für $method wird bei 'gd2' capiImgScaleHQ aufgerufen, bei 'failure' wird ganz einfach der Link zur Originalbilddatei zurückgegeben.

Ok, bei .gif $method auf 'failure' und Du hast ein .gif?

Auf meinem System gibt capiImgScaleHQ leider nichts zurück. Darum bleibt der jeweilige Dialog hängen.

Wie kommt er denn zu capiImgScaleHQ?

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

[kypta]

Wie kommt er denn zu capiImgScaleHQ?

Nein, ich habe da nur weiter überlegt. Also zu capi.. kommen die jpgs. Ich habe mich nur gefrag, warum dass die gifs da eben nicht auch rein kommen. Das mit der Lizenz wusste ich nicht.

[kypta]

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):

Es 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.

Jetzt läufts

[timo]

d.h. der Bug ist eigentlich keiner?

[kypta]

d.h. der Bug ist eigentlich keiner?

Keiner von Contenido.

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());
?>

Wenn man die Seite (resp. Datei) im Browser aufruft, erhält man etwa dies:

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) }

Dies müssten eigentlich alle bekommen, ansonsten wären in Contenido unter System ja auch Fehler zu sehen...

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;
?>

Dazu muss man noch ein Bild auf den Server legen mit dem Dateinamen testimg.jpg (oder halt den Code anpassen..).

Als Resultat bekommt man im Browser:

Resource id #3

(Die id kann natürlich eine andere sein) Wenn man ein Bild zurückbekommt mit einer Fehlermeldung dann fehlt das Bild testimg.jpg.

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.

[timo]

okay, dann verschiebe ich das mal in Misc 4.6

[kypta]

Ach ja, wer übrigens gd 2.0.28 hat, der darf auch in der Datei functions.api.images.php folgendes machen:

Code: Alles auswählen

case '2': //gd2 
$method = 'gd2'; 
/* if ($filetype == '.gif') 
{ 
$method = 'failure'; 
}
*/
break; 

(ca. ab Zeile 506)-> der if(gif)dann(failure) ist auskommentiert
Warum?

da etliche gd2-Installationen aus Lizenzgründen keine .gif-Manipulationen erlauben

2.0.28 aber schon