Änderungen an der Mitgliederdatenbank registrieren

Um unsere Vereinsdatenbank mit der TL-Mitgliederdatenbank abgleichen zu können, wäre es sehr hilfreich, wenn es einen Mechanismus gäbe, über den Änderungen an der tl_member nachgehalten werden könnten.

Konkret suche ich nach einer Funktion, die eine Liste der Datensätze bereitstellt, die von einem Frontend-User über das Modul 'Persönliche Daten' in einem bestimmten Zeitraum geändert wurden.

Ich hatte gehofft, dass dafür das Feld tstamp in tl_member geeignet wäre. Doch leider spiegelt es offenbar nicht den Zeitpunkt der letzten Änderung wieder.

Ich ahne, dass man möglicherweise einen Hook oder Callback benutzen kann. Leider weiß ich nicht so recht, wie ich da vorgehen soll.

Oder gibt es eine einfachere Möglichkeit???

Callback ist der richtige Ansatz :)

...und eigentlich auch sehr schnell gemacht.

Du könntest auch den DCA-Erweitern und die letzte Änderung im BE gleich noch mit anzeigen als readonly-field :)

Welche Callback-Funktion meinst du?

Zitat:

---

Du könntest auch den DCA-Erweitern

---

Ich nehme an, du meinst, ich soll ein neues Datumsfeld in tl_member erstellen und im BE sichtbar machen.

Zitat:

---

Zitat von LutzWinkler

Ich nehme an, du meinst, ich soll ein neues Datumsfeld in tl_member erstellen und im BE sichtbar machen.

---

Richtig. Das ist noch einfacher als der Callback und hat eben auch den Vorteil, dass du dann im BE die letzte Modifikation auch einsehen kannst. :)

Aber ansonsten würde ich mit dem onsubmit_callback arbeiten.

Zitat:

---

Richtig. Das ist noch einfacher als der Callback und hat eben auch den Vorteil, dass du dann im BE die letzte Modifikation auch einsehen kannst

---

OK - da ich mich damit nicht so gut auskenne, würde ich Callbacks natürlich gerne vermeiden.
Aber: wie bekomme ich denn dann das aktuelle Änderungsdatum in das neue Feld???

Oh, nicht viel überlegt hab ich da :D

Denn ein readonly-Feld wird nicht mitgeschickt.

Du musst ohnehin mit einem Callback dahinter.
Wobei das die Anzeige im BE ja nicht ausschliesst, wenn du das auch noch möchtest :)

Tut mir leid! Beschreib einfach mal, was du machst. Ich kann dich dann in die richtige Richtung leiten :)

Eigentlich brauche ich in tl_member nur einen Eintrag, wann der Benutzer das letzte Mal seine Daten geändert hat.
Dann will ich über einen CronJob regelmässig eine SQL-Abfrage starten, die mir eine Liste der Benutzer schickt, die z.B. in der letzten Woche ihre Einträge geändert haben.
Deshalb bräuchte ich dafür auch kein Feld im BE.

Ich hatte gedacht, das Feld tstamp würde mir das letzte Änderungsdatum liefern - das war aber eine Fehlanzeige!

Die Frage ist nun: wie kann ich erreichen, dass bei einer Änderung der Benutzerdaten im FE (Modul 'Persönliche Daten') ein Timestamp in tl_member eingetragen wird?

Nein tstamp liefert dir nur das Erstellungsdatum.

Ach so, du willst die FE-Änderungen abfangen, nicht die BE :)

Hmm dann solltest eigentlich damit weiter kommen: https://contao.org/typolight-hooks.html#processFormData

Auch wenn die Lösung gegen alle Konventionen verstößt, hier ist eine Modifikation der ModulePersonalData.php (Zeile 219), die genau das macht, was ich brauche:

PHP-Code:

---

// Save field
$this->Database->prepare("UPDATE tl_member SET " . $field . "=? , tstamp=unix_timestamp(now()) WHERE id=?")
->execute($varSave, $this->User->id); 


---

Natürlich würde ich das gerne eleganter und vor allem updatesicher implementieren. Dafür bräuchte ich aber ein kleines Tutorial.

Nee, du brauchst kein Tutorial.

Du brauchst jemand der dir das programmiert, denn offensichtlich versuchst du bis jetzt gar nicht erst, meine Hinweise umzusetzen :)

Ich würde schon gerne lernen, wie man das selbst programmiert!

Es geht offenbar auch ohne Callback:

Im Modul 'Persönliche Daten' kann eine Weiterleitungsseite definiert werden.
In einem Textelement auf dieser Seite habe ich folgenden Text eingegeben:

Zitat:

---

