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.
