[valumsFileUploader] Mehrfachupload ohne Flash

[coolflame]

hallo,

ich habe im prinzip die selben probleme wie messa und einige andere: der upload erfolgt, nach 100% schlägt das ganze aber fehl. gibt man in meinem formular jedoch das captcha ein und versendet das formular, funktioniert der email-versand und der darin enthaltene link. muss ich das verstehen!? mach ich was falsch?

in der htaccess habe ich übrigens

php_value upload_max_filesize 500M
php_value max_execution_time  1200

SetEnv TMPDIR /is/htdocs/user_tmp/wpxxxxx_yyyyy/

eingetragen, trotzdem werden daten über 120mb verweigert. in den contao-einstellungen sind die werte jedoch angepasst. liegt vllt hier der fehler?

HINWEIS AN HOST EUROPE-NUTZER: den eintrag 'Tmp-Pfad' findet ihr in den allgemeinen informationen eures webpacks (administration > webhosting > allgemeines > allgemeine informationen).

nachtrag: im system-log wird der upload als 'successfull' geführt. wird das formular nicht abgeschickt erfolgt kein eintrag ob erfolgreich oder nicht. die datei findet sich aber im system/tmp-verzeichnis wieder ...

nachtrag 2: mit den zusätzlichen htaccess-einträgen

php_value post_max_size 500M
php_value max_input_time 1200

konnte ich mittlerweile erreichen, dass ich dateien bis 120mb hochladen kann ohne fehlerhinweis ...

[david enke]

Hallo Zusammen,

ich wurde bei meiner Suche nun einfach nicht schlauer, ein grobes Debuggen der Erweiterung führte auch zu keinem Ergebnis.
Verwendet wird Version 3.10 stable build 10 mit Contao 2.11.6, der contao-check gibt grünes Licht (kein .phar, kein SMH nötig), PHP Version 5.2.17, tmpfile() ist vorhanden - alles funktioniert einwandfrei.
Filetypes, Uploadsize und -menge sind global und im FFL überdimensioniert gesetzt (versuchte es in allen Varianten).

Der Upload im Frontend funktioniert problemlos, die Json-Rückmeldungen geben okay.
Allerdings finde ich die Dateien im tmp-Ordner vor, es wird nicht ins Zielverzeichnis verschoben (Mein Zielverzeichnis ist btw. nicht der tl_files, ist in tl_settings geändert).

Versucht habe ich es mit/ohne Zielverzeichnis und mit/ohne Benutzerordner in allen Kombinationen - was alles nicht zum gewünschten Erfolg führte.


Ist das Problem bekannt, woran kann es liegen?

[david enke]

Hallo Zusammen,

ich wurde bei meiner Suche nun einfach nicht schlauer, ein grobes Debuggen der Erweiterung führte auch zu keinem Ergebnis.
Verwendet wird Version 3.10 stable build 10 mit Contao 2.11.6, der contao-check gibt grünes Licht (kein .phar, kein SMH nötig), PHP Version 5.2.17, tmpfile() ist vorhanden - alles funktioniert einwandfrei.
Filetypes, Uploadsize und -menge sind global und im FFL überdimensioniert gesetzt (versuchte es in allen Varianten).

Der Upload im Frontend funktioniert problemlos, die Json-Rückmeldungen geben okay.
Allerdings finde ich die Dateien im tmp-Ordner vor, es wird nicht ins Zielverzeichnis verschoben (Mein Zielverzeichnis ist btw. nicht der tl_files, ist in tl_settings geändert).

Versucht habe ich es mit/ohne Zielverzeichnis und mit/ohne Benutzerordner in allen Kombinationen - was alles nicht zum gewünschten Erfolg führte.


Ist das Problem bekannt, woran kann es liegen?

Mittlerweile bei Version 2.11.9 und valumsFileUploader 3.1.0#13. Bin ich denn der Einzige mit diesem Problem?

[d23]

Hab den Uploader unter 2.11.7 im Einsatz, Environment erfüllt alle Voraussetzungen, SMH nicht nötig, alles andere passt auch.

Der interessante Effekt besteht nun darin, dass der Uploader (BE) in FF unter OS X tadellos funktioniert, unter Windows 7 jedoch mit einem kläglichen "Fehlgeschlagen" endet.
Woran kann das denn bitte liegen?

[darth_saschi]

