Problem Wartung mit Dateianhänge aktualisieren

  • Toll, dass sich hier jetzt auch Betroffene melden, die das Problem etwas besser spezifizieren können. Scheinbar hatte ich Recht mit der Annahme, dass es an der zu restriktiven Fehlertoleranz des Importers bzw. des Programms für die Erzeugung der Vorschaubilder liegen könnte. Vielleicht ergibt sich daraus ja eine Lösung.


    Ich würde notfalls all die alten Bilder - etwa 60.000 - auf meinem Rechner speichern, wenn ich dann per Stapelverarbeitung alle Bilder reparieren könnte, um sie dann wieder in WBB3 hoch zu laden. Danach würde ich den Umzug samt Import in WBB4 noch einmal versuchen. Selbst wenn es 15 - 20 Stunden dauert, alle Bilder per Stapelverarbeitung zu reparieren, es wäre eine Lösung. Ich sehe da nur das kleine, sicher lösbare Problem, dass die Bilder ohne .jpg Dateiendung im WBB3 auf dem Server liegen. Wenn ich das aber richtig in Erinnerung habe, sind sie trotzdem als .jpg-Datei ohne Dateiendung les- und schreibbar
    Noch besser wäre es natürlich, wenn es ein Update des Importers oder der GD-Bibliothek für WBB4 geben würde und es dann automatisiert so läuft, wie es sollte.

  • Darfst Du aber nur mit Bild-Typen machen!


    "Mogrify" erkennt nämlich den Filetyp nicht und zerschreddert Dir eiskalt andere Dateianhänge (PDF/MP3 usw.) wenn diese im gleichen Verzeichnis liegen.
    (Da Mogrify ja auf Verzeichnisse losgelassen werden kann)

  • Ich habe gerade einmal versucht, die Attachments in Paintshop Pro 9 einzulesen. Das funktioniert einwandfrei, alle Bilder werden angezeigt und lassen sich öffnen. Dabei ist mir aufgefallen, dass WBB4 nicht nur ein Tumbnail erzeugt sondern zusätzlich ein noch kleineres Bild mit dem Namen Tiny, so dass alle Bilder, die WBB4 erzeugen konnte 3 Mal vorhanden sind. Das Original, das verkleinerte Tumbnail und die ganz kleine Tiny-Datei. Das verwundert mich, denn in WBB3 wird zusätzlich zur Originaldatei nur ein Tumbnail erzeugt.


    Da sich alle Bilder aus den vom Server auf den PC kopierten Verzeichnissen mit Paintshop problemlos öffnen lassen und auch korrekt angezeigt werden, bleibt es mir weiterhin ein Rätsel, wieso die Software von WBB4 das nicht schafft und einfach stehen bleibt. Denn mit der zurzeit laufenden WBB3 Installation werden die Bilder ebenfalls seit 2007 trotz mehrfacher Nutzung der Aktualisierung der Dateianzeigen problemlos in allen Beiträgen angezeigt.


    Ich gebe die Hoffnung nicht auf, dass die Spezialisten von WoltLab sich irgendwann dieses Problems annehmen und es lösen können. ;)

  • Der Hauptgrund für den Wechselwunsch zur neusten Softwareversion von WBB war ein Fehler in der Forensoftware, den ich nicht finden konnte. Seit gut 2 Jahren erzeugte irgendein Fehler in der Konfiguration oder in der Datenbank ständig Core-Dateien auf dem Server, die in der Regel etwa 255 MB groß waren. Bis zu 4 davon pro Tag, so dass ich diese alle paar Tage
    von Hand löschen musste.
    Im Zuge des geplanten Umstiegs auf die neuere Forensoftware mussten vom Provider Serverseitig einige Einstellungen angepasst werden. Dabei ist dann vor 3 Tagen der Server komplett abgestürzt und das Forum, so wie alle anderen Seiten, die ich betreibe waren mehr als 13 Stunden Offline.


    Das Gute daran ist, dass es seit dem nun endlich keine Fehlermeldungen und keine Core-Dateien (Speicherabbildungen) mehr gibt. Deshalb eilt es jetzt nicht mehr, auf die neuste Software umzuziehen. Der Fehler lag also nicht an einer Inkompatibilität zwischen der älteren Forensoftware und der neuen PHP-Version auf dem Server, wie von einigen Spezialisten vermutet, sondern schlicht und einfach an einer falschen Einstellung in der Serverkonfiguration. Damit war die ganze Arbeit, die ich mir mit dem gescheiterten Umzug gemacht habe letztlich nicht umsonst. Endlich läuft das Forum unter WBB3 wieder einwandfrei und fehlerlos.
    Deshalb lasse ich mir nun so lange Zeit mit dem Umzug auf die neuere Version, bis diese von WoltLab optimiert und der Fehler bei der Erzeugung von Vorschaubildern behoben wurde. Schafft WoltLab das nicht, bleiben wir bei der alten Version WBB3.

  • Wie hoch ist dein PHP memory_limit ? Gerade bei der Erzeugung von Vorschaubildern usw. wird mind. 128MB, optimalerweise 256MB benötigt.


    Vielleicht kannst du das erstmal überprüfen.


    Gruß

  • Das sind die Werte!


    max_input_nesting_level64
    max_file_uploads20
    max_execution_time60
    memory_limit128M
    post_max_size8M

    Edited 2 times, last by Bandito ().

  • Danke Dir Tim.


    Der Try/Catch läuft im worker-Namespace, sollte die Exception (48) nicht global escaped sein?
    catch (\SystemException $e)



    Evtl. werden auch durch den Array-Call (45) unterschiedlichen Typen gehandled, insofern würde ein Nicht catchbarer TypeError geraised werden, da gibt's aber Workarounds.

  • Ja...da schwimme ich noch, da oben im Kopf eine Use-Clause ist, deren Präsenz ich noch nicht verinnerlicht habe :D
    Ich hätte im Worker auch eher einen Exception-Translator hinzugefügt, der dann so ziemlich alles catched, was nicht bei 3 auf den Bäumen ist, da hier external Libs werkeln (GD/IM).

  • PS.:


    Die generelle Frage ist auch eigentlich mehr, was machen wir mit den Exceptions?


    Ich tendiere zum Finally -Block und Exception Löschung, Protokollierung des betroffenen Anhangs im Log und Fortfahren mit Import.
    So kann man später anhand des Logs gesondert mit den Problemfällen Liebe machen...

    • Official Post

    Hallo,

    Ich hätte im Worker auch eher einen Exception-Translator hinzugefügt, der dann so ziemlich alles catched, was nicht bei 3 auf den Bäumen ist, da hier external Libs werkeln (GD/IM).

    die werfen, wie fast alles in PHP, keine Exceptions. Und die Fehlermeldung im Startpost zeigt auch ganz deutlich, dass es ein Error war und keine Exception. Grundsätzlich hast du aber Recht.

    Ich tendiere zum Finally -Block

    Abgesehen davon, dass PHP 5.3 den noch nicht kennt weiß ich nicht, was du an der Stelle damit bezwecken möchtest. Das catch wirkt genau auf einen Anhang, der dann folgerichtig „ignoriert“ wird. Ich gebe aber zu, dass das „Fressen“ der Exceptions an einigen Stellen suboptimal ist. Da habe ich aber schon ein bisschen was für WCF 2.2 geplant, um die Situation zu verbessern (dazu bei gegebener Zeit auf GitHub und im Entwicklerforum mehr).

  • die werfen, wie fast alles in PHP, keine Exceptions. Und die Fehlermeldung im Startpost zeigt auch ganz deutlich, dass es ein Error war und keine Exception. Grundsätzlich hast du aber Recht.

    Moin Tim.
    Ich meinte mehr ein "custom handling" ala
    http://stackoverflow.com/quest…a-php-fatal-error/2146171.




    Abgesehen davon, dass PHP 5.3 den noch nicht kennt weiß ich nicht, was du an der Stelle damit bezwecken möchtest. Das catch wirkt genau auf einen Anhang, der dann folgerichtig „ignoriert“ wird.

    Stimmt - ich erinnerte den Block an anderer Stelle. Hab noch mal nach gesehen, Try/Catch sitzt innerhalb des Foreach-Loops und springt daher nicht raus, my bad.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!