TYPO3 / Extbase: Frontend Editing Know-How

TYPO3 Frontend Editing

TYPO3 Frontend Editing

Dieser Artikel soll ein kleiner Sammelartikel rund um das Frontend Editing durch Frontend Benutzer bei TYPO3 werden. Ich werde diesen nach und nach erweitern und ändern und freue mich über alle Tipps zu diesem Thema.

Frontend Editing – Wieso, weshalb, warum?

TYPO3 bietet ein umfrangreiches Rechtesystem im Backend, mit dem Backend Benutzer(-Gruppen) sehr genau auf spezielle Aufgabengebiete eingeschränkt werden könnten. Hat man beispielsweise ein Kalendermodul in dem Benutzer ihre Termine pflegen können, so könnte man diesen auch jeweils einen Backend Benutzer erstellen und die Benutzer auffordern ihre Daten per Backend zu pflegen.

Dazu müsste man den Benutzern jedoch erstmal TYPO3 näher bringen und Ihnen erklären wie sie im Backend (welches sich grundsätzlich vom Frontend unterscheidet) Daten finden und editieren können. Zudem muss man aufpassen, dass die Benutzer wirklich nur Ihre Daten sehen und vor allem nichts sehen, was sie nicht sehen dürfen.
Möchte man wirklich auf Frontend Editing verzichten, so sollte man im Backend zumindest ein Backend Modul einrichten um den Benutzern die Bearbeitung zu erleichtern.

Die wesentlich schönere Methode ist hingegen das Frontend Editing. Hierbei bekommen die Nutzer nichts von dem zugrunde liegendem CMS mit und man erspart sich unnötige Fragen und Verwirrung.
Das Prinzip ist einfach: Im Frontend gibt es eine Registrierung, einen Loginbereich über den man in einen internen Bereich gelangt. Dort findet man auf Basis einer Extension Formulare um Datensätze (z.B. Termine) zu erstellen, zu bearbeiten oder zu löschen. Zusätzlich kann ein Freischaltprozess durch einen Administrator implementiert werden, welcher alle Änderungen zunächst sichtet und ggf. freigibt.

Seite mit Zugangsbeschränkung

Seite mit Zugangsbeschränkung

Die Frontend User

Die sog. „Frontend User“ sind schon lange ein Bestandteil von TYPO3. Diese lassen sich als Datensätze im Backend in einem Systemordner erstellen und einer Frontend Benutzergruppe zuweisen. Ein Plugin für den Login von Frontend Benutzern ist ebenfalls von Haus aus gegeben um die Benutzer anschließend auf eine Seite zu verweisen, in deren Seiteneinstellungen eingestellt ist, dass diese nur als eingeloggter Benutzer sichtbar ist.

Vieles ist also schon da und man sollte das Rad nicht neu erfinden. Es gibt zudem schon viele Erweiterung im TER mit denen Registrierungsformulare mit Opt-In, „Passwort ändern“-Funktionen oder generelle Formulare zur Änderung von persönlichen Daten geliefert werden. In letzter Zeit benutze ich zum Beispiel gerne die Erweiterung sf_register.

Anbindung von Frontend Usern an Extensions

Erstellt man eine Extension deren Datensätze (bleiben wir mal bei einem Kalender) nur durch angemeldete Benutzer erstellt und bearbeitet werden können, so kann man relativ leicht auf die TYPO3 FE-User zurückgreifen.

Hierbei sollte man sich direkt bei der Extension-Erstellung sicher darüber sein, ob man die Frontend User ebenfalls um Attribute / Funktionen erweitern muss oder nicht. Bei unserem Beispielkalender ist lediglich die Zuordnung von einem Termin zu einem Benutzer wichtig – Änderungen am Frontend Benutzer gibt es nicht.

FE-User Variante 1

FE-User Variante 1

Variante 1 – Keine Erweiterung der Frontend User notwendig

