I came across people complaining that it was hard to associate
upload log events to actual images since img_timestamp could
be different from log_timestamp, and generally no unique id.
Well I was there I made uploads use the new logging system.
Change-Id: Icd8662ecb9eb0f6c0ff9841bdbd5736d6dd0d015
API was using SVN's version keyword which GIT does not support.
All related methods were either removed, or for those that
could have been used from extensions, emptied out.
api.php?version now shows unrecognized param warning.
Change-Id: I910ca1448ed2ed697ac19b17c486d130aa1d7e03
Fixed ApiQueryLogEvents::addLogParams for unknown (probably extension)
log types which use the new log format (with keys like 4:foo:paramname).
Until now such keys we're directly put into the XML output resulting
in invalid XML (see bug 43221, which will be fixed by this). To prevent
this we just remove everything except the plain parameter name and use that
as key for the output.
Change-Id: I1a3c7ac624eb575b879d068d47d3a13c9972b1a1
Follow up Ie188bc6f: Necessary changes to api for rights log changes
Getting for new style logs:
Notice: Undefined offset: 1 in \includes\api\ApiQueryLogEvents.php on
line 245
Notice: Undefined offset: 0 in \includes\api\ApiQueryLogEvents.php on
line 245
Added a legacy part as seen by patrol and move for the rights log action
Change-Id: I1d0bdfb483dba30572e8dcf8faac331a77eb04c6
There was a recentchanges row on enwiki whose rc_params looked like
array('4::tags'=>array('db-g11')), and the tag name wasn't set
recursively so the inner array didn't get a tag name.
This still generates invalid XML of course, because <4::tags> isn't a
valid tag, but at least it doesn't fatal any more. RAWR XML GRUMBLE
Change-Id: Ibb775df4bd010bdce5632914f789230d8626c9e7
Doing this in steps of roughly 100 changes per commit, so that it remains
reviewable. This should be the one but last change set with the "easy"
ones for core.
Change-Id: If894a92dd65b2f5f4f096b9133685eb3b067a1d8
Doxygen choke on text enclosed by '<' and '>' since it tries to
interpret them as HTML or XML elements. This patch adds double quotes
in includes/api/*.php files around the two following strings:
<Firstname>.<Lastname>@gmail.com
<Firstname><Lastname>@gmail.com
Which becomes:
"<Firstname>.<Lastname>@gmail.com"
"<Firstname><Lastname>@gmail.com"
Tested locally, it prevents doxygen 1.8.0 related warnings.
Change-Id: I36d82eb3fd4989ee3ffc65b0b527b83711d1ba69
Added information about the properties of the results of API calls
to action=paraminfo, including information about "property groups":
what should the prop parameter be set to to get that property.
Uses the same format for types as parameters already do.
The output format of some modules doesn't fit this, so the result
properties for them weren't added, or only partially.
Partially implemented modules:
* expandtemplates:
parsetree is in its own tag
* protect, allusers, backlinks, deletedrevs, info, imageinfo,
logevents, querypage, recentchanges, revisions, searchinfo,
usercontribs, userinfo, users, watchlist, upload:
response with partially complex structure
Not implemented modules:
* feedcontributions, feedwatchlist, opensearch, rds:
non-standard reponse
* help:
error is normal response; not very useful for automated tools anyway
* paraminfo, parse, pageprops, siteinfo, userrights:
response with complex structure
Change-Id: Iff2a9bef79f994e73eef3062b4dd5461bff968ab
We still get legacy log entries, so grab the data from parameters as applicable
Should probably be encapsulated into DatabaseLogEntry itself, with a getParamValue esk wrapper
This fixes issues noticed on live site for the moment
TODO: Check if rights/block are still ok (probably not?)
TODO: If (especially if above needs doing) encapsulate grabbing of old/new parameters to logging code
It's a parctice that dates back to 2006 when the API was first written, and frankly isn't covered by the coding conventions. Same thing with the docblocks, they're all copypasted with some bits changed and don't even make sense if you look at them in the genereated code docs.
I don't feel that any of us depend on this anymore (get a better IDE), so in the inerest of consistancy it's time we said goodbye to it.
Since all those used ApiQueryBase::addWhereRange, added ApiQueryBase::addTimestampWhereRange, which does automagic timestamp conversion. Not tested whether this actually fixes problems in Postgres, but at least the API modules are still functional in SQLite
* Move Block::parseExpiryInput() to the frontend SpecialBlock::parseExpiryInput()
* consolidate the several implementations of the MediaWiki:Ipblockoptions parsing into SpecialBlock::getSuggestedDurations()
