RFC: Encoding of log entry parameters, possible breaking change
Old log entry parameters were stored with integer keys. In the new
style, they are stored under keys such as "4::foo", which identifies
that the parameter is "foo" and should be "$4" when passed into
For core log entry types, we remap either of these to more normal
names. But for non-core types, we just output the given names
directly. This works fine for the old style, and still works for the
new style for most formats except for the part where clients now have
to check for both "4::foo" and "0". But bug 43221 points out that
format=xml winds up generating invalid XML, something like <item
At the moment, I'm leaning towards the following to fix this:
1. Numeric keys will continue to be output as-is, since there's really
nothing else we can do.
2. Keys like "4::foo" will be output as "foo".
3. Add a hook to allow extensions to override all of the above, like
we already do for core modules.
4. (probably) Patch WMF-deployed extensions that ever generated
old-style log entries to use the hook.
For new-style non-core log entries, and for types provided by
extensions that start taking advantage of the new hook, this will
break backwards compatibility but will result in the cleanest output.
Any comments or alternative suggestions?
Re: RFC: Encoding of log entry parameters, possible breaking change
I agree "4::foo" should be output as "foo".
Maybe if users are interested in parameter position they could be
available with an extra parameter requesting expansion, eg:
<rc type="log" ns="2" title="User:BradJorsch" rcid="544675367"
pageid="0" revid="0" old_revid="0" comment="Hello World">
Were the core parameters translated in previous versions of the api?