The syntax highlighting applied to the XML format is not all that great,
and applying it to other formats is just wrong. Instead of doing it
ourselves, let's just add a hook and let Extension:SyntaxHighlight_GeSHi
do it for us.
But for that to work, we have to add RL support to the pretty-printed
output, which means OutputPage. At the same time, lets internationalize
the header.
Bug: 65403
Change-Id: I04b1a3842abdf1fb360c54aa7164fc7cd2e50f4b
The existing API help, formatted as basically a plain-text document
embedded in XML and with a little bolding and a few links
syntax-highlighted in after the fact, works ok for experienced programmers
but isn't at all newbie-friendly. Further, all the help is hard-coded in
English, which isn't very friendly to non-English speakers.
So let's rewrite it. The help text is now obtained from i18n messages
and output in HTML, with the default display consisting of help for a
single module with links to help for other modules. This, of course,
necessitates deprecating many of the existing help-related methods and
hooks and replacing them with new ones, but backwards compatibility is
maintained for almost everything.
At the same time, action=paraminfo also needs to support the
'description' and other help-related fields being output in wikitext or
HTML, and I11cb063d (to access all modules via the 'modules' parameter
instead of having 'modules', 'formatmodules', 'querymodules', and so on)
is folded in.
And we also add Special:ApiHelp. When directly accessed, it simply
redirects to api.php with appropriate parameters. But it's also
transcludable to allow up-to-date API help text to be included within
the on-wiki documentation.
Note this patch doesn't actually add i18n messages for any API modules
besides ApiMain and ApiHelp. That will come in a followup patch, but for
the moment the backwards-compatibility code handles them nicely.
While we're messing with the documentation, we may as well add the
"internal" flag requested in bug 62905 (although the 'includeinternal'
parameter it also requests doesn't make much sense anymore) and a
"deprecated" flag that's needed by several modules now.
Bug: 30936
Bug: 38126
Bug: 42343
Bug: 45641
Bug: 62905
Bug: 63211
Change-Id: Ib14c00df06d85c2f6364d83b2b10ce34c7f513cc
Since 926afc65c3, the transformation assumes < and > occur in pairs.
This assumption is invalid for formats such as JSON.
Implementing proper JSON syntax highlighting falls outside the scope
of this workaround and is left for separate changes, likely including
the addition of a hook. That is part of the API roadmap RfC.
https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap#Changes_to_pretty-printed_HTML_formats
Bug: 65403
Change-Id: Iff8d444c82f7efd2bd1c9f703defc4f0984e8211
* Group methods in ApiBase by function
* ApiBase::validateLimit and ApiBase::validateTimestamp are now
protected; there are no callers in any extensions in Gerrit
* Group methods in ApiQueryBase by function
* Move ApiFormatFeedWrapper out of ApiFormatBase.php
* Deprecate some methods in ApiQueryBase that seem useless and are
unused in core or any extensions in Gerrit
Change-Id: I32092f13906b6826d2137401724c21ccefa6f670
While it doesn't take a lot to maintain most of these, there is some
effort needed (e.g. wddx was breaking with HHVM). None have much if any
usage that seems likely to be actual code of some sort, and humans
should be able to read the jsonfm format as easily as dbgfm, dumpfm, or
txtfm.
Change-Id: I4e3d2ef59d4306756b289a4be46caef7d359ccef
- 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
This way we no longer need to disable size checking just for one operation
(enable|disable)SizeCheck functions were depricated.
Overall, this is a much better practice than disabling than re-enabling
the flag, as it might lead to accidentally forgetting to re-enable it,
just like the issue with the dangling file handlers, etc.
Example:
disable, do some complex logic, re-enable. And later, by accident,
the complex logic is changed to return a value half-way, or throws
an exception that gets handled as part of normal operations. This
results in the unsafe disabled state of the result object,
which is not good (tm).
Change-Id: I389a334d35f52f23a1847aca4aef5e96b262f589
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
ApiFormatFeedWrapper, for example, has nothing particularly useful to do
when given an API error to print. So allow for punting errors to the
default formatter instead.
Bug: 63150
Change-Id: Ifc034d4c7861905e382c42dc22585f0cd2beaf3f
list=logevents&leaction has param values with *, which gets bold, when
there was two of them in the same line.
Bug: 61834
Change-Id: Idace9afd4f3a2dce9be539b209a02fa318df8f45
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
Problem: on API documentation pages, lines delimited with asterisks
are automatically converted to bold. However, some lines aren't,
such as the one with the url in the main header of the root API page:
https://en.wikipedia.org/w/api.php
Not only this is breaks the standard formatting for module headers, etc,
but if the font used by the browser for monospaced text
doesn't preserve character width between bold and regular weight
(which it should), any layout structures will break.
Example: http://i.imgur.com/PVh6i.png
The regex that applies bold to the lines starting and ending in *
doesn't accept < and > inside the string,
but these are added by the url-formatting regex.
Simply changing the order of these operations fixes the issue.
Note: this change also removes the regex applying italics
to lines in the $ ... $ form, as suggested by Anomie and Yurik
in code review comments.
Change-Id: I7173f812bebb8a722fefdaa6cce9fcd554c82c84
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
- Bug 260 provides potentally relevant discussion
(also eventually settled in white-space:pre-wrap)
- Wrapping isn't applied in help pages, since they rely
on the monospaced font for layout purposes.
- Rename $isError to the more exact $isHelp
- Update documentation for ApiFormatBase::initPrinter()
- Bonus: header w/ info about output formats won't show
for action=help anymore (irrelevant)
Change-Id: Id9cdf102e17b4c3eaf4b10f3e3f5e97233911b97
This patch marks the regex matching url protocol as being case
insensitive. We will from now render links like [HTTP://ww].
Tests added.
Change-Id: I706acb7a0ae194b50d2318763beae4e5e83671f3
By default, set the x-frame-options header for api result pages
to 'DENY'. This is to prevent an attacker from iframing an api
page that includes tokens and stealing them from a user, for example
with a fake captcha prompt.
The global $wgApiFrameOptions is used for the value, or can be set
to false to disable setting the header.
Change-Id: I498f874d7f6c180ec4f3abfc81f773c0fa0f421d
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
The help message that appears at the top of pretty-printed
API results suggested to use format in uppercase (e.g. format=XML).
That wouldn't work, because format names are lowercase.
This change corrects the help message so that it correctly uses
lowercase (e.g. format=xml).
Change-Id: I94275879b60c42bde607eb896aa79433dfabb34c
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.
* Introduce a boolean parameter to wfUrlProtocols() which, if set to false, will cause '//' to be dropped from the returned regex so it doesn't match protocol-relative URLs
* Introduce wfUrlProtocolsWithoutProtRel() as a wrapper for wfUrlProtocols( false ). The latter should not be used directly because the former is much clearer
* Use this new function in Parser::doMagicLinks() to fix the original bug. Also use it in ApiFormatBase::formatHTML() and CodeCommentLinker::link(), which probably had similar bugs
