[TYPO3-UG Oesterreich] TER Update Fehler

Fri Apr 26 20:08:30 CEST 2013

Hallo Markus,

magst du nicht gleich einen Bugreport im forge machen?

Kommentar zu mbstring:
Ja mbstring wird default werden. Wurde auch innerhalb der Core Devs diskutiert. Bin mir nur grade nicht sicher ob für 6.1 oder 6.2.
Die unperformante "Rad-Neuerfindung" wird "geschrottet", denn mbstring ist seit einiger Zeit ja bereits ein required php modul.

Lg Markus

> -----Original Message-----
> From: typo3-at-bounces at lists.typo3.org [mailto:typo3-at-
> bounces at lists.typo3.org] On Behalf Of Markus Kappe
> Sent: Friday, April 26, 2013 7:41 PM
> To: typo3-at at lists.typo3.org
> Subject: [TYPO3-UG Oesterreich] TER Update Fehler
> 
> Liebe TUGA Mitglieder,
> 
> unter bestimmten Voraussetzungen hört der Spinner sich nicht auf zu
> drehen, wenn man die Extension Liste aktualisieren will. TYPO3 6.0.x
> 
> Wurde schon gemeldet unter http://forge.typo3.org/issues/43539 aber dann
> aufgrund von Nicht-Nachvollziehbarkeit wieder geschlossen.
> 
> Man untersucht den Ajax Call und sieht die Fehlermeldung Fatal error:
> Maximum execution time of 30 seconds exceeded in /xxx/typo3_src-
> 6.0.4/typo3/sysext/core/Classes/Charset/CharsetConverter.php
> on line 2090
> 
> Das heißt, das Error Handling versagt hier. Der User bekommt kein Feedback.
> 
> Zum Fehler: Ich habe herausgefunden, dass eine Query fehlschlägt (Insert in
> die Datenbank der importierten Extension-Details). Das hat 2 Auswirkungen:
> 1) Das Debugging wird ausgelöst, wenn es entsprechend konfiguriert ist
> (devIpMask, sqlErrors, etc.). Das führt zum Timeout. Das erklärt, warum
> manche das Problem haben und andere nicht.
> 
> 2) Die Extensions aus dem aktuell bearbeiteten Batch (50 an der Zahl)
> werden nicht in die Datenbank eingefügt.
> 
> Wie kommt es zum DB Fehler?
> Das Insert lautet ca so:
> INSERT INTO tx_extensionmanager_domain_model_extension
> (extension_key, version, integer_version, alldownloadcounter,
> downloadcounter, title, ownerusername, author_name, author_email,
> authorcompany, last_updated, md5hash, repository, state, review_state,
> category, description, serialized_dependencies, update_comment) VALUES
> ('qrcode', '1.0.0', 1000000, 155, 0, 'QR Code', 'b263', 'Bastian Braeu', '
> bb at bftmedia.de', '', 1361908312, '3a7f3e83cbddbd910163ef5eb26d5937', 1,
> 999, 0, plugin, 'Display QR codes as content elements, embed as
> Fluidtemplate, or use the view helper in your own extensions.',
> 'a:1:{s:7:\"depends\";a:3:{s:3:\"cms\";s:12:\"6.0.0-
> 6.0.99\";s:7:\"extbase\";s:12:\"6.0.0-6.0.99\";s:5:\"fluid\";s:12:\"6.0.0-
> 6.0.99\";}}',
> 'TYPO3 CMS 6.0');
> 
> Fehlermeldung: Unknown column 'plugin' in 'field list'
> 
> Was auffällt ist, dass das Wort "plugin" nicht escaped wurde. Ein Vergleich
> mit anderen Inserts zeigt, dass an der Stelle normalerweise eine Zahl steht.
> 
> Vergleich mit dem XML, welches in SQL umgesetzt wird: hier ist bei normal
> funktionierenden Datensätzen ein <category>plugin</category>. Bei einigen
> wenigen falschen Datensätzen steht an der Stelle ein
> <category>3</category> o.ä.
> 
> D.h. 1) sind die Ausgangsdaten falsch und 2) werden falsche Daten nicht
> ausreichend abgefangen.
> 
> Zurück zum Fehler bei der Debug Ausgabe: die Zeit wird aufgebraucht in
> TYPO3\CMS\Core\Encoder::encode() bei der Codierung der 21k großen
> Debug Ausgabe.
> Das encoden ist sehr unperformat geschrieben, es wird jedes Zeichen unter
> Berücksichtigung des Zeichensatzes (UTF-8) aus dem 21k String
> ausgeschnitten und separat encoded bevor es wieder zusammengesetzt
> wird.
> Nach ca. 7k Zeichen auf diese Art encoded gibt mein Server auf - es sind 55
> Sekunden vergangen (ca. 8 davon außerhalb des Encodings).
> 
> Es gibt einen einfachen
> Workaround: $GLOBALS['TYPO3_CONF_VARS']['SYS']['t3lib_cs_utils'] muss
> auf mbstring gesetzt werden. iconv hat nicht funktioniert bei meinem Test
> (timeout).
> 
> Leider löst das nur einen Teil des Problems, denn die Debug Ausgabe (die
> nun funktioniert) invalidiert den JSON Output des Ajax Calls. Hier muss
> eindeutig noch ein Bugfix her.
> 
> Ein anderer Workaround ist, das Debugging abzudrehen. Dann sollte das mit
> dem Spinner funktionieren. Leider werden dabei trotzdem einige Extensions
> nicht importiert (es werden immer 50 gleichzeitig in die DB geschrieben und
> wenn ein Datensatz kaputt ist, fehlen anschließend die anderen 49)
> 
> Gut, wieder etwas gelernt: die Zeichensatz-Operationen müssen auf
> mbstring konfiguriert werden damit TYPO3 vernünftig läuft (zumindest
> bestimmte Aspekte von TYPO3). Meiner Meinung nach sollte mbstring die
> Default Einstellung sein und die anderen Varianten nur als Fallback dienen.
> Entweder hart codierte Fallbacks (so dass man gar nichts mehr konfigurieren
> braucht - automatische Erkennung) oder mbstring wird Default bei einer
> Neuinstallation und per Check im Install Tool (oder Reports) wird überprüft
> ob das Modul verfügbar ist - Möglichkeit umzukonfigurieren.
> 
> 
> Was muss jetzt noch gemacht wereden, damit das Problem behoben ist?
> 
> Patch 1: Fehlermeldung beim Spinner, wenn der TER Import ein Problem hat
> (d.h. kein gültiges JSON zurückkommt) Patch 2: mbstring als Default
> verankern.
> Patch 3: Datenkorrektur der "category 3"
> Patch 4: Datenvalidierung bevor das Insert ausgeführt wird  // siehe
> http://forge.typo3.org/issues/46115
> Patch 5: eventuell encode() performanter neu schreiben // siehe
> http://forge.typo3.org/issues/47124
> 
> So, ich habe jetzt viel Zeit mit der Fehlersuche verbracht und möchte
> freundlich anfragen, ob jemand so nett wäre und die Infos auf englisch
> übersetzen und Bug Reports machen würde.
> 
> Danke & LG
> Markus
> _______________________________________________
> TYPO3-at mailing list
> TYPO3-at at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-at