Jetzt spuckt die Konsole keine Fehler mehr aus, »nur« noch 3 Warnungen:

Hm, bei mir nicht.

Hat irgendwas mit den Exif-Daten bzw. dem JPG-Header zu tun.

Scheint ein Fehler in Plupload zu sein.
Hängt evtl. mit Deiner URL zusammen.
Plupload versucht aus irgendeinem Grund an irgendiener Stelle die korrekte URL inklusive etwaigem Unterverzeichnis zu ermitteln. Und dabei überprüft es eben auch den Pfad hinter der Domain, allerdings ohne zu prüfen, ob es einen solchen Pfad überhaupt gibt.

Hat irgendwas mit den bereits erwähnten Request-Headers zu tun.
Was genau? Keine Ahnung.

Jetzt spuckt die Konsole keine Fehler mehr aus, »nur« noch 3 Warnungen:

[== firebug konsole ==]
ReferenceError: reference to undefined property _hm.get(...)[0]
http://dorheeme.dd/modules/Gallery/lib/plupload/plupload.full.min.js
Line 8252

[== firebug konsole ==]
ReferenceError: reference to undefined property uri.path
http://dorheeme.dd/modules/Gallery/lib/plupload/plupload.full.min.js
Line 4160

[== firebug konsole ==]
ReferenceError: reference to undefined property up.settings.headers
http://dorheeme.dd/modules/Gallery/lib/plupload/plupload.full.min.js
Line 12647

https://hilfe-center.1und1.de/hosting/1 … 91899.html

c) Du setzt den Wert in der php.ini selber. Bei 1&1 soll das ganz einfach gehen, in dem man im CMSms Root eine php.ini erstellt.

Und was genau schreibe ich in die php.ini rein? Du weißt doch: »Man sagt irgendeine Farbe und schon ist man schuldig geschieden.« Loriot

Und im PHP-Code vom Gallery-Modul wird {$file_size_limit} folgendermaßen definiert:

get_cfg_var() hat einen gravierenden Nachteil gegenüber ini_get(): Die Funktion gibt exakt den Wert zurück, wie er in der php.ini definiert wurde. Nicht den Wert, der zur Laufzeit tatsächlich gilt. Wenn in der php.ini dieser Wert nicht oder falsch gesetzt wurde, dann dürfte da im Browser ein leerer Wert oder Mist stehen. Darauf ist weder Plupload noch Gallery vorbereitet.

Es gibt jetzt drei Möglichkeiten:

a) Du änderst das Gallery-Template "modules/Gallery/templates/editgallery.tpl" (Stichwort "module_custom") und ersetzt {$file_size_limit} mit {ini_get('post_max_size')}.

b) Du änderst den PHP-Code im Modul.
Datei: modules/Gallery/action.editgallery.php
Zeile: 86

$filesize = str_replace('M', 'MB', get_cfg_var('post_max_size'));

in

$filesize = str_replace('M', 'MB', ini_get('post_max_size'));

c) Du setzt den Wert in der php.ini selber. Bei 1&1 soll das ganz einfach gehen, in dem man im CMSms Root eine php.ini erstellt.

Letzteres wäre zwar mein Favorit (weil man am Modul keine Änderung vornehmen muss und eine korrekt gesetzte Server-Einstellung nie schaden kann), aber ich weiß nicht, ob get_cfg_var() den Wert in der benutzerdefinierten php.ini oder nur den "Master-Value" ausliest. (.htaccess dürfte nichts bringen, weil die Werte dort definitiv nur Laufzeit-Werte sind)

Ich persönlich denke, man sollte das als "Fehler" beim Entwickler des Gallery-Moduls melden. ini_get() ist meiner Meinung nach an dieser Stelle verlässlicher als get_cfg_var(). Vor allem, weil man da auch als Anwender mehr Einfluss drauf hat.

Beim Hochladeversuch wird ein Fehler für Zeile 447, Spalte 3 ausgegeben, und zwar Type Error: size is null. In der fraglichen Zeile steht: mul = size[2];

Irgendwo hatte ich mal gelesen, dass ein falscher MIME-Type bzw. falscher Response-Header Probleme mit Plupload verursachen kann. Ich weiß leider nur nicht mehr in welchem Zusammenhang. Aber das wäre auf jedenfall eine Servereinstellung, bei der man ansetzen könnte.

'ne Zeilenangabe wäre cool
Kannst Du dazu mal diese Version von Plupload auf Deinen Server laden?
( "/modules/Gallery/lib/plupload/plupload.full.min.js"  --- Backup der Datei vorher nicht vergessen)
Ist im Prinzip die "Developer-Version" - also nicht minimiert.
(Minimiert macht Debug unmöglich.)
Ich wüsste gerne was "e" in der Fehler-Meldung eigentlich sein sollte und wer wann die dazugehörige Funktion aufruft.
Dazu brauche ich die komplette Meldung. Mit Zeilenangabe etc.
Kann das hier ja leider nicht nachstellen.

Und wenn Du schonmal dabei bist, versuch das mal im Firefox + Firebug zu machen.
Schalte dabei im Firebug sowohl bei Konsole als auch Netzwerk auf "Dauerhaft".
Und dann schau Dir mal beim Upload die Requests an.

Es liegt also irgendwie an meiner aktuellen Installation. Der Debugger meldet auch ein mehrfach auftretendes JS-Problem mit plupload.full.min.js:  »TypeError: e is null«. Und drunter eine Latte von Einzelangaben, die sich immer auf die nämliche Datei beziehen.

Der Link zur JS-Datei ist korrekt.

Rechte
die Ordner Gallery, lib und plupload:  755
plupload.full.min.js: 604

In einer funktionierenden Installation hatten die Ordner 750 und die JS-Datei 640. Rechteänderung auf 640 hat nix gebracht.

Keine Ahnung, ob das mit Deinem Problem zusammenhängt, aber für den Upload wird das Plugin "Plupload" verwendet. (War vorher mal SWFUpload)
D.h. der Browser muss entweder HTML5 oder Flash unterstützen.
Plupload und IE scheinen sich nicht sonderlich zu mögen, zumindest finde ich da im Netz eine Menge ähnliche Fehler, wie Du ihn beschreibst.

In der Gallery Version 2.1 wurde außerdem Plupload auf eine neuere Version aktualisiert. Könnte also durchaus mit einer Inkompatibilität von Plupload und diversen Browsern zu tun haben.

• Backend -> Gallery mit Debug behauptet frech: done loading required files, sonst m.E. keine Warnungen oder Fehlermeldungen

• @ Klenkes: Da liegt der Hase im Pfeffer. Hier fehlt komplett der Link Bilder selektieren. Nur noch Bilder hochladen da. {$selectimages} und {$uploadimages} (s. Zeile 79 editgallery.tpl) sind anscheinend zusammengefasst worden, denn {$selectimages} ist dort auskommentiert. Das einfach rückgängig zu machen, bringt nix. Markup hat sich gegenüber 2.0.1 auch geändert, wahrscheinlich wollte man select einsparen. Das scheint nicht so geglückt zu sein.

• Da wird es ein Downgrade auf die Schnelle wohl eher bringen, wovon mich noch abhält, dass laut Liste mehrere Bugs gefixt wurden.