Page MenuHomePhabricator

Make log_params always serialized (write a maintenance script for old logging rows)
Open, LowPublic


Sometimes log_params isn't serialized. If keys aren't specified, I would think this would make it harder sometimes to tell at a glance what the data represents. If keys are specified, though, then one needs to extract the data using, e.g., substr().

Three examples I notice are changing visibility of revisions and log events; merging histories; and blocking users (for more details, see [[mw:Manual:Log actions]]).

When you change visibility of a revision, the raw text inserted into log_params is, e.g.:


Likewise, merging histories generates, e.g.:


Blocking a user is the same way; something like the following gets inserted:

3 days

Version: 1.24rc
Severity: normal



Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:53 AM
bzimport set Reference to bz70999.
bzimport added a subscriber: Unknown Object (MLST).

Is this a bug or a feature? Is it desired that sometimes log_params be easily human readable?

Its a historical thing.

Once upon a time, fields for log_params were separated by a newline. Then it got changed to being json blob (And possibly there's a couple php serialized blobs in there too, not sure). However not all log types got changed to the new format.

Anyone creating a new log type should use the json serialization. Old log types should be moved to use the the new json format for new entries. (And eventually when that is done, if someone is really board they could create a maintenance script to change old log entries.)

json? php serialized is the current format

(In reply to db from comment #3)

json? php serialized is the current format

Whoops, my mistake.

Also block log appears to use csv.

Suffice it to say, log_params is a bit of a mess.

Page protection events also insert into log_params unserialized content like this:

‎[edit=autoconfirmed] (indefinite)‎[move=autoconfirmed] (indefinite)

Following patches already exists:

  • gerrit 151683 - Migrate merge log to new log system
  • gerrit 151701 - Migrate import log to new log system
  • gerrit 152003 - Migrate block log to new log system
  • gerrit 152156 - Migrate protect log to new log system
  • gerrit 152161 - Use new log system when create log entry for revision delete

So in the grand scheme of things, I'm a rather new MediaWiki contributor so I'm not too knowledgeable on the older log types but over Wikimania I wrote a maintenance script with help from various seasoned folks to do that does this task for an older format used by one of ShoutWiki's custom extensions as part of the script.

If someone were to generate a list of older log types that are not currently serialized and perhaps links/screenshots of real examples of the parameters in use it would be very helpful as different logs have different parameters etc.

Krinkle removed a subscriber: Unknown Object (MLST).
Krinkle unsubscribed.

Reopening because I feel T26620 does not focus on the main point of this task. 26620 looks to have all the code updated to the current format so future things can be localised. It doesn't address the point of this task which is to write a script(s) to update the contents of current databases to the new storage format in the database.

Okay, when there should be a maintenance script to change old logs, than that is not a duplicate.

I see no point of changing the format of the old log rows, because MediaWiki can understand the old format and show old log records. It is just a problem when using the logging table direct on ToolLabs or the logging xml dump, which than also contains the old format, but I did not known if the serialized php is also deserialized for putting in the xml.

Aklapper subscribed.
Umherirrender renamed this task from log_params isn't always serialized to Make log_params always serialized (write a maintenance script for old logging rows).Sep 29 2015, 3:12 PM
Umherirrender unsubscribed.