Ich habs grade auf unserem Entwicklungsserver ausprobiert - 200MB waren kein Problem. Aber pauschal kann ich das einfach nicht sagen da der Server das können muss. Der Extension ist es erstmal wurscht wie groß die Datei ist.

Schau einfach mal nach folgenden Werten:

* Maximum execution time
* Memory limit
* File uploads
* Upload maximum filesize

Die 4 Werte in der php.ini sind letztendlich entscheidend wieviel du wirklich hochladen darfst.

Hallo zusammen.

Erstmal: Klasse Erweiterung , bei der ich mich freuen würde, wenn ich sie richtig zum Laufen bringen würde

Vielleicht könnt Ihr mir helfen, ich versuche schon lange auf meinem Strato-Server dicke Downloads oder Uploads zum Laufen zu bringen. Ich würde gerne diese Werte einstellen, aber es gelingt mir nicht. Ich kann zwar eine php.ini anlegen, aber ich weiss nicht wo sie hin muss. Laut Strato muss die ini dort liegen, wo das Script liegt. Wenn ich eine im Root mit testweise upload_maximum_filesize = 1M anlege, dann kann trotzdem fröhlich 16 mb hochladen - aber was auch immer ich anstelle, nach einer gewissen Zeit schlägt der Upload fehl. Ich glaube es liegt an der Zeit, denn ich kann im Büro mit einer wesentlich schnelleren Anbindung deutlich grössere Dateien hochladen als zuhause - und das obwohl standardmässig die max execution time bei Strato bei 0 liegen soll.

Ich versuche gerade testweise per php.ini den upload_maximum_filesize = 1M auch zum Greifen zu bringen, aber ohne Erfolg.

Ich habe die php.ini mittlerweile in folgende Verzeichnisse gelegt:
/system/modules/valumsFileUploader/html/js/
/system/modules/valumsFileUploader/
/plugins/ajax-upload/js/
/system/scripts/
/contao/
/
sogar ins Server-Root

Nichts. Ich kann immer mehr als 1 MB hochladen... - ...aber über 30 MB schmierts ab mit "Fehlgeschlagen"...

Kann mir hier jemand helfen ?

Vielen Dank.

Sascha

[isa]

Hallo zusammen,
ich finde keinen richtigen Zugang zu dieser Erweiterung, auch nicht durch Lesen der Beiträg hier.
Ich möchte: Mehrfachuploads im Backend nutzen und
die Möglichkeit, Dateien (auch Bilder) über das Frontend direkt in einen Artikel oder Textitem zu laden.
Redakteure sollen die Möglichkeit haben Bilder und Dateien über das FE direkt in Artitkel oder Textitems zu laden.
Gibt es irgendwo eine Anleitung? Oder habt ihr Tipps?

Vielen Dank und viele Grüße!
Isabelle

Habe hier die Lösung gefunden: http://de.contaowiki.org/ValumsFileUploader

[florianb]

Hallo zusammen,

ich benutze seit einiger zeit den uploader und bin wirklich begeistert von der erweiterung. herzlichen dank an das entwicklertem dafür. Ich habe keine technischen fragen mehr, da alles reibungslos funktioniert.
Nachbdem es mir gelungen ist über css den uolad button und die abbrechen schaltfläche zu gestaöten, stosse ich bei bei der uload-drop-area bzw. uload-drop-area-active, und der größe des uploadfeldes und der größe und farbe der schrift dort wie auch bei dem abbrechen button (ich würde abbrechen gerne kleinschreiben) an meine genzen. Wo werden diese elemente in ihrem aussehen gesteuert? Auch das löschen-kreuz würde ich geren gegen eine butten mit "löschen" austauschen. In FE Html steht <a class="qq-upload-delete" onclick="return false;" href="#">x </a> wo finde ich X?
Kann mir jemend erklären wie die elemente des ValumsFileUploader angesteuert werden (Grafik und Inhalt) in der css habe ich nicht die entsprechenden einträge gefunden.

Liebe Grüße florianb

[Nikolas]

Hallo,

ist eine Version für Contao 3(.1) geplant?
Wenn ja gibt es schon einen Zeitplan?

Gruß
Nikolas

[andreasisaak]

Nein bisher ist nix geplant in diese Richtung.

[operatorone]

Schade, es ist nämlich eine ziemlich coole Erweiterung die seines Gleichen sucht.

[dillscher]

Hallo zusammen,