Die Daten wurden geändert!{{file::userupdate.tpl}}

---

In userupdate.tpl steht dann die Routine zum Setzen eines Timestamps:

PHP-Code:

---

$this->Import('FrontendUser', 'User');
$this->Database->prepare("UPDATE tl_member SET lastchange=UNIX_TIMESTAMP(now()) WHERE id=?")
                             ->execute($this->User->id); 


---

In tl_member habe ich ein neues Feld lastchange definiert.

Trotzdem würde ich immer noch gerne lernen, wie man einen Callback realisiert.

Glaube ich dir gerne.

Aber es geht ja nicht mit einem Callback....
Dann fang mal an und teile uns mit, wo du hängen bleibst :)

OK:

1. Ich habe mit dem Extension-Creator ein Erweiterung 'UserUpdate' erstellt
2. In die Erweiterung habe ich ein Frontend-Modul 'userupdate' und die Frontend-Tabelle 'tl_member' eingefügt
3. Nach Erstellen der Erweiterung habe ich in \system\modules einen neuen Ordner 'user_update'
4. In dem Ordner befindet sich die Datei 'userupdate.php' und 2 weitere Ordner 'dca' und 'Config'
5. 'dca' ist bis auf .htaccess leer
6. In 'config' ist neben 'database.sql' die Datei 'config.php'

Das ist die config.php:

PHP-Code:

---

<?php if (!defined('TL_ROOT')) die('You can not access this file directly!');
$GLOBALS['TL_HOOKS']['processFormData'][] = array('userupdate', 'processFormData');
?>

---

und das die userupdate.php:

PHP-Code:

---

<?php if (!defined('TL_ROOT')) die('You can not access this file directly!');
class userupdate extends Module
{
    protected $strTemplate = '';
    protected function compile()
    {
        
    }

  public function processFormData($arrPost, $arrForm, $arrFiles)
  {
    msg("processFormData");
  }
  
  function msg($fehlertext){
  echo "<script type='text/javascript' language='javascript'>"; 
  echo " alert('".$fehlertext."');"; 
  echo "</script>";
  } 
}
?>

---

Die Function msg($fehlertext) ist nur zum Debuggen gedacht.
Nur leider ist sie noch nie aufgerufen worden!
Mir ist einfach nicht klar, wie meine Funktion processFormData so in TYPOlight eingebunden werden kann, dass sie bei Abschicken eines Formulars aufgerufen wird.
Eigentlich müsste meine Klasse UserUpdate doch das Frontend erweitern und nicht die Module??

Deine Debug-Funktion ist äh, sagen wir mal speziell :D

Mach mal sowas:

PHP-Code:

---

<?php if (!defined('TL_ROOT')) die('You can not access this file directly!');
class userupdate extends Frontend
{

  public function processFormData($arrPost, $arrForm, $arrFiles)
  {
      print_r($arrPost);
      print_r($arrForm);
      print_r($arrFiles);
  }
}
?>

---

Dann solltest du bei JEDEM Formular eine Ausgabe erhalten :)

Habe Deinen Code in userupdate.php eingegeben und meine oben beschriebene Weiterleitung wieder ausgebaut - nur leider passiert nichts, wenn ich im FE die Benutzerdaten speichere!

Inzwischen verstehe ich deine Bemerkung 'Aber es geht ja nicht mit einem Callback....'.
Ich hatte angenommen, processFormData sei ein Callback und kein Hook!

Naja...das Callback-Hook Dings ist so eine Sache :)
Im Grunde genommen wird bei einem Hook ja auch ein Callback ausgeführt, aber in der Terminologie von TL unterscheiden wir das :)

Nun gut. Ich hab's mir jetzt mal selbst kurz zusammengeschrieben.
Es scheint immer witziger zu werden :D

Das Modul "Persönliche Daten" läuft nicht gleich, wie die anderen Formulare. Wir können das mit dem Hook also gleich wieder vergessen.

Ich hab mir jetzt mal die ModulePersonalData.php angesehen. Leider sehe ich gerade nicht, wie wir das schlau lösen könnten.
Das Modul ist eine Art Mischung zwischen Backend und Frontend. Sprich, uns stehen da auch callbacks zur Verfügung. Leider aber kein onsubmit_callback, der das ganze Formular beinhalten würde.

Wir könnten es mit dem save_callback versuchen, aber ich bin jetzt an einem Punkt, wo ich auch einfach versuchen muss :)

Hab zum Testen des Hooks mal ein einfaches Formular mit nur einer 'Absenden'-Schaltfläche gebaut.
Beim Anklicken passiert auch nichts!

Doch, doch. Der Hook greift, wenn du alles richtig konfiguriert hast.

