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
* All content handlers that deal with code/data tend to have
English as their page language & pageview language, so moved common
code to the abstract CodeContentHandler class.
* Renamed JSONContent & JSONContentHandler into JsonContent*
Change-Id: I46819a0572ef5becc211d0d82471ff7102edaa3c
Hopefully this will stop cache pollution when a MessageContent
ends up in parser cache. MessageContent objects just do
wfMessage()->parse(), which uses user language.
Bug: 41065
Change-Id: I75e8256a61b828cb9fc93227eb517a34ac6b9d15
We need to be able to set a different content model via the
constructor, so make it an optional parameter.
Change-Id: I8b31084e0cfbcca1b3785176eac492d837e0cb0f
* Created a ResourceLoader module for redirect page styling.
* Fixed a couple of bugs in Article code.
Keeping two of the old files for a while because they might still be
referenced by something (bug 69277 comment 11).
Bug: 69277
Change-Id: I8fa565833545e41d0232101566da8c5ffa850e36
Currently the names of associated Content classes are hardcoded,
meaning that any extension that wishes to subclass these implementations
must also re-implement that function, usually copying it exactly
with just the class name changed. Using "static" avoids that issue.
For ContentHandlers, I added a TextContentHandler::getContentClass,
which should be used when creating new Content objects.
Change-Id: I70f1a3291aec3460120ec20121a23f4cb68e04d1
When the method has a type hint of Content, there is no way to pass a
string, so remove that type from @param
Change-Id: Ifbf89d52cfa3ea8801c94f2d1b336e784133cce9
- Added since to @deprecated
- Use lowercase array on @param
- Added missing type on @param
- Swapped type and variable on @param
- Fixed spelling of @return
Change-Id: Idbbc6b4c8aadb6d98c636f53024ac513346c912b
As was discussed at the architecture summit, a basic JSON content
class which handles validation and basic display. Not intended to
be used directly, but for extensions to subclass.
Co-Authored-By: addshore <addshorewiki@gmail.com>
Change-Id: Ifcde9bcd0efcf15a3ab692dd2a0a3038559e0254
Fixes for change to enable the creation of blank pages. Added test
for this case.
Follow up: I3457c36a909d1dbfaeed04a1f0568c69e0ef3386
Bug: 57238
Change-Id: Id52be6cbe22c6098d1c0824d7a7848579aa05a84
This change enables the direct creation of empty pages without needing
to use a work-around (such as "{{subst:ns:0}}"). A warning is added as
the message "blankarticle" to request confirmation that the empty page
was meant to be blank. A automatic edit summary has been added when
creating a blank page. The message is: "autosumm-newblank."
The API has been updated to permit the creation of empty pages, when
"text" is null, but not non-existant.
Unit tests have also been added to test these features.
Bug: 57238
Bug: 65206
Change-Id: I3457c36a909d1dbfaeed04a1f0568c69e0ef3386
- 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
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
ContentHandler::exportTransform() allows content handlers to apply
transformations upon export, such as conversion of legacy formats or
filtering of internal data.
Note that the transformation is applied to serialized content, since
the exporter will generally not unserialize the content blob to an
intermediate form before writing it to the dump. Implementations
may choose to unserialy, then transform and re-serialize.
Bug: 65256
Change-Id: Ic55a8bd8bea13041000b176c7c02c7c5ced76f6d
ContentHandler::importTransform allows ContentHandler
implementations to apply transformations on page content
upon import. Such transformatiosn may by useful to update
from legacy formats, apply ID rewriting, etc.
Note that the transformation is done on the serialized content.
This allows for a "raw" import implementation that writes
improted blobs directly into a blob store without unserializing
them into an intermediary representation. Implementations may
choose to unserialize, transform, and then re-serialize.
Bug: 65256
Change-Id: I290fdf5589af43def8b3eddb68b5e1c23f6124e8
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
That function was clearly a bad idea, everyone should just use
getHtml() instead. It was supposed to allow extensions to extend
the content formatting process, but actually doesn't.
A better hook-based solution follows in separate commit I979e2438.
Split off from original I979e2438 and rebased with minor changes
(updated documentation comments, etc.).
Co-Authored-By: daniel <daniel.kinzler@wikimedia.de>
Co-Authored-By: Bartosz Dziewoński <matma.rex@gmail.com>
Change-Id: I76412f9d28bb145fb5975f59e538f6560e50472f
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.
Change-Id: I64e8cfe478cb0ba438f40b0631d6e9049cdab567
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
There's no good reason for everything that wants to render a page to
have to test whether the page is a redirect and then call
Article::viewRedirect to get the fancy rendering instead of using the
ParserOutput. This logic can easily be moved into
WikitextContent::getParserOutput so callers can just use the
returned ParserOutput.
At the same time, we can handle "#REDIRECT [[File:Foo]]" and
"#REDIRECT [[Category:Foo]]" the way people expect, by recording the
link in pagelinks rather than imagelinks/categorylinks (although this
means fixing ImagePage's bug about assuming anything in imagelinks that
is a redirect is a redirect to the image too).
And we can finally fix bug 14323, too.
Bug: 14323
Bug: 17259
Bug: 27621
Bug: 42642
Bug: 50488
Change-Id: Id44d566a7ca35a1b9579d0c0e947877c980b0686
Followup: I1c7582d1bf7ec4184a45b00154e3dd5b39dd444b
Followup: I3653b608941813a73281f4f0545bea2487d43964
When importing, we need to check that the kind of content we are about to
import is actually allowed in the specified location on the local wiki.
This change does two things:
* Introduce the ContentModelCanBeUsedOn hook which provides control over
which kind of content can be used where.
* Introduce a check against ContentHandler::canBeUsedOn in the importer,
along with an appropriate error message.
Change-Id: Ia2ff0b0474f4727c9ebbba3c0a2a111495055f61