habe das gleiche Problem wie bereits einige Posts weiter oben von david enke beschrieben. Auch bei mir (Contao 2.11.11, valums 3.1.15 auf einer lokalen OSX/MAMP) bleiben die Uploads in /tmp liegen, obwohl ein Zielverzeichnis angegeben wurde. 777 für das Zielverzeichnis wurde bereits gesetzt.

Gibt es dafür eine Erklärung/Lösung?

Grüße,

Christian

[soweit_ok]

Tja und ich nun auch, mit meiner zur Zeit noch "alten" 2.9.5-Installation. Das vielfach beschriebene FE-Problem, dass der Upload an sich super funktioniert, aber die Formular-Settings anscheinend garnicht verarbeitet werden (auch nicht nach Absenden des Formulars mit dem Submit-Button) und die in system/tmp gelandeten Dateien nicht verschoben werden. Das kann eigentlich nur ein Bug sein, denn ich hab wie alle anderen User alles mögliche probiert, getestet und gecheckt. Diese Fehl- oder besser Teil-Nichtfunktion zieht sich anscheinend durch so ziemlich alle Contao-Versionen. Es ist auch egal, ob man "Benutzerverzeichnis verwenden" wählt oder einen festen Pfad ancheckt oder beides, das Ergebnis ist dasselbe. Das Formular in der DB speichern, hab noch nicht probiert, soll den Aussagen der anderen nach wohl auch nicht gehen. Was die Sache noch ein bisschen verschärft, sonst könnte man halt mittels eines kleinen Jobs mit Hilfe einer DB-Abfrage relativ einfach erstmal ein Workaround stricken.

Ist denn mittlerweile bekannt, wo in der Extension das wahrscheinlich verursacht wird? Oder anders gefragt, wird denn noch daran gearbeitet und kann man in absehbarer Zeit auf eine Lösung hoffen? Ist kein Mecker, nur nach der langen Zeit, die dieses wohlbekannte Problem nicht behoben werden konnte, drängt sich die Frage nunmal auf, ob das noch eine Chance hat. Tja und im günstigen Fall, wird 2.9.x wohl beim Bugfixing nicht mehr unterstützt, schätze ich, es sei denn, die Lösung wäre zufällig generisch für alle Contaoversionen. Wäre ggf. Unterstützung der 2.11 noch angesagt? Ich kann noch nicht auf 3.x hochziehen, unmöglich.

Es ist aber auch echt ne Krux, Fancy macht garnichts im FE und tut nur so, lässt sich nichtmal mit Starten einer neuen Session überreden. Und die totale Härte ist der eigentlich simple Standard-SingleUpload im Formular in Verbindung mit xtmembers. Funktioniert einwandfrei, bloß sind hinterher zuverlässig die Tabellen tl_member und tl_member_pages im Eimer. Bei ersterer ist das Blob-Feld mit den Zuordnungen der Mitgliedsseiten in den Datensätzen des angemeldeten Mitglieds zerstört und in tl_memberpages sind der Content nebst zwei anderer Felder komplett leergeräumt. Tja, und das filebrowser-Plugin für den Tiny, das ansonsten bestens funktioniert, da klappt der Upload nur im IE, aber nicht in Webkit- u. Mozillabrowsern. Aus demselben Grund wie beim Fancy, das Flash-Browserplugin läuft eben mit Upload einfach nicht. Das war´s, mehr Alternativen gibts nicht. Der Valuumsfileuploader, den ich an sich klasse finde, wäre im FE die perfekte Ergänzung für Nicht-IE-Besucher. Angesichts der vorstehenden Probleme bin ich ja schonmal garnicht unzufrieden, dass er ohne Zerstörungswerk überhaupt zuverlässig hochzuladen scheint. Egal in welchen Ordner. Notfalls verschiebe ich die Dateien mit einem nach dem Upload startenden Extrascript. Aber hey, das ist der einzige eigentlich grundsolide Uploader für das Contao-FE. Mit dem Flashproblem, das wird doch nix mehr.

Also dann, ich hoffe das Beste.

[dillscher]

Hallo nochmal,

habe mich heute nochmals ausführlicher mit dem Uploader befasst und festgestellt, dass der Hauptgrund, warum er nach tmp lud, aber nicht mehr weiter, darin bestand, dass er mit einer von Hand für das Formular vergebenen ID nichts anfangen konnte. Der Uploader übergibt im Hintergrund leider nicht die tatsächlich vergebene FormID als $strFormId. Er erhält also einen leeren String. Darauf wird überprüft und falls nicht vorhanden, wird die formId automatisch generiert. Dies stimmt dann allerdings nicht mehr mit der tatsächlichen ID überein, ist also ein Fehler und dann wird nicht weiter ausgeführt. Schon gar nicht, wenn man, wie bei mir, noch einen processFormData-Hook im Hintergrund das Formular weiter verarbeiten lassen will.

