Part of the point of this, is to add a hook to allow extensions to add
their own metadata (I intend to create a companion extension to parse
Commons description pages - I5e6bc45f9751)
It's hoped that this would provide a simple system to get file metadata,
and would be able to return information on any wiki (even without any
extensions installed to provide additional information). So it could
fallback to exif data, if there's no better source of information for
the file available. It's also meant to be done in such a way that, in
the future, when Wikibase is deployed on Commons, it could be integrated
without too much fuss.
marktraceur changed this patch to be a little less heavy-handed: it will
now return unformatted data by default from the API, but there's also a
method for formatting that data in the way that bawolff originally
intended. I'm still trying to figure out if there's much use in that
method, but for now it's not particularly useful.
Change-Id: I77303d8e535fc1c42e14cfb853814e5c434a81ec
The iicontinue value needs to contain the dbkey, not the text version of
the title, as the dbkey version is what is being used for comparison
internally.
Bug: 51342
Change-Id: I88d99681fd601543c1d7c824c391ce272143c2e1
When iiurlheight is given without iiurlwidth, we want to limit the
thumbnail by just the height. MediaWiki's file classes don't really
support this, though, so we pass the image's full width as the limiting
width to achieve the same effect.
However, this fails for audio files where $file->getWidth() returns 0,
but we can still get a thumbnail of a placeholder image. In that
situation, we should just choose an arbitrary non-zero limiting width.
Change-Id: I4318a06a96265d39e39e90cc706d49a1c3b6e8e3
Wanting to get a thumbnail with only the height constrained is a
reasonable use case, the only reason we don't support it in the
API is because the backend doesn't support it directly. This is
easy enough to emulate by setting the width to the full width of
the image if only the height is specified. This makes the transform
function use a bounding box of size w x h, and if w is the width of
the original image that's equivalent to just bounding the height.
Change-Id: I28c7c22ee91669469cbd9e7d25f09100933582de
When preparing Id0ec6a0a, for some reason I thought the thumbnailing
only applied to the current revision. Fix that oversight.
Change-Id: I2e8aecc76a1190bac353a2b9855bc6a19ec06dec
Doxygen expects parameter types to come before the
parameter name in @param tags. Used a quick regex
to switch everything around where possible. This
only fixes cases where a primitve variable (or a
primitive followed by other types) is the variable
type. Other cases will need to be fixed manually.
Change-Id: Ic59fd20856eb0489d70f3469a56ebce0efb3db13
Apparently calls to File::transform can be slow. Add code to limit these
calls in prop=imageinfo.
The only effect for clients will be a possibility of seeing iicontinue
more often.
Once this is merged, TimedMediaHandler's ApiQueryVideoInfo.php should be
updated in the same way.
Change-Id: Id0ec6a0afb85ca73eefb5b8370c2147c37f037e9
Reviewing this code, I spotted a few issues:
* 'imagerepository' is added to non-images, and to images that were
skipped this round due to iicontinue. The latter is particularly
troublesome, as clients may wind up with an incorrect value when
merging continued results.
* Say two images are being queried, A.jpg and B.jpg. If the query needs
to be continued somewhere in the middle of A.jpg's old versions, but
then A.jpg is deleted before the client sends the continuation query,
it will start in the middle of B.jpg's old versions instead of at the
beginning of B.jpg's revisions.
* If the query needs to be continued somewhere in the middle of A.jpg's
old versions, but in the continuation query some other module that is
also being continued fills the result object, iicontinue will be
reset to the *beginning* of A.jpg's old versions instead of preserving
the position in the middle.
Change-Id: I08e2941010c7a70ff90b6244bfddd5ed0540fc9f
RepoGroup::singleton()->findFiles() returns an associative array mapping
the redirect *target* to the image object; the image object refers back
to the original title queried.
If a redirect and its target are both queried,
RepoGroup::singleton()->findFiles() will return an entry for the target
title only, mapping to an image object that may have getOriginalTitle()
returning the redirect. If this happens, prop=imageinfo will never see
an entry for which getOriginalTitle()->isRedirect() is false and so will
not return any information about the image.
The fix is to ignore getOriginalTitle() entirely. Instead, we just go
through each of our queried titles and see if we got any result back.
Note this automatically handles a "redirects=1" query correctly, since
in that case any local redirect will already have been followed before
we ever got the list of titles to query.
Change-Id: I0b2982901e2dc4491e2933291fd97697b2a622a9
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
* If a query module has 'continue' parameter, it will auto-report
that it has 'badcontinue' error.
* Added APIQueryBase::DieUsageContinueIf( $condition ) that shows
correct badcontinue error if $condition is true.
Change-Id: I9c48bda6de0cde3c117ad24460bddf6980279633
When looking only for local files, the localonly param skipped the
mabye expensive look up inside the file repos.
Change-Id: Ib8f38d6abf9238a349bbfd617a36933bdfe74b5c
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 MediaTransformOutput::getExtension() function and use it instead.
* Also fixed getScriptedTransform() to not pass the page as the path parameter.
Change-Id: I6c530aa155d62a6bfd5727c6f3d104fe91453745
A thumb is only generated when prop=url and a urlwidth is given. Adding
a hint to param description.
list=allpages does not have a urlwidth param and therefor cannot get the
thumbmime, adding thumbmime to the filter list to remove it from output
Change-Id: Ic1dbdb9b07f6325756058d6a0aa6ea148499fdfb
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
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.