Bei dieser Variante braucht man nichts weiter zu tun als von seinen Datensätze eine Relation auf fe_users aufzubauen. Dies erfolgt einfach im Model und auch im TCA. Im Extension Builder erstellt man hierzu einfach ein Relationsfeld und mappt dieses auf das Model der Frontend User (\TYPO3\CMS\Extbase\Domain\Model\FrontendUser) – den Rest erledigt der Extension Builder.

FE-User Variante 2

FE-User Variante 2

Variante 2 – Die Frontend User müssen erweitert werden

Sollen den Frontend Usern weitere Attribute hinzugefügt werden so muss man ein eigenes Model erstellen und dieses per Typoscript auf die Tabelle fe_users mappen.
Auch hier kann man sich vom Extension Builder eine Menge Arbeit abnehmen lassen. Man erstellt einfach ein Model welches FrontendUser erweitert.

In der ext_tables.php der Extension wird das TCA von fe_users nun um alle neuen Felder erweitert. Standardmäßig wird nun außerdem das Feld „tx_extbase_type“ hinzugezogen. Dieses Feld hat den Sinn, dass man bei FrontendUsern explizit sagen kann von welchem Typ dieser ist nun nur dann die zusätzlichen Felder im Backend sehen kann.
Nutzt man „tx_extbase_type“ kann man mit dem eigenen Repository von (z.B. MeineUserRepository) auch nur auf Datensätze mit dem richtigen „tx_extbase_type“ zugreifen. Diese Einstellung erfolgt ebenfalls über Typoscript über die Anweisung „recordType“. Einen ausführlichen Beitrag zu dieser Variante findet ihr bei Torben Hansen »

Man muss „tx_extbase_type“ nicht benutzen und kann diese Einstellungen aus den durch den Extension Builder erstellten Dateien wieder entfernen und sämtliche Felder dauerhaft im Backend sichtbar machen.

Um am Ende auf die neuen Attribute zugreifen zu können ist in erster Linie das eigene Model wichtig, welches das FrontendUser Model erweitert. Nutzt man den „Extbase Type“ nicht, so benötigt man auch kein eigenes Repository und kann einfach das FrontendUserRepository für Abfragen verwenden.

Achtung Extension Reihenfolge:
Stößt man bei der Erweiterung von fe_users auf das Problem, dass die neuen Felder im TCA nicht hinzugefügt werden, so könnte dies an der Reihenfolge liegen, in der das TCA aufgebaut wird. Abhilfe schafft hierbei die ext_emconf.php unter „depends“. Dort sollte man stets die Erweiterungen eingetragen, die vor eurer eigenen Extension geladen sein sollten.

Das Frontend Editing beginnt

Nachdem man nun eine Extension mit Datensätzen hat, die eine Relation zu FrontendUsern haben kann das Frontend Editing endlich losgehen. In unserer beispielhaften Kalender Erweiterung gibt es verschiedene Actions zur Erstellung und Bearbeitung von Datensätzen: new, create, edit, update und delete.

Damit ein Benutzer nur seine eigenen Datensätze bearbeiten kann ist der Login eine Pflicht. Die Plugins der Erweiterung werden also nur auf Seiten eingesetzt, die nur für eingeloggte Benutzer sichtbar sind.

Wenn ein Benutzer nun seinen ersten Termin erstellt können wir davon ausgehen, dass die Person eingeloggt ist. Um dem neuen Termin nun also seinen Besitzer zuzuordnen können wir uns einfach den momentan eingeloggten Benutzer aus dem Repository holen und an den Termin binden (in der createAction):

.....

$feUserRepository = $this->objectManager->get("TYPO3\CMS\Extbase\Domain\Repository\FrontendUserRepository");
$user = $feUserRepository->findByUid($GLOBALS['TSFE']->fe_user->user['uid']);
$newTermin->setFeUser($user);

.....

Damit auf einer möglichen Übersichtsseite der Benutzer nun auch wirklich nur seine Termine sehen kann, reicht ein einfache Bedingung beim holen der Datensätze aus dem Repository (in der listAction):

