It is the job of git and svn to provide this information/metadata.
The form was different, some with short, some with long month name
some with leading zero at the day, some without.
The year is also present in the Copyright clause
Change-Id: If006907b82b9e45f13cfa2e45d41107a95570e1a
- mostly auto fixes
- some too long lines fixed
- ignore amp space in one case passing by reference
Change-Id: I6472f83bc3cbf4bd629d83050cc3319b19ec465c
And auto-fix all errors.
The `<exclude-pattern>` stanzas are now included in the default ruleset
and don't need to be repeated.
Change-Id: I928af549dc88ac2c6cb82058f64c7c7f3111598a
Links generated by the API are now aware of the user's preferred
language and will show documents in that language if available.
To test, log in to mediawiki.org and set your language preference to 'es',
then on an MediaWiki installation with this patch view the generated
expanded API help at `api.php?action=help&recursivesubmodules=1&modules=main`.
Each link to documentation on mediawiki.org should take you to its
translated /es subpage, if one exists.
Bug: T104518
Change-Id: I339a1f3ae1bce9d759cf251899d57c32b1def91e
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I49e2a10350a328a8572fcedd44012751a29e1068
If iiprop=badfile is set, expose the wfIsBadImage() status as a boolean.
This is mainly intended for use by Parsoid, but could be useful for
other API users too. The context title can be set by using the
badfilecontextitle parameter.
Also be a little more paranoid and make sure wfIsBadImage() always
returns a boolean.
Bug: T148343
Change-Id: I3432ead92b8d2a17de5243285f2760fc39b501ae
API warnings and error messages are currently hard-coded English
strings. This patch changes that.
With a few exceptions, this patch should be compatible with non-updated
extensions:
* The change to ApiBase::$messageMap will blow up anything trying to
mess with it.
* The changes to the 'ApiCheckCanExecute' hook will cause a wrong
(probably unparsed) error message to be emitted for extensions not
already using an ApiMessage. Unless they're currently broken like
Wikibase.
Bug: T37074
Bug: T47843
Depends-On: Ia2b66b57cd4eaddc30b3ffdd7b97d6ca3e02d898
Depends-On: I2e1bb975bb0045476c03ebe6cdec00259bae22ec
Depends-On: I53987bf87c48f6c00deec17a8e957d24fcc3eaa6
Depends-On: Ibf93a459eb62d30f7c70d20e91ec9faeb80d10ed
Depends-On: I3cf889811f44a15935e454dd42f081164d4a098c
Depends-On: Ieae527de86735ddcba34724730e8730fb277b99b
Depends-On: I535344c29d51521147c2a26c341dae38cec3e931
Change-Id: Iae0e2ce3bd42dd4776a9779664086119ac188412
execute() references the static self::getInfo, which therefor cannot be
overriden by the subclass ApiQueryVideoInfo. Preferably, we'd fix the
implementation to not require this subclassing, but this will make
that transition easier. Use late static binding to make sure the
subclass implementation can be used.
Change-Id: Iab2d01abb9f9b3b799123d8ee344ea139e476576
wfSuppressWarnings() and wfRestoreWarnings() were split out into a
separate library. All usages in core were replaced with the new
functions, and the wf* global functions are marked as deprecated.
Additionally, some uses of @ were replaced due to composer's autoloader
being loaded even earlier.
Ie1234f8c12693408de9b94bf6f84480a90bd4f8e adds the library to
mediawiki/vendor.
Bug: T100923
Change-Id: I5c35079a0a656180852be0ae6b1262d40f6534c4
Nothing in this patch should result in changed output for format=json or
format=php except as noted in RELEASE-NOTES-1.25, and changed output for
format=xml should be similar or cosmetic. However, other code accessing
the result data directly may need to be updated.
Bug: T87053
Bug: T12887
Change-Id: I3500708965cb8869b5aed1543381aad208dadd13
ApiResult was a mess: some methods could only be used with an array
reference instead of manipulating the stored data, methods that had both
array-ref and internal-data versions had names that didn't at all
correspond, some methods that worked on an array reference were
annoyingly non-static, and then the whole mess with setIndexedTagName.
ApiFormatXml is also entirely annoying to deal with, as it liked to
throw exceptions if certain metadata wasn't provided that no other
formatter required. Its legacy also means we have this silly convention
of using empty-string rather than boolean true, annoying restrictions on
keys (leading to things that should be hashes being arrays of key-value
object instead), '*' used as a key all over the place, and so on.
So, changes here:
* ApiResult is no longer an ApiBase or a ContextSource.
* Wherever sensible, ApiResult provides a static method working on an
arrayref and a non-static method working on internal data.
* Metadata is now always added to ApiResult's internal data structure.
Formatters are responsible for stripping it if necessary. "raw mode"
is deprecated.
* New metadata to replace the '*' key, solve the array() => '[]' vs '{}'
question, and so on.
* New class for formatting warnings and errors using i18n messages, and
support for multiple errors and a more machine-readable format for
warnings. For the moment, though, the actual output will not be changing
yet (see T47843 for future plans).
* New formatversion parameter for format=json and format=php, to select
between BC mode and the modern output.
* In BC mode, booleans will be converted to empty-string presence style;
modules currently returning booleans will need to use
ApiResult::META_BC_BOOLS to preserve their current output.
Actual changes to the API modules' output (e.g. actually returning
booleans for the new formatversion) beyond the use of
ApiResult::setContentValue() are left for a future change.
Bug: T76728
Bug: T57371
Bug: T33629
Change-Id: I7b37295e8862b188d1f3b0cd07f66ac34629678f
There are cases where the list of values for a 'prop' parameter may be
manipulated by a subclass or by a hook function of some sort. Rather
than requiring the subclass/hook to completely replace a monolithic i18n
message, let's add the possibility of separate messages for each value
in the list.
Bug: T77930
Change-Id: I0bb061c62ebeef125062460e26306c88390f7b31
This also adds some new ApiBase::PARAM_* constants to generate more
helpful help, and a method to override the default description message
for the use of ApiDisabled and ApiQueryDisabled.
Bug: 71638
Change-Id: Ic0c3d232e0498d58a043037e2e0c6f0b1c3edad3
ApiPageSet::getAllTitlesByNamespace is fine when that's what you want.
But in all existing uses in core, it's not what's actually wanted.
* ApiQueryBacklinksprop can generate wrong ORDER BY because it considers
redirect and invalid titles that it doesn't acutally query.
* ApiQueryCategoryInfo raises a fatal error with category redirects.
* ApiQueryDuplicateFiles and ApiQueryImageInfo will add information for
redirects, leaving them missing the standard data and missing from
indexpageids.
What all these need is really something along the lines of
"ApiPageSet::getGoodAndMissingTitlesByNamespace". So let's add that,
plus a few similar methods for good measure.
Bug: 71337
Change-Id: I3a205057edcbc303393718e1c8bfb1f1b1f95323
If the file has a duration (e.g. an audio or video file), include
it in the list of dimensions returned. Do not include anything
for still media (normal pictures).
This affects both query=imageinfo and TMH's query=videoinfo.
Bug: 55941
Change-Id: If172a1cbaca08bff2eb709f6c829985b28b0200d
Some file types might not have a specific width/height. As an
example, TimedMediaHandler can specify thumbnails that are
"mid" sized instead of specific width. The requirement for
iiurlwidth was breaking some edge cases with ForeignAPIRepo
and TimedMediaHandler (Specificly with ?embedplayer=yes).
Do not require a width, but also verify that thumbnail parameters
are ok by running through normaliseParams (Formats that require
a width make this function return false if none is specified).
Change-Id: I8bb4c26db56c814ddfbd3e53ca98d05378c2a0bd
The format for 'props' was never specified and the list for 'errors' is
impossible to keep updated when considering that many errors come from
MediaWiki backend code and extension hook functions. And since there
doesn't seem to be any real use case for either of these, let's just
kill both of them instead of wasting effort on trying to fix them.
Note that neither getResultProperties nor getPossibleErrors are called
from any extensions in gerrit, and none of the other deprecated methods
are called outside of the implementations of those two methods. Removing
the obsolete methods is left to the maintainers of the extensions, as
keeping them hurts nothing and is needed to maintain compatibility with
earlier versions of MediaWiki.
Change-Id: Ie11a401d60c834059fbf1b5625ca8ea093b3337c
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: I7b65fe04db431342cc58b469dc48f41a50c4e891
Which type is used depends on the ApiModuleManager responsible for
the API module. There are two managers, one in ApiMain and one in
ApiQuery. Both contain a list of API modules they instantiate.
Both use $this as the first parameter in the constructors of the
individual modules. There is no other regular way to instantiate the
modules, so we know the type must either be ApiMain or ApiQuery.
The lists don't intersect.
I would have prefered the naming scheme $mainModule for ApiMain
modules and $queryModule for ApiQuery modules but since this
doesn't add much I left the shorter variable names untouched.
Change-Id: Ie6bf19150f1c9b619655a06a8e051412665e54db
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Also added some missing @param.
Change-Id: I758fa4ad80ac95e2ddd3770bcb9b7d2e57ec34ea
* ApiQueryDeletedrevs, ApiQueryFilearchive, ApiQueryRecentChanges, and
ApiQueryWatchlist will now return entires where fields have been
revision-deleted. "Hidden" indicators will be provided as appropriate.
* ApiQueryImageInfo, ApiQueryLogEvents, ApiQueryRevisions,
ApiQueryContributions will now return field values in addition to the
"hidden" indicators when the requesting user has the necessary rights.
* Modules that return "hidden" indicators will now also return a
"suppressed" indicator.
* ApiQueryImageInfo will now return info for DELETED_FILE file revisions
if the requesting user has the 'deletedtext' right.
* ApiQueryLogEvents, when searching by user or title, will now return
entries where the user or action are revision-deleted if the
requesting user has the 'deletedhistory' right.
* ApiQueryContributions now uses the correct user rights rather than
'hideuser' to determine when to show contributions where the username
was revision-deleted.
* ApiQueryContributions will now indicate when the revision text is
hidden.
* Fix a bug in ApiQueryDeletedrevs found during testing where specifying
the "content" prop along with the "tags" prop or "drtag" parameter
would cause an SQL error.
* Fix various PHP warnings in ApiQueryFilearchive caused by the lack of
ArchivedFile::selectFields() fields.
* ApiQueryImageInfo::getInfo's $metadataOpts parameter has been renamed
$opts, and now may have an option to indicate the user to use for
RevDel visibility checks.
* ApiQueryWatchlist now properly uses the actual user's rights for
checking whether wlprop=patrol is allowed, rather than using the
wlowner's rights.
Bug: 27747
Bug: 27748
Bug: 28261
Bug: 34926
Bug: 48966
Change-Id: Idec2199976f460e1c73a26d0717e9fc4ab8042bb
With recent changes to the filerepo backends, prop=imageinfo will now
return information for the target file when file redirects are queried.
To make this more transparent to clients, add an iiprop to return the
canonical title for the imageinfo data.
Change-Id: I62e368ffe09512f1af6677994f1ccca776b97651
Requesting iiprop=extmetadata can return a *lot* of meta data, when the
client may only be interested in certain keys. This adds a
"iiextmetadatafilter" parameter to allow the client to indicate which
keys it cares about.
Change-Id: Ie2185ec285e40359fffab4932bff8cab16071a53
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.