Vielleicht hilft diese Erkenntnis ja auch an anderer Stelle.

Viele Grüße,

dillscher

[soweit_ok]

... habe mich heute nochmals ausführlicher mit dem Uploader befasst und festgestellt, dass der Hauptgrund, warum er nach tmp lud, aber nicht mehr weiter, darin bestand, dass er mit einer von Hand für das Formular vergebenen ID nichts anfangen konnte. Der Uploader übergibt im Hintergrund leider nicht die tatsächlich vergebene FormID als $strFormId. Er erhält also einen leeren String. ...

Hallo Dillscher,

interessante Entdeckung. Hast Du vielleicht auch einen Patch? Ich muss zugeben, die anschließende Folgeverarbeitung noch nicht so recht zu durchblicken und hab momentan leider auch nicht die Zeit, den Code komplett aufzudröseln.

Wie auch immer, aber ich hab vorhin einen ganz einfachen Patch für das Problem gefunden und erfolgreich getestet. Das brutale Zurechtstutzen der Erweiterung ist zwar nicht gerade die eleganteste Methode, aber so funktioniert jetzt bei mir alles wie es soll. Na ja, ich brauch die nachträglich Verschiebe-Mimik wohl zwecks irgendwelcher Dateiprüfungen auch garnicht, denn ich lasse für FE-Mitglieder eh nur Fotos zum Hochladen in ihren Ordner zu, vielleicht auch irgendwann noch PDF. Benötige die Valums-Extension außerdem nur als alternativen Notnagel, weil ich das sehr schöne filebrowser-Plugin in den TinyMCE einband. Tut alles bestens und zuverlässig, nur wie Fancy den flashbasierten Upload lediglich im IE.

Der Patch:

Im Ordner system/modules in der Datei valumsFileUploader.php die Zeile 180

'uploadFolder' => 'system/tmp',

ersetzen durch

'uploadFolder' => $this->uploadFolder,

Das Komma am Zeilenende nicht vergessen! :-) Das ist alles. So werden nun die Dateien sofort in den filemount des FE-Mitglieds hochgeladen und nicht erst nach system/tmp. Den Submitbutton sollte man natürlich aus dem Formular entfernen. Die Formularverarbeitung funktioniert ja sowieso nicht, und der Upload unabhängig davon. Ohne Submit-Button sind dann wenigstens auch mögliche Randerscheinungen der ins Leere laufenden Formularverarbeitung ausgeschlossen. Dass das Formular so nicht abgeschickt wird, macht ja wohl nichts, oder?

-------------------------------

Sorry, das war nicht ganz richtig. "uploadFolder" enthält nicht unbedingt den richtigen Pfad. Hab ich zunächst nicht gemerkt, weil ich beim Testen stets mit demselben FE-Login angemeldet war. Man muss den Pfad selber zusammenbauen, wofür ich das Inserttag verwende. Dann klappt der korrekte Upload. Ich habe aber noch nicht das Problem dabei gelöst, dass die Extension die Dateien für die Erfolgsanzeige und das Lösch-Icon anscheinend irgendwoanders sucht und dann trotz erfolreichem Hochladen die "Fehlgeschlagen"-Meldung bringt. Hab die Stelle noch nicht gefunden, wo genau das passiert. Ist ein bisschen kniffelig.

[dillscher]

Einen Patch kann ich Dir dazu nicht wirklich anbieten, einzig die Anmerkung, dass ich tatsächlich auf eine ID für das Formular dann doch verzichtet habe (siehe Experteneinstellungen rechts neben dem CSS).

Mein Formular selbst wird dann sauber verarbeitet und kommt auch inkl. aller notwendigen Felder und Files im Hook an, den ich nutze, um das Formular auf meine eigene Weise zu verarbeiten.

Gut möglich, dass wir also trotzdem nicht an der gleichen Baustelle unterwegs waren ;-).

[okapi]

Schade, es ist nämlich eine ziemlich coole Erweiterung die seines Gleichen sucht.

Ich finde es auch super schade, aber ich verstehe leider auch den Entwickler.