$termine = $this->terminRepository->findByFeUser($GLOBALS['TSFE']->fe_user->user['uid']);

Achtet auf die richtige Bezeichnung der findByX Funktion: Heißt das Feld für den Frontend Benutzer in eurer Extension z.B. „Admin“ so muss der Aufruf findByAdmin() heißen.

Achtung beim Caching!
Listen mit benutzergebundenen Daten sollten nur mit Vorsicht gecached werden! Der nächste Benutzter könnte sonst fälschlicherweise die Datensätze seines Vorgängers auf dieser Seite sehen. Deaktiviert das Caching für solche Ansichten also für jedes Plugin in der ext_localconf.php oder implementiert euren eigenen Caching-Mechanismus.

Sicherheit / Access Checks

Der Extension Builder fügt beim Erstellen einer Extension mit einer update / delete Action bereits einen Hinweis ein, den man unbedingt beachten sollte:

The object was updated. Please be aware that this action is publicly accessible unless you implement an access check.

Was bedeutet dieser Hinweis?
Selbst wenn eure Benutzer in ihrer Listenansicht nur Links zum Bearbeiten und Löschen ihrer eigenen Datensätze sehen, bedeutet das nicht, dass die Datensätze anderer Benutzer nicht erreicht werden können. Hierzu müsste man lediglich die ID des Datensatzes in der URL gegen eine beliebige andere ID ersetzen.
Deshalb muss bei der Aktualisierung und beim Löschen von Datensätzen unbedingt geprüft werden, ob der Benutzer auch berechtigt ist diesen Datensatz zu bearbeiten! Beispiel:

if($GLOBALS['TSFE']->fe_user->user['uid']===$termin->getFeUser()->getUid()) {
 ....
}

Oder um auf eine Benutzergruppe zu prüfen:

