The documentation page is on


We actually have a lot of tables that record the actions that occur on tw.
- tiki_actionlogs that records all the wiki updates/creations
- tiki_history that records the last wiki changes with the way to rollback(if there is no history cleaning tiki-actionlogs information is in tiki_history)
- tiki_stats that records view of all objects on a server daily basis

So a wiki page view will be recorded in one table, a wiki update in 3 tables
tiki_stats has the problem to record on a server day timing so that the information is only exact for users in the same timezone thatn the server. The advantage is the reduce the volume of the table.

- tiki_logs that register actions - mainly administrative actions. The table could have been extended to record wiki page updated .. even if the logmessage is not structurated and doesn't allow efficiebt search.


A site can want to record more type of actions on more objets. For instance, record the activity on a category as well than the activity of a user. The object can be a comment also...


To try to merge all these tables and to generalize them.

- tiki_actionlogs will be generalized to have the columns

  • date
  • who (username, categoryId)
  • whoType ('user', 'category')
  • ip
  • object (pageName, articleId, commentId....)
  • objectType ('wiki page', 'wiki comment', ...)
  • action ('Updated', 'Created', 'Removed', 'Viewed')
  • param

param is the delicate point as it can contain everything (update comment, Kb change...)

- the actions to be recorded will be defined in a special page

- the interface to sort the logs

- to simplify or merge the existing table (tiki-stats, tiki-history)


- do we create another table or use tiki_actionlog?
- do we merge tiki_logs?

Screenshots of tiki-admin_actionlog.php output

See them at:

Who is working on this