Ich verstehe nicht, warum eine solch wichtige Funktion nicht von Haus aus in Contao inkludiert ist. Ein Batch-Upload von Dateien ohne Timeouts und beschädigten Dateien wegen abgebrochenem Upload ist Bestandteil von vielen aktuellen CMS. Ich verstehe nicht, warum dies mittels Erweiterungen von Entwicklern, die auf Goodwill-Basis arbeiten und eigentlich keine Zeit haben, realisiert werden muß, wobei jede neue Contao Version neue Probleme erzeugt.

Contao bringt so viel mehr als jedes andere Open Source CMS von Haus aus mit, aber just beim Uploader steht das System etwa auf dem Stand von 2003.

(Im Übrigen finde ich - ich weiß, es gehört nicht hierher - Entwickler sollten ihre Erweiterungen auch kommerziell anbieten können. Der Marketplace von Concrete5 ist ein gutes Beispiel dafür, und er funktioniert wunderbar).

Gruß
Michael

[andreasisaak]

(Im Übrigen finde ich - ich weiß, es gehört nicht hierher - Entwickler sollten ihre Erweiterungen auch kommerziell anbieten können. Der Marketplace von Concrete5 ist ein gutes Beispiel dafür, und er funktioniert wunderbar).

Ja das ist wirklich schade. So einen Shop würde ich mir wünschen. Derzeit bauen wir sowas in Eigenregie nur für unsere Extensions

[okapi]

Ja das ist wirklich schade. So einen Shop würde ich mir wünschen. Derzeit bauen wir sowas in Eigenregie nur für unsere Extensions

Finde ich toll! Meine volle Zustimmung. Vielleicht macht das ja einmal Schule und es gibt eines Tages auch für Contao eine Art Marktplatz mit einer ausgewogenen Mischung aus kostenlosen und zu erwerbenden Erweiterungen. Bei Concrete5 beobachte ich dieses System (und auch die Diskussionen darüber) schon seit Jahren, und ich kann nur Gutes davon berichten.

[arcturus]

Hallöle,

ich habe das Problem bereits unter Nach Installation einer Extension funktioniert nichts mehr! geschildert und wurde dann von einem User auf dieses Unterforum verwiesen.

Ich habe den valumsFileUploader unter Contao 3.1.0. installieren wollen und zuerst lief garnichts mehr. Nach Löschen der Datei system/drivers/DC_Upload.php und des Ordners system/modules/valumsFileUploader war zumindest die Seite wieder verfügbar.

Leider komme ich bislang noch nicht ins Backend. Folgende Warnung wird beim Aufruf der LogIn-Seite ausgegeben:

Warning: in_array() expects parameter 2 to be array, null given in system/modules/core/library/Contao/System.php on line 110

#0 [internal function]: __error(2, 'in_array() expe...', '/mnt/webd/c0/17...', 110, Array)
#1 system/modules/core/library/Contao/System.php(110): in_array('getInstance', NULL)
#2 system/modules/core/classes/BackendTemplate.php(44): Contao\System->import('ValumsHelper')
#3 system/modules/core/classes/BackendTemplate.php(146): Contao\BackendTemplate->parse()
#4 contao/index.php(115): Contao\BackendTemplate->output()
#5 contao/index.php(124): Index->run()
#6 {main}

Fatal error: Class 'ValumsHelper' not found in /xxxxx/system/modules/core/library/Contao/System.php on line 110

Woran kann das liegen und wie kann ich das beheben?

Viele Grüße und danke,

Franz

[valentin_]

Hallo, ich versuche gerade den Uploader im Backend einzusetzen. Nach dem Upload erscheint immer: "Das Uploadverzeichnis ist nicht beschreibbar."
SMH ist aktiviert (überprüft mit smhcheck), Verzeichnis ist beschreibbar. Aktuelle Version vom Repository installiert.

Contao 2.11.11

Danke lg

[valentin_]

Zu meinem vorherigen Post:

Funktioniert anscheinend doch. Jedoch müssen die Rechte vom Ordner auf 777 gesetzt werden. Wenn ich aber im Backend einen neuen Ordner erstelle hat dieser 755 und der Upload ist nicht möglich, außer man stellt zuvor über FTP die Rechte um.

Kann ich dem Ordner beim erstellen automatisch 777 geben oder was macht man am Besten?

lg

[mcgruenigen]

