Da müsste jemand erst was programmieren
nicht so einfach wie es scheinen mag....
Mal davon abgesehen, das ich kein System kenne, das mir solche Informationen in komplexer und aussagekräftiger Form anbietet, wäre es ein nicht unerheblicher Aufwand. Nur mal ein paar Dinge, die mir da als Außenstehender einfallen:
- alles, was im Backend passiert (WB-Optionen verändert, Droplet umgebaut, eine kleine Seiteneinstellung geändert usw), müßte über den Core geloggt werden. Das bedeutet, du mußt so gut wie jede Datei einmal anfassen im /admin-Ordner und ggf auch im Ordner des Backend-Templates
- betrachte ich mir die Änderungen der letzten WB-Versionen, käme auch für solch Logging eine eher zentrale Lösung in Betracht, einfach gesagt, eine zentrale Funktion, die das eigentliche Logging übernimmt und die von den jeweiligen Aktionen mit Parametern getriggert wird. In diesem Fall würde in jeder Aktionsdatei ein oder zwei Einzeiler genügen.
- hat man das Grundkonzept, ist es für das Core-Paket zwar relativ umfangreich, aber im Grunde doch eher einfach zu lösen.
- bleiben die Addons - nicht minder komplex, wenn man dem Wunsch, ALLES zu loggen, nachkommen möchte. Bekanntermaßen waren wir mal bei über 1000 Addons, besser: Module. Mittlerweile sind es sicher ein paar mehr. Betrachtet man die Vergangenheit, war es nur in Einzelfällen möglich, Module komplett zu überarbeiten und selbst dort waren es i.d.R. oft nur Funktionskorrekture
n, weniger komplette Überarbeitungen. Ohne nun jemanden auf die Füße treten zu wollen, ich halte es für unrealistisch, das man nun plötzlich 1000 Module schaffen sollte.
- möchte man etwas aussagekräftiges, brauche ich eine komplette Historie. Nur als Beispiel: Wysiwyg als Einzelmodul auf einer Seite: Anlegen, Bearbeiten, Löschen. Beim Bearbeiten käme wohl hinzu: was wurde bearbeitet. Auf freiwillige Angaben wie z.b. Grund der Änderung - vom Ausführenden auszufüllen, sollte verzichtet werden, denn schreibt der nix oder was Falsches, ist die Information nutzlos, vielleicht sogar schädlich. Aus eigener Erfahrung weiß ich, das man auch "betriebsblind" wird, einen recht offensichtlichen Tippfehler habe ich z.b. 14 Jahre mitgeschleppt, dabei hab ich die seite mind 1x die Woche bearbeitet. Nun sagen wir, ich habe 20 Tipfehler korrigiert, möchte man dann jede Korrektur loggen oder nur eine Gesamtinfo? Irgendwo habe ich zwei Worte in Fettschrift gesetzt. Ist das ein Eintrag in die Logdatei wert? Wie gesagt, Wysiwyg, eines der einfachsten Module. Auf meinen privaten Seiten verwende ich eine Historie mit Preview, heißt: ich habe die letzten 10 Versionen in einer Datenbank, die jeweils älteste wird überschrieben. Das Grundprinzip von Wordpress, Information über Details meiner jeweiligen Änderung habe ich aber auch nicht.
Nehmen wir die Foldergallery. Jede Menge Möglichkeiten für Optionen. Ändere ich eine davon, brauche ich für eine aussagekräftige Notice im Log den Unterschied vorher vs nachher. Ich möchte den Bildausschnitt eines Thumbs ändern - ist das eine Info wert? Drei Bilder gelöscht - wäre einfach. Welche drei Bilder - wäre schon komplexer. Und so reiht sich Punkt für Punkt.
Über den AFE ließe sich der Code von Dateien ändern. Welche Info wäre da wichtig? Datei XY geändert? Datei XY in Zeile XXX geändert? Code ABC gegen Code DEF ersetzt?
Am Ende erhält man sehr umfangreiche Informationen, Daten, die man unmöglich bis ins Detail auswertet. Und selbst, wenn ich weiß, der Uwe hat es auf Seite XY verbockt, was mach ich mit dieser Info? Ihn auf die Finger klopfen? Rauswerfen? In erster Linie werde ich es erstmal korrigieren.
Mich selber interessieren solche Infos nicht, ich bin bis auf ganz wenige Ausnahmen der alleinige Bediener, auch bei den meisten Kunden. Und ich denke, so wird das in den meisten Fällen auch sein. Und das stellt dann die Frage nach Aufwand und Nutzen. Das es so komplex wie vom TE erwähnt benutzt wird, ist eher der Einzelfall und dann würde ich vielleicht nach anderen Lösungen suchen. Über Berechtigungen und Login-Zeitkontrolle bekäme man z.b. viele Informationen und ggf wäre es auch einfacher, das alles über ein Besuchsprotokoll zu lösen. Wer war wann wo? Das sagt mir zwar nichts darüber, was X und Y auf der Seite getan haben, schränkt aber den Kreis schon mal recht deutlich ein.
Noch ein Hinweis: das angesprochene Droplet Last_modifies_Pages liest die Seiten aus der pages-Tabelle, die zuletzt geändert wurden. Verwendet wird dazu ebenfalls eine zentrale Funktion, die aber auch erst mit einem zu übergebenen Parameter getriggert werden muß. Wurde der Parameter übergeben, erfolgt nach dem Save der Daten ein Update der Zeitangabe in der pages-Tabelle. Diesen Parameter ($update_when_modified = true;) übergeben, grob geschätzt, etwa 20 von 1000 Modulen, viellleicht auch 50, hab sie nie gezählt, aber viel mehr sind es eben nicht. Die Funktion selbst gibt es schon ewig in WB und auch die Einbindung ist super einfach, aber entweder die Autoren haben es nicht gewußt oder keinen Sinn in der Einbindung gesehen.
Bei einem Einzelmodul auf der Seite müßte man also schauen, ob der Parameter übergeben wird. Wenn nicht, erscheint die Seite auch nicht in der Übersicht der letzten Änderungen. Soll heißen: die >Daten in dieser Übersicht sind nur bedingt aussagekräftig.
Support WebsiteBaker
