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.
Hope I did this in an ok fashion. svn merge --re-integrate was giving me issues
so I just essentially over-wrote my working copy with the version at img_metadata.
This treats metadata and similar properties to be deleted if the file is deleted, since they
are derived from the file, and i know examples of where the file was deleted to hide sensitive
data in exif. Does still show the file size if file is deleted, because that is what is done
in interface. Follows what ApiQueryLogEvents does and outputs userhidden="" if the user cannot
be displayed due to being hidden.
Due to this bug, all the secret oversight cabal info could be visible for images, so probably
should be merged into wmf stuff soon as possible.
Additionally, rename makeThumbParam back to getScale since that makes more sense now.
Also update the version number used in ForeignAPIRepo user-agent, since this is kind of significant change.
This adds a new parameter to the query=imageinfo (and query=stashimageinfo) that takes rendering
parameters other than width and height. This could be page for pdf's and DjVu, or thumbtime for ogg's, etc.
Syntax is &iiurlparam=param1=value1|param2=value2|... I'm not sure if that really fits with the normal way
of doing things in the api, but couldn't think of anything better since the parameters are arbitrary.
I also noticed that some of the pre-existing error codes in query=imageinfo seem to duplicate the module prefix. I'm
not sure what the deal with that is, but i did not follow that example in the new error codes i introduced.
Note: In order for this to work, both the foreign repo and the local wiki have to be running this code.
* Introduced a "cache mode" concept to simplify the header generation code, and to avoid odd results when conflicting cache header requests are received from submodules, or at least to formalise the handling of such cases.
* Made the cache mode private by default, so that code written in ignorance of caching tends to be safe. If different query modules are used in a single request, private caching is preferred over public caching.
* Removed the "must-revalidate" option from all CC headers, this is really specific to page views with a hacked squid in front, I don't think it's applicable here.
* Made the watchlist module private. This is really the definition of private data. There's nothing in the HTTP spec that says the URL for a CC:public request is private and can't be leaked. CC:private provides protection against unknown proxy behaviour.
* In ApiQueryAllmessages: avoid calling $wgLang->getCode() to check if it's necessary to make a new $wgLang when lang= is specified, since this is the only thing that unstubs $wgUser.
* Removed "FIXME: should this check $user instead of $wgUser?" Answer is no.
