WebsiteBaker Community Forum
WebsiteBaker Support (2.12.x) => Modules => Topic started by: Riconico on October 09, 2019, 09:48:36 AM
-
Hi,
ich weiss die Überschrift ist etwas irreführent aber ich weiss nicht wie ich es sonst nennen soll.
Wir nutzen WB in der neusten Version als Community Software.
Da wir nun mehrere User sind die im Admin Bereich Rechte haben kommt es manchmal vor das es welche gibt die nicht immer wissen was sie da tun.
Daher suche ich eine Möglichkeit mir alle Aktionen der anderen Admins aufzeichnen zu lassen um bei ev. Fehler genau zu sehen was wurde als letztes gemacht.
Könnt Ihr mir sagen wie ich das am besten anstelle?
Gruss Riconico
-
Wir nutzen WB in der neusten Version als Community Software
Hi, wenn bei dir nicht WebsiteBaker steht, dann ist es nicht WebsiteBaker. :)
Da findest du aber auch ein Forum zu dem Fork.
-
Nutze WebsiteBaker
WB-Version
2.12.2 r379
-
Ein solches Toll ist mir nicht bekannt.
Aber im BE (BackEnd) ist oben rechts der jeweiligen "Seite" sichtbar, welcher USER die letze Änderung an einer Seite vorgenommen hat.
Da es diese Anzeige gibt, kann es vieleicht auch aus der DB (Danzenbank) über ein Tool ausgelesen werden, was sagen die Coder dazu?
Siehe Beispiel hier:
https://gyazo.com/01208aa9190a40551c818111f505d6e4
-
Es gibt ein Stück Code oder Droplet um sich die zuletzt geänderten Seiten anzeigen zu lassen.
Datum, Seite, wer hat geändert
Aber was geändert wurde würde nicht dabei stehen.
-
Es gibt ein Stück Code oder Droplet um sich die zuletzt geänderten Seiten anzeigen zu lassen.
Datum, Seite, wer hat geändert
Aber was geändert wurde würde nicht dabei stehen.
Wo würde ich dieses Droplet finden?
-
Heißt glaube "Last Modified Pages", die Suche bringt zB sowas:
https://forum.WebsiteBaker.org/index.php/topic,29312.msg205500.html#msg205500
Das angehängte Droplet kannst gern mal probieren.
-
Danke das ist doch schonmal was was mir viel mehr weiterhilft.
Würde es auch gehen sich anzeigen zu lassen wenn ein Admin oder Mod mit Berechtigung irgendwas am den Einstellungen oder der gleichen verändert hat?
-
Alles was in der Datenbank steht kann man sich anzeigen lassen.
Aber daran erkennst du keine Änderung, nur den aktuellen Stand. Da müsste jemand erst was programmieren wo der letzte Stand abgespeichert und mit dem aktuellen dann verglichen wird.
-
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.
-
also ich löse sowas außerhalb des CMS. Ich hab einen cronjob, der täglich einen Datenbank-Dump zieht.
Dann kann man innerhalb des cronjobs einen diff zwischen letztem und vorletztem Dump machen. Dabei bekommt man alle Änderungen (auch session-Einträge und so Krempel), also muss man das noch raus-filtern was man nicht sehen will und schileßlich die Ausgabe noch ein klein bisschen aufbereiten (vielleicht will man ja nicht unbedingt SQL Statements zugemailt bekommen, sondern "nur" die wesentlichen Schnipsel davon.
Diese "wesentlichen Schnipsel" die fische ich mir sukzessive raus, indem ich so einen Mechanismus erstmal rudimentär aufsetze und je nach dem, wie viel unnötiges Zeug da mitkommt, nach und nach das ganze weiter filtere.
-
Da wir nun mehrere User sind die im Admin Bereich Rechte haben kommt es manchmal vor das es welche gibt die nicht immer wissen was sie da tun.
Da liegt einer der wesentlichen Unterschiede zu einem Redaktions-/Bibliotheks-/Verlagsssystem, welches nach Abschnitten/Artikeln/Autoren Rechte vergibt, und wo Redaktion/Layouter etc. die Seiten bestimmen/verwalten. Es sieht auch nicht so aus, als wenn diesbezüglich Änderungen anständen.
MfG. Evaki
-
Mir scheint Martins Variante die "einfachste".
Das würde ich gern mal in Aktion sehen.
-
Mal davon abgesehen, das ich kein System kenne, das mir solche Informationen in komplexer und aussagekräftiger Form anbietet
Offtopic: Dann schau Dir mal das plugin "Simple History" von Pär Thernström für Wordpress an. Das protokolliert alles, inkl. Login/Logout, Seitenveränderungen inkl. Changelog, und vieles mehr. Wir benutzen das auch für einen größeren Nutzerkreis um auf dem Laufenden zu bleiben, wer, was, wo und wie verändert hat. Hilft hier nicht, deswegen Offtopic. (WB und die Forks sind trotzdem meine Lieblings-CMS!)
-
Dann schau Dir mal das plugin "Simple History" von Pär Thernström für Wordpress
Danke für den Tip (Y)
werd ich machen
Um bei WB zu bleiben: für die neueren oder umgebauten Module gilt ja schon die ungeschriebene Pflicht, das zu Datensätzen die Zusatzfelder modified_when, modified_by, created_when und created_by hinzu kommen. In meinen Modulen kommt dann noch published_when dazu, also der Zeitpunkt der geplanten Veröffentlichung. Solche Informationen hat ein Mini-Hero, Mini-Slider oder die alten Versionen aller mir bekannten Bildergalerien nicht.
Und ich denke, so insDetail geht auch Martins Variante nicht. Sie liefert "nur" den Status Quo zwischen Backup 1 und Backup 2. Was dazwischen passiert und vorallem, von wem eine Aktion ausgeführt wurde, wird da nicht zu erfahren sein.
Mal als übertriebenes Beispiel:
9.00 Uhr Montag = Cronjob-Zeit
9.10 Uhr - 20 Bilder im Ordner media/xy ersetzt
8.50 Uhr Dienstag - diese 20 Bilder wieder zurück getauscht
9.00 Uhr Dienstag - Cronjob-Zeit
Der Bildertausch erscheint nirgendwo. Man könnte ihn durch Analyse der access.log ableiten und vermuten
Ich denke, man sollte erstmal die Ziele definieren. Geht es darum, die Benutzer "beweiskräftig" zu überwachen, gibt es diese Möglichkeit nicht in der Form, die nötig sein müßte. Geht es weniger um Personen, mehr um Inhalte, ist Martin schon auf einem guten Weg.
-
Hallo,
Mir scheint Martins Variante die "einfachste".
Das würde ich gern mal in Aktion sehen.
Ehrlich gesagt habe ich in meinem Post zwei Ansätze, die ich für unterschiedliche Dinge einsetze, kombiniert.
In der Kombination habe ich es aber nicht live am Laufen, aber ein Skript, das aus der crontab heraus einmal am Tag aufgerufen wird, könnte in etwa so aussehen:
#!/bin/bash
# example for a cronjob to dump database and inform admin about relevant changes
#
# to make the cronjob run correctly and inform you about the output,
# make sure to set up the values for $SHELL, $MAILTO, and $PATH in the crontab
#
# make sure you have mysqldump installed and passwordless access configured
# for example by placing a .my.cnf file in the $HOME of the user who runs this script,
# adjust the values accordingly
#
# cat .my.cnf
# [client]
# host = localhost
# user = root
# password = y0ur_5up3r_secur3_passw0rd
#
# define a location for the dumps, protect this directory, e.g. via .htaccess
# or adjust the unix permissions such that the web server user can't go in
BACKUPDIR=$HOME/backups
# the database name
DATABASE_NAME=cms
TODAY=$(date +%Y-%m-%d)
cd $BACKUPDIR
mysqldump --databases $DATABASE_NAME > current.sql
# copy the current dump
cp -a current.sql ${DATABASE_NAME}-${TODAY}.sql
gzip ${DATABASE_NAME}-${TODAY}.sql
# in case the last.sql was not there, create an empty file
touch last.sql
# create the output and filter it - you might want to grep out some more noise.
# Maybe the IP address from where a user is logged in causes some trouble
# the sed is to make the output more human readable if you like...
diff -u0 last.sql current.sql \
| grep -v dbsessions \
| sed 's/^+/ADDED CONTENT:\n/;s/^-/REMOVED CONTENT:\n/;s/,/,\n/g'
# now move the current one to the last one
mv current.sql last.sql
# if you want to remove old snapshots you might want to keep a copy per month
# for the past year and one per year for the time even more back. You could do
# something like:
#
# MONTH=$(date +%Y-%m)
# cp -a ${DATABASE_NAME}-${TODAY}.sql.gz ${DATABASE_NAME}-${MONTH}.sql.gz
# find -maxdepth 1 -name ${DATABASE_NAME}-'*-*-*.sql.gz' -mtime +60 -delete
#
# cp -a ${DATABASE_NAME}-${TODAY}.sql.gz ${DATABASE_NAME}-${YEAR}.sql.gz
# YEAR=$(date +%Y)
# find -maxdepth 1 -name ${DATABASE_NAME}-'*-*.sql.gz' -mtime +400 -delete
#
der cronjob muss nicht unbedingt auf dem Host laufen, auf dem das Skript ausgeführt wird. Der Cronjob kann ja auch eine passwortfreie ssh-Verbindung zu dem Host aufmachen, auf dem das Skript läuft und dieses dort aufrufen. Der Output wird dann zurück geschickt und vom Cron-Daemon per Mail weitergeleitet.
Martin
-
ein wichtiger Hinweis noch zum passwortfreien Datenbankzugriff: Das my.cnf File stellt eine Möglichkeit dafür dar, aber es ist wichtig, dieses File für den Webserver nicht lesbar zu machen. Wenn das in dem Webspace nicht geht, dann muss man das Passwort aus dem cronjob heraus wie "interaktiv" eingeben. "expect" bietet sich dazu an, die Eingaben zu simulieren, als würden sie interaktiv erfolgen, auch innerhalb des cronjobs.
-
Da ich schon einen htaccess geschützten Ordner habe um mit PHP dumps und File-Backups zu machen, wäre eine PHP Variante zum Vergleichen auch interessant.Dein Script versuch ich aber erstmal.