Found by applying etsy/phan to the mediawiki codebase, in preparation
for getting it running more regularly via CI. Has no effect on how the
code runs, simply does a better job of documenting the code.
Change-Id: I4c844a51df3ffe4fbb96cac25f3eff2f7a9faca2
The prepareSave function expects the latest revision ID of the article
being replaced. Instead, we were passing an ID only used for rollbacks
and other special effects.
Change-Id: I4647930566b9370052a820ae3a46e10a6bba65ce
This is a hard deprecation, with getSecondaryDataUpdates returning an
empty array and addSecondaryDataUpdate throwing an exception. This seems
prudent since there are no known users of these methods, and they
interfere with the parser cache:
DataUpdates are basically jobs, they need access to services to
function. That makes them inherently non-serializable. This interferes
with the function of the parser cache, which serializes ParserOutput
objects in order to persist them.
This could be solved by splitting DataUpdates into DataUpdateDefinitions
and DataUpdateHandlers, similar to how JobSpecification works with
wgJobClasses. That however seems pointless and overkill, since
ParserOutput already has a mechanism for storing arbitrary data,
including any info needed by an UpdateJob: the setExtensionData method.
After this change, the preferred method to introduce custom data updates
is to store any relevant data using setExtensionData and
implement Content::getSecondaryDataUpdates() if possible. If not,
use the 'SecondaryDataUpdates' hook to construct the necessary update
objects from the info stored using setExtensionData.
Change-Id: I0f6f49e61fa3d8904e55f42c99f342a3dc357495
This hook is the counterpart of ContentGetParserOutput: it gives
high-level access to the parsing of a content object (as opposed
to lower-level parser hooks like ParserBefore*/ParserAfter* which
are called for all kinds of non-content input like interface
messages and don't have the necessary context to know what kind of
input is being parsed), but it is called when the parsing has
already finished.
The intention is to provide a convenient location for ParserOutput
modifications which depend on some global property of the parsed
content, but need to happen before LinksUpdate. Currently there are
no hooks between parsing (initiated by WikiPage::doEditUpdates()
calling WikiPage::prepareContentForEdit()) and updating the link
tables (initiated by the same method calling
Content::getSecondaryDataUpdates()), so any hook an extension would
try to use would face one of the following problems:
* the parsing output is not available yet
* LinksUpdate has run already, modifying list properties is unsafe
* there is not enough context to tell what's being parsed
A typical use of this hook would be to add tracking categories when
something is missing from the text (e.g. there are no references).
For the concrete use case, see I43ed79b6a54cd31820ecae8139e29c5880f5dd1b
Alternative approaches that have been suggested and do not require
a new hook but are not robust / do not rely on a clear contract:
* use ParserAfterTidy or a similar hook, assume that the input
being parsed is the main page content iff limit reporting is
enabled
* use ParserAfterTidy or a similar hook, assume that the input
being parsed is the main page content iff
ParserOptions::getInterfaceMessage() is false (this would yield
some false positives, but in those cases adding a tracking
category would probably have no effect)
Change-Id: I685b285fcc772382993116f7822a832eeecc0681
Since Id44d566a, the text passed to the parser when parsing a
&redirect=no page no longer contains the #REDIRECT directive. For the
benefit of extensions that want to know the redirect target from various
parser hooks, record the target on the ParserOptions object associated
with the parse.
Bug: 62856
Change-Id: Icd1da9911a43eabacbd9e9a369a8326f67f270ff
There are so many slightly different understandings of what a
"section" is or can be. I'm aware the documentation was improved
just a few weeks ago. I still find it incomplete and confusing.
1. I renamed it to $sectionId to make it more clear what it
really is.
2. Sections are usually numbers. 0, 1 and so on. There is no
reason to disallow the use of ints or even floats (this works
because the string representation of 0.0 is "0"). The code never
disallowed numbers.
3. 'T1' never was supported, as far as I can tell. 'T-1' is
supported. See Parser::extractSections().
4. null and false and '' all mean "the whole page" in
WikiPage::replaceSectionAtRev() but for some reason this meaning got
lost in WikitextContent::replaceSection(). I made it the same again.
Change-Id: Icc3997722d2ed742bf7703cd7c06d09199225720
This hooks allows extensions to override the normal model-specific
rendering of page content. A typical use would be to provide syntax
highlighting for pages that contain scripts. In that sense,
ContentGetParserOutput is a generalization of the old ShowRawCssJs
hook.
This, together with I76412f9d, is a (hopefully) fixed version of the
reverted Ibfb2cbefea44.
Change-Id: I979e2438689648ba4c959d8083197ef14ce524e8
When pages are loaded in the edit box via preload, allow parameter
substitution. The interface-style $1 is used rather than the
template-style {{{1}}} to avoid conflicts with preloads that add template
parameters. Syntax is:
action=edit&preload=Foo&preloadparams[]=first&preloadparams[]=second
Bug: 12853
Change-Id: If02cf4b3dba9f9d22a956d8bfff224677cbce00d
Reasons for touching this are:
* "@param type $var" were mixed in a lot of places. Both works but the
MediaWiki coding conventions suggest that specific order.
* Things like String and Bool aren't objects and shouldn't be uppercase.
* Tried to fill missing types in "@param $var".
* Tried to fill missing descriptions in "@return type" when I could.
* Removed duplicate descriptions if a @see is sufficend.
* Removed useless descriptions ("isUsefull returns true if usefull").
* Removed useless @return void.
* Replaces mixed[] with array (does have the exact same meaning).
* Tried to find better replacements for "varargs", phpDocumentor
suggest $var,...
* Order should be @since, @param, @throws, @return, @see. This is the
order Doxygen renders this.
There is always more to do but I think this is already much better
than before. Please feel free to put more change sets on top of mine
or request more changes by adding comments.
Change-Id: I05262ce06caabf79f68772302524ac91bbead1c6
This change removed getHtml(), but not the call to it from fillParserOutput.
It has a few other issues that I'll flag in-line after deploying the revert.
This reverts commit fda090a7e7
Bug: 49398
Change-Id: Idcef8d4cedc7c03f72bc1743e0f89cc5ed4ad7a7
This hooks allows extensions to override the normal model-specific rendering
of page content. A typical use would be to provide syntax highlighting for
pages that contain scripts. In that sense, ContentGetParserOutput is a
generalization of the old ShowRawCssJs hook.
Change-Id: Ibfb2cbefea44eeee9f2a027f47e7721bf177ba0f
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
Added/removed spaces around logical/arithmetic operator
Reduced multiple empty lines to one empty line
Removed wrong tabs before comments at end of line
Removed too many spaces in assigments
Change-Id: I2bba4e72f9b5f88c53324d7b70e6042f1aad8f6b
Added/removed spaces after opening/before closing parentheses
Added a space after a comma
Removed unneeded parentheses in condition
Change-Id: I306091347ccaaf11dee0cdfda3019cb0c12be51b
This is needed to fix bug 41706 and similar, watch for follow-ups.
Automatic, implicit conversion may be handy in several cases, especially
for converting between different text based content models. E.g. it should
be possible to create a diff between a JavaScript and a wikitext page. This
change lais the foundations for this ability.
Change-Id: Ie7d87b67b24ac9897cb5696220a7785b228d3c79
* @licence -> @license
* Protects inline HTML by using double quotes, our inline comments uses
elements such as <h1> or <firstnameLastname@gmail.com>
* Commands in lowercase (@TODO -> @todo, @NOTE -> @note)
* removes @abstract and @static since doxygen detects them from PHP
code.
* various undocumented function parameters
* typos in parameters declarations
Change-Id: I62ad6fc124c355bf31acc780b9614a59cf79a421