Dein Problem ist aber ein anderes, das sich wahrscheinlich so mehr oder weniger lösen lässt:

Mach ein Ordner "dca" und speichere das in der tl_member.php:

PHP-Code:

---

<?php

// palette ersetzen
$GLOBALS['TL_DCA']['tl_member']['palettes']['default'] = str_replace('gender;', 'gender,lastChange;', $GLOBALS['TL_DCA']['tl_member']['palettes']['default']);


$GLOBALS['TL_DCA']['tl_member']['fields']['lastChange'] = array
(
    'label'                   => &$GLOBALS['TL_LANG']['tl_member']['lastChange'],
    'exclude'                 => true,
    'flag'                    => 1,
    'inputType'               => 'text',
    'save_callback'              => array(array('userupdate', 'saveLastChange')),
    'eval'                    => array('maxlength'=>255, 'tl_class'=>'w50','rgxp'=>'datim')
);

?>

---

Dann die config/database.sql:

Code:

---

CREATE TABLE `tl_member` (
  `lastChange` int(10) unsigned NOT NULL default '0',
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

---

Und die userupdate.php im Modulordner:

PHP-Code:

---

class userupdate extends System
{
    public function saveLastChange($varValue, DataContainer $dc)
    {
        return time();
    }
} 


---

languages/de/tl_member.php:

PHP-Code:

---

$GLOBALS['TL_LANG']['tl_member']['lastChange'] = array('Letztes Änderungsdatum', 'Ändern Sie hier bitte nichts, das Datum wird automatisch gesetzt.'); 


---

Ergebnis: Ein DB-Feld, das im Frontend nicht sichtbar ist. Im Backend aber nach dem Geschlecht-Dropdown ein Feld mit der letzten Änderung hinzufügt.
Das Feld wird im sowohl im FE wie auch im BE bei jedem Speichern aktualisiert.
Leider kann man es im Backend nicht deaktivieren (grau hinterlegen), da sonst das Feld nicht abgeschickt wird.

Kannst du damit was anfangen?

Das sieht auf den 1. Blick gut aus...
nur liest die Routine immer nur die aktuelle Zeit.
Die Zeit wird nicht in tl_member.lastchange gespeichert!!

Hm?

Ja es wird immer die Zeit gespeichert, bei dem der Datensatz gerade gespeichert wird, das ist doch, was du haben wolltest?

Guck dir mal den Inhalt von lastchange in tl_member mit phpmyadmin an:
der steht bei mir immer auf 0!
Die Routine greift gar nicht auf die Datenbank zu sondern liest immer die gerade aktuelle Zeit aus.

Nönö, wie heisst denn dein DB-Feld?

lastchange

Wenn ich im BE auf speichern klicke, wird die Zeit in lastchange eingetragen - aber nicht im FE!

Und das war ja das Ausgangsszenario:
wenn ein User im FE seine persönlichen Daten ändert, soll der Änderungszeitpunkt in tl_member gespeichert werden, damit ich alle in einem bestimmten Zeitraum geänderte Datensätze herausfiltern kann.
Ein Anzeigen des Änderungszeitpunktes im BE ist eigentlich gar nicht erforderlich!

Nachtrag:
Ich habe in dca\tl_member.php folgende Änderung gemacht:

PHP-Code:

---

'exclude' => false, 


---

Das Feld wird trotzdem nur im FE und nicht im BE angezeigt - und erscheint auch nicht unter den editierbare Feldern im Modul 'persönliche Daten'.

Ich denke, wir sind nahe an der Lösung dran!

Ich habs absichtlich im FE versteckt. Ich dachte bei mir funktionierts, kanns morgen vielleicht noch einmal anschauen.

Dein DB-Feld ist auf jeden Fall falsch geschrieben, wie du siehst :)

Inzwischen habe ich noch ein wenig experimentiert und bin wieder ein Stück schlauer geworden!

Zu den DCA-Callbacks:

• onload_callback funktioniert mit FE+BE Formularen
• onsubmit_callback funktioniert nur mit BE Formularen
• load_callback + save_callback funktionieren überhaupt nicht

Zu den TYPOlight-Hooks:

• load_callback + save_callback funktionieren in FE+BE - aber nur, wenn das Feld sichtbar, editable und enabled ist

Ich habe jetzt die oben skizzierte Lösung mit der Weiterleitung des Formulars und Auswertung in einem eingebetteten Skript implementiert. Damit ist das Problem gelöst.

Ich danke dir Yanick, dass du dir den halben Sonntag Zeit genommen hast, um mir weiter zu helfen!

Bitte gerne :)

Wobei ich der Meinung bin, dass der save_callback zieht ;)