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@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 database.
There are two major parts in the new logging system: LogEntry and LogFormatter. 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 IRC feeds.
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: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/author/nikerabbit
-Niklas
-- Niklas Laxström
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l