if(is_array($GLOBALS['TSFE']->fe_user->groupData['uid']) && in_array(###ID DER BERECHTIGTEN BENUTZERGRUPPE###, $GLOBALS['TSFE']->fe_user->groupData['uid'])) {
     ....
}

Im Frontend stellt Fluid ebenfalls ViewHelper zur Verfügung um Elemente nur dann auszugeben, wenn ein Benutzer in einer bestimmten Benutzergruppe ist.

Freischaltungs-Prozesse

Um Missbrauch zu verhindern ist es oftmals sinnvoll, die von Frontend Usern eingetragenen Datensätze durch einen TYPO3 Redakteur prüfen zu lassen. Die Datensätze bleiben also solange für die Öffentlichkeit verborgen, bis diese freigeschaltet wurden. Hierzu kann bei der Erstellung / Bearbeitung von Datensätzen eine E-Mail an einen Redakteur versendet werden, der die Daten entweder im Backend oder in einem eigenständigen Frontend Bereich verwaltet und ggf. freigibt.

Bei solchen Prozessen möchte ich einfach nur empfehlen, beim temporären Verbergen von Datensätzen nicht das hidden Feld von TYPO3 zu nutzen. Dadurch würden die Datensätze zwar grundsätzlich erstmal verborgen bleiben, allerdings wird es dadurch immer komplizierter die Datensätze per Extbase noch nachträglich zu bearbeiten (z.B. wenn der Benutzer seinen noch nicht freigegebenen Termin nochmal bearbeiten möchte). Zwar kann man jedes Repository anweisen auch Hidden-Datensätze auszugeben, aber meiner Erfahrung nach wird es je nach komplexität der Erweiterung nur immer komplizierter.

Gebt den Models hierfür also lieber eigene Boolean-Hilfsfelder um solche Freischaltungs-Prozesse zu realisieren.

Frontend Upload mit dem File Abstraction Layer (FAL)

Bisher bietet TYPO3 leider noch keinen offiziellen ViewHelper um in Frontend Formularen Uploadfelder hinzuzufügen, welche automatisch den File Abstraction Layer nutzen. Eine wirklich vorbildliche Methode wie sowas zu realisieren ist, hat jedoch Helmut Hummel in einer Beispielextension veröffentlicht. Diese Extension sollte noch viel mehr verbreitet werden und ich bin auch leider nur durch Zufall darauf gestoßen.

Die Extension realisiert den Upload über TypeConverter und stellt ViewHelper zur Verfügung – vorbildlich!

Bei Fragen zur Implementierung dieser Methode bin ich euch auch gerne behiflich.

UPDATE (02.11.15):
In dem Kommentar von Klaus findet ihr eine andere Methode zur Implementierung über die Datamap Funktion des TYPO3 Datahandlers. Hier fehlt zwar noch eine Funktion zur Prüfung auf den Dateitypen und die Behandlung von entfernten Bildern, was sich jedoch schnell nachrüsten lassen sollte. Ich werde dazu sobald wie möglich nochmal genauer eingehen.

Achtung Enctype!
Immer wieder vergesse ich es und könnte mir selbst jedes Mal die Haare ausreissen! Wenn ihr euch wundert, warum beim Upload von Dateien keine Dateien im PHP _FILES ankommen, denkt daran im <form>-Tag dieses Attribut zu setzen: enctype=multipart/form-data

Texteditoren / RTE im Frontend

TYPO3 Frontend RTE

TYPO3 Frontend RTE

Natürlich möchte man seinen Benutzern auch im Frontend Texteditoren an die Hand geben. Meine Erfahrung in dieser Hinsicht ist erstmal: Den TYPO3 RTE im Frontend einzubinden ist die Arbeit nicht wert! Stattdessen kann man einfach jQuery Plugins benutzen um Textareas in Formularen mit WYSIWYG Editoren auszustatten. Man sollte allerdings bei der Ausgabe dieser Texte im Hinterkopf behalten, dass durch die TYPO3 parseFunc manche Tags dieser Plugins entfernt werden könnten, weil diese TYPO3 untypisch sind. Wenn man kann sollte man diese Editoren also simpel halten. Meine Empfehlung ist TinyMCE.

 

To Be Continued…

Ich werde diesen Artikel nachträglich immer wieder um neue Erkenntnisse und Best Practises erweitern. Für alle Tipps und Verbesserungsvorschläge bin ich dankbar und hoffe ihr nutzt die Kommentarfunktion ausgiebig.

Rechschleibfehlel suckel ick Montag.

28 Kommentare

  • Hi Paul,

    ich bin eigentlich durch Zufall hier gelandet, ursprünglich ging es um den Paginator mit Arrays, aber das ist ein anderes Thema.

    Nur so so als Hinweis … ich schätzte den Code „FAL Upload“ von Helmut sehr, ich hab das selber so seit den Anfangstagen von 6.2 gemacht. Allerdings wird heute – selbst in den TYPO3 core docs – die Datamap Funktion bevorzugt. Die Vorteile, kein gequäle von eigenen File References Models und eine saubere sanity Funktion. Siehe https://wiki.typo3.org/File_Abstraction_Layer#Add_file_reference. Etwas aufgebröselter habe ich es hier beschrieben: http://t3-developer.com/ext-programmierung/techniken-in-extensions/fal-dateiupload-im-frontend/ und die Funktion wuppt wirklich wie in den Core Docs beschrieben.

    Vielleicht kann man mal eine Mischung aus beidem machen 🙂
    Den ganzen Sicherheitsaspekt aus Helmuts Extensions gepaart mit der Datamap Funktion.

    Happy Halloween
    Klaus

    • Hey Klaus,

      vielen Dank für den Hinweis. Diese Methode sieht sehr schön aus. Ich werde das bei nächster Gelegenheit mal in Kombination mit manchen Aspekten von Helmut umsetzen… so fehlt ja zum Beispiel auch noch eine Behandlung von gelöschten Bildern, was jedoch nicht schwer zu implementieren sein sollte. Habe den Beitrag aktualisiert.

      Vielen Dank!

    • Hallo Klaus,

      esrtmal vielen Dank für die Anleitung! Immer schön, wenn Leute Ergebnisse zur Verfügung stellen für so Anfänger wie mich 🙂
      Leider bin ich allerdings beim Versuch das Ganze umzusetzen, auf ein paar Probleme gestoßen (Typo3 Version 6.2.18 bzw 6.2.19 ):

      Der Upload der Datei an sich funktioniert einwandfrei, allerdings tut er sich schwer mit dem Schreiben in der sys_file_reference.

      Zum einen wird zum Ausführen des Datamaps ein BE-User benötigt. Diese konnte ich aber dadurch lösen, dass ich einen bestehenden BE-User mit übergebe $tce->start($data, array(), $myBeUser);

      Mit der Zeile
      $data[$table][$newStorageUid] = array(‚image‘ => ‚NEW1234′); //this is needed, i dont know why 🙁 but not stored in tables
      warf bei mir dann die News-Extension einen fatal error. Allerdings konnte ich keinen Unterschied feststellen, ob die Zeile nun vorhanden ist oder nicht. Deswegen habe ich sie auskommentiert (spielte auch für den letzten Fehler keine Rolle, ob mit oder ohne).

      Weiterhin ist nun aber so, daß er beim ersten abschicken des Formulars für den Upload er im Protokoll folgende Warnung wirft:

      Attempt to insert record on page ’news fe‘ (16396) where this table, sys_file_reference, is not allowed (msg#1.1.11)

      Wenn ich den Cache leere (manuell im BE oder per $tce->clear_cacheCmd(’system‘); in der Funktion) und DANN das ganze noch mal mit F5 neu im Browser abschicke, schreibt er die Reference ganz ordnungsgemäß. Ohne Cache leeren schreibt es nie.

      Haben Sie da eine Erklärung für? Was kann ich tun?
      Vielen Dank im Voraus
      Stephanie

      • Hallo Stephanie,

        das man zum Ausführen des Datamaps einen Backend User benötigt ist mir neu und das werde ich die Tage mal probieren zu rekonstruieren. Create Actions in denen Datensätze erstellt werden sollten grundsätzlich nicht gecached werden… wenn es sich um eine Extbase Extension handelt kannst Du dies in der ext_localconf.php deiner Extension einstellen.

        Von welchem Seitentyp ist die Seite „news fe“?

        Damit der Klaus deinen Kommentar auch mit Sicherheit liest solltest Du diesen vielleicht auch nochmal unter http://t3-developer.com/ext-programmierung/techniken-in-extensions/fal-dateiupload-im-frontend/ posten 😉

  • Hallo Paul,

     

    vielen Dank für die schnelle Antwort.

    In der ext-Localconf habe ich den Eintrag, dass die Action nicht gecachtet werden soll.

    Die Seite „news fe“ ist ein Ordner mit der Erweiterung „Meldung“

    Ja, ursprünglich wollte ich den Kommentar auch direkt auf der Seite von Klaus posten, leider bekam ich immer nur die Meldung

    Upps, es ist ein Fehler aufgetreten. Dein Kommentar konnte nicht gespeichert werden.

    Deswegen bin ich ich den Umweg über diese Seite gegangen. Ich hoffe das ist ok 🙂

    Viele Grüße

    Stephanie

     

    • Scheinst heute nicht alleine damit zu sein Stephanie https://www.facebook.com/groups/250938618364487/permalink/505307616260918/

      Falls Du noch kein Mitglied bist solltest Du der Gruppe unbedingt beitreten. Ich vermute die Ursache des Problems liegt an einem der jüngsten TYPO3 Sicherheitsupdates… gehe dem ganzen spätestens morgen mal auf den Grund…

      • Huhu,

         

        ja, allerdings konnte ich dieses Problem folgendermaßen lösen:

        $BE_USER = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\CMS\Core\Authentication\BackendUserAuthentication');
        $BE_USER->userTS_dontGetCached = 1;
        $BE_USER->OS = TYPO3_OS; 
        $BE_USER->start();
        $BE_USER->setBeUserByUid(1200);
        $BE_USER->backendSetUC();
        $BE_USER->fetchGroupData();
        
        $myBeUser = $BE_USER;
        

        1200 ist die ID eines dafür angelegten BE-users
        Dann beim Aufruf von start() den user mitgeben:

        $tce->start($data, array(), $myBeUser);
        

        Viele Grüße
        Stephanie

  • Hi Stephanie, hi Paul,
    die Kommentarfunktion auf meiner Seite sollte ich mir nochmal anschauen 😉

    Ich hab den Code für den FE Upload noch nicht unter der letzten TYPO Version getestet, aber gut, wenn man jetzt einen gültigen BE User braucht …. mmmh. Irgendwie bekommt man den sicherlich einfach gefaked als hier den ganzen User aufzubauen, aber die Intention stimmt ja dann sowieso nicht. Wenn ich einen Frontend upload mache sehe ich nicht ein dafür einen Backend User zu intialisieren.

    Für die Funktion führen ja viele Wege nach Rom, und wenn es damit zu kompliziert wird ….

    In der tt-address (die ja nicht unter 7 läuft, aber der Part sollte funktionieren) gibt es unter Classes/Updates/ImageToFileReference auch einen einfachen Weg das Ganze zu bewerkstelligen. Da werden die files und reference Einträge mit ner INSERT_query geschrieben. Man brauch keine eigenen File- und Filereference Models (und auch keinen Backenduser 🙂 ).

    Ob das Bild nun aus irgendeinem altem tt-address upload Folder kommt oder über ein Formular, das lässt sich ja einfach anpassen.
    Und dann direkt die ganze Funktion aus dem Controller rauswerfen und irgendwo unter Classes/Utility speichern und sich im Controller um die wichtigen Dinge des Lebens kümmern. Das ist ja schon fertig vorgebaut in der tt-address.

    Viele Grüße

    Klaus

  • Hallo Klaus,

     

    vielen Dank für die Antwort.

    Das werde ich mir gleich mal anschauen in der tt_address 🙂

    Viele Grüße

    Stephanie

  • Hm leider scheint das so mit dem exec_INSERTquery leider derzeit nicht zu funktionieren:

    PHP Warning: mysqli::real_escape_string() expects parameter 1 to be string, array given in /var/www/htdocs/typo3_src-6.2.19/typo3/sysext/core/Classes/Database/DatabaseConnection.php line 817

    Habe dazu auch dieses hier gefunden:

    https://forge.typo3.org/issues/61508

    Wobei das mit dem BE_User ja kein Problem mehr darstellte. Die ursprüngliche Version mit dem process_datamap lief ja aus irgendwelchen Chaching-Gründen nicht.
    Schade, es war so schön schlicht und kurz, aber ich werde wohl nicht drum ‚rum kommen, es mit dem PropertyMapper umzusetzen. 🙁

    Viele Grüße
    Stephanie

    • 
      
      $insertData = array(
         'uid_local' => $file->getUid(),
         'uid_foreign' => $newStorageUid,
         'tablenames' => $table,
         'fieldname' => $field,
         'pid' => $storagePid,
         'table_local' => 'sys_file',
         'tstamp' => time(),
         'crdate' => time()
      );
      
      
      $GLOBALS['TYPO3_DB']->exec_INSERTquery('sys_file_reference',$insertData);
      

      Funktioniert für mich einwandfrei.

  • Ooooh jaaaaa :>

    Danke!!! 😀

    Anscheinend hatte ich mich da irgendwo bei getDatabaseConnection() verzettelt.
    So läuft es!
    Vielen lieben Dank 🙂

  • Huhu,

    ich noch mal 😀
    Ja, also an sich schreibt er einen Eintrag in die sys_file_reference, so dass ich auch die Datei beim Content Element sehe. Allerdings fehlt ein Eintrag für l10n_diffsource, womit ich dann unter Dateiliste bei der Datei keine Referenz zum Content Element habe.

    Ist also irgendwie auch keine Lösung 🙁
    Keiner eine Idee, woran das beim datamap mit dem Caching liegen könnte?

    Liebe Grüße

    Stephanie

    • Probier mal das hier im Typoscript:

      plugin.tx_myext.persistence.updateReferenceIndex = 1
      • Leider keine Änderung.

        • Das tx_myext hast Du durch deine Extension ersetzt? Mal den gecache gelöscht und es nochmal probiert?

          • Ja, hab auch Object-Browser geschaut, dass er es auch gezogen hat.

            Also ging jetzt um die Version mit INSERTquery oder?
            (wobei hatte beides getestet)

          • Ja. Und wenn Du mal im Backend im Modul „DB Überprüfung“ -> „Globalen Referenz-Index prüfen und aktualisieren“ ausführst… findet er sie dann als referenziert?

          • Hm, ja also hab jetzt Referenzindex aktualisieren geklickt und neben jeder Menge anderen Kram hat erauch folgendes

            Record sys_file_reference:2520 had 1 added indexes and 0 deleted indexes

            und im BE seh ich unter Dateiliste jetzt auch die Referenz bei der Datei.
            In der DB steht bei ln10_diffsource allerdings immer noch nur eine leere Datei (braucht man die denn?)

            Und was sagt mir das jetzt? Kann ich das Aktualisieren des Refrenzindex in meiner Extension automatisch veranlassen? oder sollte man das lieber gar nicht machen?

          • Also an ln10_diffsource scheint es glaube ich nicht zu liegen. Das TYPO3 System bekommt die neue Referenz einfach nur nicht mit. Je nachdem wie wichtig das bei Dir ist gibt es glaube ich im Scheduler einen Task der in beliebigen Abständen den Referenzindex automatisch aktualisiert.

          • Uff, über den Scheduler ist ja irgendwie auch eine nicht ganz so schöne Lösung 😉

            Dennoch aber bis hier hin auch schon mal ganz vielen lieben Dank für Deine Mühe, Paul! 🙂

  • Hallo Stephanie,

    falls Dir das hilft, ich baue einen FE Upload morgen oder übermorgen in einer aktuellen TYPO3 Version ein und wir meine Lösung hier posten …

    Viele Grüße

    Klaus

    • Hallo Klaus,

      ja, das wäre natürlich fantastisch.
      Muss dann mal schauen, wie gut ich das übernehmen kann, da das bei mir alles nochmal auf der News aufsetzt.Aber Deine alte Anleitung hatte mir ja bisher schon super geholfen 🙂

      Viele Grüße

      Stephanie

  • Hallo Zusammen,

    also ich hab jetzt noch mal ein wenig herumgebastelt:

    Ich habe das (Teil-)Formular zum Upload der Dateien vom restlichen Formulat separiert. D.h. vom Hauptformular aus rufe ich per newAction erst das Unterformular auf einer neuen Seite auf. In der newAction habe ich dann die Geschichte mit  $tce->clear_cacheCmd(’system‘); gepackt.
    Somit ist der Cache bereits gelöscht, bevor das Formular zum Upload geladen wird und es funktioniert einwandfrei per process_datamap() ! Die sys_file_reference wird ordentlich geschrieben und Typo3 bekommt es auch mit 😉

    Leutz, ich bin so happy 😀

    Vielen lieben Dank an Eure Hilfe und Tips, nun kenn ich wenigstens auch INSERTquery und UPDATEquery ;D

    Viele liebe Grüße
    Stephanie

    P.S. @Klaus auf Deine überarbeitete Version bin ich dennoch neugierig 😉

  • Hallo Paul,

    vielen Dank für Deinen Beitrag, er war sehr hilfreich. Kannst Du mir sagen mit welchem Tool Du das Formular erstellt hast bzw. welches javascript bzw css du verwendet hast. Danke im Voraus.

    Gruß

    Alexander

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Highlighting von Codes ist mit den Tags  [ts], [php], [html], [javascript], [xml] oder [code] möglich.