Hallo, standardmässig werden hochgeladene Dateien in der Formulardaten-Mail verlinkt. Gibt es die Möglichkeit, die Dateien direkt an die Mail anzuhängen? Ich bilde mir ein, dass das mit einer ganz frühen Version schon mal funktioniert hat.

[andreasisaak]

Nein das geht nur mit der Extension "mfa"

[fatcrobat]

Hallo,

ich habe den fileuploader in ein FE Formular eingebunden und die Option "Hochgeladene Dateien speichern" gewählt und ein entsprechendes Verzeichnis angegeben.
Vorweg, die Dateirechte sind korrekt gesetzt und ich setze den EFG ein.

Anscheinend schlägt die Überprüfung in ValumnsFileUploader::validateFormField(271) :

if ($this->lastFf['id'] == $objWidget->id && !$this->hasError) 

fehl, denn $this->lastFf['id'] ist schlichtweg leer.

Trifft der Fehler nur bei mir auf?

[mcgruenigen]

Nein das geht nur mit der Extension "mfa"

Danke Andreas. Mit mfa scheint das wunderbar zu funktionieren, allerdings tauchen bei eingeschaltetem mfa in der Mail zusätzlich die Felder FORM_SUBMIT:, REQUEST_TOKEN:, MAX_FILE_SIZE: und noch zwei weitere, kryptische auf. Ist das normal? Lässt sich das abschalten?

[heimo_]

Hallo,

Die Extension ist wirklich praktisch ich hätte noch Vorschläge falls Sie lust haben diese einzubauen:
- Automatisches erstellen des Uploadfolders bzw. des Trees
- Mehrere Instanzen pro Seite

Mit freundlichen Grüßen

[Sascha]

Hallo Andreas,

ist eine Version für Contao 3.2.+ geplant?

vg

sascha

[andreasisaak]

Wenn es nach mir geht - definitiv nicht mit dieser Codebase.

[cubano]

Ich hatte Probleme mit Dateien ab ein paar MB.
Folgender Eintrag in der htaccess hat nun mein Problem gelöst:

<Files ajax.php>
SecFilterEngine Off
</Files>

[andrea$]

Hallo,

ein Freund hat mich darauf aufmerksam gemacht, das er keine Dateien hochladen kann. Ich habe mir das angeschaut u. es stimmt. Es wird ein Button angezeigt "Dateien hochladen und zurück". Klickt man darauf kommt man wieder zur Übersicht aber man kann keine Dateien hochladen. Es wird kein Fenster dafür angezeigt. Kann mich nicht mehr so genau erinnern wie das mit VU aussah?

Es gibt im Systemlog keine Fehlermeldung!

slideItMooFramework 1.0.2 stable
VU 3.1.0 stable 16
Cto 2.11.12

[heimo_]

Hallo toto,

hab genau das gleiche Problem mit dem Datei-Upload in den verschiedenen Browsern -
es ist komplett egal, wie groß/klein die Datei ist - in IE (Win) und Opera (Mac) erscheint
immer die Fehlermeldung "Fehlgeschlagen".

Der Kunde möchte auch nach Empfehlung der alternativen Browser ausschließlich IE (Win) verwenden ...

WINDOWS
Firefox 8.0.1 --> OK
Chrome, 19.0 --> OK
Internet Explorer, 9.0 --> FEHLGESCHLAGEN!


MAC
Firefox, 12.0 --> OK
Chrome, 19.0 --> OK
Safari 5.0.5 --> OK
Opera, 11.61 --> FEHLGESCHLAGEN!

--> Handelt es sich hier um einen Bug oder ...
--> Sind spezielle Einstellungen in den jeweiligen Browsern notwendig?

Danke für Eure Hilfe!!!

Simone.

Gibt es dazu bereits eine Lösung?

[mcgruenigen]

Hallo Andreas, nochmals zur Erweiterung mfa: wenn ich die Erweiterung aktiviere, wird die Einstellung "leere Felder auslassen" anscheinend ignoriert, die Bestätigungsmail enthält dann einen Haufen leerer Felder und zusätzlich Angaben wie FORM_SUBMIT, MAX_FILE_SIZE und REQUEST_TOKEN. (Contao 2.11.16, aktuellste Versionen von mfa & valumsFU).
Eine Idee wie ich das beheben könnte? Danke!

[andreasisaak]

Ja der Bug ist bereits behoben. Über Composer oder Github direkt bekommst du die neue Version