Yay for log_params. I was thinking JSON would be appropriate here, so I'm
glat to see that.
I'll toss these revs onto my review queue.
Bugzilla from niklas.laxstrom(a)gmail.com wrote:
I just commited many changes to logging code. There is more to come,
but I think this is suitable place to write in more detail what is
going on. I'd also like to request code review and testing :)
Thus far I have committed new formatting code and small cleanups. Both
LogEventsList and RecentChanges are using the formatters now.
I haven't committed my last patch, which changes Title.php to generate
log entries using my new code. That will also fix page histories and
IRC feed, which use static version of log action text, which is
generated together when the new log item is inserted into the
There are two major parts in the new logging system: LogEntry and
LogEntry is a model around one log entry. It has multiple subclasses.
For constructing new log entries, you will create a new ManualLogEntry
and fill necessary info, after which you can call insert() and
publish(). If you are loading entries from database, you can simply
call DatabaseLogEntry::newFromRow( $row ). It supports rows both from
logging and recentchanges table. Usually you want to go directly to
LogFormatter and call newFromEntry or the hand newFromRow shortcut.
LogFormatter provides getActionText() method, which formats the log
action for you, taking those pesky LogPage::DELETED_FOO restrictions
into account. The action text includes the username, to support
different word orders. There is also getPlainActionText(), which
formats the log entry so that it is suitable for page histories and
LogEntries can have parameters. Parameters should be an associative
array. When saved to database, it is encoded to JSON. If you can pass
parameters directly to the message which is used to format the action
text, you can name the keys like "#:foobar", where # is a number and
should start from 4, because parameters 1, 2 and 3 are already
reserved and should be common to all log entries. Those are user name
link, username for gender and target page link respectively.
If they key is not in #:foobar format, it is not automatically
available for the action text message. By subclassing LogFormatter you
can do whatever you want with the parameters. Be aware of
$this->plaintext value though, it indicates whether we can use any
markup or just plaintext. This is how the MoveLogFormatter is
registered. I've added a type/* shortcut to avoid some repetition. If
the value is an existing class, it will be used. Otherwise the old
behavior of calling the function is used through LegacyLogFormatter.
$wgLogActionsHandlers = array(
// move, move_redir
'move/*' => 'MoveLogFormatter',
So what does this all bring to us?
* Flexible word order
* The most complex piece of log formatting is done only once, and it
also takes care of hiding any restricted items
* Gender is supported
* Ability to store parameters as an associative array
* New message naming conventions to reduce boilerplate
* Anonymous users can make log entries, that are actually shown
* Global logs should be easier to implement now, but it is not
directly supported by the current code.
* Two simple methods: getActionText and getPlainActionText, instead of
the mess of making log entries all over the place
* All code for one log type is now in single place, instead of lots of
switch $type in different places.
So once more, please text, review and comment. I still have lots to
do, all the log types need to be converted one by one to the new
system, to take the full benefit of improved i18n. Easiest way to find
the commits is probably this page:
Wikitech-l mailing list